The 5G letdown

 I have often written about what I think are the necessary steps for network operators to grow and prosper in our digital world. Covid, the changes in work modes, the hiring gluttony of the GAFAs, the geopolitical situation, between the banning of untrusted vendors and the consequences of a European conflicts have created quite a different situation today. 

Twitter or X reorganization and mass layoffs signaled the tech industry that it was ok to look for productivity and profitability and that over-hiring without a clear mission or reorienting companies entire strategies on far fetched, unproven concepts (web3, metaverse, crypto...) had very costly consequences. Fast forward to this summer of 2023, most GAFAs have been refocusing their efforts into their core business, with less intent on changing the telecoms landscape. This lull has allowed many network operators to post healthy growth and profits, while simultaneously laying off / fast tracking early retirement for some of their least adequately skilled personnel.

I think that a lot of these positive telco results are conjunctural, rather than structural and one crucial issue remains for operators (and their suppliers). 5G is a bust. So far.

The consumer market is not really looking for more speed at this time. The main selling proposition of 5G seems to have a 5G logo on your phone. I have 4G and 5G phones and I can't really tell the difference from a network user experience standpoint. 

No real 5G use case has emerged to justify the hype, and all in all, consumers are more likely to fork out 1000s of $ for a new device, rather than an additional 10 per month for a "better" connectivity. Especially since, us, telco literati know that 5G Non Stand Alone, is not really 5G, more like a 4G +. Until 5G Stand Alone emerges dominantly, the promises of 5G wont be fulfilled.  

The promise and business case of 5G was supposed to revolve around new connectivity services. Until now, essentially, whether you have a smartphone, a tablet, a laptop, a connected car, an industrial robot and whether you are a working from home or road warrior professional, all connectivity products are really the same. The only variable are the price and coverage.

5G was supposed to offer connectivity products that could be adapted to different device types, verticals and industries, geographies, vehicles, drones,... The 5G business case hinges on enterprises, verticals and government adoption and willingness to pay for enhanced connectivity services. By and large, this hasn't happened yet. There are several reasons for this, the main one being that to enable these, a network overall is necessary.

First, a service-based architecture is necessary, comprising 5G Stand Alone, Telco cloud and Multi-Access Edge Computing (MEC), Service Management and Orchestration are necessary. Then, cloud-native RAN, either cloud RAN or Open RAN (but particularly the RAN Intelligent Controllers - RICs)  would be useful. All this "plumbing" to enable end to end slicing, which in turn will create the capabilities to serve distinct and configurable connectivity products.

But that's not all... A second issue is that although it is accepted wisdom that slicing will create connectivity products that enterprises and governments will be ready to pay for, there is little evidence of it today. One of the key differentiators of the "real" 5G and slicing will be deterministic speed and latency. While most actors of the market are ready to recognize that in principle a controllable latency would be valuable, no one really knows the incremental value of going from variable best effort to deterministic 100, 10 or 5 millisecond latency.

The last hurdle, is the realization by network operators that Mercedes, Wallmart, 3M, Airbus... have a better understanding of their connectivity needs than any carrier and that they have skilled people able to design networks and connectivity services in WAN, cloud, private and cellular networks. All they need is access and a platform with APIs. A means to discover, reserve, design connectivity services on the operator's network will be necessary and the successful operators will understand that their network skillset might be useful for consumers and small / medium enterprises, but less so for large verticals, government and companies.

My Telco Cloud + Edge Computing and Open RAN workshops examine the technologies, use cases, implementations, strategies, operators and vendors who underlie the key growth factors for telco operators' and vendors' success in the "real" 5G.

Open RAN technical priorities release 3

The Open RAN technical priorities release 3, was published in March 2023 by Deutsche Telekom, Orange, Telefonica, TIM and Vodafone as part of the Open RAN MoU group at the Telecom Infra Project.

A review of the mandatory, highest priority unanimous requirements shed lights on what the big 5 operators consider essential for vendors to focus on this year, and more importantly highlights how much efforts are still necessary by the industry to meet markets expectations.

Scenarios

In this section, the big 5 regard virtualized DU and CU with open Front Haul on site as a must, for Macro and indoor / outdoor small cell deployments. This indicates that 7.2.x remains the interface of choice, despite recent attempts by other vendors to change its implementation. It also shows that as a first step, at least, they are looking at deploying Open RAN in the conventional fashion, replacing traditional e/g Node  B with like-for-like O-RU, DU. CU on site. The benefits of resource pooling due to disaggregation and virtualization, enabling either CU or CU and DU to be centralized is the highest priority by the majority of operators, but not all yet. Network sharing of O-RU and vDU/CU is also a highest priority for the majority of operators.

Security

