CN118042559A

CN118042559A - Conflict management for functions and services

Info

Publication number: CN118042559A
Application number: CN202311507908.7A
Authority: CN
Inventors: 阿尔达·阿卡曼; 布尔库·萨希
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2022-11-14
Filing date: 2023-11-13
Publication date: 2024-05-14

Abstract

Techniques for providing conflict management of functions and services, such as RAN Intelligent Controllers (RIC), are described. For example, a non-real-time (non-RT) RIC includes one or more processors and a memory coupled to the one or more processors, the memory storing instructions to cause the one or more processors to receive a request from an application to perform a service using an interface of the non-RT RIC. The instructions also cause the one or more processors to determine whether the service has a conflict. The instructions also cause the one or more processors to perform an act of resolving the conflict based on a determination that the service has a conflict.

Description

Conflict management for functions and services

The application claims the benefit of U.S. patent application Ser. Nos. 18/474,963 and 63/383,646, filed on 26, 9, 2022, 11, and 14, respectively, each of which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates to computer networking and to conflict management of functions and services of a controller.

Background

Computer networks have become ubiquitous and the number of network applications, network connection devices, and types of network connection devices has also increased rapidly. Such devices now include computers, smartphones, internet of things (IoT) devices, vehicles, medical appliance factory devices, and the like. The 5G mobile network architecture enhances the ability to provide communication services using cloud-based Network Function Virtualization (NFV). A private network may be created using a Radio Access Network (RAN) of a mobile network operator in combination with the functionality of the 5G core. For example, a network may be created for a particular Service Level Agreement (SLA), a particular use case, or other particular requirements. Examples of such networks include private mobile networks, industrial networks, private networks for interconnecting vehicles, and the like.

Disclosure of Invention

In general, this disclosure describes techniques for conflict management of functions and services of a RAN Intelligent Controller (RIC), such as a RAN of a mobile network. For example, the network system may include a Service Management and Orchestration (SMO) framework that provides various framework functions and a non-real-time (non-RT) RIC configured according to an open radio access network (O-RAN) standard ("O-RAN architecture") to manage and/or monitor aspects of the RAN and/or 5G core. The O-RAN architecture may include a non-RT RIC and a near real-time RIC (near RT RIC), each of which performs different functions and services for the RAN functions. For example, a non-RT RIC is an orchestration and automation function configured to provide radio resource management, higher layer process optimization, policy optimization, and to provide guidelines, parameters, policies, and AI/ML models to support the operation of near RT RIC functions in the RAN. The non-RT RIC may load one or more applications (e.g., rApp) that provide non-real-time (e.g., greater than one second) control of the RAN elements and their resources, and the near-RT RIC may load one or more applications (e.g., xApp) that provide near-real-time control of the RAN elements and their resources. The O-RAN architecture includes several interfaces, e.g., A1, O1, and O2 interfaces, each for providing functions and services by which SMOs and RIC can configure or direct other components of the RAN. For example, the functions and services of the non-RT RIC may include policy management services and/or rich information services (collectively referred to herein as "A1 services" because these services are provided over the A1 interface) for the near-RT RIC that are provided over the A1 interface; operation, administration, and management (OAM) services of the O-RAN management element provided over the O1 interface, such as performance management services and configuration management services (referred to herein as "O1 services" because these services are provided over the O1 interface); infrastructure management services and deployment management services (referred to herein as "O2 services" because these services are provided over the O2 interface) and/or other services of the resources of the O-RAN cloud provided over the O2 interface, such as Service Management and Exposure (SME) services (e.g., service registration, update of service registration), data Management and Exposure (DME) services, and/or AI/ML services. In accordance with the techniques disclosed herein, a non-RT RIC may include one or more micro-services configured to provide conflict management of these functions and services.

In accordance with the techniques of this disclosure, a non-RT RIC may provide conflict management for A1 services. For example, a conflict manager of a non-RT RIC may receive a request from an application to execute an A1 service (e.g., create or update a policy of the application) and determine whether the A1 service has a conflict. Based on the determination of whether the A1 service has a conflict, the non-RT RIC may perform actions to resolve the conflict (e.g., by implementing (or not implementing) the applied policies based on conflict management rules). In some examples, a non-RT RIC may provide conflict management for O1 services. For example, a conflict manager of a non-RT RIC may receive a request from an application to perform an O1 service (e.g., implement a configuration change of a RAN element, create a performance job, etc.) and determine whether the O1 service has a conflict. Based on the determination of whether the O1 service has a conflict, the non-RT RIC may perform actions to resolve the conflict (e.g., by implementing (or not implementing) configuration changes based on conflict management rules). In some examples, a non-RT RIC may provide conflict management for O2 services. For example, a conflict manager of a non-RT RIC may receive a request from an application to perform an O2 service (e.g., implement a configuration change of a resource of an O-RAN cloud) and determine whether the O2 service has a conflict. Based on the determination of whether the O2 service has a conflict, the non-RT RIC may perform an action to resolve the conflict (e.g., by implementing (or not implementing) the configuration based on conflict management rules). In some examples, the non-RT RIC may provide conflict management for other services, such as SME services (e.g., service registration, updates to service registration), DME services, and/or AI/ML services.

These techniques may provide one or more technical advantages to realize at least one practical application. For example, the techniques in this disclosure may provide conflict management in a RAN, and more particularly, for a non-RT RIC deployed in accordance with an O-RAN framework. Furthermore, the techniques in this disclosure may provide a conflict management system that is configurable so that an operator may configure various settings of the conflict management system, e.g., implementation of particular conflict management rules.

In one example, the technique describes a non-real-time (non-RT) radio access network intelligent controller (RIC) for a Radio Access Network (RAN), the non-RT RIC comprising: one or more processors; and a memory coupled to the one or more processors, the memory storing instructions to cause the one or more processors to: receiving a request from an application to perform a service using an interface other than an RT RIC; determining whether the service has a conflict; and performing an action to resolve the conflict based on the determination that the service has a conflict.

In another example, the technique describes a method comprising: receiving, by a non-real-time (non-RT) radio access network intelligent controller (RIC) for managing non-real-time events of a Radio Access Network (RAN), a request from an application to perform a service using an interface of the non-RT RIC; determining, by the RIC, whether the service has a conflict; and performing, by the RIC, an action to resolve the conflict based on the determination that the service has the conflict.

In another example, the technique describes a non-transitory computer-readable storage medium comprising instructions that, when executed, cause one or more processors of a non-real-time (non-RT) radio access network intelligent controller (RIC) for managing non-real-time events of a Radio Access Network (RAN): receiving a request from an application to perform a service using an interface other than an RT RIC; determining whether the service has a conflict; and performing an action to resolve the conflict based on the determination that the service has a conflict.

The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims.

Drawings

Fig. 1A is a block diagram illustrating an example network system configured to provide conflict management of functions and services of a RAN in accordance with one or more techniques of the present disclosure.

FIG. 1B is a block diagram illustrating further example details of the non-RT RIC of the service management and orchestration of FIG. 1A.

Fig. 2A is a block diagram illustrating an example non-RT RIC providing conflict management for A1 services in accordance with one or more techniques of the present disclosure.

Fig. 2B is a flow diagram of example conflict management for an A1 service in accordance with one or more techniques of the present disclosure.

FIG. 3A is a block diagram illustrating an example non-RT RIC providing conflict management for O1 services in accordance with one or more techniques of the present disclosure.

FIG. 3B is a flow diagram of example conflict management for an O1 service in accordance with one or more techniques of the present disclosure.

FIG. 4 is a block diagram illustrating an example non-RT RIC providing conflict management for O2 services in accordance with one or more techniques of the present disclosure.

Fig. 5A is a block diagram illustrating an example non-RT RIC providing conflict management for SME services in accordance with one or more techniques of the present disclosure.

Fig. 5B is a flow diagram of example conflict management for an SME service in accordance with one or more techniques of the present disclosure.

Fig. 5C is a flow diagram illustrating another example conflict management of an SME service according to one or more techniques of this disclosure.

FIG. 6 is a flowchart of example operations of a RIC configured to perform conflict management in accordance with the techniques described in this disclosure.

FIG. 7 is a block diagram illustrating in detail an example computing system in accordance with the techniques of this disclosure.

Detailed Description

Fig. 1A is a block diagram illustrating an example network system configured to provide conflict management of functions and services of a RAN in accordance with one or more techniques of the present disclosure. In the example shown in fig. 1A, 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 "core") 105 that provides user equipment 104A-104N (collectively, "UEs 104") with access to one or more applications or services provided by a data network 140.

