Conflict management for non-real-time RAN Intelligent Controller (RIC) and other optimized systems

Abstract

Embodiments of the present disclosure relate to collision management for non-real-time RAN Intelligent Controller (RIC) and other optimized systems. An example computing system includes a radio access network (RAN) intelligent controller (RIC). The RIC includes a storage medium configured to store configuration update information. The configuration update information includes one or more configuration parameters, and the configuration update information indicates a change in the one or more configuration parameters of the application through the RIC. The RIC includes a conflict manager. The conflict manager is configured to determine, based on the configuration update information, that a first parameter associated with one or more configuration parameters has been previously updated. The conflict manager is configured to determine a conflict based on the previously updated configuration parameters. The conflict manager is configured to apply a policy to determine to update the one or more configuration parameters based on determining the conflict, and update the one or more configuration parameters in accordance with the policy.

Description

[0001] This application claims priority to Greek application No. 20240100741, filed on October 21, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to computer networking, and more specifically, to conflict management and mitigation in mobile networks. Background Technology

[0003] Computer networks have become ubiquitous, and the number and types of network applications, network-connected devices, and network-connected devices are rapidly expanding. Such devices now include computers, smartphones, Internet of Things (IoT) devices, vehicles, medical equipment, factory equipment, and more. The fifth-generation (5G) mobile network architecture enhances the ability to provide communication services using cloud-based Network Functions Virtualization (NFV). Private networks can be created using the mobile network operator's Radio Access Network (RAN) combined with the core functions of 5G. For example, networks can be created for specific Service Level Agreements (SLAs), special use cases, or other specific requirements. Examples of such networks include private mobile networks, industrial networks, and dedicated networks for connected vehicles. Summary of the Invention

[0004] Generally, this disclosure describes a conflict management and mitigation framework for a RAN Intelligent Controller (RIC) for a mobile network's RAN and at least one other system (e.g., a non-Open-RAN or non-O-RAN system). The RIC includes or implements optimization algorithms based on the Open-RAN (O-RAN) system, for example, utilizing an application similar to rApp. The at least one other system includes legacy systems such as Centralized Self-Organizing Networks (C-SON), Distributed Self-Organizing Networks (D-SON), or any other system attempting to automatically or manually optimize RAN configuration parameters. Because network operators may wish to slowly migrate their networks from legacy systems to O-RAN systems, non-O-RAN and O-RAN systems can operate within the same network, potentially leading to conflicts when these different systems seek to optimize configuration parameters with different values.

[0005] C-SON can be configured to understand the topology, load, adjacency relationships, etc., of a group of base stations and can optimize the configuration parameters of that group of base stations. However, C-SON may take a relatively long time to implement any optimized configuration parameters. D-SON is configured to optimize the configuration parameters of an individual base station. Although D-SON may be more limited in the range of configuration parameter modifications, D-SON can make such changes much faster than C-SON.

[0006] Because network operators may use C-SON, D-SON, and / or other systems to attempt to optimize RAN configuration parameters, the addition of the O-RAN RIC, which may also include applications that optimize RAN configuration parameters, may inherently cause conflicts that should be managed. It should be noted that systems such as C-SON, D-SON, and / or others may not be configured according to the O-RAN standard, which may complicate conflict management and mitigation.

[0007] RAN conflict management and mitigation is a challenging problem, and there are no easy, obvious, and / or standard-defined solutions, leading to or requiring vendors to propose different solutions. Conflict management and mitigation has always been a common problem due to the introduction of different optimization algorithms (e.g., Self-Organizing Network (SON) algorithms) without a good solution, and this problem is further complicated by the O-RAN RIC architecture, the overlap between O-RAN RIC systems and SON systems, and the simultaneous existence and execution of multiple vendor applications (e.g., r / xApps). Furthermore, when network operators deploy O-RAN systems, such as non-real-time (non-RT) RICs, they may continue to run other systems, such as C-SON or D-SON systems for optimizing network configuration, instead of immediately upgrading the entire network to be O-RAN compatible. This can lead to conflicts not only between different rApps attempting to change RAN configuration parameters, but also between legacy equipment and rApps attempting to change configuration parameters. There is a need to manage these conflicts.

[0008] This disclosure describes a conflict management and mitigation framework and techniques that enable a non-RT RIC to collect information about optimization actions (e.g., configuration changes) performed by both (multiple) non-O-RAN systems and one or more rApps, allowing the non-RT RIC to detect and / or mitigate conflicts arising between the actions of (multiple) non-O-RAN systems and one or more rApps. Additionally, the techniques disclosed include new services exposed by the non-RT RIC, allowing external entities to inspect for potential conflicts with the non-RT RIC / rApp through open interfaces (e.g., O-RAN Service Management and Open (SME) interfaces or a well-defined set of Representational State Transmission (REST) ​​application programming interfaces).

[0009] The conflict management and mitigation framework described herein allows a conflict manager to subscribe to signals stored by a RIC. The conflict manager can be a component of a Service Management and Orchestration (SMO) framework and / or a non-RT RIC, for various enterprises, mobile network operators, or providers associated with a RAN managed by the RIC. The conflict manager can also be, or optionally, a separate application associated with various third parties, which can also be enterprises, mobile network operators, or providers. The conflict manager can also be, or optionally, an application of the RIC platform (e.g., rApp). The conflict manager can implement artificial intelligence (AI) and / or machine learning (ML) based methods to manage and mitigate conflicts. The RIC stores signals that can include messages transmitted via interfaces; events reported via interfaces; and / or actions guided and optionally reported via interfaces, where interfaces can include, for example, O1, A1, O2, and E2 interfaces. The RIC can store such signals in association with network state information representing the state of the mobile network at the time the signal occurs.

[0010] The Conflict Manager subscribes to the RIC to obtain signals (and optional associated network status information) deemed useful for conflict management and mitigation. Based on the obtained data, the Conflict Manager can identify conflicts. The Conflict Manager can then provide feedback and communicate directly or otherwise with the RIC to mitigate and / or manage the identified conflicts.

[0011] These technologies offer one or more technical advantages for implementing one or more practical applications. For example, the technology enables a dynamic and flexible approach to conflict mitigation and management, allowing for a slow migration from legacy technologies to newer O-RAN-based technologies while managing conflicts between legacy systems and RICs (including rApps). This provides conflict management and / or mitigation services across different technologies, thereby improving network operation by reducing one or more of resource contention, race conditions, or consistency issues that would otherwise prevent conflicts between different systems from being effectively managed and / or mitigated.

[0012] In one example, a computing system includes a Radio Access Network (RAN) Intelligent Controller (RIC), comprising: a Radio Access Network (RAN) Intelligent Controller (RIC) for managing the RAN, the RIC including: a storage medium configured to store configuration update information, the configuration update information including one or more configuration parameters and indicating changes to the one or more configuration parameters applied through the RIC; and a conflict manager configured to: determine, based on the configuration update information, that a first parameter associated with the one or more configuration parameters has previously been updated by a non-O-RAN computing system; determine a conflict based on the previously updated first parameter; apply a strategy for determining to update the one or more configuration parameters based on the determination of the conflict; and update the one or more configuration parameters according to the strategy.

[0013] In another example, a method includes: a Radio Access Network (RAN) Intelligent Controller (RIC) determining, based on configuration update information, that a first parameter associated with one or more configuration parameters has been previously updated, the configuration update information including the one or more configuration parameters and indicating a change in the one or more configuration parameters applied by the RIC; the RIC determining a conflict based on the previously updated first parameter; the RIC applying, based on the determination of the conflict, a strategy for determining to update the one or more configuration parameters; and the RIC updating the one or more configuration parameters according to the strategy.

[0014] In another example, a non-transient computer-readable medium stores instructions that, when executed, cause processing circuitry to: determine, based on configuration update information including the one or more configuration parameters, that a first parameter associated with one or more configuration parameters has been previously updated, and indicate a change in the one or more configuration parameters for an application via a Radio Access Network (RAN) Intelligent Controller (RIC); determine a conflict based on the previously updated first parameter; apply a strategy for determining to update the one or more configuration parameters based on the determination of the conflict; and update the one or more configuration parameters according to the strategy.

[0015] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will become apparent from the description and drawings and from the claims. Attached Figure Description

[0016] Figure 1A This is a block diagram illustrating an example network system configured to provide conflict management and mitigation between functions and / or services in a mobile network, according to one or more aspects of this disclosure.

