1 Introduction

This is an extension of an article that was originally presented at the 2nd International Conference on 6G Networking (6GNet)Footnote 1 held in September 2023 in Paris, France [1].

The radio access networks (RANs) of mobile networks have undergone a continuous evolution throughout the generations until 5G, which saw the introduction of virtualization and cloud concepts in Cloud RAN (C-RAN) and Virtual RAN (vRAN) [2]. In the C-RAN architecture, the base-band units (BBU) have been virtualized and decoupled from remote radio heads (RRHs). To enable high-capacity services, especially indoors, the BBUs of a 5G RAN deployment communicate with several geographically distributed RRHs from a centralized location, via front-haul connections, enabling centralized control and traffic aggregation [3]. RANs were yet further decomposed into a split between radio units (RUs) mostly equivalent to RRHs but with some of the functionality formerly provided by BBUs, distributed units (DUs) that took over the latency-critical functionality of BBUs, and central units (CUs) which implement the BBU functionality less dependent on low latency which can be further centralized than DUs.

Given the flexibility provided by the simultaneous centralization of functionality and the connectivity to multiple distributed RRHs, a new opportunity to optimize the network for different goals, such as improved network performance, better quality, more robust services for the subscriber, and overall energy efficiency, arises.

Building on this, the Open RAN (O-RAN) paradigm introduces a near-real-time (near-RT) RAN intelligent controller (RIC) framework able to integrate multiple optimization functions, named xApps, and to facilitate their communication with the RUs, DUs, and CUs [4]. On top of the RAN components and the near-RT RIC, the service management and orchestration (SMO) framework provides non-RT functionality. One of the SMO’s main components is the non-RT RIC which can integrate multiple management and orchestration functions, so-called rApps. Both rApps and xApps can be provided by the same or different vendors from the RICs and RAN components. As of the writing of this article, over 25 use cases have already been identified and specified by the O-RAN Alliance [5], but not all of them can be realized with xApps. A very large number of proof-of-concept xApps were developed [6,7,8,9,10,11]. They were related to aspects of network topology such as antenna tilt control, allocation of frequencies, mobility management, resource allocation to subscribers [12], and traffic steering [10] among many others [5, 6, 13].

However, all of these proven optimizations were validated in isolation, without assessing their impact on the other proposed optimizations. As such, albeit proven useful, there are no means to assure that deploying them improves the overall system or even that stability is ensured, given the potential side effects they might have on each other. For example, when an energy efficiency-focused xApp tries to lower energy consumption by decreasing the output power of RRHs, it will conflict with xApps aiming to improve performance for users connected to the same RRHs. The system needs to be able to mitigate or manage conflicts between the different optimization functions [14,15,16]. To progress beyond this initial state and towards a commercially viable solution, an integrated approach to the management of these decision elements should be taken.

In this paper, we present a first assessment of the relations between multiple xApps and how they can be harmonized in an integrated system. The highly diverse use cases are first grouped in a set of essential network management decision categories including performance, quality of service (QoS) offered to subscribers, reliability/robustness, security, and energy efficiency. These broad categories are then integrated into a network management framework, underlining the high-level functionality required by the xApps from the O-RAN architecture.

Furthermore, we underline the essential functions which the RAN CU has to expose to the Near-RT RIC, to manage the RAN across previously discussed categories. This represents an essential step towards determining which existing RAN equipment can be integrated with the management plane implementations and to evaluate their capabilities to sustain the expected management functionality.

As a reference, we propose a theoretical road map for the implementation of such functionality, based on the Fraunhofer FOKUS Open5GCore [17], underlining the functionality which can be imported from the core network in a kind of convergence between RAN and core, as well as the network management functions to be implemented.

The paper is organized as follows: A discussion of related work is conducted in Section 2. In Section 3, we provide a short description of the O-RAN architecture underlining its open points. In Section 4, we present and classify the different O-RAN xApps available from the literature, followed in Section 5 by the proposed integrated network management framework. Section 6 describes the functionality which has to be exposed by the RAN components to use the flexible management, and Section 7 subsequently describes a near-RT RIC implementation roadmap based on the Fraunhofer Open5GCore toolkit. Section 8 concludes the text.