The UE 104 may represent a smart phone, desktop computer, laptop computer, tablet, smart watch, and/or "internet of things" (IOT) device, e.g., camera, sensor, television, appliance, etc. As shown in fig. 1A, the network system 100 includes a RAN 109 that provides network access, data transmission, and other services to the UE 104. In some examples, the RAN 109 may be an open radio access network (O-RAN), a 5G mobile network RAN, a 4G LTE mobile network RAN, another type of RAN, or a combination of the foregoing. For example, in a 5G radio access network, RAN 109 includes a plurality of cell sites (or simply "cells"), each of which includes a radio device, e.g., base stations 106A-106M (collectively, "base stations 106"), also referred to as gNodeB, to exchange packetized data within the data network to ultimately access one or more applications or services provided by data network 140. Each base station 106 is divided into three functional components: radio Units (RU), distributed Units (DU), and Centralized Units (CU), which may be deployed in various configurations. RU manages radio frequency layers and has antenna arrays of various sizes and shapes. The DU performs low-level protocol processing. The CU performs upper layer protocol processing. Depending on operator and service requirements, base station 106 may be deployed in its entirety, e.g., RU, DU and CU reside within a cell site, or these functions may be distributed across cell sites while a CU resides in an edge cloud site that controls multiple distributed DUs. For example, O-RAN is a networking method in which a resolution function may be used to deploy mobile fronthaul and intermediate networks. The decomposition function may be a cloud-based function.

The radio access network 109 is connected to the core 105 for exchanging data packets with the data network 140. The core 105 may be a 5G core network and the data network 140 may represent, for example, one or more service provider networks and services, the internet, third party services, one or more IP-VPNs, IP multimedia subsystems, combinations thereof, or other networks or network combinations. In some examples, resources associated with services provided by a mobile network operator to a tenant may be provided or managed by functionality of components of core 105 and/or RAN 109. In some examples, core 105 implements various discrete control plane and user plane functions for network system 100. Examples of 5G control plane functions that may be provided by core 105 include an access mobility management function (AMF) that provides access mobility management services, a Session Management Function (SMF) that provides session management services, a Policy Control Function (PCF) that provides policy control services, user Data Management (UDM) that provides network user data management, a Network Repository Function (NRF) that provides a repository that may be used to register and discover services in a network of a network operator, an authentication server function (AUSF) that provides authentication services, a Network Slice Selection Function (NSSF), a Network Slice Management Function (NSMF) that may be used to select an instance of available network slices for use by any UE device 104, and a Network Slice Subnet Management Function (NSSMF) that provides coordination, management, and orchestration of Network Slice Subnet Instances (NSSI). The core 105 may also include User Plane Functions (UPFs) that provide packet routing, forwarding, and other network data processing functions (e.g., quality of service, packet inspection, traffic optimization, etc.). For more details on services and functions provided by the 5G core, see third generation partnership project 2021, technical specification group services and system aspects; a system architecture of a 5G system (5 GS); stage 2 (version 17), TS 23.501V17.0.0 (2021-03), technical specification group services and system aspects by 2021; a system architecture of a 5G system (5 GS); stage 2 (version 18), TS23.501V18.2.2 (2023-07) are substituted, each of which is incorporated herein by reference in its entirety. For more details on O-RAN architecture, see the O-RAN alliance, "O-RAN architecture description", version 7.00, month 10 of 2022, the entire contents of which are incorporated herein by reference.

Aspects of RAN 109 and/or core 105 may 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 may be operated by a mobile network operator that provides 5G services to tenants. SMO 112 may orchestrate and control management and automation aspects of RAN 109 (e.g., network slicing, orchestration of management and O-clouds (O-clouds), etc.). In addition, SMO 112 may control aspects of non-RT RIC 122 and near-RT RIC 124. non-RT RIC 122 may provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (e.g., RU, DU, and CU), workflow management, and policy-based control of applications and features of near-RT RIC 124. Near RT RIC 124 may provide near real-time (e.g., millisecond) control and optimization of RAN elements and resources via fine-grained data collection and actions. As further described in fig. 1B, non-RT RIC 122 and near-RT RIC 124 may be deployed as highly scalable, micro-service based containerized architectures. In some examples, the near RT RIC 124 may be located within an edge or regional cloud.

Non-RT RIC 122 may load one or more applications, e.g., application 123 (e.g., rApp of fig. 1B) that manages non-real-time events within non-RT RIC 122, e.g., applications that do not require a response time of less than one second. Application 123 may utilize functionality exposed via a non-RT RIC framework of non-RT RIC 122. The application 123 may be used to control and manage RAN elements and resources, e.g., resources in the near RT RIC 124, RAN nodes, and/or O-RAN cloud. Application 123 may also utilize network data, performance metrics, and user data to provide suggestions of network optimization and operational guidance (e.g., policies) to one or more applications of near RT RIC 124. Near RT RIC 124 may load one or more applications, e.g., application 125 (e.g., xApp of fig. 2A) that manages near real-time events within near RT RIC 124. Application 125 may utilize functionality exposed via the near RT RIC framework of near RT RIC 124. Near RT RIC 124 may implement policies received from applications 123 of non-RT RIC 122 and may provide policy feedback to non-RT RIC 122. Although shown as being within non-RT RIC 122, any one or more of applications 123 may be executed by a third party separate from non-RT RIC 122. Also, although shown as being within the near RT RIC 124, any one or more of the applications 125 may be executed by a third party separate from the near RT RIC 124.

As described further below, the non-RT RIC 122 may use the A1, O1, and O2 interfaces to provide services. The A1 interface connects the non-RT RIC 122 and the near RT RIC 124. non-RT RIC 122 may execute services via an A1 interface, such as policy management services (e.g., creation and updating of policies), ML model management services, and/or rich information services. The service performed via the A1 interface is referred to herein as an "A1 service". The O1 interface may include interfaces that connect SMO 112 with O-RAN management elements, e.g., near RT RIC 124 and/or RAN nodes (e.g., O-RAN centralized units (O-CUs), O-RAN distributed units (O-DUs)). The non-RT RIC 122 may perform services via an O1 interface, such as configuration management services and performance management services (e.g., operations and maintenance (OAM) services) of an O-RAN management element, fault supervision, file management, heartbeat, trace, physical Network Function (PNF) discovery, software management, etc. The service performed via the O1 interface is referred to herein as an "O1 service". The O2 interface may include an interface that connects SMO 112 to ORAN O-cloud resources. The O-cloud may include one or more physical infrastructure nodes that host O-RAN functions (e.g., virtual network functions), supporting software components, and appropriate management and orchestration functions. non-RT RIC 122 may perform services via an O2 interface, for example, services that provide infrastructure management and/or network function deployment of resources in an O-cloud (e.g., discovery and management of O-cloud resources, inward expansion, outward expansion of cloud/deployment, failure of cloud/deployment, configuration, billing, performance, and security (FCAPS), software management of cloud platform/deployment, creation/deletion of deployment and associated allocated O-cloud resources). The service performed via the O2 interface is referred to herein as an "O2 service". The non-RT RIC 122 may also perform other functions and services, such as a service management and presentation (SME) service (e.g., service registration, updates to service registration), a data management and presentation (DME) service, an AI/ML service, and the like.

In some cases, the functions and/or services provided by non-RT RIC 122 (e.g., A1 services, O2 services, etc.) may be conflicting. Some conflicts can be directly observed by the framework functions (referred to herein as "direct conflicts"). For example, two or more applications 123 may request different settings for exactly the same parameters of the target (e.g., a first application requesting a first priority of a network slice, and a second application requesting a second, different priority of the same network slice). The targets may be configurable parameters, settings, objects or resources of the RAN, e.g. priorities, policies, network slice or network slice parameters, etc. As another example, an application may perform a change that conflicts with a previously requested running configuration from the same or another application. As another example, the application may perform changes beyond the limits of the target or RAN.

In some examples, some conflicts may not be directly observed, but dependencies between the parameters and resources for which the application is directed (referred to herein as "indirect conflicts") may be observed. For example, an application may perform a change that produces a system effect that is equivalent to a change performed by another application (e.g., the application performs a different action, but the effect on the system is equivalent). The above are example conflict types, and are just some examples of conflict types. Other conflicts may be observable, for example, conflicts that cannot be directly observed where dependencies between applications are not apparent (referred to as "implicit conflicts").

In accordance with the techniques described in this disclosure, non-RT RIC 122 may provide conflict management for one or more non-RT RIC functions or services (e.g., A1 services, O2 services, and other services). In this example, non-RT RIC 122 may include a conflict manager 121 configured to provide conflict management for one or more non-RT RIC functions or services. The conflict manager 121 may be implemented, for example, by one or more micro-services.

As described further below, non-RT RIC 122 may include a conflict manager 121 configured to determine whether an A1 service has a conflict. For example, conflict manager 121 of non-RT RIC 122 may determine whether creation of a policy would result in a conflict in response to receiving a request from application 123 to create a policy to be deployed to near RT RIC 124 via the A1 interface. If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct non-RT RIC 122 (e.g., a policy manager of non-RT RIC 122) to continue creating policies for application 123. If conflict manager 121 determines that there is a conflict (e.g., a policy statement will conflict with a previously deployed policy from the application or another application), conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict. Such actions to resolve conflicts may include, for example, implementing (or not implementing) the policy based on one or more conflict management rules. Conflict management rules may include, for example, implementing policies based on a first come first served principle, implementing policies from applications with higher priorities (referred to herein as "priority-based overrides"), implementing policies based on scope of policies (e.g., implementing policies with a particular scope rather than policies with a general scope), and so forth. In some examples, the user may specify which conflict management rule to apply to resolve the conflict.

