Toward Open and Intelligent Wireless Networks
Initiatives toward Intelligent RAN

RIC AI/ML automation

Taichi Katsuragawa, Akihiro Kawana, Yoshio Inoue, Takahiro Tateishi, Eina Hashimoto and Takumi Fujitsuka
Radio Access Network Development Department

Abstract
The network of the 5G era must be able to support many and varied applications, which means ever increasing complexity. It will therefore not be easy to control and optimize network operations by manual means as done in the past. At NTT DOCOMO, we are developing RIC technology now being standardized at the O-RAN ALLIANCE with the aim of achieving more autonomous and automatic RAN operations, that is, intelligent RAN, by using machine learning and other forms of artificial intelligence, big data, etc. This article describes the state of RIC standardization at the O-RAN ALLIANCE and presents NTT DOCOMO’s approach to use cases and a roadmap toward intelligent RAN.

  • 01.Introduction

    The mobile network of the fifth-generation mobile communications ...

    Open

    The mobile network of the fifth-generation mobile communications system (5G) is expected to provide services that can satisfy diverse requirements and conditions such as high speeds and large capacity, low latency, and massive connectivity. To meet these advanced service requirements, mobile network operators have been working continuously to enhance Radio Access Network (RAN)*1 functions and expand the scale of the network, but as a result, RAN design and operation have become increasingly complex. In response to this issue, a technology called Self Organizing Network (SON)*2 has been standardized at the 3rd Generation Partnership Project (3GPP) as a means of automatically constructing networks, optimizing coverage areas and operation parameters, and recovering from faults to ease the burden of RAN construction and operation on operators. On the other hand, the evolution of artificial intelligence (AI) technology in recent years is spurring demand for automation achieved through intelligent systems using big data and AI with machine learning (AI/ML). From the viewpoint of RAN control, AI/ML will enable proactive*3 control, which is expected to improve RAN performance and the customer’s degree of satisfaction.

    At the O-RAN ALLIANCE*4, standardization of architecture and various control interfaces is underway to achieve operation and control using big data and AI/ML toward intelligent RAN. As described above, intelligent RAN is expected to benefit not only mobile network operators in terms of lower operation costs but end-user customers too through improved RAN performance and an enhanced User eXperience (UX)*5. With this in mind, NTT DOCOMO is actively conducting technical studies of this technology.

    In this article, we describe architecture and the functions and control procedures of various interfaces for achieving intelligent RAN, whose specifications are now being studied at the O-RAN ALLIANCE. We also overview NTT DOCOMO’s approach toward a roadmap for achieving intelligent RAN, discuss issues that need to be addressed, and present a future outlook.

    1. RAN: The network consisting of radio base stations and other equipment situated between the core network and mobile terminals to control the radio layer.
    2. SON: A network installed with functions to self-configure and self-optimize its parameters.
    3. Proactive: Taking measures in advance.
    4. O-RAN ALLIANCE: A group of telecommunications carriers and telecommunications equipment suppliers aiming to make the next generation radio access networks more scalable, open and intelligent.
    5. UX: A general term for the experiences gained through the use or consumption of certain products or services.

  • 02.Overview of RIC Standardization at O-RAN ALLIANCE

    2.1 RIC Architecture

    Open

    In RAN architecture at the O-RAN ALLIANCE, a RAN Intelligent Controller (RIC) is defined as a logical node for performing base station parameter design and settings and automating and optimizing operations with the aim of achieving intelligent network operations using AI/ML.

    As shown in Figure 1, RIC is defined as Non-Real Time (Non-RT) RIC and Near-Real Time (Near-RT) RIC. Among these, Non-RT RIC is situated within the Service Management and Orchestration (SMO) block that performs RAN monitoring/maintenance and orchestration. Non-RT RIC connects to Near-RT RIC via an A1 interface, and Near-RT RIC connects to the O-RAN Central Unit (O-CU)*6 and O-RAN Distributed Unit (O-DU)*7 E2 nodes*8 via an E2 interface. In addition, these E2 nodes and Near-RT RIC connect to SMO by an O1 interface. Based on RAN architecture now under study at the O-RAN ALLIANCE, intelligent control can be achieved in a variety of formats by combining the control interfaces to be used with an appropriate arrangement of AI/ML functions.

    1) Non-RT RIC

    Non-RT RIC links with the function that provides Operation Administration and Maintenance (OAM)*9 services within SMO and uses the O1 interface to collect various types of data from the E2 nodes such as Performance Management counter (PM counter)*10, Fault Management data (FM data)*11, and Trace Management data (TM data)*12 accumulated within those nodes. It can optimize parameter settings through advanced analysis using AI/ML and reflect those settings optimized to the radio environment, traffic load, etc. in the E2 nodes via the O1 interface. Non-RT RIC can also generate policies governing RAN control and notify Near-RT RIC of those policies via the A1 interface. These control processes are executed in a relatively long control loop greater than 1 s.

    text

    Figure 1  RAN architecture at O-RAN ALLIANCE

    2) Near-RT RIC

    Near-RT RIC collects information from the E2 nodes via the E2 interface and can reflect the results of internal analysis in the control of those nodes in accordance with the policies notified from Non-RT RIC. It performs high-speed control in a control loop of several 10 ms to 1 s by connecting directly with the E2 nodes via the E2 interface.

    3) rApp

    Non-RT RIC uses an application called Non-RT RIC Application (rApp) for analyzing various types of information and generating policies. The rApp takes on architecture independent of the Non-RT RIC framework*13 and connects with that framework via the R1 interface.

    4) xApp

    The application that analyzes various types of information and performs control processes on the Near-RT RIC framework is called the Near-RT RIC Application (xApp). In Near-RT RIC as well, the framework and application are separated but interconnected by Near-RT RIC application programming interfaces (APIs) being standardized at the O-RAN ALLIANCE.

    2.2 Interfaces specified at O-RAN ALLIANCE

    1) O1 interface

    The O1 interface is used by SMO to provide E2 nodes and Near-RT RIC with OAM functions such as Fault, Configuration, Accounting, Performance and Security (FCAPS)*14 management, software management, and file management. Non-RT RIC links up with a function that provides OAM services within SMO to obtain PM counter data generated by E2 nodes using the O1 interface. It can also reflect configuration settings, which are optimized by rApp in Non-RT RIC, in the E2 nodes. Furthermore, for cases that apply ML in Near-RT RIC, the O1 interface can potentially be used to deploy*15 an ML model.

    2) A1 interface

    The A1 interface connects Non-RT RIC and Near-RT RIC. Three functions for the following services are specified for this interface: (1) A1 Policy Management Service (A1-P), A1 Enrichment Information Service (A1-EI), and A1 ML Model Management Service (A1-ML).

    1. The A1-P function transfers polices issued by Non-RT RIC to Near-RT RIC, the latter of which controls target E2 nodes according to those policies. The policies transferred via the A1 interface are called “A1 policies,Ewhich specify performance targets such as throughput and latency with respect to a specific end-user or slice or even a cell. Near-RT RIC uses the functions released to it by lower E2 nodes as a basis to notify Non-RT RIC of the types of policies that can be supported.
    2. The A1-EI function provides Enrichment Information to Near-RT RIC. Enrichment Information refers to information on the analysis and processing of data collected from E2 nodes within RAN and information sources outside of RAN.
    3. The role envisioned for the A1-ML function is to control the ML-related workflow to be used by xApp, but details have not yet been specified.

    3) E2 interface

    The E2 interface connects Near-RT RIC and E2 nodes. It performs the functions of exposing information on E2 node control functions and control history to Near-RT RIC and notification of control commands to E2 nodes. The E2 interface can control E2 nodes through Radio Resource Control (RRC)*16 Hand Over (HO) control*17 and control of S1*18/X2*19/NG*20/Xn*21/F1*22/E1*23 procedures*24. Here, control can be specified in units of cells, slices, or User Equipment (UE).

    4) R1 interface

    The R1 interface sends and receives data and control information between rApp and the Non-RT RIC framework. Its main functions consist of Service Management and Exposure (SME) services and Data Management and Exposure (DME) services. A1-related services, O1-related services, O2-related services, and AI/ML workflow services are also being specified.

    The functions in SME include BootStrap that conveys endpoints*25 of various services provided by the Non-RT RIC framework, Registration that registers services provided by rApp, Discovery that searches for services provided by the Non-RT RIC framework and rApp, Heartbeat that monitors the state of rApp, and Authentication and Authorization that authenticates and authorizes services provided by rApp.

    As for DME, its functions include Data Registration that registers data that can be provided by the Non-RT RIC framework and rApp, Data Discovery that obtains data whose registration has been completed (data catalog), Data Request/subscription that requests data, Data Collection that collects data, and Data Delivery that transmits data.

    Currently specified for O1-related services are a Network Information service that obtains the configuration, status, etc. of a Network Function (NF)*26 that SMO can obtain and a FM/PM service that obtains FM and PM information. Details on A1-related, O2-related, and AI/ML workflow functions have not yet been specified. In addition, standardization of the R1 interface at the O-RAN ALLIANCE has just begun, so details have not yet been specified. Function updates and changes can therefore be expected.

    5) Near-RT RIC APIs

    Near-RT RIC APIs lie between xApp and the Near-RT RIC framework. In addition to A1-related APIs and E2-related APIs, these include Management APIs that handle xApp and AI/ML model management (registration, modification, deletion, and configuration), logging*27, tracing*28, and metrics collection*29, Shared Data layer (SDL)*30 APIs that provide access to SDL-related functions, and Enablement APIs that perform authentication, registration, etc. to enable API use by xApp.

    2.3 rApp/xApp

    Control algorithms running on Non-RT RIC and Near-RT RIC are implemented by rApp and xApp, respectively, as described above, and are separated from the Non-RT RIC framework and Near-RT RIC framework by the R1 interface and Near-RT RIC APIs, respectively. This scheme enables a mobile network operator to freely select applications. In other words, it is possible to adopt not only an rApp from a vendor that provides a Non-RT RIC framework but also an rApp provided by a third party. An operator can also reflect RAN control policies in rApp algorithms based on RAN operation experience and know-how and thereby provide services that satisfy a variety of requirements and conditions.

    An rApp can share data with another rApp via DME. For example, rApps having different functions, such as an rApp specialized in collecting and analyzing data, an rApp that takes the results of that analysis to generate a ML model, and an rApp that performs inference using that ML model and generates control commands and control policies for E2 nodes based on inference results, could be linked together to achieve a single use case.

    It is also possible to apply different rApps or xApps (hereinafter referred to as “AppE for each automation/optimization objective (use case). For example, a flexible automated service can be applied by running App_A and App_B in parallel as shown in Figure 2 (1). Alternatively, different Apps can be applied to different areas as shown in Figure 2 (2) or configuration settings can be changed for the same App to change automation or optimization operations as shown in Figure 2 (3).

    text

    Figure 2  rApp/xApp deployment scenarios

    2.4 Application of ML

    Recent progress in cloud technology has made it easy to accumulate large amounts of data, and as a result, the application of ML to a variety of fields is attracting attention. At the O-RAN ALLIANCE that aims to achieve intelligent RAN, there are expectations that network performance will improve by applying ML to the RAN field, so architecture for making that possible is being prepared.

    The application of ML requires training and inference processes. In the training process, network performance data stored in a data lake*31 are used by ML Training Hosts*32 situated inside or outside RIC architecture to train an ML model and save it on RIC. In the inference process, the ML model is loaded into the rApp or xApp on RIC and used by ML Inference Hosts*33 situated inside or outside RIC architecture to infer optimal values for target parameters. Optimized parameters are then set in O-CU and O-DU via the A1, O1 and E2 interfaces.

    A variety of configuration methods are being studied as scenarios for implementing other function such as Model Management*34, Data Preparation*35, and AI/ML Training*36. Typical patterns are given below (Figure 3).

    1. All functions including Model Management, Data Preparation, and AI/ML Training are implemented on Non-RT RIC.
    2. Model Management is implemented in SMO outside of Non-RT RIC, Data Preparation and AI/ML Training are implemented on Non-RT RIC, and Data Collection*37 and AI/ML Inference*38 are implemented on Near-RT RIC.
    3. Model Management, Data Preparation, and AI/ML Training are implemented in SMO outside of Non-RT RIC and AI/ML Inference is implemented within Non-RT RIC.
    text

    Figure 3  Examples of ML implementation scenarios

    1. O-CU: Equipment that controls radio resources of the radio base station.
    2. O-DU: A function performing real-time Layer 2 functions, etc. of the radio base station.
    3. E2 node: Refers to equipment connected by E2 and to O-CU-CP, O-CU-UP, O-DU, and O-eNB in particular.
    4. OAM: Operations, Administration and Management functions on a network.
    5. PM counter: Data related to performance information.
    6. FM data: Data related to fault information.
    7. TM data: Data related to signaling information and user-data characteristics.
    8. Framework: Software that encompasses functionality and control structures generally required for software in a given domain. In contrast to a library in which the developer calls individual functions, code in the framework handles overall control and calls individual functions added by the developer.
    9. FCAPS: Fault, Configuration, Accounting, Performance, and Security management.
    10. Deploy: Installing applications by placing them in their execution environments.
    11. RRC: Layer 3 protocol that controls radio resources in the radio network.
    12. HO control: Changes the base station that UE is connected to.
    13. S1: Interface between EPC and eNB.
    14. X2: Interface between eNodeB equipment.
    15. NG: Interface between 5GC and gNB.
    16. Xn: Interface between gNB equipment.
    17. F1: Interface between O-CU and O-DU.
    18. E1: Interface between O-CU-CP and O-CU-UP.
    19. Procedure: A signal processing procedure that uses various interfaces.
    20. End point: A URI for accessing API.
    21. NF: Logical unit for identifying individual network functions.
    22. Logging: The process of generating operations and performance history.
    23. Tracing: The process of generating a history of workflow, subscriptions, etc.
    24. Metrics collection: The process of collecting performance and fault information.
    25. SDL: Function that simplifies database access.
    26. Data lake: A data storage repository.
    27. ML Training Hosts: Function for hosting ML model training.
    28. ML Inference Hosts: Function for hosting ML model inference.
    29. Model Management: Function for managing a ML model deployed by an inference host.
    30. Data Preparation: Function for preparing the data needed for ML model learning.
    31. AI/ML Training: Function for training a model.
    32. Data Collection: Function for collecting the data resulting from the execution of a model.
    33. AI/ML Inference: Function for performing model inference.

  • 03.Implementation Scenario for Intelligent RAN

    3.1 Intelligent RAN Roadmap

    Open

    On implementing intelligent RAN by RIC, the functions and control interfaces that will be needed and the data collection items needed for optimization analysis will differ depending on the use cases adopted, and the interfaces and functions needed in RAN equipment (next generation NodeB (gNB)*39) will differ as well. The formulation of an implementation plan that takes the above into consideration is therefore important. It is also necessary to draw up a plan for enhancing intelligent RAN in a step-by-step manner taking into account the status of formulating specifications related to use cases at the O-RAN ALLIANCE and the time that those specifications can be expected to mature.

    As shown in Figure 4, NTT DOCOMO considers the automating of operations implemented via maintenance personnel in the conventional RAN operation system as an initial use case with the aim of reducing operating costs (Figure 4 (1)). This phase envisions, for example, the automating and optimizing of base station operation parameters, antenna directivity, etc. and base station sleep control for power-saving purposes based on predictions of traffic load. The aim here is to provide optimized network settings in an adaptive manner in control loops of several hours to several days based on changes in the radio environment or fluctuations in traffic load. It is also possible to achieve such use cases by control processes using the O1 interface by Non-RT RIC, and since the impact on functions on the RAN equipment (gNB) side should be relatively small here, costs at the time of implementation should be minimized. Furthermore, the plan is to increase the application domain of AI/ML in a stepwise manner to make RAN operations increasingly intelligent (Figure 4 (2)).

    In the next phase, we will target use cases connected to improving RAN performance and the degree of customer satisfaction by enhancing control schemes (for example, by shifting from low-speed to high-speed control or from individual-cell control to individual-user control). Specifically, we envision “traffic steeringEor “QoS/QoE optimizationEthat optimizes resource control according to service requirements for each end-user or network slice*40 (Figure 4 (3)). Achieving these use cases will require support of A1/E2 interfaces in addition to implementing Near-RT RIC. In RAN equipment (gNB) as well, it will be necessary to support various functions prescribed by E2 Service Model RAN Control (E2SM-RC), whose specifications are being drafted in O-RAN ALLIANCE WG3. It will also be necessary to add functions to RAN equipment or undertake a medium-term or long-term migration that eyes the possibility of upgrades (Figure 5). Furthermore, with a view to linking with external systems and applying prediction technology in the future, there is the goal of creating new value through the mobile network (Figure 4 (4)).

    text

    Figure 4  Implementation scenario for intelligent RAN

    text

    Figure 5  Migration scenario for RAN architecture

    3.2 Examples of Use Cases in Each Phase

    The following introduces (1) optimization of HO control parameters as a use case for the initial phase and (2) traffic steering as a use case for the following phase.

    1) Optimization of HO control parameters

    Executing a HO between a base station and UE either too early or too late will cause a HO failure and the UE to be temporarily disconnected from the network. To prevent such a failure from occurring, Non-RT RIC can adjust threshold values, timing, etc. used in HO control by analyzing information on the cell environment and disconnection events. The procedure for optimizing HO control parameters by Non-RT RIC is shown in Figure 6. An optimal HO environment can always be provided to the UE by autonomously and automatically repeating steps 1 to 5 in Figure 6 in units of cell or time.

    2) Traffic steering

    Mobile communication networks can support combinations of various types of access networks such as NR, LTE, and Wi-Fi. These combinations feature a radio environment with multiple frequency bands and traffic fluctuations due to diverse user applications, so to provide a stable network, advanced traffic management beyond what has been required up to now is deemed necessary as summarized below.

    • Radio Resource Management (RRM) covering the range from conventional cell units to UE units having diverse requirements
    • Load balance through a multi-access network and UE performance prediction
    • Application of traffic control with appropriate timing

    With the aim of achieving the above items, a mobile network operator can utilize RIC, which will configure optimal policies in a flexible manner according to the purpose of network operation, perform appropriate network and UE performance measurements in real time, and manage traffic proactively. The procedure for traffic steering by Non-RT RIC and Near-RT RIC is shown in Figure 7. A load-balanced smooth-running network can always be provided by autonomously and automatically repeating steps 1 to 9 in Figure 7.

    text

    Figure 6  Example of optimizing and controlling HO control parameters by Non-RT RIC

    text

    Figure 7  Example of traffic-steering control by Non-RT RIC and Near-RT RIC

    1. gNB: A radio base station providing NR signals in RAN.
    2. Network slice: A format for achieving next-generation networks in the 5G era that entails logically dividing a network into service units for use cases, business models, etc.

  • 04.4. Summary

    4.1 Future Issues

    Open

    The following problems related to multi-vendor operation are taken up as future issues.

    Activities are progressing in O-RAN ALLIANCE WG5 with the aim of achieving multi-vendor interoperability in RAN equipment interfaces, but interoperability is also needed for RIC interfaces (R1 interface, A1 interface, E2 interface, Near-RT RIC APIs, and external interfaces to outside services and applications). Specifications for these interfaces are currently being drafted in WG2 and WG3, but clarification of control and operation with respect to E2 nodes for each use case is deemed necessary so that parameter interpretation among vendors does not differ.

    Additionally, various issues surrounding operation can be considered, such as management of AI/ML models provided by Apps (rApp, xApp), conflict management between Apps, and operation management of applicable/non-applicable areas of RIC functions at the time of system implementation. It is thought that maintenance personnel will evaluate and manually carry out these operation management tasks in the initial implementation phase, but studies will be needed on incorporating RIC functions to automate these operations.

    4.2 Future Use Cases

    Looking to the future, RAN parameter optimization using data outside the RAN domain can also be considered.

    As one example, we can consider mobility optimization on an expressway. In this case, RIC optimizes base station parameters according to the speed of user-terminal movement and user-terminal density using not only base station data in the vicinity of the expressway but also real-time congestion information or congestion prediction data provided by the expressway management company. We can also consider parameter optimization according to current conditions by having RIC obtain data collected from on-vehicle sensors from an intelligent on-vehicle terminal such as a smartphone via the Internet. Specifically, congestion in the local mobile network could be predicted and measures for eliminating that congestion taken, or the speed of user-terminal movement or predictions of the vehicle’s destination could be used to optimize HO control or secure resources at that destination.

    Additionally, to perform network operations appropriate to the amount of power available in a country or region with an unstable power supply, power-off and power-on plans from the power provider could be used to automatically shut down base stations in the power-off area and expand the coverage of base stations in the power-on area. In another case, a stable power supply may be available, but mobile network operators are free to select the power supply source they wish to use from among multiple power retailers, solar power generation equipment or storage batteries near base stations, etc. In this case, data on the amount and cost of power available from each power supply can be used to minimize power expenses while maintaining communications quality.

    As another example, we can consider events where a large number of people come together such as large-scale sports events, music festivals, and fireworks displays. In such cases, postings on social networking services (SNSs) on the Internet could be used to determine the location and time of such an event, and that information could then be passed to the RIC. Using that information, the RIC could then increase the number of simultaneous user-terminal connections by adjusting the parameters of the base stations near that event beforehand, which should eliminate the difficulty of making a connection due to base station congestion.

    If the public release of such data related to the urban infrastructure expands, intelligent RAN should be able to contribute to the creation of smart cities.

  • 05.5. Conclusion

    This article described RIC now being standardized at the O-RAN ...

    Open

    This article described RIC now being standardized at the O-RAN ALLIANCE, a roadmap and various use cases as a scenario for implementing intelligent RAN, and upcoming issues and future use cases.

    Going forward, NTT DOCOMO plans to continue making contributions to the drafting of specifications for intelligent RAN at the O-RAN ALLIANCE. It will also promote studies on enhancing intelligent RAN and achieving multi-vendor interoperability at the 5G Open RAN ECosystem (OREC) that is still evolving.

VOL.24 NO.1

Go to top of the page