2 Related work

Wireless mobile networks are complex distributed systems. Open RAN approaches increase complexity, due to the focus on disaggregation. In such a complex system with multiple control loops, conflicts are bound to happen. For example, when multiple xApps with different optimization goals are deployed to a near-RT RIC, potentially conflicting actions being requested by the different xApps at the same time need to be addressed, to avoid service degradation, over-provisioning of radio resources, or similar issues.

Fig. 1
figure 1

O-RAN architecture [4]

Full size image

The self-organizing network (SON) functions of LTE serve a similar, albeit more limited, purpose to those of rApps and xApps and can cause similar conflicts [16]. Two of the most prominent SON functions are mobility robustness optimization (MRO) and mobility load balancing (MLB) [16].

The O-RAN Alliance e.V. specifies an architecture of interfaces and components for an Open RAN system [4]. The work is split across several working groups (WGs). Working Group 3 (WG3) discusses conflict mitigation for xApps in the near-RT RIC [18], identifying three types of conflicts: direct conflicts in which xApps attempt to modify the same resources or parameters, indirect conflicts in which the actions taken by xApps affect indirectly related resources or parameters, and implicit conflicts that are not easily identified or derived, but result in a problematic overall system state. Different mitigation strategies are discussed for each type. Direct conflicts can be addressed “pre-action coordination” through the xApps themselves or a “Conflict Mitigation“ function [18]. Thus, the actions taken should be decided once all xApps requests are taken into account. To handle indirect conflicts, the system should monitor the effects of actions in post and detect problems. When a problem occurs, the system has to take appropriate mitigation actions. According to the specification, implicit conflicts are too difficult to detect and handle, and there is no guidance on how to address them. However, the different kinds of possible xApps and their relationships are not discussed. Furthermore, no details on a potential implementation are provided. Lastly, the newer version of the specification does not discuss the topic in such detail anymore [19].

In parallel to the presented work, researchers have recently begun addressing the problem of conflict management and mitigation in O-RAN. Amanczyk et al. proposed a conflict mitigation framework (CMF) between O-RAN’s near-RT RICs and their xApps [16]. They discussed the potential for conflicts in the O-RAN architecture. Conflicts can be horizontal, i.e., between components on the same architectural level and of the same type, or vertical, i.e., between components of different types on different levels of the architecture. To address conflicts, they propose an implementation of the real-RT RIC’s conflict mitigation, using three components, conflict detection agent (CD Agent), conflict resolution agent (CR Agent), and performance monitoring (PMon). These components leverage the near-RT RIC’s shared data layer (SDL) and database to store information about resource actions. The CD Agent comprises sub-components to detect the different kinds of conflicts, direct, indirect, and implicit as per the O-RAN specification mentioned above. Before the actions requested by xApps can be executed, the near-RT RIC sends the request to the CMF for conflict mitigation. Their discussion and evaluation are limited to the xApps for MRO and MLB. While the results look promising, they need to also consider other xApps, such as the ones presented later in this article.

Wadud et al. propose using game theoretical approaches to resolve conflicts [20]. They integrate their components into the near-RT RIC similarly to the previously discussed work, by introducing conflict detection, conflict mitigation controllers (CDC and CMC respectively), and performance monitoring. This so-called conflict mitigation system (CMS) also leverages the near-RT RIC’s SDL. When a service degradation is detected, it is correlated with most recent parameter changes. The CDC informs the CMC about the degradation. The CMC deals with conflicts by “adopt[ing] cooperative game theory” [20]. Their approach appears to be primarily reactive, but is shown to also detect specific implicit conflicts.

3 O-RAN architecture assessment

In this section, we succinctly analyze the O-RAN Architecture as the basis for the development of the xApps from the perspective of an integrated near-RT network control and management solution.

As illustrated in Fig. 1, the O-RAN architecture [4] splits the existing RAN functionality across three network functions (NFs): O-RAN radio unit (O-RU) handling the wireless communication of the base station to the user equipment (UE), the O-RAN distributed unit (O-DU) which handles the lower-level protocols, and the CU which is further split into a user plane (CU-UP) and a control plane function (CU-CP). In the context of this study, we consider the O-RU equivalent to a RRH and will thus use both terms synonymously in the remainder of the text.