In some examples, the application may request guidance from conflict manager 121 prior to creating the policy. In these examples, conflict manager 121 of non-RT RIC 122 may determine whether there is a conflict with the creation of the policy and provide a response (e.g., a directive response) indicating whether there is a conflict, including one or more suggestions to resolve the conflict, and/or identify the cause of the conflict (e.g., identification of contradictory declarations, etc.).

Conflict manager 121 of non-RT RIC 122 may additionally or alternatively be configured to determine whether O1 services have a conflict. For example, in response to a request to provide a configuration change or create a Performance Management (PM) job, conflict manager 121 may determine whether the configuration and/or performance of the O1 service would result in a conflict (e.g., with the configuration and/or performance of the previous O1 service). If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct non-RT RIC 122 (e.g., an O1 service manager of non-RT RIC 122) to continue to implement the O1 service. If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform actions to resolve the conflict, e.g., to implement (or not implement) O1 services based on the conflict management rules described above (e.g., first come first served; priority based coverage; scope, etc.).

Conflict manager 121 of non-RT RIC 122 may also be configured to determine whether the O2 service has a conflict. For example, conflict manager 121 may request that configuration changes be provided on one or more resources of the O-RAN cloud. If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct non-RT RIC 122 (e.g., an O2 service manager of non-RT RIC 122) to continue to implement the O2 service. If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict, e.g., to implement (or not implement) the O2 service based on the conflict management rules described above (e.g., first come first served; priority based coverage; scope, etc.).

Although the above described examples are described with respect to A1, O1, and O2 services, conflict manager 121 may provide conflict management to other services, such as a Service Management and Exposure (SME) service that supports services provided through an internal interface (R1 interface) of non-RT RIC 122 and their exposure and extensibility (e.g., service registration, updates to service registration, discoverability of services), a Data Management and Exposure (DME) service that manages data of application 123, and/or other services, such as AI/ML services. For example, when the application 123 performs service registration and/or updates to service registration, the conflict manager 121 may determine whether there is a conflict of SME services (e.g., determine whether the service conflicts with a previously registered service). If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct non-RT RIC 122 (e.g., a service manager of non-RT RIC 122) to continue to register or update SME services. If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict, e.g., allow or deny registration or update service. As another example, conflict manager 121 may determine whether there is a conflict when application 123 performs service discovery or authorization (e.g., determine whether a service conflicts with a previously discovered or authorized application). If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct non-RT RIC 122 (e.g., a service manager of non-RT RIC 122) to continue to allow discovery of the service. If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict, e.g., reject discoverability of the service.

FIG. 1B is a block diagram illustrating further example details of the non-RT RIC 122 of FIG. 1A. In the example shown in fig. 1B, SMO 112 may include a non-RT RIC 122, one or more AI/ML models 142, one or more functions 144 (e.g., NSSMF, NFMF, and other functions), and open interfaces, e.g., 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 of one or more base stations, O-RAN decentralized units (O-DUs) 148), and O-RAN cloud 150.

Near RT RIC 124 may 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) by fine-grained data collection and actions performed via E2 interface 165. For example, near RT RIC 124 may load one or more applications (e.g., xApp) that provide near real-time control of RAN elements and their resources.

Non-RT RIC 122 may provide non-real-time (e.g., greater than one second) control and optimization of RAN elements and resources (e.g., RU, DU, and CU), workflow management, and policy-based control of applications and features of near-RT RIC 124.

The non-RT RIC 122 may be deployed as a highly scalable, micro-service based containerized architecture. In this example, non-RT RIC 122 may load, deploy, and/or terminate one or more applications, e.g., rApp a through rApp N (collectively, "applications 123"). Application 123 may represent an application that utilizes functionality exposed via the framework of non-RT RIC 122. Application 123 may provide non-real-time (e.g., greater than one second) control of RAN elements and their resources to non-RT RIC 122. The application 123 may provide services for radio resource management, higher layer process optimization, policy optimization, and provide guidelines, parameters, policies, and AI/ML models to support the operation of RAN functions.

For example, the application 123 may provide A1 services that provide and facilitate RAN operation and optimization of the near RT RIC 124, e.g., providing operational guidance (e.g., policies), rich information (e.g., predictions), and AI/ML services. The A1 service may include a policy management service, e.g., creation, update, and/or deletion of A1 policies; receiving strategy feedback; querying policy type, identifier and status; define which policy types are supported by near RT RIC 124; and registering the application (xApp) of the near RT RIC 124 to the specific policy type. The A1 service may include a rich information service, for example, providing data, e.g., predictions and/or data analysis, for model training of AI/ML models.

Application 123 may provide O1 services that provide configuration management or performance management of O-RAN management entities, e.g., near RT RIC 124 and/or RAN nodes, e.g., O-CUs 146, O-DUs 148 (also referred to herein as "E2 nodes"). The O1 service may provide a configuration management service to create, update, and/or delete configurations for the O-RAN management entity. For example, the configuration management service may include provisioning operations (e.g., for NSS and NF provisioning) to create Management Object Instances (MOIs), obtain MOI attributes, modify MOI attributes, and/or delete MOI. The O1 service may also provide performance management services that monitor the status of elements or components in the O-RAN management entity. For example, non-RT RIC 122 may create, modify, or delete performance management jobs to receive performance metrics, or send heartbeat messages to monitor the status and/or availability of services of RAN nodes, or send trace messages to monitor link failures. The O1 service may also provide file management, e.g., pushing files to RAN nodes (e.g., software updates, beamforming profiles, ML models, security certificates, etc.).

The applications 123 may provide O2 services that provide infrastructure management and/or network function deployment of resources in the O-RAN cloud 150 (also referred to herein as "O-cloud 150"). The O2 service may provide discovery and management of O-cloud resources; inward expansion, outward expansion of cloud/deployment (e.g., deploying resources using more or fewer processors); FCAPS for cloud/deployment, software management for cloud platform/deployment; create/delete deployments and associated allocated O-cloud resources.

The application 123 may provide a service management and presentation (SME) service, a data management and presentation (DME) service, and/or other services. The SME service may provide services that support the presentation and extensibility of services provided through the internal interface (R1 interface 154) of the non-RT RIC 122 and through services including bootstrapping, service registration/deregistration or updates to service registration, service discovery or notification, heartbeat, authentication, authorization, etc. Data management and presentation (DME) services may include services that manage data between applications 123 and presentation thereof. For example, the applications 123 may have different functions, such as an application 123A configured to collect and analyze data, an application 123B configured to generate an ML model based on the analysis results, and an application 123N configured to use the ML model for prediction or inference and/or to generate control of RAN nodes based on the prediction or inference. The DME service may manage data shared between applications 123, such as collection of data, processing of data, and/or advertising of data.

The non-RT RIC 122 may include one or more managers to handle A1, O2, SME, DME services, and other services. For example, non-RT RIC 122 may include policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, data manager 155, and conflict manager 121. non-RT RIC 122 may include other managers configured to manage the installation and deployment of applications 123, e.g., application managers and onboard applications.

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

O1 service manager 160 is configured to control deployment of O1 services to monitor performance of near RT RIC 124 and/or RAN nodes (e.g., O-CUs 146, O-DUs 148). For example, in response to receiving a request from application 123 via R1 interface 154 for an O1 service for monitoring performance of near RT RIC 124, R1 interface 154 sends the request to O1 service manager 160 via message bus 151. The O1 service manager 160 may process the O1 service and may send the O1 service to an O1 terminal 168, which provides the O1 service to the near RT RIC 124 via an O1 interface 166. In some examples, the O1 interface may implement REST/HTTPS APIs and/or netcon f.

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

The O2 service manager 162 may be configured to control the deployment of O2 services to monitor the performance of the resources of the O-cloud 150. For example, in response to receiving a request via R1 interface 154 for an O2 service for monitoring performance of resources within O-cloud 150, R1 interface 154 sends the request to O2 service manager 162. The O2 service manager 162 may process the O2 service and may send the O2 service to the O2 terminal 169, which provides the O2 service to the resources of the O-cloud 150 via the O2 interface 167.

The O2 service manager 162 may additionally or alternatively be configured to control the deployment of O2 services for resource configuration of the O-cloud 150. For example, in response to receiving a request from application 123 via R1 interface 154 for an O2 service for configuring resources within O-cloud 150, R1 interface 154 sends the request to O2 service manager 162. The O2 service manager 162 may process the O2 service and may send the O2 service to the O2 terminal 169, which provides the O2 service to the resources of the O-cloud 150 via the O2 interface 167.

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 SME services from the application 123 via the R1 interface 154, the R1 interface 154 sends the request to the service manager 163. The service manager 163 may process SME services (e.g., registration/update services) and may send SME services to the R1 terminal 152, which provides SME services (e.g., sends responses to applications regarding service registration, update, or discovery) to the applications 123 via the R1 interface 154. Similarly, in response to receiving a request for DME services from application 123 via R1 interface 154, R1 interface 154 sends the request to data manager 155. The data manager 155 may handle the DME services and may send the DME services to the R1 terminal 152, which provides the DME services to the application 123 via the R1 interface 154 (e.g., sending data from an application configured as a data producer to an application configured as a data consumer).

