This article was stimulated from a weekend conversation where I realized the historical context for service innovation in carriers is being overlooked; and the history of programmable communications in telecoms is being rewritten.

Through the ‘90s

When I first joined BT Labs I worked on OEICs (Opto-Electronic Integrated Circuits), after previously working on HEMT (High Electron Mobility Transistor) and CCD (Charge Coupled Device) characterization as a student. It was fun, academically tough, and experimentally challenging. However, I could see the writing on the wall for Research within carriers as Project Sovereign took its toll on people who had dedicated their life to particular areas of study, e.g. subsea fiber amplifiers, coherent optics, materials science. 

I moved to the Video group, working on compatible coding of different video resolutions within the same stream. We see the fruits of that work in MPEG, WebRTC, video streaming, and collaboration. We built a VoD demonstration over DSL (Digital Subscriber Loop), with that project I understood the role of the Labs was to show what was possible, hacking innovation, and acting as a nudge to the vendors by showing what was possible. It wasn’t research, nor development for production, rather development for understanding through hacking.

From there I moved to broadband access, building more demonstrations, VDSL bricks, long distance PON ranging (100km), and FSAN that became the global standard for GPON. I remember the political battles in standards over trying to create an ANI, Access Network Interface. The vendors seriously did not like that. Carriers increasingly did not have the resources to drive standards, the vendors were taking control of the process. 

I remember being asked by a vendor in a standards meeting, ‘what do your customers want?’, and embarrassingly realizing I was so far removed from the end customer, I’d never be able to answer with authority. The end customer wasn’t really part of the process. Today carriers’ roles in standards is one tenth of this period. Standards are controlled by the vendors. Standards must be used carefully, they can make things inflexible, slow, and not customer focused. Which is sort of OK with 10 year network time frames. But the lack of customer focus in 5G is clear.

Carriers need their network vendors to help them bring network innovations to market, and operate them efficiently. It’s a team effort, and it’s delivered for decades as DSL, PON, IP core, and the ‘Gs were rolled out. Note telcos copied the service innovation of internet access from early ISPs.

Through the ‘00s and ‘10s

I popped over the vendor side and discovered a political battlefield, where the managers did not understand the technologies. At BT I’d always expected the managers to understand the technologies, they were mostly engineers. In the vendors they’d hire a big name management consultant firm and use the misinformation on the web to create a nice story for an organizational power-play or funding battle.

On the core products: switches, routers, fixed and mobile access networks, there were teams with an amazing breadth, depth, and history. But they were also entrenched, to survive they had to remain the technology experts for those revenues streams. Their strengths made technology shifts difficult, as we see in the dogged following of the ‘Gs today, while the market showed 4G is good enough.

The shift to software in telecoms was now happening, first softswitches, which was not happening within the network vendors, rather from outside and being bought in. VoIP and APIs were on the rise in part due to open source, and new categories of enterprise service providers offering what was once traditionally the carrier domain. But carriers were playing a role in innovation as well. I was a customer of AT&T CallVantage, a VoIP service. I shocked so many telecom executives who did not believe in VoIP with the conversation we were having was: a) VoIP working reliably over the internet, and b) AT&T was doing it. Today the analog PSTN is being switched off by 2025 for BT.

Web 2.0 was getting into the swing of things and APIs (machine readable web pages) were showing potential from the likes of Salesforce, eBay and Amazon. And again carriers were there in the early days as well, BT’s API trial in the UK had developers initially impressed. Open source was now making it easy for the carriers’ Labs to get in an have a go. Then there was BT’s Ribbit acquisition, a political bun fight, and the project became a line item on the CFO’s spreadsheet, hence collapse. 

Over the past 20 years the challenge has been: innovative projects kick off, e.g. BT’s APIs and AT&T CallVantage; but before the formula on how a carrier operates and makes money is discovered, its profile is raised too high, corporate antibodies get involved, and things go south. It’s cyclical. Carriers were active on APIs before Twilio, then as carriers saw the success of Twilio they had more goes.

But they were up until recently unable to copy Twilio’s success. They’re not a technology company, and because of that they are not developer-centric. Their network vendors lack the knowledge and experience in programmable communications, and through this period closed down their standardized Parlay gateways. Telcos need programmable communication partners, not network equipment partners.

Into the ‘20s

Imagine deciding to standardize ChatGPT because it shows promise, rather than letting it evolve in the market…

The argument for the standardization of telecom APIs is that carriers need a common API, so they can cooperate in a common approach to achieve global scale. We’ve been here before with OneAPI 1.0 and RCS. RCS is a common standard that did not deliver global scale across carriers, well, not until Google implemented its version of RCS.

Carriers should be working with aggregators and programmable communication partners, not their network vendors. But that does not mean programmable communications has failed to launch in carriers. Through the pandemic we’ve seen some carriers refocus on wholesale services (SMS and Voice APIs), particularly in the Middle East and Asia, copying the success of local aggregators like Unifonic, Cequens, and the global aggregators like Infobip, Syniverse, etc.

The carriers control pricing within their countries of operation so can undercut the aggregators. Also automation technologies are now available thanks to open source projects like Jambonz. The carriers do not chase developers, rather target large B2B deals, e.g. Facebook, Google, and Twilio. They’ll even implement the interface Google wants, again more evidence against CAMARA. For enterprise communication services from programmable communications companies like RingCentral, carriers successfully partner with them for large enterprise accounts. Carriers are being successful in programmable communications through a focused non-standards-led approach with partners.

With CAMARA (OneAPI 2.0), because the lead is coming from the network equipment vendors there is a network focus, such as multi-access edge compute, QoS, and network slicing. We can look at the fixed broadband experience to show us how customers care about carrier cloud compute (many carriers have closed down their cloud business), QoS (remember the turbo button?), and application aware networking (is used by enterprises use today). 

CAMARA is really a standardized interface to the aggregators, not developers. Which is a mostly solved problem. Remember a standard makes everything inflexible, slow, and not customer focused.

CAMARA addresses only part of the problem. It’s not just the technical interface, it’s the business, operations (compliance) and people that must be considered. Aggregators employ carrier relations people to manage the real-world complexity and difficulty of working with carriers.

For carriers to be successful in programmable communications, they need to partner with aggregators and programmable communication companies, they’ll help find the opportunities and manage the people, process, and technology issues to avoid a repeat of OneAPI 1.0, RCS and likely OneAPI 2.0 (CAMARA).

Network equipment vendors are the right partners for network innovation with carriers, however, after several decades is clear for programmable communications, they are not the right partners. They walked away from their standardized Parlay gateways while Twilio, Syniverse, Infobip, Vonage, MITTO, RingCentral, Telesign etc. built the programmable communications / aggregation business.

Partner with the experts in programmable communications, and given the maturity of some open source projects, consider building it yourself and target large accounts in your countries of operations. The targets are always moving thanks to technology evolution, particularly thanks to open source. However, large organizations do tend to be more set in their ways. The pre-occupation on API standards given decades of history is absolute proof.