Wednesday, January 22, 2020

vRAN, cRAN, ORAN... whats going on with the Telco Radio Network?

I have been doing more than a dozen due diligence engagements in the virtualized, cloud and disaggregated RAN market space in the last 2 months.

As much as many telco clouds implementation have been somewhat disappointing, due to the inability of the industry to force the traditional telecommunications vendors to adopt an open orchestration model, the Radio Access Networks (RAN) have been undergoing a similar transformation with a different outcome.

Based on the same premises that market pressures have forced telecommunications traditional vendors to oligopolistic consolidations, some operators have been trying to open up RAN value chain by forcing the implementation of a disaggregated model.
Specifically, separating hardware from software and deploying radio solutions on commercial-off-the-shelf (COTS) hardware and virtualizing software logical elements such as Radio Remote Units (RRU)  and Base Band Units (BBU).
The RAN is the last part of the network that sees heavy proprietary implementation, from hardware to software to professional services, and most contracts tend to be for key-in-hand study, implementation, installation and maintenance where margins are fairly opaque. This is the bread and butter of traditional telco vendors.

The idea is that if you force all vendors to move to software and you can source COTS hardware, you gain CAPEX cost efficiency (COTS is cheaper than proprietary) and if you virtualize all the software, you gain OPEX cost efficiency (you can ideally software -manage everything, which leads to on demand use and cost, as well as vendor independance if the interfaces are open).
Predictably, just like in the case of telco clouds, traditional vendors hesitated cannibalizing a multi billion annual revenue. Unlike in telco cloud, though, a number of operators (BT, Deutsche Telekom, Telefonica, Vodafone...) elected to show how serious they were about RAN cost optimization and decided to approach a number of emerging vendors.
These vendors, unlike traditional telco vendors provide an array of innovative solutions, that are usually cloud-native (software defined, virtualized, hardware agnostic) and are eager to attack the incumbents market.
In order to show a clear market commitment, Telefonica and Vodafone released two years ago and last year a public tender within Facebook's TIP summit. This process is remarkable in the telco space in the fact that the list of invited companies (any company part of TIP), the content of the RFI and the ranking of the participating vendors were publicly announced.

The results ranked the vendors along their performance, openness and time to market readiness. The sponsoring operators committed to clear timeframe for lab trials, field trials and commercial deployments.
The tender showed that an ecosystem of innovative vendors was capable to emerge and complement the current value chain with adapted solutions.
Generally speaking these emerging companies do not have to manage the legacy of hundreds of obsolete product releases, which allows them to have a much faster development cycle. This is important because in many case, they do not have the product depth of their more mature competition (2G, 3G, 4G, 5G, small, mini, macro cells). On the other hand they also often lack the operational maturity to manage a RAN deployment at scale for a tier one operator.

Cloud RAN (cRAN), Virtualized RAN (vRAN) and Open RAN (O RAN) are all concepts that have emerged in the last few years to describe this emerging ecosystem. While most operators would rather continue purchasing from their traditional vendors, to reduce operational and financial risks, the race to 5G and the pressure on margins and operators stock prices is forcing them to reevaluate the RAN value chain.
Open, open source and disaggregation are trendy topics in telco, but they come with a steep learning curve as they force those who want to follow this path to actually change their operating model if they want to extract the most value.
The market needs the emergence of a new category of open source distributors, a Red Hat of telco open source if you will, as well as a new category of systems integrators that can take the effort of assembling these new vendors categories into coherent solutions and services that traditional telco will want to purchase.

Hit me up if you want more details on that market space, I am preparing a workshop and report on this.






Wednesday, January 8, 2020

Open or open source?

For those who know me, you know that I have been a firm supporter of openness by design for a long time. It is important not to conflate openness and open source when it comes to telco strategy, though.