R1 interface 154 may also expose application 123 to a sliced subnet management service, e.g., RAN NSSMF interface, to retrieve sliced Service Level Agreements (SLAs) and sliced topology and/or sliced management, SLA and sliced performance management notifications to application 123.

In accordance with the techniques described in this disclosure, conflict manager 121 is configured to provide conflict management for services of the respective interfaces of non-RT RIC 122. In some examples, conflict manager 121 may be implemented, for example, by one or more micro-services of non-RT RIC 122. Although conflict manager 121 is shown as a separate micro-service from RT RIC 122, in some examples, the techniques described herein may be performed by one or more other micro-services, e.g., policy manager 158, O1 service manager 160, O2 service manager 152, service manager 163, and/or data manager 155. In this example, in response to receiving a request for an A1 service, an O2 service, or other service (e.g., SME, DME), R1 terminal 152 may send a message to conflict manager 121 via message bus 151 to perform conflict management for the A1 service, the O2 service, or other service.

As one example, conflict manager 121 may provide conflict management for A1 services to create, modify, or delete policies. Policies may be declarative policies that use formal declaration expressions that enable non-RT RIC 122 to direct near-RT RIC 124 functions. As one example, a policy may include a scope identifier and one or more policy statements. The range identifier may represent an application range (e.g., cell, network slice, UE, group of UEs, qoS flow, etc.) of the policy statement. One or more policy statements may specify policy objectives, such as policy objectives (e.g., qoS, qoE, UE levels, slice SLA objectives) and policy resources (e.g., resource usage of policies). Other examples of policy management services are described in O-ran.wg2.a1gap-v03.000; "O-RAN second working group; a1 interface: general aspects and principles, "which are incorporated herein by reference in their entirety. An example of a policy created by a first application (e.g., rApp a) is as follows:

Example A1 policy:

the scope of the above policy includes a slice with a slice SLA target specifying the maximum number of UEs (e.g., 10000) and the maximum number of PDU sessions (e.g., 800), and a slice SLA resource specifying a target cell in the near RT RIC domain includes certain types of cells.

In some cases, the second application (e.g., rApp B) may request to create a policy that conflicts with the policy of the first application. For example, an example of a policy for a second application (e.g., rApp B) is as follows:

Example A1 policy:

Conflict manager 121 may determine whether there is a conflict between overlapping policies of application 123 (rApp), for example, by determining whether the overlapping policies include contradictory declarations (e.g., object/resource declarations). In this example, the conflict manager 121 may determine that there is a conflict between the objective declaration (e.g., a policy of the first application (rApp a) that designates the maximum number of UEs as 10000 and a policy of the second application (e.g., rApp B) that designates the maximum number of UEs as 30000).

Based on determining that there is a conflict between the target declaration of the policy of application 123A and the target declaration of the policy of application 123B, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict. In some examples, conflict manager 121 may determine which conflict policies to implement based on one or more conflict management rules. As one example, conflict manager 121 may implement a first-come first-served rule. In this example, if the request to create the policy of the first application precedes the request to create the policy of the second application, non-RT RIC 122 may implement the policy of the first application. Alternatively or additionally, the conflict manager 121 may implement priority-based priority rules, wherein policies of applications with higher priorities are implemented. For example, the conflict manager 121 may implement a policy of the second application based on the second application having a higher priority than the first application. In some examples, conflict manager 121 may override policies with a general scope with policies that specify a narrower scope. For example, the non-RT RIC 122 may implement policies for UE-specific performance targets, rather than policies that specify performance targets for all UEs. In some examples, an operator may configure conflict management rules to apply to each policy statement. For example, an operator may configure an implementation of a first conflict management rule in response to determining a conflict with a first policy statement, and configure an implementation of a second conflict management rule different from the first conflict management rule in response to determining a conflict with a second policy statement. In some examples, parameters of network resources may be categorized into different types, e.g., information Object Class (IOC), proxy class, and data type parameters. The IOC describes information that may be used in the management interface. The IOC includes attributes that represent various characteristics of the IOC. When performing configuration management, a Management Object Instance (MOI) may be an instantiation object of the IOC. In some examples, a Distinguished Name (DN) is used to uniquely identify the MOI within the namespace. In these examples, non-RT RIC 122 may apply conflict management rules based on parameters or based on parameters and parameter types. For example, conflict manager 121 may determine whether the destination Distinguished Name (DN) of the first request overlaps with the destination DN of the second request and determine whether the MOI and attributes of the first request overlap with those of the second request.

In some examples, non-RT RIC 122 may provide operator-configurable conflict management rules (e.g., a user may specify the type of conflict management rules to apply).

In some examples, an application (e.g., rApp A) may request policy guidelines before requesting to create a policy. In these examples, in response to receiving a request for conflict guidance for a policy, conflict manager 121 may examine target near RT RIC 124 and/or examine contradictory declarations of overlapping policies, verify restrictions (e.g., whether the restrictions are exceeded), and/or conflict indirect actions. Conflict manager 121 may provide a response (directive response) that includes an indication of whether the policy generated a conflict. In some examples, conflict manager 121 may provide a response that includes one or more suggestions to resolve the conflict (e.g., suggestions to resolve contradictory statements). Alternatively or additionally, conflict manager 121 may provide a response that includes information about the cause of the conflict, e.g., a list of contradictory declarations (e.g., contradictory targets/resource parameters).

As another example, conflict manager 121 may provide conflict management for O1 services to create configuration requests for Management Object Instances (MOIs) of O-RAN management elements (e.g., near RT RIC 124, O-CU 146, O-DU 148). In this example, the first application (e.g., rApp A) may have previously issued a configuration request to create the MOI of the O-DU 148. The conflict manager 121 may determine whether a configuration request by a second application (e.g., rApp B) to create the MOI of the O-DU 148 conflicts with a previous configuration request by a first application to create the MOI of the O-DU 148. Based on a determination of whether there is a conflict between the configuration request of the first application and the configuration request of the second application, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict. Conflict manager 121 may determine which conflicting configuration requests to implement based on one or more conflict management rules (e.g., first come first served; priority based coverage; scope, etc.), as described above.

As another example, conflict manager 121 may provide conflict management for O2 services to be deployed (e.g., provide configuration changes to resources of O-cloud 150). For example, a first application (e.g., rApp a) may have previously issued a configuration request to scale up the number of processors of the resources of the O-cloud 150. The conflict manager 121 may determine whether a configuration request by the second application (e.g., rApp B) to provide a configuration change to a resource conflicts with a previous configuration of the resource requested by the first application. As one example, if the second application requests to configure resources of the O-cloud 150 to reduce the number of processors to save energy, the conflict manager 121 may determine that there is a conflict if the configuration of the first application requests to configure resources to increase the number of processors to achieve extensibility. Based on determining that there is a conflict between configuration requests of resources of O-cloud 150, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict. Conflict manager 121 may implement which conflicting configuration requests based on one or more conflict management rules (e.g., first come first served; priority based coverage; scope, etc.), as described above.

Fig. 2A is a block diagram illustrating an example non-RT RIC 122 that provides conflict management for A1 services in accordance with one or more techniques of the disclosure. In this example, conflict manager 121 may provide conflict management for an A1 service (e.g., policy management request) provided by application 123 (rApp). Although the techniques for providing conflict management of A1 services are described with respect to conflict manager 121 of fig. 2A, the techniques for providing conflict management of A1 services may alternatively or additionally be performed by policy manager 158 of fig. 1B or any other micro-service of non-RT RIC 122.

Non-RT RIC 122 may include an A1 interface 164 that provides an interface between non-RT RIC 122 and near-RT RIC 124. The A1 interface 164 may support A1 services such as policy management services, rich information services, and/or AI/ML services. In this example, R1 terminal 152 may receive a request for A1 service from rApp a via R1 interface 154, e.g., a request to create a policy for near RT RIC 124. The request may include a policy type identifier, a policy, and a scope identifier (e.g., an identifier of near RT RIC 124). In response, R1 terminal 152 sends a message (e.g., via a message bus) to conflict manager 121 to determine whether the A1 service has a conflict. For example, conflict manager 121 may examine formal declarations within the overlapping policies to find contradictory declarations. Conflict manager 121 may determine whether there is a direct conflict between policies of one or more applications 123. For example, collision manager 121 may determine whether each request specifies different settings for the exact same parameters of the target (e.g., the two policies include contradictory declarations, e.g., different priorities for slices within the cell, different QoS priorities for the QoS of the UE, contradictory Technical Specification (TS) guidelines for the UE or the slices, etc.), or whether the policies of application 123 perform changes that exceed the limits of the target or RAN (e.g., application 123 sets an impractical downlink throughput target for the UE). In some examples, the conflict manager 121 may determine whether there is an indirect conflict, e.g., one application sets a performance target for all UEs of a slice and another application sets a UE-specific performance target, or whether one application load balances each slice of each cell to transfer load to another cell and another application performs a technical specification for the slice that prohibits the target cell from being a primary/secondary cell.