On top of the CU-CP which makes automatic real-time decisions concerning the connectivity of the subscribers, specifically handling the service continuity through signal-strength-based handovers and wireless resource allocation to the subscribers, two new RIC layers were proposed: a near-RT RIC [19] and a non-RT RIC [21] handling runtime network management operations with different time constraints. The two new RIC layers host a set of xApps and rApps respectively. xApps and rApps execute different optimizations on system parameters, UE handling policies, NF deployment, and new procedures for handling unforeseen situations. This includes self-optimization xApps such as MRO, UE QoS management, and load balancing (LB), and typical network management rApps such as fault, configuration, accounting, performance, and security management (FCAPS). A near-RT RIC platform exposes APIs to empower the xApps. The non-RT RIC is part of the O-RAN SMO layer shown to the right of Fig. 1. The rApps have access to a non-RT RIC framework. Further management functionality is provided by the SMO. It requests radio resource management operations from the near-RT RIC via the A1 interface. The O1 interface allows the SMO to manage and orchestrate the near-RT and RT components. The near-RT RIC communicates with the E2 nodes (CU-CP, CU-UP, O-DU, O-RU) via the E2 interface. CU-CP controls the CU-UP via the E1 interface. While the F1c and F1u interfaces connect the CU control and user plane components to DUs, the front-haul (FH) communication between O-DU and O-RU uses the open FH protocol.

The current architecture does not presume any communication between these xApps and rApps. Although the communication between non-real-time and near-real-time Apps would provide limited benefit, given the very different time scales, synchronization between the Apps at a certain level is of utmost importance, as they impact each other’s decisions and resulting actions in the same running system. This is especially important for xApps, whose overall impact is expected to be in the lower microsecond level.

For example, the MRO would aim to postpone handovers as long as possible and to camp UEs in RRHs with larger coverage, and QoS aims to provide the best RRH alternative to the UEs from the perspective of having more radio resources available in case the UE would need more resources, while the LB will distribute UEs towards the different RRHs. Although not completely orthogonal, the actions on the same UEs may result in contradicting decisions, ping-pong effects, overall system instability, and an increased number of overhead operations, as well as in a potentially less optimized system than without these optimizations.

Many of these xApps were proposed in the literature and prove their specific advantage, if they are alone in the system [4]. We cannot assume that commercial systems will include only a single xApp. The specifications for non-RT and near-RT RIC list conflict mitigation for rApps and xApps respectively among the provided functionality, but do not provide detailed information on how this should be implemented [14, 18, 21]. To allow the use of multiple xApps, an integrated approach should be provided. In the next sections, we will present such an approach.

Table 1 A classification of xApps with regard to goals and targeted management functionality
Full size table

4 An xApps classification

This section classifies xApps, to better understand their functionality and requirements. Most of the xApps proposed in the literature optimize one or a reduced set of parameters [6, 14]. A governance view of these optimizations should be considered. In this section, we classify the xApps by the type of optimization they are providing from the perspective of network management optimization goals [22]. These goals, abbreviated as PQRS+, primarily include, but can be extended in the future (hence the “+”), the following:

  • Performance (P): performance of the network from an operators perspective. Accomplishing better communication capabilities with the same deployment. Ultimately, this means serving more subscribers with less overhead. This is the main goal of any communications network system, as it reduces the costs of deployment and operation, while offering better services for the subscribers.

  • Quality (Q): the quality of the service offered to the subscribers, from the perspective of the subscribers: capacity, packet loss, communication delay, and reduced jitter.

  • Robustness (R): making the system more reliable and robust. Improving radio link robustness by allocating more resources, resulting in fewer link failures and fewer handovers. Reducing the amount of handovers, to improve connection stability and lower overhead. Introducing redundancy by establishing backup links to UEs and potentially in the FH. Ultimately, this can be achieved by consuming more resources per subscriber.

  • Security (S): adding more and more sophisticated security checks and additional functionality able to detect and mitigate potential attacks. This represents additional functionality in the system which ultimately reduces the achievable performance of a given deployment.

  • Energy efficiency (+): consuming less energy while offering the same service, potentially at the expense of performance (P) or quality (Q). Operations like stopping RRHs or reducing their transmission power provide certain benefits towards this goal. Ultimately, energy efficiency operations make the system appear “smaller” temporarily [23].

  • Others (+): additional goals not covered by the above, that do not warrant their own category.

