What is open RAN?
Open RAN (with a capital O) describes a set of standards defined by the O-RAN Alliance. The standard architecture of Open RAN is shown in the figure below, and the major parts of the architecture include:
- The Service Management and Orchestration Framework (SMO), which will most likely form the umbrella RAN management system for all RANs going forward. It includes:
- A design environment for rapid application development
- A common data collection platform for management of RAN data and mediation for the O1, O2 and A1 interfaces
- Support for licensing, access control and AI/ML lifecycle management
- Existing OSS functions such as service orchestration, inventory/topology and policy control.
- The RAN Intelligent Controller (RIC), which is responsible for controlling and optimising RAN functions. It has three main objectives: to receive a stream of data on which to make optimisation decisions, to ensure that services maintain the required performance levels, and to ensure RAN efficiency, balancing the needs of all users. The RIC has two components:
- The Non-Real Time RIC (Non-RT RIC) offers closed-loop control functions which last for more than one second. Some of these functions are available today in C-SON. The placement of the Non-RT RIC in the SMO and not in the RAN is to secure access to contextual data and use it to optimise the RAN, something that the RAN nodes CU, DU and Near RT-RIC can’t do. rApps are developed for the Non-RT RIC and ingest radio environment data (e.g. device location, signal strength measurements), device data (e.g. positioning and trajectories, plus application-level information), cross-domain information (e.g. insights from the core) and external data (e.g. weather). There are a wide range of potential rApps being developed – including those involved in traffic steering, load balancing, capacity optimisation and energy optimisation. They also involve complex self-organising network functions, such as the dynamic orchestration of radio and transport domains; and various management functions, such as management of the cloud, slices and policy.
- The Near-Real Time RIC (near-RT RIC) offers closed-loop control with functions lasting between 10ms and one second which support faster data streams and fast control of RAN functions. xApps are developed for the near-RT RIC and, unlike rApps, have access to data from specific CUs and DUs, and receive instructions from the rApps on actions to take. Use cases include network control, such as radio bearer management, load balancing, handover and interference mitigation, and mMIMO beamforming optimisation. Their development is challenging and requires specific knowledge of radio network parameters and of currently vendor-proprietary APIs, as well as the ability to tightly interact with the vendor’s CUs and DUs.
Enter your details below to download an extract of the report
O-RAN overall logical architecture
Source: O-RAN Alliance White Paper, Feb 2020
Overview of the xApp/rApp market and opportunities for vendors
This section looks at the trends in xApp and rApp deployment over the next couple of years and provides some detail from analysis of their current availability.
As previously discussed, telcos have a wide range of requirements when upgrading the RAN: improved performance, cost reduction, improved spectrum and capital utilisation, as well as developing its future potential to underpin new revenues. This broad goal offers many opportunities for both RAN-specialist and other vendors to develop a range of simple to more sophisticated intelligence and automations. Opportunities will be dependent on market factors including:
- The amount of telcos which will choose to convert, or ask vendors to convert, the already deployed capabilities of their existing C-SON into rApps/xApps. We expect this to be a popular option where the telco feels comfortable with current performance and capabilities
- As the non-RT RIC can also interoperate with legacy RAN, which will help a smooth transition of existing capabilities into the open RAN, the number of new rApps needed in the short term might be smaller
- Telcos, many of which will be Tier 1s with the ability to develop their own A3, will also impact the early market. Our interview discussions suggested that the majority of DIY telcos will solve specific network situations where there is no available vendor solution and that, therefore, the creation of home-grown solutions will reduce over time. However, there was also discussion of telcos wanting to become rApp developers in order to monetise their IP, which is likely to see a steady stream of app development from telcos.
Table of Contents
- Executive Summary
- The need for A3 within open RAN
- A3 market development
- Actions for telcos and vendors
- Table of Contents
- Table of Figures
- Quick review: What is open RAN?
- Overview of the xApp/rApp market and opportunities for vendors
- rApp market
- xApp market
- Assessing the potential of rApps and xApps
- A3 requirements in open RAN
- Interference management
- Channel estimation
- RAN design and planning
- Handover management
- Load balancing
- Traffic steering
- RAN management
- Power management
- The use of A3 in the SMO