[0017] Figure 1B This illustrates one or more aspects of this disclosure. Figure 1A A block diagram providing further example details of non-RT RIC service management and orchestration.

[0018] Figure 2 This is a block diagram illustrating in detail one or more aspects of an example computing system according to this disclosure.

[0019] Figure 3 This is a flowchart illustrating an example conflict management technique according to one or more aspects of this disclosure. Detailed Implementation

[0020] Figure 1A This is a block diagram illustrating an example network system 100 configured to provide conflict management and mitigation between functions and / or services in a mobile network, according to one or more aspects of this disclosure. Figure 1A In the example shown, network system 100 includes a Service and Management Orchestrator (SMO) 112, a non-RT RIC 122, a near-RT RIC 124, one or more Radio Access Networks (RANs) (e.g., RAN 109), and a mobile core network (or, simply, the “core”) 105, which provides user equipment 104A-104N (collectively, “UE 104”) with access to one or more applications or services provided by data network 140. Network system 100 also includes a RAN optimization system 115. RAN optimization system 115 may be an external system and / or part of RAN 109. In the example where RAN optimization system 115 is part of RAN 109, RAN optimization system 115 may be implemented in one or more CUs and / or DUs of RAN 109. RAN optimization system 115 may include one or more C-SONs, D-SONs, or any other system that attempts to optimize or otherwise modify the configuration parameters of RAN 109 or its components. In some examples, RAN optimization system 115 may include a manual system (e.g., user interface (UI)) that allows operators to manually update the configuration parameters of RAN 109.

[0021] SMO 112 can provide various framework functions (e.g., logical entities or modules providing a set of functions), such as a non-RT RIC 122 configured according to the O-RAN standard (which may be referred to as the "O-RAN architecture"), to manage and / or monitor various aspects of the RAN and / or 5G core. System 100, which may include an O-RAN architecture or serve as an example of an O-RAN architecture, may include a non-RT RIC 122 and a near-real-time RIC (near-RT RIC) 124, each performing different functions and services of the RAN. For example, the non-RT RIC 122 includes orchestration and automation functions, configured to provide radio resource management, high-level process optimization, policy optimization, and provide guidance, parameters, policies, and artificial intelligence (AI) and / or machine learning (ML) models to support the operation of near-RT RIC functions in the RAN. The non-RT RIC 122 may carry one or more applications (e.g., rApp) to provide non-real-time (e.g., greater than one second) control of RAN elements and their resources, while the near-RT RIC 124 may carry one or more applications (e.g., xApp) to provide near-real-time control of RAN elements and their resources. System 100 includes several interfaces, such as A1, O1, and O2 interfaces, which are used to provide functions and services that SMO 112 and RIC can use to configure or bootstrap other components of the RAN. For example, the functions and services of non-RT RIC 122 may include policy management services and / or enhanced information services for near-RT RIC 124 provided through the A1 interface (collectively referred to herein as “A1 services”, as they are provided through the A1 interface); operation, supervision, and management (OAM) services for O-RAN management elements provided through the O1 interface, such as performance management services and configuration management services (referred to herein as “O1 services”, as they are provided through the O1 interface); infrastructure management services and deployment management services for resources of the O-RAN cloud provided through the O2 interface (referred to herein as “O2 services”, as they are provided through the O2 interface) and / or other services, such as service management and openness (SME) services (e.g., service registration, service registration updates), data management and openness (DME) services, and / or AI / ML services.

[0022] UE 104 can represent smartphones, desktop computers, laptops, tablets, smartwatches, and / or "Internet of Things" (IoT) devices, such as cameras, sensors, televisions, appliances, etc. Figure 1AAs shown, network system 100 includes a RAN 109 that provides network access, data transmission, and other services to UE 104. In some examples, RAN 109 may be an Open Radio Access Network (O-RAN), a 5G mobile network RAN, a 4G Long Term Evolution (LTE) mobile network RAN, another type of RAN, or a combination thereof. For example, in a 5G radio access network, RAN 109 includes multiple cell sites (or, simply, "cells"), each cell site including radio equipment, such as base stations 106A-106M (collectively referred to as "base station 106"), also known as gNodeBs for 5G mobile networks, to exchange packetized data, thereby ultimately providing access to one or more applications or services provided by data network 140. Each base station 106 is divided into three functional components: a Radio Unit (RU), a Distributed Unit (DU), and a Central Unit (CU), which can be deployed in various configurations. The RU manages the radio frequency layer and has antenna arrays of various sizes and shapes. The DU performs low-layer protocol processing. The CU performs upper-layer protocol processing. Depending on the operator and service requirements, base station 106 can be deployed monolithically, such as with RUs, DUs, and CUs residing within a cell site, or these functions can be distributed across cell sites while the CU resides in an edge cloud site controlling multiple distributed DUs. For example, O-RAN is a networking approach where functional de-aggregation can be used to deploy mobile fronthaul and midhaul networks. Functional de-aggregation can be cloud-based. In some examples, RAN optimization system 115 can be implemented within RAN 109, for example, within one or more DUs or CUs.

[0023] Radio access network 109 connects to core 105 to exchange data packets with data network 140. Core 105 may be a 5G core network, while data network 140 may represent, for example, one or more service provider networks and services, the Internet, third-party services, one or more Internet Protocol (IP)-Virtual Private Networks (VPNs), IP Multimedia Subsystems, combinations of the above components, or other networks or combinations of networks. In some examples, resources associated with services provided to tenants by the mobile network operator may be provided or managed by the functions of core 105 and / or components of RAN 109. In some examples, core 105 implements various independent control plane and user plane functions of network system 100. Examples of 5G control plane functions that can be provided by core 105 include: Access Mobility Management Function (AMF) providing access mobility management services; Session Management Function (SMF) providing session management services; Policy Control Function (PCF) providing policy control services; User Data Management (UDM) providing network user data management; Network Storage Function (NRF) providing a storage that can be used for registration and discovery services in a network operator's network; Authentication Server Function (AUSF) providing authentication services; Network Slice Selection Function (NSSF); Network Slice Management Function (NSMF) providing the ability to select instances of available network slices for use by any UE device 104; and Network Slice Subnet Management Function (NSSMF) providing coordination, management, and orchestration of network slice subnet instances (NSSIs). Core 105 may also include User Plane Functions (UPF) providing packet routing, forwarding, and other network data processing functions (e.g., Quality of Service, packet inspection, traffic optimization, etc.). Further details regarding the services and functions provided by the 5G core network can be found in the 3G Partnership Technical Specification Group 2021, Services and Systems, entitled "System Architecture for 5G Systems (5GS) (Phase 2) (Release 17)" (TS 23.501 V17.0.0 (2021-03)), which was superseded by the 2021 Technical Specification Group 2021, Services and Systems, entitled "System Architecture for 5G Systems (5GS) (Phase 2) (Release 17)" (TS 23.501V18.2.2 (2023-07)), both of which are incorporated herein by reference in their entirety. Further details regarding the O-RAN architecture can be found in the O-RAN Alliance's "O-RAN Architecture Description" (Version 7.00, October 2022), the entire of which is incorporated herein by reference in its entirety.

[0024] Various aspects of RAN 109 and / or Core 105 can be managed and / or monitored by SMO 112, non-RT RIC 122, and near-RT RIC 124. In some examples, SMO 112, non-RT RIC 122, and near-RT RIC 124 can be operated by the mobile network operator providing 5G services to tenants. SMO 112 can orchestrate and control various management and automation aspects of RAN 109 (e.g., network slicing, management and orchestration of the Open Cloud (O-Cloud), etc.). Furthermore, SMO 112 can control various aspects of non-RT RIC 122 and near-RT RIC 124. Non-RT RIC 122 can provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (such as RUs, DUs, and CUs), workflow management, and policy-based control of applications and features of near-RT RIC 124. The near-RT RIC 124 can provide near real-time (e.g., millisecond) control and optimization of RAN elements and resources through fine-grained data collection and action. Figure 1B As further described, the non-RT RIC 122 and near-RT RIC 124 can be deployed as a highly scalable, microservice-based containerized architecture. In some examples, the near-RT RIC 124 can be located at the edge or in a regional cloud.