Furthermore, the xApps can be classified, based on what layer in the network architecture they impact, into two major categories:

  • Topology management (TM): modifying the network itself through operations related to the radio head parameters, obtaining a different communication environment such as frequency allocation, transmission power, or beam-forming policies

  • User management (UM): modifying the UE communication parameters within a given topology, such as when and how to execute a handover, and which resources can be reserved

It is important to split the network optimizations against these two layers, as they ultimately relate to the expected procedure delay margins. Specifically, topology-related operations are expected to happen less frequently than subscriber-related ones, even in a highly dynamic environment. Per-subscriber-related ratios being customized for each connected device will impact them more than the topology ratios, which relate to the infrastructure.

We classify the xApps found in the literature, according to the previous criteria. Please note that this list is not exhaustive. Table 1 provides an overview of the classification.

4.1 4G SON applications adapted for 5G O-RAN

  • Automatic neighbor relations (P, T): enables automated configuration of RRHs to optimize network quality and capacity, i.e., network performance.

  • Interference management (R, T): maintaining an acceptable level of interference between different RRHs. As they pertain to the same central unit, this can be solved with automatic neighbor relations, however, related to the robustness of the network.

  • Capacity and coverage optimization (R, T): extending the RRH coverage to provide network availability in the complete environment and decreasing the RRH coverage in dense areas to provide extensive capacity.

  • Random access channel (RACH) optimization (P, T): allocation of random-access channels appropriate to expected new users in the network.

  • Mobile robust optimization (MRO) (R, U): optimize the inter-RRH handover of user devices and RRH reselection parameters reducing the interruptions and missed handovers.

  • Mobile load balancing (MLB) (Q, U): enables automated analysis and adjustment of traffic settings to optimize user throughput and ultimately manage network congestion.

  • Energy saving (+, T): consuming less energy by adapting transmission power levels, RF channel reconfiguration, carrier or cell switch on/off O-Cloud Resource Energy Saving Mode [23].

  • Cell split/merge/shape (PQR, T): modification of the network at the cell level. In this paper, we are concerned with deployments having a single cell with multiple RRHs.

  • Atmospheric interference (P, T): understanding the momentary interference of radio transmissions due to weather conditions and determining the appropriate adaptation of the cell.

  • Beam forming related optimizations, (PQR+, T): Several optimizations regarding how beam-forming policies function are related, such as grid of beams (GoB) or non-GoB parameterizations, as well as the extension of SON towards a beam-oriented environment.

4.2 User-service-related optimizations

  • Traffic steering (PQ, U): engineers the paths (i.e., selection of RRHs) of user/data plane traffic to increase the performance of the network and the quality offered to the users.

  • Admission control (Q, U): registration and resource allocation based on the subscription profile of the user adapted to the momentary network conditions.

  • QoS optimization (Q, U): dynamically adapting the allocated resources to a UE, depending on the network conditions related to the running applications.

  • Content-based dynamic handover (Q, U): selecting specific inter-RRH handovers depending on the content the UE requires, enabling content-based network scheduling.

  • Mobility path-based resource allocation (Q, U): pre-allocation of resources for a user on its mobility path to be able to maintain the quality of service.

  • Application-aware radio resource allocation (Q, U): a cross-layer application-level extension of the QoS optimization to also handle application information.

  • Cell camping association (R, U): allocation of RRHs to users in highly overlapping environments to reduce the number of needed handovers and maintain the UE continuity with the same binding.

  • UE tracking (PQR, U): tracking of the location of the UEs in the scope of mobility prediction and predictive understanding of resource consumption mobility.

  • UE connection manager (RQ, U): tracking the connectivity requirements of the UE from both mobility and QoS perspectives for increased user communication robustness and guaranteed quality.

