OK, let’s face facts. The whole of telecom standards is broken, and something radical is needed to fix it. You only have to read the story of 5G, and reflect on past initiatives like frame relay and ATM, or the IPsphere concept, or Network Function Virtualization (NFV) to see how badly the industry is served by telecom standards. But we’ve been stuck in the process for decades, and that demonstrates how difficult it is to change things there. Do we know what needs to change, what barriers there are to change, and how to overcome them? All of these are a big “maybe” at this point.
We’ve all heard jokes about meetings and consensus. “A mule is a horse designed by committee”, or “The IQ of any group is equal to that of the dumbest member divided by the number of members.” Wry humor aside, there’s an element of truth in this. One problem with telecom is that you need broad consensus for something to be accepted, and achieving that consensus is inevitably a matter of compromise. How do you avoid compromising too much, giving away the essential value of what you’re working on?
Telecom standards are created by two distinct groups who often have polar opposite needs. One group is the telcos, who are at least usually on the same page at the high level. This group is primarily concerned with controlling the cost the standard might expose them to, and in practical terms that is often focused on avoiding the displacement of gear that, in the telecom world, is often written down over a very long period. The other group is the telecom vendors, and this group is usually at each other’s throats in rabid competition for spending that may be under threat overall, and may be further impacted (higher or lower) by the standard.
My own experience with standards bodies, going back to the 1970s, has led me to believe that the starting point in standards problems, and therefore the first target for solutions, is the nature of the telecom people working on them. Most telcos have a formal group under the CTO who participate in standards. This is good in the sense that they bring a sense of order to the process, which might otherwise get pretty chaotic. It’s bad in the sense that these people rarely have much exposure to the demand side of telecom, and so can’t bring a picture of future market need to the table.
I remember one memorable early meeting, where I saw the agenda for the day was “Who are we?” This sure sounded more existential than useful to me, but the leader explained that when a report said “We believe…” or something similar, there was a need to be explicit on who “we” were. We spent a full day on that.
I think that a telco standards team should be made up of equal numbers of standards people and marketing/sales staff people. The former organize, the latter set the mandatory demand-side focus by introducing market factors and ensuring that the process continually addresses them. This division should be reflected in the nature of the agenda and the structure of the document. An early section needs to address the specific new revenues that the standard is to facilitate.
My experience also says that vendors in a standards process are inevitably disruptive. Not all of them, but enough to taint the whole process. I can honestly say that I have never participated in a standards process that wasn’t eventually contaminated by vendors who sought their own advantage even at the expense of doing something optimal in a total-market sense. The biggest problem always comes from incumbents, who reason that given they’re winning under the current paradigm, any paradigm shift is bad for them.
The IPsphere Forum actually found a way to address this that, for quite a while, worked. What they did was to establish a “service provider council” whose meetings were for operators only, with others allowed to speak at one only by invitation. The SPC laid out the framework for something, and only after that was done, and staying at all times consistent with it, was a broader group that included vendors formed to address the concept and turn it into a real model.
The next issue I saw, and that needs addressing, is a notion that consensus means unanimity. Going into the process, there must be a realization that a single individual/company or even a small group cannot block something the majority favors. It’s fine to say that you need more than a simple majority, but whatever you decide has to agree, you must allow members of the group to call for a vote to end discussion and move forward. This is critical not only at plenary sessions, but in working group meetings as well. Regular votes on points is smart so it doesn’t look like you’re only doing it to shut out dissent, though that’s necessary in any group meeting.
The last issue is simple; rate of progress. Standards groups don’t meet often enough to make significant progress even in a year. If F2F meetings more regularly is a burden, everyone is used to online virtual meetings at this point. Every telecom standard takes years to mature, and there’s no way that even the best futurists can hope to anticipate needs too far into the future. We are working on 6G, for example, with an expected early availability of 2030. Who can possibly know what conditions will prevail then?
OK, the issue is simple, but the solution may not be. Neither classic telco supply-side planning nor the yet-unrealized vision of demand-side planning seems likely to generate a five-year window of visibility, which is why I think that the efforts have to focus on getting results quicker. The telco interest in a 6G model that’s software-only, or at least primarily software, is in effect a mechanism that could speed up development of a deployable version of a new standard. Why bother if you’re waiting five years to even offer a final version to deploy? In any event, if we really want to start to focus on software (which I think we should), then a primary step that could be taken as a kind of “5G Advanced Next Gen” would be to frame 5G implementation as a set of generic devices rather than as special-function boxes.
One thing that has hurt almost every standards initiative in the telecom space is a tendency to encapsulate logical elements of functionality into boxes on a diagram, which then tends to get them implemented as discrete devices. How far might application software progressed if we did that in application design? We’d still be reading punched cards or paper tape. Even little steps in an outdated process need to be modernized, lest they anchor us in a past we can no longer live with.
