Cognitive Foundation Collaboration Platform Technology for Enhancing the Intelligence of Radio Access Network Operation and Management

1. Enhancing the intelligence of RAN operation and management

In radio access networks (RANs) for 5th-generation mobile communications system (5G)/6G networks, the use of high-frequency bands is prompting the adoption of microcells, leading to increased network capacity. This means that the number of installed radio base stations is growing, which in turn increases the power consumption of RANs yearly. It thus necessary to implement power-saving measures such as sleep control of radio base stations during low-traffic periods. As standardization progresses for enabling network use in new fields, such as smart factories, it is becoming a necessity to achieve network slicing and integrated operation and management of devices and slices such as identifying slices that will be affected in the event of a device failure. As we see increases in both the installation density of radio base stations in an area and the number of total radio parameters to be set, the design and operation of RANs is becoming so complex that they are difficult to manage manually. Hence, automated design and operation is required.

To meet these requirements, in addition to executing conventional operations, the network needs to acquire “intelligence” so that it can autonomously decide what to control and how to control it by using big data and artificial intelligence (AI)/machine learning (ML).

The path to making RAN operation and management intelligent is being studied by the O-RAN ALLIANCE, a standardization organization. This article introduces the Cognitive Foundation (CF) Collaboration Platform technology that enables autonomous control of RANs based on the O-RAN specification.

2. O-RAN architecture and SMO

The O-RAN ALLIANCE is developing a set of functions and an architecture for intelligent RAN operation and management. Figure 1 shows the O-RAN architecture.

Fig. 1. O-RAN architecture.

RAN devices for 5G consist of radio units (RUs) that control antennas and radio waves, distributed units (DUs) that process radio signals, and a central unit (CU) that controls RUs/DUs and connects them to the core network. These units are called network functions (NFs). It is necessary to execute fault, configuration, accounting, performance, security (FCAPS) control, such as setting radio parameters, for NFs. The virtualization of RANs is in progress [1], and virtualized DUs and CUs (vDUs and vCUs) are commercially available. It is necessary to control the virtualization platform on which vDUs and vCUs operate by, for example, managing compute resources. The O-RAN architecture defines the service management and orchestration (SMO) layer as a functional part that executes these basic control functions.

The O-RAN architecture also defines the RAN intelligent controller (RIC) as a functional part that processes the logic that enables autonomous control. There are two categories of RIC: near-real-time RIC (Near-RT RIC), which executes near-real-time control actions that take less than 1 second, and Non-RT RIC, which executes control actions that take 1 or more seconds. The SMO is internally equipped with the Non-RT RIC and externally controls the Near-RT RIC.

On the basis that the SMO is essential to achieving intelligent RAN operation and management, we are working to make it a reality.

3. SMO architecture

As mentioned above, the SMO is required to control FCAPS for NFs, control the virtualization platform, and process control logic. How these capabilities are implemented as well as the functions required of the SMO and its architecture are described below.

FCAPS control for NFs includes the creation of new NFs, modification of NF configurations, status monitoring, and alarm detection. Specifically, FCAPS control includes data management such as collection and storage of performance management (PM) and fault management (FM) information, and inventory management such as storage, modification, and history control of configuration management (CM) information.

When virtualized NFs operate on the virtualization platform, a variety of control measures are required, such as reserving virtual resources, monitoring failures, and restoring them when failures occur.

The Non-RT RIC, which is responsible for processing control logic, consists of Non-RT RIC applications (rApps), which execute individual control logic, and the Non-RT Framework, which provides, as a platform, various data needed for logic execution and NF control functions. Since there can be a variety of control logic, rApps are loosely coupled with the Non-RT RIC Framework, and an rApp management function is needed to commonly manage the deployment, start, and stop of rApps.

To implement these functions, the O-RAN ALLIANCE specifies the SMO function groups shown in Fig. 2. However, implementation methods for the functions indicated with dotted boxes in the figure (non-anchored functions), such as the locations and sharing of functions, have not been specified and are still being studied.

Fig. 2. Functions within SMO.

Even though NFs are expected to be provided by multiple vendors, it is desirable that the control logic to be executed by the Non-RT RIC should operate in a common manner regardless of the vendor. For this reason, an operation support system (OSS) functional part is defined, which is responsible for providing the RAN management functions that executes FCAPS control for NFs, data management functions, and inventory management functions. It is loosely coupled with the Non-RT RIC.

The standardization of the functions and control schemes needed for controlling virtual resources is well underway. These are specified by the European Telecommunications Standards Institute (ETSI) for network functions virtualisation (NFV) and management and orchestration (MANO). Therefore, we define the MANO functional part, assuming the use of vDUs/vCUs, and loosely couple it with the OSS functional part.