4.3 Security xApps

As we are not aware of any xApps related to security, we propose the following, based on the potential functionality to be imported from the core network to the RAN.

  • Private service zones/private service access (S, TU): isolating part of the communication to some RRHs where higher security policies like additional encryption are maintained. This can provide an additional value to security-conscious applications and users.

  • Quarantine zones (S, U): isolating the communication of suspicious users to a specific set of RRHs where the data traffic is monitored more intensively. In cases of potential attacks or when lawful interception is required, this could be more resource-efficient, as only a part of the RAN would need to support the additional capabilities.

However, these xApps would separate the different security zones better, when implemented at the cell level.

4.4 Other xApps

Other apps considered in the literature not so easily classified due to various reasons are as follows:

  • Spectrum sharing (+, T): relates to the interaction and harmonization of multiple network deployments covering the same area.

  • RAN sharing/RAN slicing (+, T): using the same RAN for multiple networks.

  • Location service (+, U): a significantly important enabler for user-related xApps. However, such a service is not an xApp by itself. Instead, it is implemented as a core network service. This service can be optimized through the usage of different positioning algorithms.

  • Anomaly detection (PQRS+, TU): detecting anomalies represents one of the major use cases for machine learning enabling the network administrator to spot unusual behavior of the network or the users within the network and allowing optimizing through new configurations and policies of its functioning. Anomaly detection can cover any behavior of the system including the response to modifications by xApps.

Fig. 2
figure 2

Multi-layer and multi-criteria scheduler decisions

Full size image

5 Integrated O-RAN management framework

As illustrated in Fig. 2, to achieve the PQRS+ goals, three levels of network management functionality are considered, depending on which part of the network is managed.

For optimizations related to the network topology, we propose a high-level topology management (TM) function, which includes control loops related to modifications of the RAN environment. These loops make optimization decisions and enforce them on the running system, based on the current status of RAN, users, and related policies.

To be able to mitigate, potentially conflicting decisions between these control loops, a governance entity, able to interpret the global goals introduced by the administrator of the system and to mediate between the different control loops, is considered.

The TM scheduler has the most important role in these optimizations, as it defines the parameters of the running system. Similar to the 4G SON, it will execute a multi-criteria optimization of the network according to the goals previously described and as part of the O-RAN SMO FCAPS functionality, still in near real-time.

To reach some of these deployment optimizations, the UEs will have to be handed over or receive less capacity. For this, the TM has to be able to transmit commands to the user management (UM) high-level function, to adapt the system for the specific management level operations, for example, using the O-RAN O1 interface.

Also, the UM can transmit specific events, such as congestion or empty spaces in specific areas that should trigger topology changes, to the TM, which will enable it to make appropriate topology modifications.

The main role of the UM is to execute control loops at the user level. For each of its own decisions, the UM considers the network topology as static and tries to optimize the different goals by modifying the parameters of the different connected devices such as triggering handovers or QoS. These modifications are happening in near real-time and should not take priority or conflict with the lower service continuity (SC) functionality which is provided by the CU-CP radio resource control (RRC). The provided functionality is related to UE mobility and session control similar to the core network’s access and mobility management function (AMF) and session management function (SMF), but it is specifically oriented towards the RAN and cannot replace the core NFs.

The UM is receiving different decision information from the CU-CP RRC service continuity on real-time operations executed, such as reservation of additional resources and handovers, enabling the UM to have an accurate, near real-time understanding of the system. Furthermore, it would transmit its conditional and command decisions through the CU-CP RRC to the UE.

Both the TM and the UM will have to execute their multi-criteria optimization each using multiple control elements and optimizations. These can be selected from the ones available in the literature as described in the previous section.

First, with a limited granularity, the TM decisions are to be taken resulting in an optimized momentary topology. These decisions are triggered by the network situation as well as by the goal-oriented administration policies and at a minimal level by the UM requirements to change the topology. This is because user-related changes are significantly more frequent and require a closer real-time-ness.