[0025] The non-RT RIC 122 can be integrated with one or more applications, such as application 123 that manages non-real-time events within the non-RT RIC 122 (e.g., Figure 1B Application 123 can utilize the functionality opened via the non-RT RIC framework of non-RT RIC 122. Application 123 can be used to control and manage RAN elements and resources, such as resources in near-RT RIC 124, RAN nodes, and / or the O-RAN cloud. Application 123 can also utilize network data, performance metrics, and subscriber data to provide recommendations for network optimization and operational guidance (e.g., policies) to one or more applications within near-RT RIC 124. Near-RT RIC 124 can integrate one or more applications, such as application 125, which manages near real-time events within near-RT RIC 124 (e.g., [missing information]). Figure 2(xApp). Application 125 can utilize the functionality opened by the near-RT RIC framework via near-RT RIC 124. Near-RT RIC 124 can implement policies received from application 123 of non-RT RIC 122 and can provide policy feedback to non-RT RIC 122. Although shown within non-RT RIC 122, any one or more of applications 123 can be executed by a third party separate from non-RT RIC 122. Similarly, although shown within near-RT RIC 124, any one or more of applications 125 can be executed by a third party separate from near-RT RIC 124. Although application 123 is shown separate from non-RT RIC 122, application 123 may, in some cases, include conflict manager 121 and other components supporting conflict manager 121, as described elsewhere in this document. In some examples, conflict manager 121 may be an rApp, an xApp, or implemented as part of non-RT RIC 122 or near-RT RIC 124.

[0026] Non-RT RIC 122 can provide services using the A1, O1, and O2 interfaces. The A1 interface connects the non-RT RIC 122 and the near-RT RIC 124. The non-RT RIC 122 can perform services via the A1 interface, such as policy management services (e.g., policy creation and updating), ML model management services, and / or enhancement information services. Services performed via the A1 interface are referred to herein as "A1 services." The O1 interface may include an interface connecting the SMO 112 to O-RAN managed elements, such as the near-RT RIC 124 and / or RAN nodes (e.g., O-RAN Centralized Unit (O-CU), O-RAN Distributed Unit (O-DU)). The non-RT RIC 122 can perform services via the O1 interface, such as configuration management and performance management services for O-RAN managed elements (e.g., Operations and Maintenance (OAM) services), fault monitoring, file management, heartbeat, tracing, Physical Network Function (PNF) discovery, software management, etc. Services performed via the O1 interface are referred to herein as "O1 services." The O2 interface may include an interface for connecting the SMO 112 to resources in the O-RAN O-cloud. The O-cloud may include one or more physical infrastructure nodes that host O-RAN functions (e.g., virtual network functions), support software components, and appropriate management and orchestration functions. The non-RT RIC 122 may perform services via the O2 interface, such as providing services for infrastructure management and / or network function deployment of resources in the O-cloud (e.g., O-cloud resource discovery and management; cloud / deployment scaling up and down; cloud / deployment fault, configuration, billing, performance, and security (FCAPS); cloud platform / deployment software management; creation / deletion of deployment-related allocated O-cloud resources). Services performed via the O2 interface are referred to herein as "O2 services." The non-RT RIC 122 may also perform other functions and services, such as Service Management and Openness (SME) services (e.g., service registration, service registration updates), Data Management and Openness (DME) services, AI / ML services, etc.

[0027] In some instances, functions and / or services provided by non-RT RIC 122 (e.g., A1 service, O1 service, O2 service, etc.) may conflict with services provided by RAN optimization system 115. In addition to services associated with different interfaces and functions associated with core network functions or RAN functions, the term "service" here may also include higher-order use cases or objectives, such as power-saving modes or slice service level agreement (SLA) guarantees.

[0028] Conflicts can be directly observed in framework functions such as non-RT RIC 122. Such conflicts may be referred to herein as “direct conflicts.” For example, an application in application 123 may request a specific setting for a target parameter, while RAN optimization system 115 may request a different setting for the same target parameter (e.g., application 123 requests a specific antenna tilt, while RAN optimization system 115 requests a different tilt for the same antenna). The target can be a configurable parameter, setting, object, or resource of the RAN, such as priority, policy, network slice, or network slice parameters. As another example, an application in application 123 may perform a change that conflicts with a previously requested runtime configuration from RAN optimization system 115 (or vice versa). Direct conflicts include conflicts involving the same parameters of a device or system. According to the techniques of this disclosure, direct conflicts can be directly observed by the control plane components of network system 100 by subscribing to configuration updates.

[0029] In some examples, conflicts may not be directly observable, but dependencies between the parameters and resources targeted by the application can be observed (referred to as "indirect conflicts" in this paper). For example, an application may perform changes that create system effects equivalent to changes performed by the RAN to optimize the system, and vice versa (e.g., the application performs different actions, but the effects on the system are equivalent). Indirect conflicts cannot be directly observed; however, some dependencies between parameters and resources can be observed.

[0030] The above are examples of conflict types, and only a few examples. Other conflicts may be observed in the control plane components of network system 100, such as conflicts that are not directly observed or conflicts where dependencies between applications are not obvious (referred to as "implicit conflicts"). Implicit conflicts cannot be directly observed. Different use cases may optimize different functions / different parameters, and may have implicit, undesirable, and / or detrimental side effects on other use cases.

[0031] There are different possible approaches to conflict mitigation. In some examples, direct conflicts can often be mitigated through pre-action coordination. Indirect conflicts can be resolved through post-action verification. Based on observations of network state that may include parameters of the network resource model, the system can determine potential corrections, such as rolling back one of the xApp or rApp actions. Implicit conflicts are the most difficult to mitigate because these dependencies are difficult or impossible to observe, and therefore difficult to model in any mitigation scheme. In some cases, this can be addressed by ensuring that use cases (implemented or supported by, for example, xApp or rApp) are designed around such conflicts with different parameters, thus returning to post-action verification. In some examples, network system 100 can implement one or more AI and / or ML models that can be trained on network data, such that the AI ​​and / or ML models can predict conflicts (including direct, indirect, and / or implicit conflicts), and conflict manager 121 can use the predicted conflicts to mitigate them through pre-action coordination.

[0032] According to the techniques described in this disclosure, network system 100 provides a conflict management and mitigation framework for non-RT RIC 122 managing RAN 109. In this example, SMO 112 includes a conflict manager 121 configured to provide conflict management for one or more non-RT RIC 122 functions or services. Figure 1A As shown, the conflict manager 121 may be a component of the SMO 112 associated with an affiliated enterprise, mobile network operator, and / or provider related to RAN 109. The conflict manager 121 may also be, or alternatively, a separate system associated with a third party, which may also be an enterprise, mobile network operator, and / or provider. The conflict manager 121 may also be, or alternatively, a component of a non-RT RIC 122 or a near-RT RIC 124. The conflict manager 121 may be pluggable within a scalable platform, such as a non-RT RIC 122 and / or SMO 112. The conflict manager 121 may include one or more AI and / or ML models. The conflict manager 121 may be implemented, for example, by one or more microservices. In some examples, the conflict manager 121 may be implemented in one or more applications 123.

[0033] The non-RT RIC 122 stores signals that may include messages transmitted via an interface; events reported via an interface; and / or actions initiated and optionally reported via an interface, wherein the interface may include, for example, the O1, A1, O2, and E2 interfaces defined by 3GPP and O-RAN standards. The non-RT RIC 122 may associate such signals with network state information representing the state of the mobile network at the time the signal occurs. The network state information may include telemetry information, network resource model data, or other data indicating network configuration status, operational status, and / or network performance. Thus, the non-RT RIC 122 captures events, messages, and / or actions of applications 123 and / or 125 (e.g., rApp and / or xApp) via the O1, A1, O2, and E2 interfaces. The conflict manager 121 obtains signals (and optionally associated network state information) stored by the non-RT RIC 122 that are determined to be useful for conflict management and mitigation.

[0034] Based on the acquired data, the conflict manager 121 can identify conflicts. The conflict manager 121 can then provide feedback and communicate directly or otherwise with the non-RT RIC 122 to mitigate and / or manage the identified conflicts.

[0035] While solutions for conflict management within O-RAN RICs and O-RAN applications are under development, no known solution addresses the potential conflicts between O-RAN RICs and non-O-RAN RIC systems (such as C-SON, D-SON, operator-triggered optimizations, and other external optimization systems). RAN-optimized systems, such as RAN-optimized system 115, may be slowly decommissioned rather than immediately replaced entirely by non-RT RICs and rApps. Long transition periods are possible, and in some cases, prolonged coexistence is possible. Thus, conflicts may arise between these two optimization systems (non-RT RIC 122 / rApp 123 and RAN-optimized system 115, e.g., conventional C-SON, D-SON, etc.).

[0036] For example, the non-RT RIC 122 can be configured to collect information about optimization actions (e.g., configuration changes) performed by the RAN optimization system 115, enabling the non-RT RIC 122 to detect and mitigate conflicts. In some examples, the non-RT RIC 122 can be configured to open new services, allowing external entities such as the RAN optimization system 115 to inspect for potential conflicts with the non-RT RIC 122 and / or rApp 123 via the SME interface.

[0037] Non-RT RIC 122 can subscribe to configuration update notifications using 3GPP (TS28.532) or O-RAN defined technologies. In this way, the non-RT RIC 122 can learn about or be notified of configuration parameters of RAN 109, which the RAN optimization system 115 can then modify or optimize. For example, if RAN-based nodes such as base stations, CUs, and DUs do not support 3GPP or O-RAN configuration update features, the non-RT RIC 122 can be configured to use a provider-specific configuration update notification API to learn about or be notified of configuration parameters of RAN 109 that the RAN optimization system 115 may modify or optimize. In some examples, operators can access this information via the RIC UI (…). Figure 1A (Not shown in the image) Manually enter configuration update notification information. In this case, the non-RT RIC 122 can be notified not only of standard-based and / or supplier-specific configuration updates, but also of operator-manual configuration updates.

[0038] The conflict manager 121 can process configuration update notifications from the RAN optimization system 115 for conflict detection purposes (e.g., via standards-based, vendor-specific, and / or manually entered techniques). The conflict manager can store configuration update requests (e.g., target node / cell ID, target configuration object, target attributes within the configuration object, etc.) or their information in tables, databases, etc., to enable conflict detection on rApp 123.

[0039] By capturing configuration changes made by the RAN optimization system 115, the non-RT RIC 122 can be used to detect potential conflicts between legacy systems such as the RAN optimization system 115 and rApp 123.

[0040] The non-RT RIC 122 can also monitor rApp 123 for any configuration updates that rApp 123 can perform or attempt to perform in RAN 109. The non-RT RIC 122 can store rApp configuration update requests or their information in, for example, tables or databases. Additionally or alternatively, the non-RT RIC 122 can subscribe to configuration updates from rApp 123, similar to subscribing to configuration updates from RAN optimization system 115. In this way, the conflict manager 121 of the non-RT RIC 122 can obtain information indicating which configuration parameters are being updated by RAN optimization system 115 and rApp 123.

[0041] For example, when RAN optimization system 115 performs a configuration update on RAN 109, a non-RT RIC detects the configuration update and can determine that the configuration update is conflicting based on information stored in tables or databases, indicating that another entity, such as a particular rApp, may have previously updated that specific parameter. Similarly, when a particular rApp performs a configuration update on RAN 109, non-RT RIC 122 detects the configuration update and can determine that the configuration update is conflicting based on information stored in tables or databases, indicating that RAN optimization system 115 has previously updated that specific parameter. In some examples, such previous updates include previous configuration updates to the same cell or base station as the configuration update.

[0042] Although this example is described with regard to direct conflict, it should be understood that the techniques disclosed herein can also be used to manage and / or mitigate indirect and / or implicit conflicts. In some examples, the non-RT RIC 122 may execute one or more artificial intelligence (AI) and / or machine learning (ML) models to determine indirect and / or implicit conflicts, and may store correspondences of parameters that may be involved in any indirect and / or implicit conflicts, such that the conflict manager 121 can manage and / or mitigate indirect and / or implicit conflicts.

[0043] In the example where rApp performs or seeks to perform parameter updates, after non-RT RIC 122 detects a conflict, non-RT RIC 122 can mitigate the conflict because it controls the actions of rApp 123. For example, non-RT RIC 122 can employ operator policies (e.g., operator conflict management policies), deterministic algorithms, AI and / or ML models, etc., to take action on changes that rApp attempts to make. Example operator policies may include "allow rApp to overwrite external systems," "disallow rApp to overwrite external systems," "time-based allow / disallow," etc. For example, a "allow rApp to overwrite external systems" policy would allow rApp to overwrite changes previously implemented by RAN optimization system 115. A "disallow rApp to overwrite external systems" policy would disallow rApp to overwrite changes previously implemented by RAN optimization system 115. A "time-based allow / disallow" policy would allow rApp to overwrite changes previously implemented by RAN optimization system 115 only during a specific time of day. It should be understood that many other types of policies can be implemented.

[0044] In an example where RAN optimization system 115 is performing or seeking a parameter update, non-RT RIC 122 may have very limited or no control over RAN optimization system 115. Thus, after non-RT RIC 122 detects a conflict, it can provide conflict guidance services to RAN optimization system 115 or the operator's UI, allowing RAN optimization system 115 and / or the operator to take action to check for conflicts with non-RT RIC 122 / rApp 123 before parameter updates, if needed. In some examples, conflict guidance can provide possible actions that can be taken to avoid conflicts. Where conflict guidance is not required before parameter updates, non-RT RIC 122 can provide conflict notification to RAN optimization system 115 or the operator's UI after the parameters have been updated.

[0045] In some examples, these technologies can be used for any interaction between an SMO 112 and an Operations Support System (OSS) / Business Support System (BSS), where any configuration updates made on the SMO or OSS / BSS system can be tracked, and conflicts can be detected and potentially mitigated.

[0046] For example, RAN optimization system 115 may issue commands to change antenna tilt configuration parameters to affect geographic coverage and / or interference. Such changes may negatively impact changes made by the rApp of application 123 for other reasons. This could be a conflict and could lead to a struggle between RAN optimization system 115 and rApp over continuous configuration changes to control antenna tilt. Other variable parameters may include cell identifiers identifying a given cell from other cells within the mobile network, tracking area codes, carrier frequencies, other antenna configuration parameters, cell reselection parameters, handover parameters, UE initial connectivity parameters, and System Information Block (SIB) parameters, etc.

[0047] In some examples, when the conflict manager 121 receives a notification of a change in configuration parameters via a configuration update subscription, the conflict manager 121 can determine whether any rApp has previously changed the same parameter (which may indicate a direct conflict) or related parameter that could cause an indirect or implicit conflict. If one of the rApps has previously changed the same or related parameter, the conflict manager 121 can determine a conflict.

[0048] In some examples, the base station can generate a notification of a configuration change. In some examples, the component management system can generate a notification of a configuration change.

[0049] When an rApp attempts to change configuration parameters, the conflict manager 121 can perform a lookup in a table or database to see if another entity (e.g., RAN optimization system 115, another rApp, etc.) has previously updated the same or related parameters. If another entity has previously updated the same or related parameters, the conflict manager 121 can allow or disallow the change, for example, based on an operator-defined policy. For example, an operator-defined policy can assign priorities to different devices or systems attempting to change parameters, and allow the change if the rApp has a higher priority than the device or system that made the previous change. For example, "Allow rApps to overwrite external systems" and "Disallow rApps to overwrite external systems" can be considered priority-based policies. In another example, an operator-defined policy could be a first-come, first-served policy, which prevents changes from occurring because another entity initiated the parameter change earlier.

[0050] Because the non-RT RIC 122 can subscribe to configuration updates, if the changes that rApp attempts to make conflict with previous changes, and the conflict manager 121 permits the changes, the non-RT RIC 122 can receive confirmation through the configuration update subscription that the parameters have been changed.

[0051] In some examples, the conflict manager 121 may utilize time constraints or parameters when determining whether a conflict exists. For example, if a change to a parameter was made at least a certain time ago or more ago, such a change may be considered unlikely to cause a conflict. This time constraint may be an operator-configurable parameter or may be determined by one or more AI and / or ML models based on network data, such as previous changes, network key performance indicators (KPIs), etc. For example, if network availability is always 99%, one or more AI and / or ML models may determine that there is no conflict even when a given configuration parameter is changed, and the time constraint may be relatively small. However, if such a change would negatively impact network availability, one or more AI and / or ML models may determine that the time constraint should be larger, or even identify less frequent changes to configuration parameters as conflicts.

[0052] For detailed information on conflict handling, please refer to U.S. Patent Publication 2024 / 0163649, published May 16, 2024, entitled “Conflict Management of Functions and Services”, and Greek Patent Application No. 20240100589, filed August 22, 2024, entitled “Framework for Conflict Management and Mitigation of RAN Intelligent Controller (RIC)”, the entire contents of which are incorporated herein by reference.

[0053] Figure 1B This illustrates one or more aspects of this disclosure. Figure 1A A block diagram showing the example details of the non-RT RIC 122. Figure 1B In the example shown, SMO 112 may include a non-RT RIC 122, one or more AI / ML models 142, one or more functions 144 (e.g., NSSMF, Network Function Management Function (NFMF), and other functions), and open interfaces such as O1 terminal interface 168 and O2 terminal interface 169. SMO 112 may manage resources in non-RT RIC 122, near-RT RIC 124, O-RAN management elements (e.g., centralized units (O-CUs) 146 and distributed units (O-DUs) 148 of one or more base stations), and O-RAN cloud 150.

[0054] The near-RT RIC 124 can provide near real-time (e.g., millisecond) control and optimization of RAN elements and resources (e.g., O-CU 146 and / or O-DU 148) via fine-grained data collection and actions performed via the E2 interface 165. For example, the near-RT RIC 124 can be equipped with one or more applications (e.g., xApp) that provide near real-time control of RAN elements and their resources.

[0055] The non-RT RIC 122 can provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (such as RU, DU, and CU), workflow management, and policy-based control of applications and features of the near-RT RIC 124.

[0056] The non-RT RIC 122 can be deployed as a highly scalable, microservices-based containerized architecture. In this example, the non-RT RIC 122 can mount, deploy, and / or terminate one or more applications, such as rApp 123A to rApp 123N (collectively, "Application 123"). Application 123 can represent an application that utilizes the functionality exposed via the framework of the non-RT RIC 122. Application 123 can provide the non-RT RIC 122 with non-real-time (e.g., longer than one second) control over RAN elements and their resources. Application 123 can provide services for radio resource management, high-level process optimization, policy optimization, and provide guidance, parameters, policies, and AI and / or ML models to support the operation of RAN functions.

[0057] For example, application 123 can provide A1 services that provide and facilitate the optimization of RAN operations and near-RT RIC 124, such as providing operational guidelines (e.g., policies), enhancement information (e.g., predictions), and AI / ML services. A1 services may include policy management services, such as creating, updating, and / or deleting A1 policies; receiving policy feedback; querying policy types, identifiers, and status; defining which policy types are supported by near-RT RIC 124; and registering near-RT RIC 124 applications (xApps) to specific policy types. A1 services may include enhancement information services, such as providing data for model training of AI and / or ML models, such as predictions and / or data analysis.

[0058] Application 123 can provide O1 services, which offer configuration or performance management for O-RAN managed entities (such as near-RT RIC 124 and / or RAN nodes, such as O-CU 146, O-DU 148 (also referred to herein as "E2 nodes")). O1 services can provide configuration management services to O-RAN managed entities to create, update, and / or delete configurations. For example, configuration management services may include provisioning operations (e.g., for Network Switching Subsystem (NSS) and Network Function (NF) provisioning) to create managed Object Instances (MOIs), obtain MOI attributes, modify MOI attributes, and / or delete MOIs. O1 services can also provide performance management services to monitor the status of elements or components within O-RAN managed entities. For example, non-RT RIC 122 can create, modify, or delete performance management jobs to receive performance metrics, or send heartbeat messages to monitor the status and / or availability of RAN node services, or send trace messages to monitor link failures. The O1 service can also provide file management, such as pushing files to RAN nodes (e.g., software updates, beamforming profiles, ML models, security certificates, etc.). As another example, the O1 service via O1 interface 166 can be used to configure network elements, including those modeled according to the information model defined in the new Radio Network Resource Model (NRNRM), as described in the 3rd Generation Partnership Project Technical Specification Group Services and Systems; Management and Orchestration; 5G Network Resource Model (NRM); Phase 2 & 3 (Release 18), TS28.541 V18.8.0 (June 2024), which is incorporated herein by reference in its entirety.

[0059] Application 123 can provide O2 services, which provide infrastructure management and / or network function deployment of resources in O-RAN Cloud 150 (also referred to herein as "O-Cloud 150"). O2 services can provide discovery and management of O-Cloud resources; scaling up and down of the cloud / deployment (e.g., deploying resources with more or fewer processors); FCAPS for the cloud / deployment; software management of the cloud platform / deployment; and creation / deletion of allocated O-Cloud resources associated with the deployment.

[0060] Applications 123 can provide Service Management and Openness (SME) services, Data Management and Openness (DME) services, and / or other services. SME services provide services that can be offered through the internal interface (R1 interface 154) of non-RT RIC 122, and achieve their openness and scalability through services including bootstrapping, service registration / deregistration or updates to service registration, service discovery or notification, heartbeat, authentication, and authorization. DME services can include services that manage data between applications 123 and their openness. For example, applications 123 can have different functionalities, such as application 123A configured to collect and analyze data, application 123B configured to generate ML models based on the analysis results, and application 123N configured to use ML models for prediction or inference and / or generate control over RAN nodes based on predictions or inferences. DME services can manage data shared between applications 123, such as data collection, data processing, and / or data advertising.

[0061] As already mentioned, application 123 may include conflict manager 121, and collection and publishing services 127.

[0062] The non-RT RIC 122 may include one or more managers that handle A1, O1, O2, SME, DME services, and other services. For example, the non-RT RIC 122 may include a policy manager 158, an O1 service manager 160, an O2 service manager 162, a service manager 163, a data manager 155, and a conflict manager 121. The non-RT RIC 122 may include other managers configured to manage the installation and deployment of application 123, such as application managers and application loader.

[0063] Policy manager 158 is configured to control the deployment of policies (e.g., A1 services). For example, in response to a request for an A1 service received from application 123 via R1 interface 154, R1 interface 154 sends the request to policy manager 158 via message bus 151. Policy manager 158 can process the A1 service and can send the A1 service to A1 terminal 156 via message bus 151, which in turn provides the A1 service to near-RT RIC 124 via A1 interface 164. In some examples, the A1 interface can implement the A1 Application Protocol (A1AP) based on the O-RAN specification.

[0064] O1 Service Manager 160 is configured to control the deployment of O1 services for monitoring the performance of near RT RIC 124 and / or RAN nodes (e.g., O-CU 146, O-DU 148). For example, in response to a request received from application 123 via R1 interface 154 for an O1 service to monitor the performance of near RT RIC 124, R1 interface 154 sends the request to O1 Service Manager 160 via message bus 151. O1 Service Manager 160 can process the O1 service and can send the O1 service to O1 terminal 168, which provides the O1 service to near RT RIC 124 via O1 interface 166. In some examples, the O1 interface can implement a REST / HTTPS API and / or a NETCONF protocol.

[0065] Alternatively or additionally, the O1 service manager 160 is configured to control the deployment of O1 services for the configuration of near RT RIC 124 and / or RAN nodes. For example, in response to a request for O1 services for the configuration of near RT RIC 124 received from application 123 via R1 interface 154, R1 interface 154 sends a request to O1 service manager 160. O1 service manager 160 can process the O1 services and can send the O1 services to O1 terminal 168, which provides the O1 services to near RT RIC 124 via O1 interface 166.

[0066] O2 Service Manager 162 can be configured to control the deployment of O2 services to monitor the performance of resources in O-Cloud 150. For example, in response to a request for an O2 service for monitoring the performance of resources within O-Cloud 150 received via R1 interface 154, R1 interface 154 sends the request to O2 Service Manager 162. O2 Service Manager 162 can process O2 services and can send O2 services to O2 Terminal 169, which provides O2 services to resources in O-Cloud 150 via O2 interface 167.

[0067] Alternatively or additionally, the O2 service manager 162 can be configured to control the deployment of O2 services for the configuration of resources within the O-cloud 150. For example, in response to a request received from application 123 via R1 interface 154 for an O2 service used to configure resources within the O-cloud 150, R1 interface 154 sends a request to the O2 service manager 162. The O2 service manager 162 can process the O2 service and can send the O2 service to O2 terminal 169, which provides the O2 service to the resources of the O-cloud 150 via O2 interface 167.

[0068] In some examples, R1 interface 154 also exposes application 123 to SME services, DME services, and / or other services. For example, in response to receiving a request for an SME service from application 123 via R1 interface 154, R1 interface 154 sends the request to service manager 163. Service manager 163 can handle SME services (e.g., registration / update services) and can send the SME services to R1 terminal 152, which provides the SME services to application 123 via R1 interface 154 (e.g., sending a response to the application regarding service registration, update, or discovery). Similarly, in response to receiving a request for a DME service from application 123 via R1 interface 154, R1 interface 154 sends the request to data manager 155. Data manager 155 can handle DME services and can send the DME services to R1 terminal 152, which provides the DME services to application 123 via R1 interface 154 (e.g., sending data from an application configured as a data producer to an application configured as a data consumer).

[0069] R1 interface 154 can also expose application 123 to slice subnet management services, such as the RAN NSSMF interface, to retrieve slice service level agreements (SLAs) and slice topology and / or slice management, SLAs, and slice performance management notifications for application 123.

[0070] According to the technology described in this disclosure, the conflict manager 121 and the collector and publisher 127 are services used to facilitate the conflict management discussed herein. The signal database 131 may include a storage medium and may store signal data related to the signal, optionally associated with network state information representing the mobile network state at the time the signal occurred. The signal database 126 may represent a redistribution database, a Structured Query Language (SQL) database, another database, a file, a table, a log, or other data structure stored on the storage medium. The conflict manager 121 and the collector and publisher service 127 may be a microservice or other containerized application, virtual machine, process, and / or other type of deployable software.

[0071] In the example shown, the non-RT RIC 122 can monitor signals exchanged between the manager / service and application 123 via message bus 151, and additionally send these signals to the collector and publisher service 127. The collector and publisher service 127 collects these O1, A1, O2, and E2 interface signals from the RIC, combines them, and stores these signals along with other applicable state information about the network in the signal database 131.

[0072] The collector and publisher service 127 uses (optionally open) interfaces to provide these signals to authorized conflict managers 121 or other applications not part of RT RIC 122, or to plugins for third-party applications. The open interfaces support future replacements and / or upgrades of conflict managers 121 to continuously improve conflict management and mitigation capabilities, including the adoption of AI and / or ML-based conflict management and mitigation technologies to achieve dynamically scalable conflict management and mitigation approaches. Although only one conflict manager 121 is shown, other conflict managers (e.g., associated with other operators or users) can be authorized to receive signals for analysis and / or conflict mitigation and management. Conflict managers 121 can subscribe to the collector and publisher service 127 to receive signals. This subscription framework can adopt a publish / subscribe model, where the collector and publisher service 127 publishes selected signals and associated network status information to specific topics for conflict managers 121, message buses, or other frameworks to subscribe to. Conflict managers 121 can subscribe to specific subsets of signals, such as signals associated with specific O1, A1, O2, or E2 interfaces, or signals associated with specific network elements or information models.

[0073] Conflict manager 121 processes signals obtained from signal database 131, and once a conflict is detected, it interacts with non-RT RIC 122 regarding possible conflict avoidance and mitigation strategies. For non-RT RIC 122, the collector and publisher service 127 and conflict manager 121 may interact via (optionally open) interfaces to enable future replacement of these services and / or applications. The open interface may be an interface implemented according to open standards or a non-proprietary interface. Conflict manager 121 may implement AI and / or ML-based conflict management and mitigation strategies.

[0074] For example, Conflict Manager 121 is configured to provide conflict management for the corresponding interfaces(s) of Non-RT RIC 122. While Conflict Manager 121 is shown as a separate microservice of Non-RT RIC 122, in some examples, the techniques described herein can be performed by one or more other microservices, such as Policy Manager 158, O1 Service Manager 160, O2 Service Manager 162, Service Manager 163, and / or Data Manager 155. In this example, in response to receiving a request from A1 Service, O1 Service, O2 Service, or other services (e.g., SME, DME), R1 Terminal 152 can send a message to Conflict Manager 121 via Message Bus 151 to perform conflict management for A1 Service, O1 Service, O2 Service, or other services.

[0075] Figure 2 This is a block diagram illustrating in detail an example computing system according to one or more aspects of this disclosure. Figure 2 In the example, computing system 200 can implement, for example, non-real-time RIC, such as Figure 1A-1B The non-RT RIC 122. The conflict manager 121, signal database 131, and collection and dissemination service 127 may be part of the RIC platform or deployed to a separate computing system and communicate via the RIC platform over a network.

[0076] Computing system 200 includes one or more processors 220, one or more input devices 222, one or more output devices 223, one or more communication units 219, and one or more storage devices 221. In some examples, computing system 200 is a cloud computing system, server farm, and / or server cluster (or a portion thereof) that provides services to client devices and other devices or systems. In other examples, computing system 200 may be implemented using one or more virtualized computing instances (e.g., virtual machines, containers) of a data center, cloud computing system, server farm, and / or server cluster.

[0077] One or more devices, modules, storage areas, or other components of the computing system 200 can be interconnected to enable inter-component (physical, communicative, and / or operative) communication. In some examples, this connectivity can be achieved via communication channels, system buses (e.g., Figure 1B The message bus (151), network connection, inter-process communication data structure, or any other method for communicating data is provided.

[0078] One or more processors 220 of the computing system 200 may implement functions and / or execute instructions associated with conflict management of a non-RT RIC or with one or more modules shown and / or described herein, including application 123, policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, data manager 155, and conflict manager 121. The one or more processors 220 may be, may be part of, and / or may include processing circuitry performing operations according to one or more aspects of this disclosure. Examples of processors 220 include microprocessors, application processors, display controllers, auxiliary processors, one or more sensor hubs, and any other hardware configured to function as a processor, processing unit, or processing device. The computing system 200 may use one or more processors 220 to perform operations according to one or more aspects of this disclosure using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and / or executing at the computing system 200. Application 123, Policy Manager 158, O1 Service Manager 160, O2 Service Manager 162, Service Manager 163, Data Manager 155, Conflict Manager 121, Signal Database 131, or Collection and Publisher Service 127 may be hosted by a cloud provider or other third party.

[0079] One or more communication units 219 of computing system 200 can communicate with devices outside computing system 200 by sending and / or receiving data, and in some respects can operate as both an input device and an output device. In some examples, communication unit 219 can communicate with other devices via a network. In other examples, communication unit 219 can send and / or receive radio signals on a wireless network such as a cellular wireless network. In other examples, communication unit 219 of computing system 200 can send and / or receive satellite signals on a satellite network such as a Global Positioning System (GPS) network. Examples of communication unit 219 include network interface cards (e.g., Ethernet cards), optical transceivers, radio frequency transceivers, GPS receivers, or any other type of device capable of sending and / or receiving information. Other examples of communication unit 219 may include devices capable of communicating via Bluetooth®, GPS, NFC, ZigBee, and cellular networks (e.g., 3G, 4G, 5G), as well as Wi-Fi® radios in mobile devices, and Universal Serial Bus (USB) controllers, etc. Such communication may follow, implement, or comply with appropriate protocols, including Transmission Control Protocol / Internet Protocol (TCP / IP), Ethernet, Bluetooth, Near Field Communication (NFC), or other technologies or protocols.

[0080] One or more input devices 222 can represent any input device of the computing system 200 that is not otherwise separately described herein. One or more input devices 222 can generate, receive, and / or process input for any type of device capable of detecting input from humans or machines. For example, one or more input devices 222 can generate, receive, and / or process input in the form of electrical, physical, audio, image, and / or visual input (e.g., peripherals, keyboards, microphones, cameras).

[0081] One or more output devices 223 may represent any output device of the computing system 200 that is not otherwise separately described herein. One or more output devices 223 may generate, send, and / or process output for any type of device capable of detecting output from a person or machine. For example, one or more output devices 223 may generate, send, and / or process output in the form of electrical and / or physical outputs (e.g., peripheral devices, actuators).

[0082] One or more storage devices 221 within the computing system 200 may store information for processing during operation of the computing system 200. Storage devices 221 may store program instructions and / or data associated with one or more modules described according to one or more aspects of this disclosure. One or more processors 220 and one or more storage devices 221 may provide an operating environment or platform for these modules, which may be implemented as software, but in some examples may include any combination of hardware, firmware, and software. One or more processors 220 may execute instructions, and one or more storage devices 221 may store instructions and / or data of one or more modules. The combination of processors 220 and storage devices 221 may retrieve, store, and / or execute instructions and / or data of one or more applications, modules, or software. Processors 220 and / or storage devices 221 may also be operatively coupled to one or more other software and / or hardware components, including but not limited to one or more components of the computing system 200 and / or one or more devices or systems shown as connected to the computing system 200.

[0083] In some examples, one or more storage devices 221 are temporary storage, meaning that the primary purpose of the one or more storage devices is not long-term storage. The storage device 221 of the computing system 200 can be configured as volatile memory for short-term storage of information, and therefore the stored content is not retained if it is deactivated. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, the storage device 221 also includes one or more computer-readable storage media. The storage device 221 can be configured to store a larger amount of information than volatile memory. The storage device 221 can also be configured to long-term store information in non-volatile memory space and retain information after an on / off cycle. Examples of non-volatile memory include magnetic hard disks, optical disks, flash memory, or electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM).

[0084] The computing system 200 can provide conflict management for application 123. As described above, application 123 can manage non-real-time events within the non-RT RIC 122, such as applications that do not require a response time of less than one second. Application 123 can utilize the functionality exposed by the non-RT RIC framework via the computing device 200. Application 123 can be used to control and manage RAN elements and resources, such as resources in near-RT RICs, RAN nodes, and / or the O-RAN cloud. Application 123 can provide one or more services executed using interfaces of the computing system 200 (e.g., A1 interface, O1 interface, O2 interface, etc.). For example, application 123 may include services such as policies 232 for near-RT RICs, configuration instructions 234 for elements managed by O-RAN, performance operations 236 for elements managed by O-RAN, and services for management services and / or data 238.

[0085] The computing system 200 may include one or more modules or units configured to perform one or more services or functions of the application 123, such as the policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, data manager 155 and conflict manager 121 as described above.

[0086] For example, policy manager 158 is configured to control the deployment of policies (e.g., service A1). For example, policy manager 158 can receive requests for service A1 from application 123 (e.g., via...). Figure 1B The R1 interface 154 handles the A1 service from application 123, and uses the A1 interface (e.g., Figure 1BThe A1 interface (164) executes A1 services for near-RT RIC. In some examples, the A1 interface can implement the A1AP application protocol based on the 3GPP framework.

[0087] The O1 Service Manager 160 is configured to control the deployment of O1 services for monitoring O-RAN managed components (e.g., Figure 1B The performance of near-RT RIC 124, O-CU 146, O-DU 148. For example, O1 service manager 160 can obtain data from application 123 (e.g., via...). Figure 1B The R1 interface 154 receives requests for the O1 service used to monitor the performance of the near-RT RIC, processes the O1 service, and uses the O1 interface (e.g., Figure 1B The O1 interface (166) performs O1 services for O-RAN-managed components. In some examples, the O1 interface can implement REST / HTTPS APIs and / or NETCONF.

[0088] Additionally or alternatively, the O1 service manager 160 is configured to control the deployment of O1 services for configuration near RTRIC 124 and / or RAN nodes. For example, the O1 service manager 160 can control the deployment of O1 services from application 123 (e.g., via...). Figure 1B The R1 interface 154 receives requests for O1 services for configuring elements used for O-RAN management, processes O1 services, and can use the O1 interface (e.g., Figure 1B The O1 interface (166) is used to perform O1 services for elements used for O-RAN management.

[0089] O2 Service Manager 162 can be configured to control the deployment of O2 services to monitor the performance of resources in the O-RAN cloud. For example, O2 Service Manager 162 can receive requests for O2 services used to monitor the performance of resources within the O-RAN cloud (e.g., via...). Figure 1B The R1 interface 154), handles O2 services, and can use the O2 interface (e.g., Figure 1B The O2 interface 167) performs O2 services on resources in the O-RAN cloud.

[0090] Alternatively or additionally, the O2 service manager 162 can be configured to control the deployment of O2 services for the configuration of resources in the O-RAN cloud. For example, the O2 service manager 162 can control the deployment of O2 services from application 123 (e.g., via...). Figure 1B The R1 interface 154 receives requests for O2 services used to configure resources within the O-RAN cloud, processes O2 services, and can use the O2 interface (e.g., Figure 1B The O2 interface 167) performs O2 services on resources in the O-RAN cloud.

[0091] Service Manager 163 is configured to manage services, such as service registration, service registration updates, and service discovery. For example, Service Manager 163 can receive requests for the SME service from application 123 (e.g., via...). Figure 1B The R1 interface 154) performs SME services (e.g., registration / update services) for one or more applications 123, and uses the R1 interface (e.g., Figure 1B The R1 interface 154 sends a response to one or more applications 123.

[0092] Data manager 155 is configured to manage data from application 123. For example, data manager 155 can receive requests for DME services from application 123 (e.g., via...). Figure 1B The R1 interface 154) performs DME services for one or more applications 123 (e.g., sending data from an application configured as a data producer to an application configured as a data consumer), and uses the R1 interface (e.g., Figure 1B The R1 interface 154 sends a response to one or more applications 123.

[0093] The computing system 200 includes a conflict manager 121 configured to provide conflict management to services that execute using a non-RT RIC interface. In this example, the conflict manager 121 includes an analysis engine 240, an action engine 242, and one or more conflict management rules 244.

[0094] In some examples, the analytics engine 240 is configured to determine that services may have conflicts. For example, the analytics engine 240 may be configured to determine whether overlapping policies (e.g., where at least a portion of the policy scope overlaps) include contradictory statements (e.g., target / resource statements) of A1 services executed using the A1 interface. In some examples, the analytics engine 240 is configured to determine whether requests to configure one or more O-RAN-managed elements executed using the O1 interface or one or more resources of the O-RAN cloud executed using the O2 interface would cause conflicts (e.g., conflicting MOIs). In some examples, the analytics engine 240 is configured to determine whether requests to performance jobs executed using the O1 interface or one or more O-RAN-managed elements or one or more resources of the O-RAN cloud executed using the O2 interface would cause conflicts (e.g., interoperability compliance (IOC) and attribute overlap, contradictory attribute value changes, specifying different data networks, etc.).

[0095] In response to the determination that a service has a conflict, action engine 242 is configured to resolve the determined conflict. For example, action engine 242 may implement the service based on one or more rules 129. In addition to or as an alternative to the above description, rule 129 may include, for example, implementing a policy based on a first-come, first-served basis, implementing a policy from an application with higher priority, implementing a policy based on policy scope, implementing a policy based on IOC type, or implementing a policy based on both IOC type and IOC attribute.

[0096] In some examples, the user can specify which rules 129 to apply to resolve conflicts via UI module 286, or add or modify rules 129. UI module 286 can generate data indicating various user interface screens that graphically depict the conflict management rules. UI module 286 can output, for example, data indicating various user interface screens for display on a separate display device. UI module 286 can also output data for display, indicating graphical user interface elements requesting input. For example, the input could be conflict management rules to be applied to a specific service, query, or other input.

[0097] Figure 3 This is a flowchart illustrating an example conflict management technique according to one or more aspects of this disclosure. In some examples, the conflict manager 121 may obtain configuration update information. For example, the conflict manager 121 may read configuration update information from a signal database 131, or receive configuration update information from a message bus 151, R1 terminal 152, O1 terminal 168, O2 terminal 169, A1 terminal 156, UI 286, etc. The configuration update information may include one or more configuration parameters and indicates (e.g., of application 123) changes to one or more configuration parameters by the rApp. For example, the configuration update information may include information about the configuration updates that the rApp is attempting to make.

[0098] The conflict manager 121 can determine, based on configuration update information, that a first parameter associated with one or more configuration parameters has been previously updated (302). For example, the conflict manager 121 can look up parameters in the configuration update information (which may indicate a direct conflict) and / or parameters associated with one or more parameters (which may indicate an indirect or implicit conflict) in the signal database 131 to determine whether the parameter has been previously updated. In some examples, this determination may be time-limited, indicating that it was previously updated within a specific time period, rather than indicating that it was ever updated.

[0099] The conflict manager 121 can determine a conflict (304) based on a previously updated first parameter. For example, the conflict manager 121 can determine the existence of a direct conflict, an indirect conflict, and / or an implicit conflict based on a previously updated first parameter.

[0100] Based on the identified conflict, the conflict manager 121 can apply a policy (306) to determine whether to update one or more configuration parameters. For example, the conflict manager 121 can apply a policy to determine whether to update one or more configuration parameters, and based on that policy, determine that one or more configuration parameters should be updated.

[0101] The conflict manager 121 can update one or more configuration parameters (308) according to a policy. For example, the conflict manager 121 can apply a policy and update (or not update) one or more configuration parameters according to that policy.

[0102] In some examples, the policy includes an operator conflict management policy. In some examples, the conflict manager 121 is configured to obtain configuration update information via a configuration update subscription service. In some examples, the configuration update subscription service and the corresponding notification service operate according to at least one of the Open-RAN or 3GPP standards.

[0103] In some examples, to determine that the first parameter has been previously updated, the conflict manager 121 is configured to determine that the first parameter has been previously updated for the same cell or base station within a time period. In other words, updating the first parameter for the same cell or base station will be affected by changes associated with configuration update information within the time period. In some examples, this time period includes a user-defined time period or a time period determined by one or more artificial intelligence or machine learning models. In such examples, "previous" will be time-limited. For example, the conflict manager 121 may determine that the first parameter was updated within the time period (e.g., within the past 24 hours), rather than determining whether the first parameter has ever been updated. In some examples, to determine that the first parameter has been previously updated within the time period, the conflict manager is configured to look for changes to the first parameter in storage media (e.g., signal database 131).

[0104] In some examples, computing system 200 includes one or more processors 220. In some examples, conflict manager 121 is also configured to: determine whether configuration update information is associated with recommended configuration updates from applications in the RIC; and to apply policies based on the recommended configuration updates from applications in the RIC.

[0105] In some examples, the configuration update information is first configuration update information. In some examples, the one or more configuration parameters are first or more configuration parameters. In some examples, the conflict is a first conflict. In some examples, the conflict manager 121 is configured to determine, based on second configuration update information, that a second parameter associated with a second or more configuration parameter has been previously updated, the second configuration update information including the second or more configuration parameters and indicating changes to the second or more configuration parameters by a non-O-RAN computing system (e.g., RAN optimization system 115). In some examples, the conflict manager 121 is configured to determine a second conflict based on the previously updated second parameter. In some examples, the conflict manager 121 is configured to send a notification indicating a second conflict to the non-O-RAN computing system based on the determination of a second conflict (e.g., determining that a second conflict exists and is associated with a proposed configuration update from a non-O-RAN computing system).

[0106] In some examples, the second configuration update information includes information about the proposed configuration update. In some examples, the notification includes conflict guidance. In some examples, the non-O-RAN computing system (e.g., RAN optimization system 115) includes a centralized self-organizing network (C-SON) or a distributed self-organizing network (D-SON).

[0107] In some examples, the conflict manager 121 is configured to obtain second configuration update information via a configuration update subscription service, a supplier-specific application programming interface (API), or a user interface (UI). In some examples, the configuration update subscription service and the corresponding notification service operate according to at least one of the Open-RAN or 3GPP standards.

[0108] The techniques described in this disclosure can be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, aspects of the described techniques can be implemented within one or more programmable processors, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuits, and any combination of such components. The terms "processor" or "processing circuitry" can generally refer to any of the aforementioned logic circuits, alone or in combination with other logic circuits or any other equivalent circuitry. A control unit, including hardware, can also perform one or more of the techniques described in this disclosure.

[0109] Such hardware, software, and firmware can be implemented within the same device or in separate devices to support the various operations and functions described in this disclosure. Additionally, any of the described units, modules, or components can be implemented together or individually as discrete but interoperable logical devices. Describing different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that these modules or units must be implemented by separate hardware or software components. Rather, the functionality associated with one or more modules or units can be performed by separate hardware or software components or integrated within common or separate hardware or software components.

[0110] The techniques described in this disclosure can also be implemented or encoded in a computer-readable medium (e.g., a computer-readable storage medium) containing instructions. Instructions embedded or encoded in a computer-readable medium can cause a programmable processor or other processor to perform the methods, for example, when the instructions are executed. Computer-readable media can include non-transitory computer-readable storage media and transient communication media. Tangible and non-transitory computer-readable storage media can include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, magnetic tape, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, not a signal, carrier, or other transient medium.

Claims

1. A computer system, comprising: A Radio Access Network (RAN) Intelligent Controller (RIC) for managing the RAN, the RIC comprising: A storage medium configured to store configuration update information, the configuration update information including one or more configuration parameters, and the configuration update information indicating changes to the one or more configuration parameters applied through the RIC; and The conflict manager is configured as follows: Based on the configuration update information, it is determined that a first parameter associated with the one or more configuration parameters has been previously updated by a non-O-RAN computing system; The conflict is determined based on the previously updated first parameter; Based on the determination of the conflict, a strategy is applied to determine the updating of the one or more configuration parameters; and Update one or more configuration parameters according to the strategy.

2. The computing system according to claim 1, wherein the strategy includes an operator conflict management strategy.

3. The computing system of claim 1, wherein the conflict manager is configured to obtain the configuration update information via a configuration update subscription service.

4. The computing system according to claim 3, wherein the configuration update subscription service and the corresponding notification service operate according to at least one of Open-RAN or 3GPP standards.

5. The computing system of claim 1, wherein, in order to determine that the first parameter has been previously updated, the conflict manager is configured to determine that the first parameter has been previously updated for the same cell or base station within a time period, and wherein the time period includes a user-defined time period or a time period determined by one or more artificial intelligence or machine learning models.

6. The computing system of claim 5, wherein, in order to determine that the first parameter has been previously updated during the time period, the conflict manager is configured to search for changes to the first parameter in the storage medium.

7. The computing system of claim 1, wherein the conflict manager is further configured to: Determine that the configuration update information is associated with the suggested configuration update for the application from the RIC; and The policy is applied based on the recommended configuration update from the application in the RIC.

8. The computing system of claim 1, wherein the configuration update information is first configuration update information, the one or more configuration parameters are first or more configuration parameters, and the conflict is a first conflict, and wherein the conflict manager is further configured to: Based on the second configuration update information, it is determined that a second parameter associated with a second or more configuration parameters has been previously updated. The second configuration update information includes the second or more configuration parameters and indicates a change in the second or more configuration parameters through a non-O-RAN computing system. The second conflict is determined based on the previously updated second parameter; as well as Based on the determination of the second conflict, a notification indicating the second conflict is sent to the non-O-RAN computing system.

9. The computing system of claim 8, wherein the second configuration update information includes information about a proposed configuration update, and wherein the notification includes conflict guidance.

10. The computing system of claim 8, wherein the non-O-RAN computing system comprises a centralized self-organizing network (C-SON) or a distributed self-organizing network (D-SON).

11. The computing system of claim 8, wherein the conflict manager is configured to obtain the second configuration update information via a configuration update subscription service, a provider-specific application programming interface (API), or a user interface (UI).

12. The computing system of claim 8, wherein the configuration update subscription service and the corresponding notification service operate according to at least one of Open-RAN or 3GPP standards.

13. A method comprising: The Radio Access Network (RAN) Intelligent Controller (RIC) determines, based on configuration update information, that a first parameter associated with one or more configuration parameters has been previously updated, the configuration update information including the one or more configuration parameters, and the configuration update information indicating the change of the one or more configuration parameters applied through the RIC; The conflict is determined by the RIC based on the previously updated first parameter; The RIC, based on the determination of the conflict, applies a strategy to determine the updating of the one or more configuration parameters; as well as The RIC updates one or more configuration parameters according to the policy.

14. The method of claim 13, wherein the strategy includes an operator conflict management strategy.

15. The method of claim 13, wherein obtaining the configuration update information comprises: The configuration update information is obtained through the configuration update subscription service.

16. The method of claim 15, wherein the configuration update subscription service and the corresponding notification service operate according to at least one of Open-RAN or 3GPP standards.

17. The method of claim 13, wherein determining that the first parameter has been previously updated comprises: It is determined that the first parameter has been previously updated for the same cell or base station within a time period, and the time period includes a user-defined time period or a time period determined by one or more artificial intelligence or machine learning models.

18. The method of claim 13, further comprising: Determine that the configuration update information is associated with the recommended configuration update for the application from the RIC; as well as The policy is applied based on the recommended configuration update from the application in the RIC.

19. The method of claim 13, wherein the configuration update information is first configuration update information, the one or more configuration parameters are first or more configuration parameters, and the conflict is a first conflict, and wherein the method further comprises: The RIC determines, based on second configuration update information, that a second parameter associated with a second or more configuration parameters has been previously updated, the second configuration update information including the second or more configuration parameters, and the second configuration update information indicating a change in the second or more configuration parameters through a non-O-RAN computing system; The RIC determines the second conflict based on the previously updated second parameter; as well as The RIC sends a notification indicating the second conflict to the non-O-RAN computing system based on the determination of the second conflict.

20. A non-transient computer-readable medium, the non-transient computer-readable medium comprising instructions that, when executed, cause processing circuitry to: Based on configuration update information, it is determined that a first parameter associated with one or more configuration parameters has been previously updated, the configuration update information including the one or more configuration parameters, and the configuration update information indicating a change in the one or more configuration parameters applied through the Radio Access Network (RAN) Intelligent Controller (RIC); The conflict is determined based on the previously updated first parameter; Based on the determination of the conflict, a strategy is applied to determine the updating of the one or more configuration parameters; as well as Update one or more configuration parameters according to the strategy.

Images