We equip the Non-RT RIC with a set of functions needed for executing the control logic of rApps (the R1-related functions, A1-related functions, and AI/ML workflow functions) and the rApp management functions.

Figure 3 shows the CF Collaboration Platform that implements the SMO on an architecture that includes three functions: the Non-RT RIC, OSS, and MANO. Each functional part is described below.

Fig. 3. CF Collaboration Platform architecture.

4. OSS functional part

Specific examples of FCAPS control for NFs implemented by the OSS include managing NF configurations, changing parameter settings for each DU/CU, controlling the antenna angle (tilt angle), and updating NF software. Regardless of NF vendors, the OSS monitors the operational status of NFs, collects operational status data and logs, traces signals, closes cells or puts cells in sleep mode, monitors PM information, and issues alarms when threshold values are exceeded.

When an NF is to be created and added to the SMO, the OSS functional part works with the MANO functional part to allocate virtual resources, boots the NFs, configures, and manages the association between NFs and virtual resources. The OSS functional part manages NF configuration, such as changing/deleting configurations, and managing the generations of configuration. When a failure occurs in virtual resources, it associates the alarm from the virtual resources received via MANO with the NF running on the virtual resources and generates its own alarm associated with the relevant NF. Maintenance personnel can receive alarms from both the virtual resources and NF and centrally control restoration and recovery of the NF and the associated virtual resources. These NF management functions are called network function management functions (NFMFs).

It is necessary to consider the use of RAN slices in certain new network usage patterns such as in fixed-mobile convergence services. For such usage patterns, it is necessary to combine a given network with other networks depending on how the particular service is used. In such a scenario, end-to-end (E2E) network slices spanning multiple network domains will be used. Standardization for this approach is underway in the 3rd Generation Partnership (3GPP) (Fig. 4).

Fig. 4. E2E network slice and RAN slice.

To implement network slicing, it is necessary to manage the association between slices and individual radio base stations and configure base stations to support slices. When slices are to be created/deleted or slice configurations are to be changed, CM actions are executed, such as identifying the base stations, the configuration of which is to be changed, classifying slice parameters according to base stations, and inputting the parameters accordingly. FM actions are also executed, such as identifying affected slices and generating alarms for each slice when device alarms are received. PM actions are also executed, such as monitoring PM information and determining whether threshold values for each slice have been exceeded. The slice management function that covers CM, FM, and PM for slices will be implemented by incorporating the RAN network slice subnet management function (NSSMF) specified in 3GPP TS28.531.

By implementing these functions, we will enable slicing in the RAN domain. We will also provide E2E network slices through a collaboration between slicing in the RAN domain and network slice management function (NSMF), which is a higher-level system that manages E2E network slices. By combining the slicing in the RAN domain described above with slicing in transport and core networks—which is expected to yield technical advances in the future—we aim to provide E2E network services. Thus, the OSS functional part will be implemented equipped with NFMF and NSSMF.

5. Non-RT RIC functional part

To enable intelligent RAN operation and management, it is necessary to implement a range of control logics. Each control logic is implemented as a module in the form of an rApp, and necessary rApps can be added on the Non-RT RIC Framework on the basis of the nature of any desired control.

Since the information required by an rApp varies depending on its control logic, the Non-RT RIC Framework provides the PM/FM/CM information it stores to any rApp in such a manner that the information can be searched for using a variety of keys, such as by a PM item or the period in which the data were collected, CM item, CM update history, FM alarm detail, and the date/time that the alarm was issued. When the Non-RT RIC Framework controls NFs, it works with the OSS functional part to implement CM change and base station control, such as sleeping for energy saving, in a manner that enables multi-vendor procurement. Since sophisticated control may be achieved using multiple rApps, the Non-RT RIC Framework provides functions necessary for collaborative operation between rApps, such as data transfer between them.

The control logic for the base station sleep mode is described below as a specific example. When a base station is installed, its capacity is designed to meet traffic demand during the busiest time of the day. In areas with a small nighttime population, such as office areas, the network traffic decreases significantly at night and on weekends. By identifying the characteristics of such areas through continuous traffic analysis and putting the relevant radio base stations into sleep mode when their traffic decreases, it is possible to reduce the power consumption of these base stations. However, when a base station is put into sleep mode, the terminals in the area covered by it lose radio access. This problem is avoided by automatically identifying those base stations that have an overlay coverage relationship with the currently sleeping base station and by automatically optimizing their antenna tilts [2, 3] to cover the area. The traffic of the covering base stations is monitored, and when an increase in traffic is detected, the sleeping base station is taken out of sleep mode. This type of control logic leads to lower power consumption than can be achieved by simple time-based sleep/wake control. In this example, the rApp that identifies the overlay coverage relationship of the base stations and calculates the desired amount of antenna angle change, and the rApp that determines whether to put a base station into sleep mode on the basis of periodic traffic analysis work together. They share data, such as on the amount of antenna angle change and the candidate base stations to be put into sleep mode, via the Non-RT RIC Framework.