Second, the UM has to define where to connect the different subscribers to reach the expected goals within the momentary topology [24]. For this, it has to consider optimizations of network performance and quality of the subscriber service by balancing the UEs across multiple RRHs, for example, increasing the communication robustness by handing over UEs to RRHs with larger coverage and reducing the energy consumption of the network by freeing RRHs and of the UEs by connecting them to the RRH where the least power is consumed. This implies that the scheduler has to provide an “optimum” across multiple criteria.

Third, continuously, the service continuity (SC) is assured by the RRC CU-CP layer. This implicitly takes into account the network topology as reflected in the signal strength resulting in automatic handovers from RRHs where the connectivity would potentially be lost to a target neighbor base station with the best signal.

6 Exposed RAN functionality

To be able to implement any of the xApps except the monitoring ones, the RAN components need to provide additional functionality. This is critical for the success of any O-RAN implementation. Only implementing the standard interfaces without the specific underlying functionality would make the xApps unusable, as they would be unable to automatically trigger system changes. In this regard, we have observed current implementations to be very fragmented. Each vendor implements only a specific subset of functionality in their O-RAN RIC implementations, effectively creating lock-ins. Although significant progress was made in the last years, the issue persists.

In this section, we discuss the functionality expected from the RAN from the perspective of goals achievable with the near-real-time RIC, in the order of importance.

6.1 Essential functionality

This category includes the functionality which should be exposed by the RAN, to cover a large number of the most promising xApps optimizations. Without this functionality, the system would be very static.

  • Inter-RRH handover control: Most of the user-related optimizations are based on the possibility to hand over the UE to a new RRH decided by other criteria than the service continuity. Especially in dense environments where multiple connectivity options are possible with similar signal strengths (e.g., RRHs in different frequencies highly overlapping like in indoor factory shop-floor environments), such flexibility would enable the UM to proactively schedule the UEs across the different options.

  • Resource allocation control: Current resource allocation enables only a division into best-effort maximum resource allocation and guaranteed resources. A more differentiated mechanism, where the resources allocated to the UEs are made in appropriate intervals, will enable more flexible usage of the wireless environment.

Most of the user management (UM) control loops can be executed, in network environments, where these functions are offered, resulting in significant advances towards reaching the network goals from the perspective of the offered service. Similar functionality was previously exposed at a higher level towards the core network, enabling subscriber control for inter-gNB management. However, with the centralization of the RAN, such functionality is now important also for intra-RAN optimizations.

6.2 Significant functionality

This category includes the functionality, that will provide the flexibility expected from an O-RAN environment. It includes the following:

  • Start/stop of RRHs: A drastic operation in the direction of topology changes and energy consumption.

  • Frequency allocations: How the different available frequencies are allocated to the RRHs, to allow mitigating interference.

  • Transmission power allocation: Defining the coverage for each RRH as well as the energy consumption.

  • Energy consumption: To be able to understand the energy usage and to optimize it through topology changes, such as the previous items.

  • Subscription profile/application profiles: information that should be provided by the core network, including what the user is allowed to receive as resources, as well as the requirements for handovers and service continuity.

  • Connectivity map: A historical-data-based map constructed from the learned connectivity and signal strength of the different RRHs, enabling the dynamic assessment of the environment.

  • UE position relative to RRHs: To assure that the Inter-RRH handovers are not executed against the service continuity decisions, the positioning of the UE within the connectivity map should be considered.

6.3 Further flexibility parameters

In this category, additional flexibility-related parameters are included which provide only specific limited optimizations:

  • RRH positions: Needed for the connectivity map in case the base stations are changing their locations, e.g., nomadic and network mobility scenarios.

  • Channel allocations: Optimization of the radio resource scheduling for highly variable usage.

  • Mobility and QoS usage predictions: Can significantly optimize the user management as well as the topology, requiring, however, intensive computation and back-off mechanisms, due to the incurred uncertainty.

  • Atmospheric conditions: A more granular adaptation of the topology would be possible when understanding the weather implications.

Fig. 3
figure 3

UM and TM internal structure implementation plan

Full size image

7 Open5GCore extensions and road map