Most network operators believe that any iteration of their network elements must be fully interoperable within their internal ecosystem (their network) and their external ecosystem (other telco networks). This is fundamentally what allows any phone user to roam and use any mobile networks around the planet.
This need for interoperability has reinforced the importance of standards such as ETSI and 3GPP and forums such as GSMA over the last 20 years. This interoperability by design has led to the creation of rigid interfaces, protocols and datagrams that preside over how network elements should integrate and interface in a telco and IP network.
While this model has worked well for the purpose of creating a unified global aggregation of networks with 3G/4G, departing from the fragmentation of 2G (GSM, CDMA, TDMA, AMPS...), it has also somewhat slowed down and stifled the pace of innovation for network functions.

The last few years have seen an explosion of innovation in networks, stemming from the emergence of data centers, clouds, SDN and virtualization. The benefits have been incredible, ranging from departing from proprietary hardware dependency, increased multi tenancy, resource elasticity, traffic programmability, automation and ultimately the atomization of network functions into microservices. This allowed the creation of higher level network abstractions without the need for low level programming or coding (for more on this, read anything ever written by the excellent Simon Wardley). These benefits have been systematically developed and enjoyed by those companies that needed to scale their networks the fastest: the webscalers.

In the process, as the technologies underlying these new networks passed from prototype, to product, to service, to microservice, they have become commoditized. Many of these technologies, once close to maturity, have been open sourced, allowing a community of similarly interested developers to flourish and develop new products and services.

Telecom operators were inspired by this movement and decided that they needed as well to evolve their networks to something more akin to an elastic cloud in order to decorrelate traffic growth from cost. Unfortunately, the desire for interoperability and the lack of engineering development resources led operators to try to influence and drive the development of a telco open source ecosystem without really participating in it. NFV (Networks function Virtualization) and telco Openstack are good examples of great ideas with poor results.Let's examine why:

NFV was an attempt to separate hardware from software, and stimulate a new ecosystem of vendors to develop telco functions in a more digital fashion. Unfortunately, the design of NFV was a quasi literal transposition of appliance functions, with little influence from SDN or micro service architecture. More importantly, it relied on an orchestration function that was going to become the "app store" of the network. This orchestrator, to be really vendor agnostic would have to be fully interoperable with all vendors adhering to the standard and preferably expose open interfaces to allow interchangeability of the network functions, and orchestrator vendors. In practice, none of the traditional telecom equipment manufacturers had plans to integrate with a third party orchestrators and would try to deploy their own as a condition for deploying their network functions. Correctly identifying the strategic risk, the community of operators started two competing open source projects: Open Source Mano (OSM) and Open Network Automation Platform (ONAP).
Without entering into the technical details, both projects suffered at varying degree from a cardinal sin. Open source development is not a spectator sport. You do not create an ecosystem or a community of developer. You do not demand contribution, you earn it. The only way open source projects are successful is if their main sponsors actively contribute (code, not diagrams or specs) and if the code goes into production and its benefits are easily illustrated. In both cases, most operators have opted on relying heavily on third party to develop what they envisioned, with insufficient real life experience to ensure the results were up to the task. Only those who roll their sleeves and develop really benefit from the projects.

Openstack was, in comparison, already a successful ecosystem and open source development forum when telco operators tried to bend it to their purpose. It had been deployed in many industries, ranging from banking, insurances, transportation, manufacturing, etc... and had a large developer community. Operators thought that piggybacking on this community would accelerate development and of an OpenStack suited for telco operation. The first efforts were to introduce traditional telco requirements (high availability, geo redundancy, granular scalability...) into a model that was fundamentally a best effort IT cloud infrastructure management. As I wrote 6 years ago, OpenStack at that stage was ill-suited for the telco environment. And it remained so. Operators resisted hiring engineers and coding sufficient functions into OpenStack to make it telco grade, instead relying on their traditional telco vendors to do the heavy lifting for them.

The lessons here are simple.
If you want to build a network that is open by design, to ensure vendor independence, you need to manage the control layer yourself. In all likeliness, tring to specify it and asking others to build it for you will fail if you've never built one before yourself.
Open source can be a good starting point, if you want to iterate and learn fast, prototype and test, get smart enough to know what is mature, what can should be bought, what should be developed and where is differential value. Don't expect open source to be a means for others to do your labour. The only way you get more out of open source than you put in is a long term investment with real contribution, not just guidance and governance.