If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct policy manager 158 of non-RT RIC 122 to continue creating policies for application 123. For example, conflict manager 121 may instruct policy manager 158 to process a request to create a policy. Policy manager 158 may generate a command (e.g., HTTP PUT claim) to create a policy and send the command to A1 terminal 156, which in turn sends the command to near RT RIC 124 via A1 interface 164. In response to creating a policy on near RT RIC 124, near RT RIC 124 may create and send a response to A1 terminal 156 indicating that the policy has been created, which in turn communicates the response to R1 terminal 152 to send the response to rApp a.

If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict, e.g., to implement (or not implement) the A1 service based on the rules described above (e.g., first come first served; priority based coverage; scope, etc.).

In some examples, an application (e.g., rApp a) may request guidance before creating a policy. For example, R1 terminal 152 may receive a request via R1 interface 154 for directions to create policies (e.g., HTTP PUT methods) for near RT RIC 124. The R1 interface 154 sends a directive request to the conflict manager 121, which determines if a conflict would occur if a policy was created. Based on the determination of whether a conflict exists, conflict manager 121 may generate a response to the direction request specifying whether creation of the policy will result in a conflict. In some examples, conflict manager 121 may provide one or more suggestions to resolve conflicts (e.g., suggestions to resolve contradictory declarations of overlapping policies). Alternatively or additionally, the conflict manager 121 may provide information about the cause of the conflict, such as a list of contradictory declarations (e.g., contradictory target/resource parameters). The conflict manager 121 may send a response to the direction request to the R1 terminal 152, which in turn sends the response to rApp a.

Fig. 2B is a flow diagram of example conflict management for an A1 service in accordance with one or more techniques of the present disclosure. FIG. 2B is described with respect to conflict manager 121 of FIG. 2A, but may also be applied to policy manager 158 of FIG. 1B or any other micro-service of non-RT RIC 122. Although the example depicted in fig. 2B is described with respect to a request to create a policy, the technique may be similarly applied to modification or deletion of policies.

In the example of fig. 2B, steps (202) and (204) may represent steps for providing policy guidelines. For example, the application 123 may send a policy directive request ("A1 policy directive request") to the R1 terminal 152 (202), which sends a message to the conflict manager 121 to provide guidance as to whether the creation of a policy would have a conflict. The policy directive request may include an identifier (A1 policy type ID), a policy (A1 policy), and an identifier of the target of the policy (near RT RIC ID). In response to determining whether there is a conflict, conflict manager 121 sends a response (A1 policy directive response) to the application that sent the directive request (204). As described above, the response to the directive request may include an indication of whether the policy generated a conflict, one or more suggestions to resolve the conflict, information about the cause of the conflict, (e.g., a list of contradictory claims), or any other information.

Steps (206) through (218) may represent steps for providing conflict management, as described in this disclosure. For example, the application 123 may send a request to create a policy (create A1 policy request) to the R1 terminal 152 (206). The request may include an identifier (A1 policy type ID), a policy (A1 policy), and an identifier of near RT RIC 124 (near RT RIC ID). The R1 terminal 152 transmits a message to the conflict manager 121 to determine whether there is a conflict with the designated policy. Conflict manager 121 may verify the policy (208) and determine if any conflicts exist (210). For example, conflict manager 121 may examine formal declarations within the overlapping A1 policy to find contradictory declarations.

In response to determining that there is no conflict, conflict manager 121 may instruct policy manager 158 to create a policy request for near RT RIC 124 (212). For example, policy manager 158 may execute an HTTP PUT request to create a policy on near RT RIC 124. In response to creating the policy on near RT RIC 124, near RT RIC 124 may create and send a response to A1 terminal 156 indicating that the policy has been created (214), which in turn communicates the response to the R1 terminal to send the response to the application (216).

In response to determining that a conflict exists, conflict manager 121 may create a response (create an A1 policy response) indicating that a conflict exists (218). In some examples, conflict manager 121 may implement one or more conflict management rules, e.g., first come first served, in response to determining that a conflict exists; priority-based coverage; policy scope, etc.

FIG. 3A is a block diagram illustrating an example non-RT RIC 122 providing conflict management for O1 services in accordance with one or more techniques of the present disclosure. In this example, conflict manager 121 may provide conflict management for O1 services (e.g., configuration management or performance management requests) provided by applications 123 (rApp). Although the techniques for providing conflict management of O1 services are described with respect to conflict manager 121 of FIG. 1B, the techniques for providing conflict management of O1 services may alternatively or additionally be performed by O1 service manager 160 and/or O2 service manager 162 of FIG. 1B or any other micro-service of non-RT RIC 122.

