Is Ericsson's Open RAN stance that open?

 

An extract from the Open RAN RIC and Apps report and workshop.

Ericsson is one of the most successful Telecom Equipment Manufacturers of all time, having navigated market concentration phases, the emergence of powerful rivals from China and elsewhere, and the pitfalls of the successive generations and their windows of opportunity for new competitors to emerge.

With a commanding estimated global market share of 26.9% (39% excluding China) in RAN, the company is the uncontested leader in the space. While the geopolitical situation and the ban of Chinese vendors in many western markets has been a boon for the company’s growth, Open RAN has become the largest potential threat to their RAN business.

At first skeptical (if not outright hostile) to the new architecture, the company has been keeping an eye on its development and traction over the last years and has formulated a cautious strategy to participate and influence its development.

In 2023, Ericsson seems to have accepted that Open RAN is likely to stay and represents both a threat and opportunity for its telecom business. The threat is of course on the RAN infrastructure business, and while the company has been moving to cloud ran, virtualizing and containerizing its software, the company still in majority ships vertical, fully integrated base stations.

When it comes to Open RAN, the company seems to get closer to embracing the concept, with conditions.

Ericsson has been advocating that the current low layer split 7.2.x is not suitable for massive MIMO and high capacity 5G systems and is proposing an alternative fronthaul interface to the O-RAN alliance. Cynics might say this is a delaying tactic, as other vendors have deployed massive MIMO on 7.2.x in the field, but as market leader, Ericsson has some strong datasets to bring to the conversation and contest the suitability of the current implementation. Ericsson is now publicly endorsing Open RAN architecture and, having virtualized its RAN software, will offer a complete solution, with O-RU, vDU,.vCU, SMO and Non-RT RIC . The fronthaul interface will rely on the recently proposed fronthaul and the midhaul will remain the F1 3GPP interface.

On the opportunity front, while most Ericsson systems usually ship with an Element Management System (EMS), which can be integrated into a Management and Orchestration (MANO) or Service Management and Orchestration (SMO) framework, the company has not entirely dominated this market segment and Open RAN, in the form of SMO and Non-RT RIC represent an opportunity to grow in the strategic intelligence and orchestration sector.

Ericsson is using the market leader playbook to its advantage. First rejecting Open RAN as immature, not performing and not secure, then admitting that it can provide some benefits in specific conditions, and now embracing it with very definite caveats.

The front haul interface proposal by the company seems self-serving, as no other vendor has really raised the same concerns in terms of performance and indeed commercial implementations have been observed with performance profiles comparable to traditional vendors.

The Non-RT RIC and rApp market positioning is astute and allows Ericsson simultaneously to claim support for Open RAN and to attack the SMO market space with a convincing offer. The implementation is solid and reflects Ericsson’s high industrialization and quality practice. It will doubtless offer a mature implementation of SMO / Non-RT RIC and rApps and provide a useful set of capabilities for operators who want to continue using Ericsson RAN with a higher instrumentation level. The slow progress for 3^rd party integration both from a RIC and Apps perspective is worrisome and could be either the product of the company quality and administrative processes or a strategy to keep the solution fairly closed and Ericsson-centric, barring a few token 3^rd party integrations.

O-RAN alliance rApps and xApps typology

 An extract from the Open RAN RIC and Apps report and workshop.

1.    O-RAN defined rApps and xApps

1.1.        Traffic steering rApp and xApp

Traditional RAN provides few mechanisms to load balance and force traffic on specific radio paths. Most deployments see overlaps of coverage between different cells in the same spectrum, as well as other spectrum layered in, allowing performance, coverage, density and latency scenarios to coexist. The methods by which a UE is connected to a specific cell and a specific channel are mostly static, based on location of the UE, signal strength, service profile and the parameters to handover a connection from one cell to another, or within the same cell from one bearer to another or from one sector to another. The implementation is vendor specific and statically configured.

Figure 9: Overlapping cells and traffic steering

Non-RT RIC and rApps offer the possibility to change these handover and assignments programmatically and dynamically, taking advantage of policies that can be varied (power optimization, quality optimization, performance or coverage optimization…) and that can change over time. Additionally, the use of AI/ML technology can provide predictive input capability for the selection or creation of policies allowing a preferable outcome.

The traffic steering rApp is a means to design and select traffic profile policies and to dynamically allow the operator to instantiate these policies, either per cell, per sector, per bearer or even per UE or per type of service. The SMO or the Non-RT RIC collect RAN data on traffic, bearer, cell, load, etc. from the E2 nodes and instruct the Near-RT RIC to enforce a set of policies through the established parameters.

1.2.       QoE rApp and xApp

This rApp is assuming that specific services such as AR/VR will require different QoE parameters that will need to be adapted in a semi dynamic fashion. It proposes the use of AI/ML for prediction of traffic load and QoE conditions to optimize the traffic profiles.

UE and network performance data transit from the RAN to the SMO layer over the O1 interface, QoE AI/ML models are trained, process the data and infer the state and predict its evolution over time, the rApp transmits QoE policy directives to the Near-RT RIC via the Non-RT RIC.

1.3.       QoS based resource optimization rApp and xApp

QoS based resource optimization rApp is an implementation of network slicing optimization for the RAN. Specifically, it enables the Non-RT RIC to guide the Near-RT RIC in the allocation of Physical Resource Blocks to a specific slice or sub slice, should the Slice Level Specification not be satisfied by the static slice provisioning.

1.4.       Context-based dynamic handover management for V2X rApp and xApp