The security requirements have increased dramatically in this latest version, with the vast majority of the requirements (166 out of 180) considered highest priority by al the MoU operators. This evolution marks the effort that have been dedicated to the topic over the last 24 months. Open RAN has been openly criticized and accused of lax security and the O-RAN alliance has dedicated a working group to assess and shore up criticism in that space. My assessment is that most of the security concerns of Open RAN are either linked to virtualization / O-Cloud implementation or just mechanically a result of having more open interfaces, providing more attack surfaces. Open RAN is not inherently more or less secure than 3GPP implementation and the level of security by design necessary to satisfy the criticisms we have seen in the media is not today implemented by traditional RAN vendors either. Having said that, the requirements now spell out exhaustively the level of admission control, authentication, encryption, certification necessary for each interface, for each infrastructure block and for their implementation in a cloud native containerized environment.

O-Cloud Infrastructure (CaaS)

The O-Cloud requirements are focused on ensuring a cloud-native architecture, while allowing acceleration hardware whenever necessary. As a result, the accent is put on bare metal or IaaS implementations of Kubernetes, with FPGA, eAsic, GPU acceleration support and management. The second theme that is prevalent in O-Cloud unanimous high priority requirements is the lifecycle management features which indicate a transition from the lab to more mature commercial implementations going forward.

CU and DU requirements

First and foremost the big 5 unanimously are looking at virtualized and containerized implementations of O-CU/O-DU with both look-aside and inline acceleration (this is contradictory, but I assume either one is acceptable). The next requirements are the usual availability, scalability, and performance related requirements we find in generic legacy RAN systems. All O-RAN interfaces support are mandatory.

Interestingly, power consumption targets are now spelled out per scenario.

RU requirements

The Radio Units requirements area good illustration of the difficulty to create a commercially viable Open RAN solution at scale. While all operators claim highest urgent priority for a variety of Radio Units with different form factors (2T2R, 2T4R, 4T4R, 8T8R, 32T32R, 64T64R) in a variety of bands (B1, B3, B7, B8, B20, B28B, B32B/B75B, B40, B78...) and with multi band requirements (B28B+B20+B8, B3+B1, B3+B1+B7), there is no unanimity on ANY of these. This leads vendors trying to find which configurations could satisfy enough volume to make the investments profitable in a quandary. There are hidden dependencies that are not spelled out in the requirements and this is where we see the limits of the TIP exercise. Operators cannot really at this stage select 2 or 3 new RU vendors for an open RAN deployment, which means that, in principle, they need vendors to support most, if not all of the bands and configurations they need to deploy in their respective network. Since each network is different, it is extremely difficult for a vendor to define the minimum product line up that is necessary to satisfy most of the demand. As a result, the projections for volume are low, which makes the vendors only focus on the most popular configurations. While everyone needs 4T4R or 32T32R in n78 band, having 5 vendor providing options for these configurations, with none delivering B40 or B32/B75 makes it impossible for operators to select a single vendor and for vendors to aggregate sufficient volume to create a profitable business case for open RAN.

The other RU related requirements helpfully spell out the power consumption, volume and weight targets for each type of configuration.

Open Front Haul requirements

There are no changes in the release 3, which shows the maturity of the interface implementation.

RAN features

The RAN features of the highest priority unanimously required by the big 5 operators remain mostly unchanged and emphasize the need for multi connectivity. Dual connectivity between 4G and 5G is essential for any western european operator to contemplate mass deployment of open RAN or replacement of their Chinese RAN vendor. The complexity does not stop to the support of the connectivity, but also necessitate advanced features such as Dynamic Spectrum Sharing (DSS) and Carrier Aggregation (CA) which is a complexity multiplier when associated with the RU band support requirements. These advanced features are probably some of the highest barriers to entry for new vendors in the space, as they have been developed for years by traditional vendors and require a high level of technological maturity and industrialization.

Near-RT RIC

The requirements for the Near-Real Time RAN Intelligent Controller are extremely ambitious. While they technically would enable better control of a multi-vendor RAN operation, they are unlikely to succeed in the short to medium term, in my opinion, as per previous analysis.

SMO and Non-RT RIC

The requirements for Service Management and Orchestration and Non-Real Time RIC are fairly mature and provide a useful framework for RAN domain automation and lifecycle management. The accent in this release is put on AI/ML support and management, which shows that the operators have been seduced by the promises of the technology, allowing a zero touch, automated, network, relying on historical analysis and predictive algorithms. The requirements are fairly high level, suggesting that the operators themselves might not have yet very clear targets in terms of algorithmics policy, performance and management.

In conclusion, this document provides useful data on Open RAN maturity and priorities. While the release 3 shows great progress in many aspects, it still fails to provide sufficient unanimous guidance from a commercial standpoint on the minimum set of end to end capabilities a vendor could reasonably develop to be selected for deployment at scale in these western european networks.