Non-RT RIC 122 may include an O1 interface 166 that provides an interface between SMO 112 and an infrastructure management framework supporting O-RAN virtual network functions (e.g., xApp and E2 nodes of near RT RIC 124). The O1 interface 166 may support O1 services, such as configuration management services and/or performance management services. In this example, the R1 terminal 152 may receive a request for O1 services from rApp a via the R1 interface 154, e.g., a configuration request to create an MOI for an O-RAN management element (e.g., the base station's O-DU 148). In response, R1 terminal 152 sends a message to conflict manager 121 to determine if there is a conflict with the configuration modifications requested by one or more applications 123. For example, the application may request modification of the configuration of the base station, e.g., a cell identifier. In this example, the collision manager 121 may determine whether a configuration request to modify the cell identifier of the base station would result in a collision.

If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct O1 service manager 1 to continue to implement the O1 service. For example, conflict manager 121 may instruct O1 service manager 160 to process a request to create a configuration. The O1 service manager 160 may generate a command to create a configuration (e.g., create a MOI request) and send the command to the O1 terminal 168, which in turn sends the command to the O-DU 148 via the O1 interface 166.

If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform actions to resolve the conflict, e.g., to implement (or not implement) O1 services based on the conflict management rules described above (e.g., first come first served; priority based coverage; scope, etc.).

As another example, R1 terminal 152 may receive a request to create a performance job (e.g., a performance guarantee) for O-DU 148. In response, R1 interface 154 sends a message to conflict manager 121 to determine whether there is a conflict with the creation of the performance job requested by one or more applications 123. For example, an application may request to create a performance job with overlapping IOCs and attributes, contradicting attribute value changes, and so on. In this example, conflict manager 121 may determine whether a request to create a performance job would result in a conflict.

If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct O1 service manager 160 to continue to implement the O1 service. For example, conflict manager 121 may instruct O1 service manager 160 to process a request to create a performance job. The O1 service manager 160 may generate a command to create a performance job and send the command to the O1 terminal 168, which in turn sends the command to the O-DU 148 via the O1 interface 166.

FIG. 3B is a flow diagram of example conflict management for an O1 service in accordance with one or more techniques of the present disclosure. FIG. 3B is described with reference to conflict manager 121 of FIG. 3A, but is also applicable to O1 service manager 160 of FIG. 1B. Although the example depicted in fig. 3B is described with respect to a request to modify a configuration request, the techniques may also be applied to creation or deletion of configuration requests and/or creation, modification, or deletion of performance jobs.

In the example of fig. 3B, the application 123 may send a request (e.g., create, modify, or delete a configuration or performance job) for an O1 service to the R1 terminal 152 (302), which sends a message to the conflict manager 121 to determine if a conflict exists with the specified O1 service. Conflict manager 121 may verify the O1 service and determine if the O1 service has any conflicts (304).

In response to determining that there is no conflict, conflict manager 121 may instruct O1 service manager 160 to continue to implement the O1 service. For example, O1 service manager 160 may process O1 services of O-RAN management elements (e.g., near RT RIC 124, O-CU 146, O-DU 148) by generating a command to modify an attribute of the O-RAN management element (e.g., modify MOI attribute request) and send the command to O1 terminal 168, which in turn sends the command to the O-RAN management element (e.g., O-DU 148) via O1 interface 166 (306). Similarly, O1 service manager 160 may process O1 services of the O-RAN management element by generating a command to create a performance job and transmitting the command to O1 terminal 168, which in turn transmits the command to the O-RAN management element via O1 interface 166. In response to executing the O1 service (e.g., modifying the MOI attribute, creating a performance job, etc.), the O-RAN management element may create and send a response to the O1 terminal 168 (308). Conflict manager 121 may generate a response to the O1 service request and send the response to R1 terminal 152, which in turn sends the response to application (310).

In some examples, conflict manager 121 may notify the configuration of the O-RAN management element of the change of the application (if the application subscribes to the configuration change notification). For example, in response to a change in configuration, the O-RAN management element may send a notification of the configuration change to the O1 terminal 168 (312). O2 service manager 162 may generate a notification of the configuration change and send the notification to R1 terminal 152, which in turn sends the notification to an application subscribed to receive notifications of configuration changes to the O-RAN management element (314).

FIG. 4 is a block diagram illustrating an example non-RT RIC 122 providing conflict management for O2 services in accordance with one or more techniques of the present disclosure. In this example, conflict manager 121 may provide conflict management for O2 services provided by application 123 (rApp). Although the techniques for providing conflict management of O2 services are described with respect to conflict manager 121 of fig. 1B, the techniques for providing conflict management of O2 services may alternatively or additionally be performed by O2 service manager 162 or any other micro-service of non-RT RIC 122. The conflict management of the O2 services performed by conflict manager 121 may be substantially similar to the operation of the conflict management of the O1 services, as described and illustrated in fig. 3B.

The non-RT RIC 122 may include an O2 interface 167 that provides an interface between SMO 112 and one or more resources of the O-RAN cloud 150. The O2 interface 167 can support O2 services, such as infrastructure management services and/or deployment management services for resources of the O-cloud 150, such as one or more physical infrastructure nodes hosting O-RAN functions (e.g., virtual network functions), supporting software components, and appropriate management and orchestration functions. In this example, the R1 terminal 152 may receive a request for O2 services via the R1 interface 154, e.g., a request to modify the configuration of the nodes of the O-cloud 150. The request may specify modifications to the node configuration to enable extensibility using additional processors. In response, R1 interface 154 sends a message to conflict manager 121 to determine if there is a conflict with the configuration modifications requested by one or more applications 123. Conflict manager 121 may provide conflict management for O2 services similar to the conflict management for O1 services described above. In this example, conflict manager 121 may determine whether a configuration request to modify the configuration of a node to use additional processors would result in a conflict (e.g., with a previous request to configure the node to use fewer processors to save energy).

If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct O2 service manager 162 to continue to implement the O2 service. For example, conflict manager 121 may instruct O2 service manager 162 to process a request to create a configuration. The O2 service manager 162 may generate a command to create a configuration and send the command to the O2 terminal 169, which in turn sends the command to the node of the O-cloud 150 via the O2 interface 167.

If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform an action to resolve the conflict, e.g., to implement (or not implement) the O2 service based on the conflict management rules described above (e.g., first come first served; priority based coverage; scope, etc.).

Fig. 5A is a block diagram illustrating an example non-RT RIC 122 providing conflict management for SME services in accordance with one or more techniques of the present disclosure. In this example, conflict manager 121 may provide conflict management for SME services (e.g., service requests) provided by applications 123 (rApp). Although the techniques for providing conflict management of SME services are described with respect to conflict manager 121 of fig. 1B, the techniques for providing conflict management of SME services may alternatively or additionally be performed by service manager 163 or any other micro-service of non-RT RIC 122.

The non-RT RIC 122 may include an R1 interface 154 that provides an interface between one or more applications 123 and the R1 terminal 152. The R1 interface 154 exposes the application 123 to SME services. The SME service may provide services supporting R1 services and their presentation and extensibility through services including bootstrapping, service registration/deregistration or updates to service registration, service discovery or notification, heartbeat, authentication, authorization, etc. In this example, the R1 terminal 152 may receive a request for SME services from rApp a via the R1 interface 154, e.g., a request to register for services via the R1 interface 154. The request may specify rApp a's identifier, service profile, or other information for registering with the service. In response, the R1 interface 154 sends a message to the conflict manager 121 to determine whether there is a conflict with the request to register for service.

The conflict manager 121 may determine whether a request to register for a service would result in a conflict (e.g., with a previously registered request). If conflict manager 121 determines that there is no conflict, conflict manager 121 may instruct service manager 163 to continue registering for service. The service manager 163 may register the service and send a response to the service registration to the R1 terminal 152, which in turn sends the response to rApp a via the R1 interface 154.

If conflict manager 121 determines that a conflict exists, conflict manager 121 may instruct non-RT RIC 122 to perform actions to resolve the conflict, e.g., to implement (or not implement) SME services based on the conflict management rules described above (e.g., first come first served; priority based coverage; scope, etc.).

Fig. 5B is a flow diagram of example conflict management for an SME service in accordance with one or more techniques of the present disclosure. FIG. 5B is described with respect to conflict manager 121 of FIG. 5A, but may also be applied to service manager 163 or any other micro-service of non-RT RIC 122. Although the example depicted in fig. 5B is described with respect to registering a service, the techniques may also be applied to modification or deletion of a service.

In the example of fig. 5B, the application 123 may send a request (e.g., a registration service request) for SME service to the R1 terminal 152 (502), which sends a message to the conflict manager 121 to determine if there is a conflict with the specified SME service. Conflict manager 121 may check the authorization of the service request (504), validate the service request (506), and determine if the service request has any conflicts (508).

In response to determining that there is no conflict, conflict manager 121 may instruct service manager 163 to continue to implement the SME service. For example, the service manager 163 may process the SME service through the registration service (510). The service manager 163 sends a response to the service registration to the R1 terminal 152, which in turn sends the response to the application 123 via the R1 interface 152 (512).

Fig. 5C is a flow diagram illustrating another example conflict management of an SME service according to one or more techniques of this disclosure. FIG. 5C is described with respect to conflict manager 121 of FIG. 5A, but may also be applied to service manager 163 or any other micro-service of non-RT RIC 122.

In the example of fig. 5C, the application 123 may send a request for SME service (e.g., discovery service request) to the R1 terminal 152 (522), which sends a message to the conflict manager 121 to determine if there is a conflict with the specified SME service. Conflict manager 121 may examine the authorization of the service discovery request (524) and determine if the service discovery request has any conflicts (526).

In response to determining that there is no conflict, conflict manager 121 may instruct service manager 163 to continue to implement the SME service. For example, the service manager 163 may process SME services by allowing (or not allowing) discovery services. The service manager 163 sends a response to the service discovery request to the R1 terminal 152, which in turn sends the response to the application 123 via the R1 interface 152 (528).

Fig. 6 is a flowchart of example operations of a radio access network intelligent controller (RIC) configured to perform collision management in accordance with the techniques described in this disclosure. Example operation 600 is described with reference to non-RT RIC 122 of fig. 1B.

In the example of fig. 6, non-RT RIC 122 may receive a request from an application to perform a service using an interface of non-RT RIC 122 (602). For example, non-RT RIC 122 may receive a request from application 123 (e.g., a request for an A1 service, an O1 service, etc.) and send a message to conflict manager 121 to determine whether the service has a conflict.

Non-RT RIC 122 may determine whether the service has a conflict (604). For example, non-RT RIC 122 may include one or more micro-services (e.g., conflict manager 121) configured to provide conflict management for services of respective interfaces (e.g., A1, O2 interfaces) and services available on those interfaces. In some examples, conflict manager 121 is configured to determine whether an A1 service (e.g., policy) from near RT RIC 124 of application 123 (rApp) has a conflict. For example, conflict manager 121 may determine whether a conflict exists between policies of application 123 (rApp), such as by determining whether overlapping policies include contradictory declarations (e.g., target/resource declarations). In some examples, conflict manager 121 is configured to determine whether an O1 service (e.g., configuration management service, performance management service) from an O-RAN management element of application 123 (rApp) has a conflict. For example, the conflict manager 121 may determine whether a request to provide a configuration of an O-RAN management element (e.g., a request to create or update a Management Object Instance (MOI)) would conflict with a previous configuration of the O-RAN management element. In some examples, conflict manager 121 is configured to determine whether an O2 service (e.g., infrastructure management service, deployment management service) of a resource from an O-RAN cloud of application 123 (rApp) has a conflict. For example, conflict manager 121 may determine whether a request to provide a configuration of resources of an O-RAN cloud would conflict with a previous configuration of resources of the O-RAN cloud. In some examples, conflict manager 121 is configured to determine whether other services have a conflict, e.g., SME services, DME services, AI/ML services, or other services provided by non-RT RIC 122.

In response to determining that the service has a conflict ("yes" of step 604), non-RT RIC 122 may perform an action to resolve the conflict (606). In some examples, conflict manager 121 may determine which conflict policies to implement based on one or more conflict management rules. As one example, conflict manager 121 may implement a first-come first-served rule. In this example, if the request to create the policy of the first application precedes the request to create the policy of the second application, non-RT RIC 122 may implement the policy of the first application. Alternatively or additionally, the conflict manager 121 may implement priority-based priority rules, wherein policies of applications with higher priorities are implemented. For example, the conflict manager 121 may implement a policy of a second application based on the second application having a higher priority than the first application. In some examples, conflict manager 121 may override policies specifying a general scope with policies specifying a narrower scope. For example, the non-RT RIC 122 may implement policies for UE-specific performance goals, rather than more general policies that specify performance goals for all UEs, or for narrower policies, cover more general policies that are widely applied in the case of a specific UE. In some examples, an operator may configure conflict management rules to apply to each policy statement. For example, an operator may configure an implementation of a first conflict management rule in response to determining a conflict with a first policy statement, and configure an implementation of a second conflict management rule different from the first conflict management rule in response to determining a conflict with a second policy statement. In some examples, parameters of network resources may be categorized into different types, e.g., information Object Class (IOC), proxy class, and data type parameters. The IOC describes information that may be used in the management interface. The IOC includes attributes that represent various characteristics of the IOC. In these examples, non-RT RIC 122 may apply conflict management rules based on parameters or based on parameters and parameter types. For example, conflict manager 121 may determine whether the target Distinguished Name (DN) of the first request overlaps with the target DN of the second request and whether the attributes of the Management Object Instance (MOI) and MOI of the first request overlap with the attributes of the MOI and MOI of the second request.

If conflict manager 121 determines that there is no conflict ("NO" of step 604), then conflict manager 121, non-RT RIC 122 may implement the service (608). In some examples, if conflict manager 122 determines that the A1 service (e.g., creating a policy for near RT RIC 124) does not have a conflict, conflict manager 121 instructs policy manager 158 of non-RT RIC 122 to continue creating policies for near RT RIC 124 (e.g., generating an HTTP PUT claim to create the policies and send the command to A1 terminal 156, which in turn sends the command to near RT RIC 124 via A1 interface 164). In some examples, if conflict manager 121 determines that the O1 service (e.g., providing a configuration for the O-RAN management element) is not conflicting, conflict manager 121 instructs O1 service manager 160 to continue providing a configuration for the O-RAN management element (e.g., generates a command to modify the MOI attribute of the O-RAN management element and sends the command to O1 terminal 168, which in turn sends the command to the O-RAN management element via O1 interface 166). In some examples, if conflict manager 121 determines that the O2 service (e.g., providing a configuration for resources of the O-RAN cloud) is not conflicting, conflict manager 121 instructs O2 service manager 162 to continue providing a configuration for resources of the O-RAN cloud (e.g., generating a command to modify the configuration of the physical infrastructure nodes hosting the O-RAN functions (e.g., virtual network functions), supporting software components, and appropriate management and orchestration functions), and sends the command to O2 terminal 169, which in turn sends the command to the resources of the O-RAN cloud via O2 interface 167.

FIG. 7 is a diagram illustrating an example computing system in detail, in accordance with the techniques of this disclosure. In this example of fig. 7, computing system 700 may implement, for example, a non-RT RIC, e.g., non-RT RIC 122 of fig. 1A, 1B, 2A, 3A, 4, and 5A.

The computing system 700 includes one or more processors 720, one or more input devices 722, one or more output devices 723, one or more communication units 719, and one or more storage devices 721. In some examples, computing system 700 is a cloud computing system, a server farm, and/or a server cluster (or portion thereof) that provides services to client devices and other devices or systems. In other examples, computing system 700 may be implemented by one or more virtualized computing instances (e.g., virtual machines, containers) of a data center, a cloud computing system, a server farm, and/or a server cluster.

One or more devices, modules, storage areas, or other components of computing system 700 may be interconnected to achieve inter-component (physical, communicative, and/or operational) communication. In some examples, such a connection may be provided by a communication channel, a system bus (e.g., message bus 151 of fig. 1B), a network connection, an interprocess communication data structure, or any other method for communicating data.

The one or more processors 720 of computing system 700 may implement functions and/or execute instructions associated with conflict management of a non-RT RIC or associated 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 720 may be, may be part of, and/or may include processing circuitry that performs operations in accordance with one or more aspects of the present disclosure. Examples of processor 720 include a microprocessor, an application processor, a display controller, an auxiliary processor, one or more sensor hubs, and any other hardware configured to act as a processor, processing unit, or processing device. Computing system 700 may use one or more processors 720 to perform operations in accordance with one or more aspects of the present disclosure using software, hardware, firmware, or a mixture of hardware, software, and firmware resident in and/or executing at computing system 700. Any one or more of application 123, policy manager 158, O1 service manager 160, O2 service manager 162, service manager 163, data manager 155, and conflict manager 121 may be hosted by a cloud provider or other third party.

One or more communication units 719 of the computing system 700 may communicate with devices external to the computing system 700 by sending and/or receiving data, and may operate as both input devices and output devices in some aspects. In some examples, the communication unit 719 may communicate with other devices over a network. In other examples, the communication unit 719 may transmit and/or receive radio signals over a radio network (e.g., a cellular radio network). In other examples, the communication unit 719 of the computing system 700 may transmit and/or receive satellite signals over a satellite network (e.g., a Global Positioning System (GPS) network). Examples of communication unit 719 include a network interface card (e.g., an ethernet card), an optical transceiver, a radio frequency transceiver, a GPS receiver, or any other type of device capable of transmitting and/or receiving information. Other examples of the communication unit 719 may include a communication-enabled unitGPS, NFC, zigBee devices for communication with cellular networks (e.g., 3G, 4G, 5G) and/>, in mobile devicesRadio, universal Serial Bus (USB) controller, etc. Such communication may adhere to, implement, or adhere to appropriate protocols, including transmission control protocol/internet protocol (TCP/IP), ethernet, bluetooth, NFC, or other technologies or protocols.

The one or more input devices 722 may represent any input device of the computing system 700 that is not separately described herein. The one or more input devices 722 may generate, receive, and/or process input from any type of device capable of detecting input from a person or machine. For example, one or more input devices 722 may generate, receive, and/or process input in the form of electrical, physical, audio, image, and/or visual input (e.g., peripheral devices, keyboards, microphones, cameras).

The one or more output devices 723 may represent any output devices of the computing system 700 that are not separately described herein. The one or more output devices 723 may generate, receive, and/or process input from any type of device capable of detecting input from a person or machine. For example, one or more output devices 723 may generate, receive, and/or process output in the form of electrical and/or physical output (e.g., peripherals, actuators).

One or more storage devices 721 within computing system 700 may store information for processing during operation of computing system 700. The storage 721 may store program instructions and/or data associated with one or more modules described in accordance with one or more aspects of the present disclosure. The one or more processors 720 and the one or more storage devices 721 may provide an operating environment or platform for these modules, which may be implemented as software, but may include any combination of hardware, firmware, and software in some examples. The one or more processors 720 may execute instructions and the one or more storage devices 721 may store the instructions and/or data for the one or more modules. The combination of processor 720 and storage 721 may retrieve, store and/or execute instructions and/or data for one or more applications, modules or software. Processor 720 and/or storage device 721 may also be operably coupled to one or more other software and/or hardware components, including but not limited to one or more components of computing system 700 and/or one or more devices or systems shown connected to computing system 700.

In some examples, the one or more storage devices 721 are temporary storage, illustrating that the primary purpose of the one or more storage devices is not long term storage. The storage device 721 of the computing system 700 may be configured as volatile memory for short-term storage of information, and thus, if deactivated, does not retain the stored content. 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, storage device 721 also includes one or more computer-readable storage media. The storage device 721 may be configured to store larger amounts of information than the volatile memory. The storage device 721 may also be configured as a non-volatile storage space for long-term storage of information and to retain information after an activation/deactivation cycle. Examples of non-volatile memory include magnetic hard disks, optical disks, flash memory, or various forms of electrically programmable memory (EPROM) or Electrically Erasable Programmable (EEPROM) memory.

Computing system 700 may provide conflict management for a particular application 123. As described above, application 123 may manage non-real-time events within non-RT RICs 122, e.g., applications that do not require a response time of less than one second. Application 123 can utilize functionality exposed via a non-RT RIC framework of computing device 700. The application 123 may be used to control and manage RAN elements and resources, e.g., resources in near RT RIC, RAN nodes, and/or O-RAN clouds. The application 123 may provide one or more services that are executed using an interface (e.g., an A1 interface, an O2 interface, etc.) of the computing system 700. For example, application 123 may include services such as policy 732 for near RT RIC, configuration instructions 734 for O-RAN management elements, performance jobs 736 for O-RAN management elements, services 738 for managing services and/or data, and the like.

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

For example, the policy manager 158 is configured to control deployment of policies (e.g., A1 services). For example, policy manager 158 may receive a request for an A1 service from application 123 (e.g., via R1 interface 154 of fig. 1B), process the A1 service from application 123, and execute the A1 service of the near RT RIC using the A1 interface (e.g., A1 interface 164 of fig. 1B). In some examples, the A1 interface may implement an A1AP application protocol based on a 3GPP framework.

O1 service manager 160 is configured to control deployment of O1 services to monitor performance of O-RAN management elements (e.g., near RT RIC 124, O-CU 146, O-DU 148 of fig. 1B). For example, O1 service manager 160 may receive a request from application 123 for an O1 service for monitoring performance of a near RT RIC (e.g., via R1 interface 154 of fig. 1B), process the O1 service, and perform the O1 service for the O-RAN management element using the O1 interface (e.g., O1 interface 166 of fig. 1B). In some examples, the O1 interface may implement REST/HTTPS APIs and/or netcon f.

The O1 service manager 160 is additionally or alternatively configured to control deployment of O1 services for configuration of the near RT RIC 124 and/or RAN nodes. For example, O1 service manager 160 may receive a request from application 123 (e.g., via R1 interface 154 of fig. 1B) for an O1 service for a configuration of an O-RAN management element, process the O1 service, and may perform the O1 service of the O-RAN management element using an O1 interface (e.g., O1 interface 166 of fig. 1B).

The O2 service manager 162 may be configured to control deployment of O2 services for monitoring performance of resources of the O-RAN cloud. For example, the O2 service manager 162 may receive a request for an O2 service for monitoring performance of resources in the O-RAN cloud (e.g., via the R1 interface 154 of fig. 1B), process the O2 service, and may perform the O2 service for the resources of the O-RAN cloud using the O2 interface (e.g., the O2 interface 167 of fig. 1B).

The O2 service manager 162 may additionally or alternatively be configured to control deployment of O2 services for configuring resources of the O-RAN cloud. For example, O2 service manager 162 may receive a request from application 123 (e.g., via R1 interface 154 of fig. 1B) for an O2 service for configuring resources in the O-RAN cloud, process the O2 service, and may perform the O2 service for the resources of the O-RAN cloud using an O2 interface (e.g., O2 interface 167 of fig. 1B).

The service manager 163 is configured to manage services, for example, service registration, update of service registration, service discovery, and the like. For example, the service manager 163 may receive a request for SME services from the applications 123 (e.g., via the R1 interface 154 of fig. 1B), perform SME services (e.g., registration/update services) for one or more applications 123, and send responses to one or more applications 123 using the R1 interface (e.g., the R1 interface 154 of fig. 1B).

The data manager 155 is configured to manage data of the application 123. For example, the data manager 155 may receive a request for DME services from the applications 123 (e.g., via the R1 interface 154 of FIG. 1B), perform DME services for one or more applications 123 (e.g., send data from an application configured as a data producer to an application configured as a data consumer), and send a response to the one or more applications 123 using the R1 interface (e.g., the R1 interface 154 of FIG. 1B).

Computing system 700 includes a conflict manager 121 configured to provide conflict management of services performed using interfaces other than RT RIC. In this example, conflict manager 121 includes an analysis engine 740, an action engine 742, and one or more conflict management rules 744.

In some examples, analysis engine 740 is configured to determine whether an overlapping policy (e.g., at least a portion of the policy scope overlaps) includes contradictory declarations (e.g., objective/resource declarations) of A1 services performed using the A1 interface. In some examples, analysis engine 740 is configured to determine whether a request to configure one or more O-RAN management elements performed using an O1 interface or a request to configure one or more resources of an O-RAN cloud performed using an O2 interface would result in a conflict (e.g., conflicting MOI). In some examples, analysis engine 740 is configured to determine whether a request for a performance job of one or more O-RAN management elements performed using an O1 interface or a request for a performance job of one or more resources of an O-RAN cloud performed using an O2 interface would result in a conflict (e.g., overlapping IOCs and attributes, contradicting attribute value changes, specifying a different data network, etc.). In some examples, analysis engine 740 is configured to determine if a request for management services performed using the R1 interface would result in a conflict (e.g., with a previously registered service or a previously implemented application).

In response to determining that the service has a conflict, the action engine 742 is configured to resolve the determined conflict. For example, action engine 742 may implement services based on one or more conflict management rules 744. As described above, conflict management rules 744 may include, for example, implementing policies based on a first come first served principle, implementing policies from applications with higher priority, implementing policies based on scope of policies, implementing policies based on IOC type or based on IOC type and IOC attributes.

In some examples, a user may specify which conflict management rule to apply to resolve the conflict via a user interface module (UI) 786. UI module 786 may generate data indicating various user interface screens that graphically depict conflict management rules. UI module 786 may output data indicative of various user interface screens, for example, for display by a separate display device. UI module 786 may also output data indicative of the graphical user interface element soliciting input for display. The input may be, for example, a conflict management rule applied to a particular service, query, or other input.

The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, the respective aspects of the described techniques may be implemented in 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 circuitry, as well as any combinations of such components. The term "processor" or "processing circuit" may generally refer to any of the foregoing logic circuits (alone or in combination with other logic circuits) or any other equivalent circuit. A control unit comprising hardware may also perform one or more techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. Furthermore, any of the described units, modules, or components may be implemented together or separately as discrete but interoperable logic devices. The description of different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components or integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium containing instructions, such as a computer-readable storage medium. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer readable media may include non-transitory computer readable storage media and transitory communication media. The tangible and non-transitory computer-readable storage medium may 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, a hard disk, a CD-ROM, a floppy disk, a magnetic tape cartridge, a magnetic medium, an optical medium, or other computer-readable storage medium. The term "computer-readable storage medium" refers to physical storage media, rather than signal/carrier wave or other transitory media.

Claims

1. A non-real-time radio access network intelligent controller, non-RTRIC, for a radio access network, RAN, the RIC comprising:

One or more processors; and

A memory coupled to the one or more processors, the memory storing instructions to cause the one or more processors to:

Receiving a request from an application to perform a service using an interface of the non-RT RIC;

Determining whether the service has a conflict; and

An act of resolving the conflict is performed based on a determination that the service has a conflict.

2. The non-RT RIC of claim 1, wherein the interface comprises an A1 interface, an O2 interface, or an R1 interface of the non-RTRIC.

3. The non-RT RIC of claim 1,

Wherein, to perform the act of mitigating the conflict, the instructions further cause the one or more processors to perform one or more of:

Allowing the implementation of said service;

implementing the service based on a first-come first-serve principle;

Implementing the service based on the priority of the application; or alternatively

The service is implemented based on a policy scope of the service.

4. The non-RT RIC of claim 1, wherein the action is user configurable.

5. The non-RT RIC according to any one of claims 1 to 4,

Wherein to determine whether the service has a conflict, the instructions further cause the one or more processors to:

Based on a comparison of a first policy of the application with a second policy of the application or a different application, determining whether one or more claims of the first policy contradict one or more claims of the second policy, wherein the first policy overlaps at least a portion of the second policy.

6. The non-RT RIC according to any one of claims 1 to 4,

A determination is made as to whether one or more claims within the applied policy exceed a limit of a target of the policy.

7. The non-RT RIC according to any one of claims 1 to 4,

Wherein the service comprises a first service, and

Wherein the instructions further cause the one or more processors to:

Receiving, from a second application of the one or more applications, a request for conflict guidance for a second service using the interface of the non-RT RIC;

Determining whether the second service has a conflict; and

Providing a guidance response to the second application based on the determination that the second service has a conflict.

8. The non-RT RIC of claim 7, wherein the bootstrapping response comprises one or more of:

An indication of whether the second service is generating a conflict;

One or more suggestions to resolve the conflict; or alternatively

Information identifying the cause of the conflict.

9. The non-RT RIC according to any one of claims 1 to 4,

Based on a comparison of a first request by the application to configure an O-RAN management element with a second request by the application or a different application to configure the O-RAN management element, it is determined whether the first request to configure the O-RAN management element contradicts the second request to configure the O-RAN management element.

10. The non-RT RIC according to any one of claims 1 to 4,

Based on a comparison of a first request for a performance job of an O-RAN management element by the application with a second request for a performance job of the O-RAN management element by the application or a different application, it is determined whether the first request for a performance job of the O-RAN management element contradicts the second request for a performance job of the O-RAN management element.

11. The non-RT RIC according to any one of claims 1 to 4,

based on a comparison of a first request by the application to a first configuration management service configuring a physical infrastructure node hosting an O-RAN function and a second request by the application or a different application to a second configuration management service configuring the physical infrastructure node, determining whether the first request contradicts the second request.

12. The non-RT RIC according to any one of claims 1 to 4,

Based on a comparison of a first request by the application for a first performance management service that monitors performance of a physical infrastructure node hosting an O-RAN function with a second request by the application or a different application for a second performance management service that monitors performance of the physical infrastructure node, a determination is made as to whether the first request contradicts the second request.

13. The non-RT RIC according to any one of claims 1 to 4,

Determining whether a target distinguished name, DN, of the first configuration request overlaps a target DN of a second configuration request based on a comparison of the first configuration request of the application with the second configuration request of the application or a different application; and

Based on a comparison of a first configuration request of the application with a second configuration request of the application or a different application, it is determined whether attributes of management object instances, MOIs, and MOIs, of the first configuration request overlap with attributes of MOIs, and MOIs, of the second configuration request.

14. The non-RT RIC according to any one of claims 1 to 4,

Based on a comparison of a first configuration request of the application with a second configuration request of the application or a different application, it is determined whether an attribute value of a management object instance, MOI, of the first configuration request is different from an attribute value of an MOI of the second configuration request.

15. The non-RT RIC of any one of claims 1-4, wherein to determine whether the service has a conflict, the one or more processors are configured to determine whether the service has at least one of a direct conflict, an indirect conflict, or an implicit conflict.

16. A method, comprising:

Receiving, by a non-real-time radio access network intelligent controller for managing non-real-time events of a radio access network RAN, a request from an application for performing a service using an interface of the non-RT RIC;

determining, by the RIC, whether the service has a conflict; and

An act of resolving the conflict is performed by the RIC based on a determination that the service has a conflict.

17. The method of claim 16, wherein the interface comprises an A1 interface, an O2 interface, or an R1 interface of the non-RT RIC.

18. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to be configured as a non-RT RIC according to any one of claims 1-15 or to perform a method according to any one of claims 16-17.