The Fraunhofer FOKUS Open5GCore toolkit is a software-only implementation of the 3GPP 5G packet core network, designed for R &D activities [17]. It serves as a consistent basis for 5G test bed deployments in trials and pilots. Due to its very modular design, the Open5GCore is a well-suitable foundation for the development of new core network functionality. In this section, we propose the theoretical extensions and road map for an implementation of the TM and UM based on Open5GCore. The described implementation plan is shown in Fig. 3. Because the UM NF is ultimately an extended core NF handling specific external RAN control, we propose to implement it as an extension of the Open5GCore. Furthermore, the TM uses similar interfaces and requires the near real-time quality, so we also consider to develop it as a new Open5GCore NF.

First, to be able to demonstrate the proposed essential functionality, a comprehensive radio environment will be established. This environment will include a set of test-UEs capable of handing over based on RRC Reconfigure messages and an O-RAN base station able to receive E2-based commands. For the test bed to function, the base station must be able to connect RRHs either directly to a base-band unit or through a DU. Furthermore, the base station should allow for external commands to be received by the CU, especially to command external RRC messages. The E2 interface and the communication with the DU and the CU make the UM able to distribute control to its Near-RT RIC xApp. As the E2 interface is only a carrier of the specific information and not describing the actual information exchanged, it can ultimately be replaced by any other protocol, as long as the CU can handle the specific requests from the UM. However, such an interface would be proprietary for each solution, requiring a new implementation for each RAN CU and DU solution, losing the advantage brought by the standardized O-RAN architecture.

For the initial tests, we are assuming a static topology that can be adapted from the data path topology module already available in the SMF and used in the core network for user plane selections. Given this assumption, there is no need to implement the TM during the initial phase.

During the implementation of the UM, the relevant functionality from the Open5GCore’s AMF and SMF will be grouped and adapted into a new NF. Thus, the SBA interface between former AMF and SMF parts is removed. Furthermore, the core network’s NG-AP interface towards the RAN and NAS interface towards the UE will be replaced by an E2 interface towards the CU.

As most of the interfaces are available at this stage, the system can already be tested in a real radio environment using minimal schedulers, e.g., to hand over a single UE between RRHs in the same area.

It is to be noted that the only software component which has to be newly implemented is the interfacing to the RAN and the SMO; the rest of the functionality is available already in the Open5GCore.

Going further, using the already available monitoring system of the Open5GCore or the monitoring from the base station, basic UE profile analytics can be developed and incorporated into an evolved network data analytics functions (eNWDAF). The addition of the profile information will enable the extension of the UM scheduler with more granular information used to optimize the network against the criteria described in the previous section. This completes most of the functionality proposed for the UM, which would be enough for trials in statically deployed networks.

Alternatively, with the development of UE-centric communication, the access network discovery and selection policies (ANDSP) [25] managed by the Open5GCore Policy Control Function (PCF) can be used to transfer policies to the UE. However, this is highly dependent on finding a device capable of dynamically interpreting ANDSPs as standardized for inter-technology handovers and extending its functionality to accept intra-technology handover-related ones.

As a last step, a TM is added to the system, adding the dynamicity of the network itself by controlling the RRH power and frequency allocation. With this information, the UM scheduler will become also dynamic in terms of resources that can be scheduled.

In each of the steps, the UM scheduler will have to be extended with new methods and algorithms, to properly address the additional, more granular information of the system. Thus, the scheduler is expected to have more exact knowledge and will schedule the subscribers more appropriately.

8 Conclusions and further work

In this article, we have presented a framework designed to handle the xApps-based network management optimizations in a coherent and integrated manner, underlining the required RAN functionality, which has to be standardized in order to make such solutions function. Without an alignment of the RAN capabilities, the possibility to use the same near-real-time optimizations across different types of equipment would be drastically reduced, thus potentially creating a vendor lock-in.

To practically prove this functionality, a bottom-up implementation approach, starting with the implementation of the basic handling of the specific RAN parameters and the pushing of the xApp decisions to the appropriate decision points, will be taken. Parallel discussions with RAN providers to extend their component’s APIs will be pursued.

In future work, it has to be investigated, how this new framework can interact with the core network. Given the partially overlapping functionalities, a tighter coordination or even a convergence with the core network could be beneficial. Furthermore, the possibility of a contribution to the O-RAN alliance could be considered.