If real-time control is required, rApps work with the Near-RT RIC. For example, when the load at a certain base station increases, it can be distributed by handing over the terminals served by that base station to surrounding base stations. For this purpose, rApps monitor the loads of surrounding base stations, identify appropriate handover destinations, and notify the Near-RT RIC of these destinations in advance. The Near-RT RIC executes actual real-time handover.

With the advancement of AI/ML technology, various proposals have been made to apply AI/ML to network operations. The O-RAN ALLIANCE is studying how to apply AI/ML to RAN operation and management. One function-sharing proposal being studied to implement AI/ML-assisted control logic in rApps involves making rApps execute inference using AI/ML models and making the Non-RT RIC manage the models used for inference. Specifically, the Non-RT RIC is equipped with a model repository, accepts model registrations and updates, deploys models to rApps, and sends notifications to rApps when a new version of the AI/ML model is available to them.

The accuracy of inferences made using AI/ML degrades over time for various reasons. Therefore, relearning and some other functions are required. AI/ML platform products that provide these functions, including relearning and model creation, are available, including open source products such as Kubeflow. Since different AI/ML platforms support different learning algorithms, it is desirable that an appropriate product be selected on the basis of the nature of the desired control. Therefore, we are studying a way to enable selection of an AI/ML platform product for relearning and model creation by providing model storage, update, and deletion functions as an interface for AI/ML platforms. This interface was derived on the basis of the AI/ML model management interface specified as the R1 interface (Fig. 5).

Fig. 5. Integrating AI/ML functions into the SMO.

6. MANO functional part

The MANO functional part was designed on the basis of ETSI NFV standards. It consists of an NFV orchestrator (NFVO) that mediates resources used by virtual network functions (VNFs) and a VNF manager (VNFM) that manages the VNF life cycle (Fig. 6).

Fig. 6. Outline of the MANO functional part.

MANO components, such as the NFVO and VNFM, are often designed and implemented individually by each VNF vendor. Therefore, costs increase when operating a combination of products from multiple vendors. To solve this problem, we have designed MANO interfaces and functions on the basis of the common specifications defined by ETSI NFV. Therefore, MANO can be run with unified specifications and operations even if it is built with a combination of products from multiple vendors.

We have specifically developed VNFM in conjunction with open source community activities through the OpenStack Tacker [4] Project to ensure multi-vendor procurement. We have also leveraged NTT’s expertise in carrier network operation to implement additional functions that assist the real-world operation of RAN functions.

7. Conclusion

In this article, we introduced the CF Collaboration Platform technology that enables autonomous control of RANs and enhances their intelligence. In addition to reducing network power consumption through use of sleep and area coverage control of radio base stations, this technology enables various intelligent operations, such as optimized and automated design and configuration of base station parameters, optimized radio parameters for handover, and detection of abnormal PM counter values using AI/ML. We believe that the CF Collaboration Platform will serve as a platform for a variety of control tasks in the future.

References

[1]	S. Mizuta, A. Umesh, Y. Nakajima, and Y. Kuno, “Initiatives toward Virtualized RAN,” NTT Technical Review, Vol. 20, No. 11, pp. 52–63, Nov. 2022. https://doi.org/10.53829/ntr202211fa7
[2]	M. Iwamoto, A. Suzuki, and M. Kobayashi, “Deep Reinforcement Learning Based Antenna Selection for Cell Outage Compensation,” Proc. of IEEE International Conference on Communications (ICC 2023), pp. 3945–3950, Rome, Italy, May 2023. https://doi.org/10.1109/ICC45041.2023.10279017
[3]	H. Kinsho, K. Takeshita, and K. Yamagishi, “Block Kriging Based Mobile User Distribution Estimation for Antenna Tilt Optimization,” IEEE International Communications Quality and Reliability Workshop 2023 (CQR 2023), pp. 13–18, Washington, DC, USA, Oct. 2023. https://doi.org/10.1109/CQR59928.2023.10317795
[4]	Tacker, https://wiki.openstack.org/wiki/Tacker