Since mobile networks have been designed for mobile but relatively low velocity users, the provision of high speed, reliable mobile service along highways requires specific designs and configurations. As vehicles become increasingly connected to the mobile network and might rely on network infrastructure for a variety of uses, Vehicle to infrastructure (V2X) use cases are starting to appear primarily as research and science projects. In this case, the App is supposed to use AI/ML models to predict whether a UE is part of a V2X category and its trajectory in order to facilitate cell handover along its path.

1.5.       RAN Slice Assurance rApp and xApp

3GPP has defined the concept of creating a connectivity product with specific attributes (throughput, reliability, latency, energy consumption) applicable to specific devices, geographies, enterprises… as slices. In an O-RAN context, the Non-RT RIC and Near-RT RIC can provide optimization strategies for network slicing. In both cases, the elements can monitor the performance of the slice and perform large or small interval adjustments to stay close the slice’s Service Level Agreement (SLA) targets.

Generally speaking, these apps facilitate the allocation of resource according to slice requirements and their dynamic optimization over time.

1.6.       Network Slice Instance Resource Optimization rApp

The NSSI rApp aims to use AI/ML to model traffic patterns of a cell through historical data analysis. The model is then used to predict network load and conditions for specific slices and to dynamically and proactively adjust resource allocation per slice.

1.7.       Massive MIMO Optimization rApps and xApps

Massive MIMO (mMIMO) is a key technology to increase performance in 5G. It uses complex algorithms to create signal beams which minimize signal interference and provide narrow transmission channels. This technology, called beamforming can be configured to provide variations in the vertical and horizontal axis, azimuth and elevation resulting in beams of different shapes and performance profiles. Beamforming and massive MIMO are a characteristic of the Radio Unit, where the DU provides the necessary data for the configuration and direction of the beams.

In many cases, when separate cells overlap a given geography, for coverage or density with either multiple macro cells or macro and small cells mix, the mMIMO beams are usually configured statically, manually based on the cell situation. As traffic patterns, urban environment and interference / reflection, change, it is not rare that the configured beams lose efficiency over time.

In this instance, the rApp collects statistical and measurement data of the RAN to inform a predictive model of traffic patterns. This model, in turn informs a grid of beams that can be applied to a given situation. This grid of beams is transmitted to the DU through the Near-RT RIC and a corresponding xApp, responsible for assigning the specific PRB and beam parameters to the RU. A variant of this implementation does not require grid of beams or AI/ML, bit a list of statically configured beams that can be selected based on specific threshold or RAN measurements.

Additional apps leveraging unique MIMO features such as downlink transmit power, Multiple User MIMO and Single User MIMO allow, by reading UE performance to adjust the transmit power or the beam parameters to improve the user experience or the overall spectral efficiency.

1.8.       Network energy saving rApps and xApps

These apps are a collection of methods to optimize power consumption in the open RAN domain.

    Carrier and cell switch off/on rApp:

A simple mechanism to identify within a cell the capacity needed and whether it is possible to reduce the power consumption by switching off frequency layers (carriers) or the entire cell, should sufficient coverage / capacity exist with other adjoining overlapping cells. AI/ML model on the Non- RT RIC might assist in the selection and decision, as well as provide a predictive model. The prediction in this case is key, as one cannot simply switch off a carrier or a cell without gracefully hand over its traffic to an adjoining carrier or cell before to reduce quality of experience negative impact.

    RF Channel reconfiguration rApp:

mMIMO is achieved by the combination of radiating elements to form the beams. A mMIMO antenna array 64 64 transceivers and receivers (64T64R) can be configured to reduce its configuration to 32, 16 or 8 T/R for instance, resulting in a linear power reduction. An AI/ML model can be used to determine the optimal antenna configuration based on immediate and predictive traffic patterns.

Why was virtualized RAN started?

 

Traditional RAN equipment vendors have developed and deployed RAN solutions in every band, in every generation, for any network configuration. This doesn’t happen without an extremely well industrialized process, with rigid interfaces and change management. This cumulative intellectual property, together with the capacity to deploy in a few months a new generation of network is what operators have been valuing until now.

The creation of a new Radio platform is a large investment, in the range of tens of millions, with a development timeframe extending from 18 to 30 months. Because it is a complex solution, underpinned with large hardware dependencies, it requires very good planning and development management only available to highly industrialized companies. The development of subsequent radios on the same platform might take less time and costs, but essentially the economics remain the same, you need at least 10,000 units of firm order, for a radio to be economically viable.

It is expensive because it works. As long as you don’t mind being essentially dependent of your vendor for all professional services associated with their product, they can guarantee it will work. This part is key, because taking sole responsibility for deployment, operation and maintenance of a radio system is a huge undertaking. Essentially, the traditional vendors are selling together with equipment and services an insurance policy in the form of onerous Service Level Agreements (SLA), willing to undertake penalties and damages in case of failure.

Unfortunately, most network operators find themselves in a situation where, with the reduction of their Average Revenue per User (ARPU) combined with the perpetual traffic growth and appetite for video streaming, they see their costs steadily increase and their margins compressed. Connectivity seems increasingly like a commodity from a customer standpoint, with easy availability and low friction to change provider, whereas it comes at an increasing cost for its operators.

Changing the cost structure of buying capacity is a must for all networks operators to survive, and it touches all aspects of their network.

Fortunately, there are a few markets that have seen similar needs in the past and solutions have emerged. Particularly, the internet giants, video streaming services and social networks, have had to face explosive growth of traffic, with essentially flat pricing or advertising-based revenue models which forced them to reimagine how to scale their network capacity.

From there have emerged technologies such as network virtualization, Software Defined Networking (SDN) and their higher levels of abstraction leading to the cloud computing market as we know it.

Applying these methods and technologies to the RAN market seemed like a sensible and effective way to change its cost structure.