Collision management for open radio access networks

Abstract

The described techniques generally relate to conflict management of applications implemented on a radio access network (RAN). Various embodiments are presented to enable identification of potential conflicts (e.g., if applications are being loaded) and current conflicts (e.g., if two or more applications have run). Conflicts may directly affect control targets, e.g., two applications are trying to control the same target. Conflicts may indirectly affect control objectives, two applications affecting a first metric and a second metric, but a third metric is affected. Conflict resolution includes preventing loading of an application, terminating execution of the application, identifying a cause irrelevant to the application, and the like. Collision resolution can be performed at a RAN Intelligent Controller (RIC).

Description

Related Applications

[0001] This application claims priority to U.S. Non-Provisional Patent Application No. 18 / 336,299, filed June 16, 2023, entitled “CONFLICT MANAGEMENT OF AN OPEN-RADIO ACCESS NETWORK,” which is incorporated by reference herein in its entirety. BACKGROUND

[0002] A radio access network (RAN) provides wide-area wireless connectivity to mobile devices. A RAN can be composed of devices manufactured by different vendors. In view of the potentially vast scale and complexity of RANs developed to meet the ever-increasing demand for cellular communications, various vendor alliances have formed with the goal of generating specifications to facilitate configuration, technology, methodology, devices, etc. for respective communications over the RAN. Such alliances include the Third Generation Partnership Project (3GPP), Long Term Evolution Fourth Generation (LTE 4G), Fifth Generation / New Radio (5G, 5G / NR), and most recently, Open Radio Access Network (O-RAN).

[0003] The impetus for O-RAN is for an open disaggregated RAN, which can be achieved by splitting the RAN architecture, applications (e.g., xApps), and protocols into different independent components. Disaggregation is expected to reduce energy consumption, improve system performance, and allow for fast, open innovation in different components, while ensuring multi-vendor, vendor-agnostic, and operable networks.

[0004] The above-described background is merely intended to provide some context overview of current problems and is not intended to be exhaustive. Other context information can become apparent upon review of the following detailed description. SUMMARY

[0005] A brief summary of the disclosed subject matter is presented here for the purpose of providing a basic understanding of one or more embodiments described herein. This summary is not an extensive overview of the various embodiments. It is not intended to identify key or critical elements of the various embodiments. The purpose of the summary is to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description presented later.

[0006] In one or more embodiments described herein, systems, devices, computer- implemented methods, configurations, apparatuses, and / or computer program products are presented to identify and resolve conflicts between applications implemented over a RAN.

[0007] According to one or more embodiments, a computer-implemented method is provided, where the method includes receiving, by a device comprising a processor, a request to load a first application (xApp), where the first xApp is configured to adjust a first metric of a radio access network (RAN). The method can further include determining, by the device, whether the adjustment to the first metric would cause a conflict with a current operation of the RAN. In embodiments, the RAN is an open RAN (O-RAN).

[0008] In embodiments, the method can further include determining, by the device, whether the RAN can support the adjustment to the first metric by the first xApp, and further, in response to the RAN being determined as unable to support the adjustment to the first metric by the first xApp, rejecting, by the device, the load request from the first xApp to operate the first xApp at the RAN.

[0009] In another embodiment, the method can further include determining, by the device, a second metric adjusted by a second xApp, where the first metric of the first xApp and the second metric of the second xApp have a common control objective, and further, in response to the first metric of the first xApp and the second metric of the second xApp being determined, by the device, as having the common control objective, determining, by the device, whether the first metric of the first xApp adversely affects operation of the common control objective in accordance with the operation of the common control objective adjusted by the second metric of the second xApp. Further, in response to the first metric of the first xApp being determined as adversely affecting the operation of the common control objective in accordance with the operation of the common control objective adjusted by the second metric of the second xApp, rejecting, by the device, the load request from the first xApp to operate the first xApp at the RAN.

[0010] In another embodiment, the method can further include: (i) in response to the first metric of the first xApp being determined as adversely affecting the operation of the common control objective in accordance with the operation of the common control objective adjusted by the second metric of the second xApp, applying, by the device, a first priority to the first xApp and a second priority to the second xApp, where the first priority has a higher priority than the second priority; (ii) executing, by the device, the first xApp based on the higher priority; (iii) terminating, by the device, the operation of the first xApp; and (iv) executing, by the device, the second xApp. In embodiments, the operation of the first xApp can be terminated based on a configured duration.

[0011] In another embodiment, the method can further include identifying, by the device, a second metric adjusted by a second xApp, wherein the first metric and the second metric are different, and further determining, by the device, that a third metric running at the device is negatively impacted by the interaction resulting from the first metric being adjusted by the first xApp and the second metric being adjusted by the second xApp. In another embodiment, the method further includes terminating, by the device, execution of the first xApp.

[0012] Other embodiments can utilize a system including at least one processor; and a memory coupled to the at least one processor and having instructions stored thereon, wherein when executed by the at least one processor, the instructions facilitate performance of operations including identifying that a first metric of a radio access network (RAN) is controlled by a first application (xApp), further identifying that a second metric of the RAN is controlled by a second xApp, and determining whether control of the second metric is adversely affected by control of the first metric by the first xApp. In an embodiment, the system is one of: a real-time RAN intelligence controller (RIC), a near-real-time RIC, or a non-real-time RIC.

[0013] For some contexts, example non-limiting Non-RT RIC functions include service and policy management, RAN analytics, and model training for Near-RT RIC. In this regard, the Non-RT-RIC implements non-real-time (e.g., a first time range, such as > 1 s) control of RAN elements and their resources through applications (e.g., specialized applications, referred to as rApps). Example non-limiting Near-RT RIC functions implement near-real-time optimization and control of CU nodes and DU nodes and data monitoring on a near-real-time timescale (e.g., representing a second time range that is less than the first time range, such as between 10 ms to 1 s). In this regard, the Near-RT RIC controls RAN elements and their resources with optimization actions that typically take approximately 10 milliseconds to approximately 1 second to complete, although different time ranges can be selected. The Near-RT RIC can receive policy guidance from the Non-RT-RIC and can provide policy feedback to the Non-RT-RIC through specialized applications (referred to as xApps). In this regard, a real-time RIC (RT RIC) is designed to handle network functions on a real-time timescale (e.g., representing a third time range that is less than the first time range and the second time range, such as < 10 ms).

[0014] In another embodiment, the operations can further include terminating execution of the first xApp in response to determining that control of the second metric by the second xApp is adversely affected by control of the first metric by the first xApp.

[0015] In another embodiment, the operations can further include running the first xApp for a first time period and running the second xApp for a second time period in response to determining that the second xApp’s control of the second metric is adversely affected by the first xApp’s control of the first metric, wherein the first time period and the second time period are non-overlapping and different.

[0016] In another embodiment, the operations can further include: (i) determining to run a third metric at the RAN in response to determining that the second xApp’s control of the second metric is not adversely affected by the first xApp’s control of the first metric; (ii) determining whether the running of the third metric at the RAN is adversely affected by the combination of the first metric being controlled by the first xApp and the second metric being controlled by the second xApp; and (iii) terminating the running of the first xApp in response to determining that the running of the third metric at the RAN is adversely affected by the combination of the first metric being controlled by the first xApp and the second metric being controlled by the second xApp.

[0017] In an embodiment, the first metric can have a key performance indicator (KPI) configured to identify the running of the first metric, and wherein the first metric relates to at least one of a coverage of the RAN, a capacity of the RAN, or an energy-related performance of the RAN.

[0018] Other embodiments can include a computer program product having stored thereon non-transitory computer-readable medium and including machine-executable instructions that, when executed, cause a machine to perform operations including: identifying a first running characteristic of a first application (xApp), also identifying a second running characteristic of a second xApp, wherein the first xApp and the second xApp are configured to be executed via a radio access network (RAN); and also determining whether the first running characteristic of the first xApp is a threshold that can negatively affect the second running characteristic of the second xApp in a case that the first xApp and the second xApp are co-deployed on the RAN. In an embodiment, the machine is one of: a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC.

[0019] In another embodiment, the operations can further include: in response to determining that the first operational characteristic of the first xApp is a threshold likely to negatively affect the second operational characteristic of the second xApp in the case where the first xApp and the second xApp are co-deployed on the RAN, also rejecting the loading of the first xApp on the RAN. In another embodiment, the operations can further include: in response to determining that the first operational characteristic of the first xApp is not a threshold likely to negatively affect the second operational characteristic of the second xApp in the case where the first xApp and the second xApp are co-deployed on the RAN, co-deploying the first xApp and the second xApp on the RAN, resulting in the co-deployment of the first xApp and the second xApp. The operations can further include: (i) monitoring the running of the metric at the RAN; (ii) determining whether the running of the metric at the RAN is adversely affected by the co-deployment of the first xApp and the second xApp; and further, (iii) in response to the metric being determined to be adversely affected by the co-deployment of the first xApp and the second xApp, terminating the running of the first xApp. BRIEF DESCRIPTION OF DRAWINGS

[0020] Numerous embodiments, objectives, and advantages of the presented embodiments will become apparent in view of the following detailed description, taken in conjunction with the drawings, and wherein like reference numerals refer to like parts throughout and wherein:

[0021] Figure 1 Systems are presented in accordance with embodiments, including various components / devices and various types of interactions / analyses that can be performed with respect to conflicts between various xApps deployed on a RAN.

[0022] Figure 2 Systems are illustrated in accordance with embodiments, including xApp conflict management architecture.

[0023] Figure 3 xApp conflict management systems are presented in accordance with embodiments.

[0024] Figure 4 Systems are presented in accordance with embodiments, including PM engine components.

[0025] Figure 5 High-level structures of conflict detection sub-components are presented in accordance with embodiments.

[0026] Figure 6 Structural frameworks for conflict xApp detection components configured to detect conflicting xApps are presented in accordance with embodiments.

[0027] Figure 7 Methods are illustrated in accordance with one or more embodiments described herein for determining whether a running conflict will occur by running / executing xApps on a RAN.

[0028] Figure 8 FIG. illustrates a method for determining whether a run conflict will occur by running / executing an xApp on a RAN, according to one or more embodiments described herein.

[0029] Figure 9 FIG. illustrates a method for determining whether a run conflict will occur by running / executing an xApp on a RAN, according to one or more embodiments.

[0030] Figure 10 FIG. illustrates a method for deploying an xApp on a RAN based on KPI classes, according to one or more embodiments described herein.

[0031] Figure 11 FIG. illustrates an example wireless communication system, according to one or more embodiments described herein.

[0032] Figure 12 FIG. illustrates an example environment for implementing various embodiments. DETAILED DESCRIPTION

[0033] One or more embodiments will now be described with reference to the attached drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It can be evident, however, that various embodiments can be practiced without restriction to these specific details (e.g., particular wired logic circuitry can be implemented as reconfigurable logic circuitry having a fixed functionality). In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these embodiments. Embodiments are illustrative of the various aspects of the present disclosure.

[0034] Various embodiments presented herein relate to the use of a conflict management system (CMS) in conjunction with conflict detection and mitigation strategies. The CMS can be configured to implement embodiments under any of real-time (RT), near-RT, and / or non-RT. The CMS is configured to comply with O-RAN platform requirements, xApp requirements, and corresponding RAN intelligent controller (RIC) application programming interface (API) requirements.

[0035] According to respective embodiments, one or more systems are presented configured to support multi-xApp interactions. A combination of preventive and reactive measures leads to co-deployment of xApps in case of possible interactions. Based on detected and / or predicted conflicts, xApp subscriptions / deployments at the RAN can be enabled to avoid conflict control actions. xApp subscription management enables operators to adjust their deployment strategies for xApps. Further, when priority evaluation and subscription management can not be an effective solution, implementation of machine learning (ML) and / or artificial intelligence (AI) based models can provide intervention commands to the E2 node.

[0036] For pre-action / deployment measures, during the onboarding process, respective xApps can provide descriptors including any of: configuration information, control (level and type of control) information, target key performance indicator (KPI) categories and sub-categories, xApp classification, etc. The provided descriptors can be used by the CMS to trigger preventive measures.

[0037] For post-action / post-onboarding measures, the RIC can act as an observer independent of the xApps to detect conflicting xApps based on performance monitoring.

[0038] According to respective systems / techniques presented herein, with the multi-xApp interaction framework, respective ML techniques can be used to learn / identify “projections” of performance changes. ML can also predict KPIs in advance to establish baseline behavior. One or more ML techniques / models can be deployed so that a correlation between xApp actions and performance changes can be established and also determine xApps that lead to opposite performance directions.

[0039] During the onboarding process, a restrictive framework can be utilized where the RIC restricts the selection range instead of having a free choice of all information exposed to the xApp that is requesting onboarding. Thus, the RIC can specify a target KPI list for an xApp to select from based on App classification and also can specify an allowed action list for an xApp to select from based on target KPIs. Further, according to various embodiments presented herein, size annotation can be utilized to limit the number of xApps allowed for the same class / KPI category.

[0040] Terminology

[0041] xApp An application, deployable at the O-RAN (e.g., at the RIC) and configured to optimize / automate RAN runs in conjunction with supporting use cases, with the aim of reducing total cost of ownership (TCO) for operators (e.g., mobile operators), enhancing quality of experience (QoE) for customers, etc.

[0042] Class / KPI Class: The corresponding KPIs can be grouped into Class , so that each KPI can have its own class. Each xApp (e.g., each xApp 120A- n can be assigned / associated with a KPI that is the focus of the operation of the respective xApp. Thus, based on classifying a first xApp (e.g., during onboarding) as a KPI, and determining the operational effect of the first xApp on one or more xApps that have been classified for that particular KPI, potential conflicts with respect to the KPI can be quickly identified. Further, to maintain the operational efficiency of the RAN and to mitigate potential unforeseen conflicts, the number of xApps that can be supported / operated for a particular KPI class can be limited. The fewer the number of xApps that impact a particular KPI, the less likely conflicts, whether foreseeable or unforeseeable, will occur.

[0043] Dimensioning : Limit the number of xApps based on their KPI classification.

[0044] Key Performance Indicator KPI : Provide quantifiable performance measures for a particular objective. KPIs can relate to accessibility, availability, integrity, mobility, retainability, etc.

[0045] Key Performance Measurement KPM : Provide performance measures for a KPI.

[0046] Node & E2 Node : The RAN architecture can include a series of units (referred to as nodes), such as a central unit (CU), a distributed unit (DU), and a radio unit (RU). Generally, the CU centralizes the RAN grouping processing functions, the DU performs baseband processing functions across cell sites, and the RU provides radio functions at antenna sites. While the RU is located at the antenna site, the locations of the CU and the DU are not fixed to any particular geographic area or site. The DU can be co-located with the RU that is local to the antenna, or the DU can be located miles away from the RU, such that the connection between the DU and the RU is implemented through any suitable technology, such as fiber. The CU and the DU can be located “in the cloud,” such as at a data center, which can or can not be close to the RU.

[0047] O-cloud: The operational layer, including hardware components and software components, is used to provide cloud computing capabilities to perform various RAN network functions. The O-cloud functions can include O-DU, O-CU-CP, O-CU-UP, O-eNB, near real-time RIC, and non-real-time RIC. ​​

[0048] Preventive Action Conflict management, performed before potentially adverse xApps are deployed / run, preventing xApps that can negatively impact RAN operation from being loaded / deployed / run.

[0049] RAN Intelligent Controller RIC RIC is an O-RAN component configured to control and optimize RAN functions. RIC enables O-RAN disaggregation for multi-vendor / third-party xApp loading to automate / optimize RAN operation, e.g., use cases for reducing mobile operator’s TCO, enhancing customer’s QoE, etc. RIC can control which xApps are deployed on the RAN.

[0050] Coping Action Conflict management, performed while multiple xApps are deployed / run, identifying and resolving interactions among multiple xApps and their impact on respective KPIs.

[0051] n is any positive integer.

[0052] 1. SUMMARY

[0053] While the impetus for O-RAN is for an open disaggregated RAN, the openness of the RAN architecture and protocols can lead to the following: (i) xApps can not be supported by the RAN; (ii) various conflicts when multiple applications (xApps) are co-deployed on the RAN; and / or (iii) xApps can adversely affect the performance of another xApp and / or RAN performance / cause its performance to degrade. System providers / operators can not be aware that the simultaneous deployment of certain xApps on the same RAN site can cause potential conflicts. Conflicting xApps can cause degradation in RAN and / or RIC performance. Conflicts can occur when a first xApp attempts to override a policy or action recently applied / configured / set by a second xApp. This override scenario can put the first and second xApps in a “ping-pong” state where the first xApp constantly overrides the second xApp’s decisions / configurations (and vice versa), causing degradation in RIC and / or RAN performance.

[0054] ​The various embodiments presented herein are configured to observe xApp behavior to identify / infer potential and existing conflicts among various xApps and also manage / mitigate the deleterious effects of deploying one or more conflicting xApps on the RAN and / or RIC. When negative relationships among xApps are identified, warnings / alerts can be generated to help avoid direct and indirect conflicts whenever problematic combinations of xApps are deployed / can be deployed on the RAN site. In embodiments, by leveraging current or historical data about the operation of two or more xApps, warnings / alerts can be issued to prevent combinations of xApps from being broken and deleteriously affecting the operation of the RAN.

[0055] To provide an understanding of the various embodiments presented herein, Figure 1 , the system 100 presents a high-level overview of some of the systems / components involved and various types of interactions / analyses that can be performed with respect to conflict management among various xApps deployed on the RAN.

[0056] As shown, Figure 1 a RAN 110 is presented in which respective xApps 120A-n can be configured to potentially operate and / or are currently operating. The RAN 110 can include various nodes 115, such as one or more of a CU 117, a DU 118, and a RU 119. The RAN 10 can be communicatively coupled to a service management orchestration (SMO) layer / component 135, in which the SMO 135 can be configured to control configuration and automation aspects of the respective components / elements of the RAN 110 and the RIC 150. The SMO 135 can also be configured to coordinate the deployment of respective xApps 120A- n , in example scenarios, this can involve the SMO 135 operating in conjunction with the RIC 150 regarding the likelihood of conflicts occurring during the deployment of respective xApps 120A- n .

[0057] The RIC 150 can be configured to control and optimize functions at the RAN 110, including loading xApps 120A- n to be operated at the RAN 110. As further described, the RIC 150 can also include a conflict management system (CMS) 130 configured to identify potential and existing conflicts among various xApps 120A- n during the potential and current deployment of one or more xApps 120A- n on the RAN 110. As further described, the xApps 120A- n can affect various KPIs 140A- nThe operation, for example, is measured by the key performance metric KPM 145A- n Confirmed. Ideally, RAN 110 will be configured to support numerous xApp 120A- n However, the deployment of the first application (e.g., xApp 120A) can affect the deployment of the second application (e.g., xApp 120B) on RAN 110, and harmfully impact KPI 140A- n One or more KPIs in the dataset. For example... Figure 1 As shown, each xApp 120A- n All can be configured with specific features, use cases, metrics, etc., xApp 120A- n They are designed for specific features, use cases, metrics, etc., with each xApp 120A- n The individual characteristics, use cases, etc. of each focus are represented as data 121A- n The respective data 121A- n With their respective xApp 120A- n Related, for example, xApp 120A has related data 121A, xApp 120B has data 121B, xApp 120n has data 121n, and so on.

[0058] System 100 may also include: O-cloud 160; an infrastructure layer configured to coordinate functions for RAN 110, SMO 135, and RIC 150.

[0059] Figure 1 Three advanced scenarios were presented: (1) loading, (2) subscription / pre-deployment, and (3) deployment and operation.

[0060] (1) On-boarding The xApp120A will be deployed on RAN 110; however, during the loading / subscription of the xApp 120A to RAN 110, CMS 130 is able to determine whether one or more operations to be performed by the xApp 120A are (i) supported by RAN 110 and / or (ii) if supported, whether they can adversely affect RAN 110 and / or other xApp 120Bs already deployed on RAN 110. n The operation of xApp 120A is permitted. If the target / operation of xApp 120A is not supported by RAN 110, subscriptions to xApp 120A at RAN 110 can be rejected.

[0061] (2) Subscription / Pre-deploymentWhen xApp 120B can be deployed on RAN 110, CMS 130 can be configured to determine whether there are one or more operational conflicts between xApp 120B and the deployed / to-be-deployed xApp 120C. If CMS 130 determines that there is an operational conflict between xApp 120B and xApp 120C, various responses are possible, such as either xApp 120B or xApp 120C not being deployed, xApp being deployed with xAppB's operation taking precedence over xAppC, etc., as further described.

[0062] (3) Deployment and Operation : Many xApp 120A- n Deployed on and running on RAN 110, thus xApp's 120A- n The performance of one or more xApps within the system can be evaluated using CMS 130. xApp 120A- n One or more xApps can run based on their respective xApp 120A- n For one or more KPIs 140A- n and / or KPM150A- n The impact of the operation is being evaluated. Therefore, the negative impact KPI 140A- n The execution of one or more KPIs and / or xApp's 120A- n Any xApp running (e.g., xApp 120N) can be isolated, and its operation can be terminated, delayed, postponed, etc., as further described.

[0063] like Figure 1 As shown, CMS 130 and RAN 110 are communicatively coupled to computer system 180. Computer system 180 may include processor 182 and memory 184, wherein processor 182 is capable of executing various computer-executable components, functions, operations, etc., as presented herein. Memory 184 may be used to store various computer-executable components, functions, code, etc., as well as information about any of the following: xApp 120A- n KPI 140A- n KPM 150A- n Operating condition information of O-RAN (e.g., RAN 110, RIC 150, SMO 135, as further described), process 245 (as further described), and data 121A stored in information database 250 and subscription database 260. n (As further described), thresholds, alarms / warnings / notifications, etc.

[0064] As further shown, the computer system 180 can include an input / output (I / O) component 186, where the I / O component 186 can be a transceiver configured to enable transmission / reception of information between any of the components included in the system 100. The I / O component 186 can be communicatively coupled to remotely located devices and systems. In embodiments, the I / O component 186 can be configured to transmit various alerts / warnings (e.g., warnings / alerts / information 236A- n between the xApps 120A- n ).

[0065] In embodiments, the computer system 180 can also include a human-machine interface (HMI) 188 (e.g., a display, a graphical user interface (GUI)) that can be configured to present various information in accordance with the various embodiments presented herein, including any of the xApps 120A- n , associated conflicts and solutions, etc.). The HMI 188 can include an interactive display 189 to present various information via various screens presented thereon, and also be configured to facilitate input of information / settings, etc., regarding the xApps 120A- n .

[0066] In accordance with the various components presented in the system 100, conflict mitigation can involve detecting, avoiding, and / or resolving conflicting interactions between different xApps 120A- n deployed on the RAN 110. The deployment of xApps 120A- n can involve changing one or more operational parameters at the RAN 110 (or at the SMO 135, RIC 150, etc., as further described) with the goal of optimizing a particular metric (e.g., with associated KPI 140A- n ). However, while two or more xApps 120A- n (e.g., a first xApp 120A and a second xApp 120B) can be designed to optimize the same metric, respectively, the co-deployment of the two or more xApps 120A- n can result in conflicting actions. In another case, while a first operational goal of an xApp 120A and a second operational goal of an xApp 120B can be different, the co-deployment of the xApp 120A with the xApp 120B can result in conflicting actions that can also adversely affect the operation of the RAN 110. Thus, when two or more xApps 120A- n are deployed, conflict management and resolution is of paramount importance, particularly when the respective xApps 120A-n With different vendors creating the case, this can be possible considering the decomposed nature of the O-RAN system.

[0067] According to Figure 1 The presented O-RAN environment, the xApps 120A- n can interact with any of the SMO platform 135, RIC 150 (e.g., control interface exposure), and o-cloud 160 components, respectively. It should be appreciated that to minimize repetition, while various embodiments presented herein can make specific mention of one or more xApps 120A- n are presented / deployed / run on the RAN 110, RIC 150, etc., but considering the ubiquitous nature of the xApps 120A- n can run on the RAN 110, SMO 135, RIC 150, etc., mention of utilizing the xApps 120A- n on any of the various components described herein applies equally to applications on any of the various components.

[0068] The various embodiments presented herein can be used for RT, near-RT, and / or non-RT implementations of the RIC, e.g., as presented in traditional RAN architectures. In traditional systems, implementation solutions for resolving conflicts between xApps 120A- n are not available in near-RT or RT, which the various embodiments presented herein address. The various embodiments presented herein provide a management architecture that utilizes the CMS 130 to identify and resolve conflict issues according to one or more operational requirements of the RAN 110, operational requirements of the respective xApps 120A- n , RIC 150 API requirements, vendor-agnostic approach, etc.

[0069] 1.1. Conflict Overview

[0070] An overview of some of the conflicts that can exist between various xApps 120A- n deployed on the RAN 110 is provided below. As mentioned, the respective xApps 120A- n can configure a single parameter or a set of parameters to optimize a particular metric (e.g., KPI 140A- n ) at the RAN 110. Each xApp 120A- n can have a specific control objective (e.g., objective 212A, according to Figure 2). For example, two or more xApps 120A- n may be deployed as part of a radio resource management (RRM) application Figure 2 may be a cell, a user equipment (UE), a bearer, etc. Further, the control content of RRM can include access control, bearer control, handover control, resource allocation, quality of service (QoS) control, etc. Moreover, the control commands can have a control time span, indicating a valid control duration. Thus, at any time, there can be a conflict between the control commands of the respective xApps 120A- n , e.g. because these control commands all relate to RRM.

[0071] As further described, the respective conflicts can be classified as follows:

[0072] 1.1. a. Direct conflict:

[0073] A direct conflict can occur between multiple xApps 120A- n and can be directly observed by the CMS 130. Examples of direct conflicts are presented below:

[0074] i) One or more parameters of a control target (e.g. target 212A, according to Figure 2 ) are requested by two or more xApps 120A- n to be set differently. The CMS 130 can be configured to handle the respective requests and decide which requests to operate / execute based on priority and / or other metrics.

[0075] ii) A configuration can be running (e.g. a previous request has been executed and the operation is running). A new request from a first xApp (e.g. xApp 120F) can conflict with a previous request from the same xApp (e.g. xApp 120F) or a different xApp (e.g. xApp 120G). Thus, a conflict can arise according to adding a new request on top of a previous request.

[0076] iii) The total requested resources from different xApps 120A- n may exceed the limit of resources supported by the RAN 110.

[0077] As further described, the mitigation of direct conflicts can be achieved by the action- ahead coordination implemented by the CMS 130. Thus, the CMS 130 can implement specific changes and / or a sequence of already applied changes to prevent a conflict between the respective xApps 120A- n .

[0078] 1.1.b. Indirect conflict:

[0079] between the xApps 120A- n may not be directly observable. However, some interdependencies among the target parameters (e.g., targets 212A, according to Figure 2 ) and resources of different xApps 120A- n may be observable. As further described, the CMS 130 can be configured to predict potential conflicts and operate to avoid and / or mitigate conflicts. Indirect Conflict An example of this is where different xApps 120A- n target different parameters to optimize the same metric based on the respective xApp 120A- n 's respective target. This situation can not result in conflicting parameter settings, but the configuration of the first xApp 120P can impact the system metric (e.g., targets 212A, KPIs 140A, KPMs 145A) which can equate to a parameter change targeted by another xApp 120Q. For example, antenna tilt and cell individual offset (CIO) are two different control actions where the antenna tilt configuration (e.g., targets 212A, Figure 2 ) is targeted by xApp 120P and the cell individual offset (CIO) (e.g., targets 212B, Figure 2 ) is targeted by xApp 120Q, but both control actions can impact the handover function(s).

[0080] As further described, mitigation of indirect conflicts can be achieved by post-action verification. In an example scenario, the changes imposed by the respective xApps 120A- n are made and the target metric (e.g., KPIs 140A- n ) is observed.

[0081] 1.1.c. Implicit conflict:

[0082] Such conflicts are not directly visible and, further, dependencies between the xApps 120A- n may not be directly observable. In essence, different xApps 120A- n utilize different parameters to optimize different metrics. In this case, optimization of a first metric can negatively impact other metrics optimized by other xApps 120A- n . For example, a throughput metric for guaranteed bit rate (GBR) users can reduce the metric for non-GBR users or overall cell throughput.

[0083] As further described, prior to deployment of xApps 120A- n , mitigation of implicit conflicts (e.g., by CMS 130) can not be achievable via analytical modeling, as operational dependency relationships between two or more xApps 120A- n may be difficult to predict / observe. Thus, AI and ML based coordination schemes (e.g., in accordance with implementations of process 245, as further described) can be employed at CMS 130 to identify inter-application dependency relationships between two or more xApps 120A- n . In embodiments, conflict detection schemes can be provided (e.g., by CMS 130) based on, for example, end-to-end (E2E) system performance and network intent, specific use cases, etc.

[0084] In embodiments, objectives of each xApp 120A- n can be configured prior to providing optimization modeling. However, defining utility metrics can facilitate review of xApps 120A- n during the conflict coordination phase. Utility metrics can include objective metrics as well as importance of use cases related to xApps 120A- n . In embodiments, CMS 130 can employ various ML based methods (e.g., in process 245, as further described) to pre-assess proposed changes to xApps 120A- n and / or operational environments in which xApps 120A- n are to operate to estimate probability of degradation of metrics / metric sets compared to expected improvement in metrics / metric sets.

[0085] It should be appreciated that while respective systems, techniques, methods, etc. are presented as providing solutions for RIC 150 conflict management at near-RT, the systems, etc. are equally relevant to other RIC layers (e.g., RT, non-RT). As mentioned, respective xApps 120A- n can provide control / optimization functionality to the underlying RAN 110, and thus, can be required to avoid contradicting actions when multiple xApps 120A- n are deployed / operated. In embodiments, CMS 130 can be designed to accommodate independent xApp 120A- n designs, where CMS 130 is vendor agnostic. In accordance with embodiments presented herein, complexity of conflict management is not limited to independence of different xApps 120A- n . Given the open-architecture nature of O-RAN, it is not possible to predict which xApps 120A- nto be deployed together, and further, the RCI 150 can not be aware of the respective designs of each xApp 120A- n . Thus, in embodiments, the CMS 130 can be used in a multi-xApp 120A- n interaction framework, as presented below in Figure 2 .

[0086] 2. Preventive and Mitigating Measures

[0087] In light of the above regarding unpredictable interactions between xApps 120A- n , the respective deployments of xApps 120A- n , the open architecture structure of the RAN 110, etc., various embodiments presented herein can utilize a combination of preventive ( Pre-Action ) and mitigating ( Post-Action ) measures.

[0088] 2.1. Preventive measures can be applied to avoid enabling / deploying two or more xApps 120A- n with directly conflicting or overlapping functionalities that can detrimentally affect the operation of the respective xApps 120A- n , the RAN 110, etc. Based on the information generated at this stage, preventive measures enable the operator to determine a pre-deployment strategy for their respective xApps 120A- n .

[0089] 2.2. Mitigating measures can be implemented to detect xApps 120A- n with conflicting decisions, whereby the co-deployment of a first xApp (e.g., xApp 120A) and a second xApp (e.g., xApp 120B) causes a change in the KPIs 140A- n , which can be opposite, opposite, incompatible in nature.

[0090] By utilizing preventive and / or mitigating measures, the operator of the xApps 120A- n may be notified (e.g., via the HMI 188, the alerts 236A- n ): the respective xApps 120A- n interactions (whether there is a conflict, or friendly, etc.) combined with any recommendations (e.g., ML / AI derived) generated by one or more components (e.g., the onboarding component 210, the subscription management component 220, the conflict detection component 240, the conflict management component 230, etc.) presented in respective embodiments herein. Further, regarding two or more deployed and running xApps 120A- npost-verification of actions of the interactions (e.g., generated by the CMS 130) enables the operator to adjust the deployment policies including the respective xApps 120A- n .

[0091] 3. A conflict management system.

[0092] Figure 2 The system 200 illustrates an xApp conflict management architecture in accordance with an embodiment. As shown, a collection of xApps 120A- n are to be deployed and / or are presently deployed on the RAN 110. The CMS 130 can be included in the system 200, where the CMS 130 is configured to identify and / or resolve any conflicts between the xApps 120A- n . The CMS 130 can include a loading component 210, communicatively coupled to an xApp information database 250 and a subscription database 260 (e.g., where the database 250 and the database 260 can be included in the memory 184). In another embodiment, the CMS 130 can also include a subscription management component 220, coupled to the subscription database 260 and also coupled to a conflict management component 230. As Figure 2 shown, the subscription management component 220 can be configured to interact with the xApps 120A- n . In another embodiment, a conflict detection component 240 can be connected to the conflict management component 230, and also connected to any of the RAN 110, an E2 terminal (E2T) 270, and also monitor and interact with the xApps 120A- n . As further described herein (e.g., in accordance with Figure 4 to Figure 7 ), the conflict detection component 240 can be configured with various ML and AI techniques (e.g. Figure 3 , processes 245) to enable detection of conflicts arising from multiple deployed xApps 120A- n . As Figure 2 shown, the information database 250 and the subscription database 260 can be connected via a connector 289, respectively, and the subscription database 260 can be connected to the conflict management component 230 via a connector 288, so that information regarding the xApps 120A- n can be freely shared between the two. As mentioned, the information database 250 and the subscription database 260 can be configured to store information (e.g., data 121A- n obtained from previously loaded / requested loading of the xApps 120A- n , where the stored data 121A- nData (e.g., data 121A) for a current xApp (e.g., xApp 120A) can be compared against historical data. In embodiments, while shown as being at conflict management component 230, any of the subcomponents of CMS 130 can utilize the threshold relationships 231A-n of determined likelihoods (e.g., likely, unlikely, etc.) of conflicts between any of the xApps in xApp 120A- n . CMS 130 can also include a warning component 235 configured to generate and send warnings / alerts / notifications 236A- n regarding operation, denial of loading, etc. of xApp 120A- n .

[0093] The interaction and operation of the respective components are represented by steps operations (1) through (3), as further described.

[0094] At (1), one or more xApps 120A- n are being submitted for loading / operation on RAN 110. In example embodiments, loading component 210 can be configured to receive xApp 120A (e.g., a first xApp) where xApp 120A- n is desired to be deployed on RAN 110. Loading component 210 can be configured to review xApp 120A- n to determine one or more features (e.g., operational features, such as in data 121A) of xApp 120A. Loading component 210 can also be configured to compare the one or more features of xApp 120A with information (e.g., data 121B- n stored in xApp information database 250 to determine whether the one or more features of xApp 120A can be supported by RAN 110. In embodiments, in response to determining that the one or more features of xApp 120A can be supported by RAN 110, loading component 210 can be configured to approve loading of xApp 120A for subsequent deployment of xApp 120A. In another embodiment, in response to determining that the one or more features of xApp 120A cannot be supported by RAN 110, loading component 210 can be configured to deny loading of xApp 120A.

[0095] At (2), prior to deploying a first xApp (e.g., xApp 120A), a determination can be made as to whether xApp 120A- nany potential negative interactions of the first xApp. As shown, the subscription management component 220 can be configured to interact with the xApp 120A- n (e.g., according to connection 280), the conflict management component 230 (e.g., via subscription guidance connection 282), the RAN 110 / E2T 370 (e.g., according to connection 284), and / or the subscription database 260 (e.g., via connection 286). Prior to deployment of the xApp 120A, respective characteristics (e.g., data 121A) of the xApp 120A- n may be compared to respective characteristics (e.g., data 121B- n ) of the xApp 120B- n , which can be currently deployed or previously deployed on the RAN 110. Respective actions / determinations can be communicated in the alert / alarm 236A- n .

[0096] At (3), where respective xApps 120A- n have been deployed, the conflict detection component 240 can be configured to monitor and evaluate the operation of the xApps 120A- n with respect to one or more interactions between the respective xApps 120A- n , and further, to monitor and evaluate the operational effects of the respective xApps 120A- n on system components, such as the RAN 110. In embodiments, the conflict detection component 240 can monitor interactions (multiple times) between the xApps 120A- n , the RAN 110, and the E2T 270, as shown by the control / command (CTRL / CMD) connection 290. Further, interactions originating from the RAN 110 (and the E2T 270) with the xApps 120A- n can be monitored by the conflict detection component 240, as shown by the KPM / EVENT connector 292. Further, the KPMs 145A- n can be received at the conflict detection component 240 from the RAN 110 (and the E2T 370), as shown by the KPM connector 294. The conflict detection component 240 can interact with the conflict management component 230 according to the conflict xApp detection connection 296. Respective actions / determinations can be communicated in the alert / alarm 236A- n .

[0097] 4. Co-deployment and Application Prioritization

[0098] In an embodiment, the conflict management component 230 can be configured to control one or more xApps 120A- n interact with a component / parameter. In an embodiment, the conflict management component 230 can be configured to determine that a first xApp 120A interacts with a component / parameter (e.g., target 212A), and further, that a second xApp 120B also interacts with the same component / parameter. The conflict management component 230 can be configured to utilize Application Priority characteristics. In an embodiment, a first priority setting (e.g., in data 121A) can be applied to the first xApp 120A, and a second priority setting (e.g., in data 121B) can be applied to the xApp 120B. In an embodiment, the priority setting can be configured (e.g., as a utility metric) to the xApp 120A- n , configured at deployment and applied to the xApp 120A- n deployment settings, etc. Thus, for example, the conflict management component 230 can be configured to, upon receiving the first xApp 120A with a High Priority metric and the second xApp 120B with a Low Priority metric, prevent the second xApp 120B from issuing command(s) for a certain time interval when the first xApp 120A issues a command. High Priority Low Priority

[0099] The conflict management component 230 can also be configured to adjust the xApp 120A- n subscriptions to avoid the conflicting control actions to be operated by the respective xApp 120A- n . The common deployment rules are not limited to priority evaluation, and the subscription adjustment as well as the ML-based model (e.g., in process 245 in conflict detection component 240) can be trained to provide intervention commands to the E2 node (e.g., in E2T 270), such as CU 117, DU 118, RU 119, etc.

[0100] 5. Preventive Measures - Example

[0101] The preventive measures avoid xApps 120A- n with direct conflicts or overlapping functions. The preventive measures allow an operator to determine a deployment strategy among such xApps 120A- n In a traditional O-RAN system, for the RIC 150 and / or the conflict management component 230, xApps 120A- n ​​Particular implementation solutions can not be available. According to various embodiments presented herein, the application of preventive measures can involve defining (e.g., for RIC 150) a set of criteria in order to obtain a high-level understanding of the one or more functions of xApps 120A- n .

[0102] 5.1. Criteria

[0103] Among a non-limiting list, criteria can include:

[0104] App Classification : Classification can be based on span level of xApp decomposition across the cloud edge continuum.

[0105] Target KPI Class and Sub-classes : KPI 140A- n categories include Coverage , Capacity , Energy , Level and Control Type Coverage , etc. KPI 140A- Accessibility related to n can include features such as Preservability , Mobility , Indirect , etc.

[0106] The above criteria can be provided by xApps 120A- n to RIC 150, e.g., during onboarding (e.g., as data 121A at onboarding component 210). The criteria provided by xApps 120A- n can be used by conflict management component 230 to initiate rule-based conflict mitigation strategies (e.g., priority assessment based on utility metrics, subscription adjustment, etc., as described herein). A non-limiting list of example conflict mitigation strategies is also provided in 8.3. Conflict Management below.

[0107] 6. Mitigation measures - examples and operation

[0108] As mentioned, due to the complexity of interactions among deployed xApps 120A- n , post-action verification can require target ML and AI solutions (e.g., implemented at conflict detection component 240 via process 245, as further described) to identify Implicit and Figure 3 conflicts. In embodiments, conflicts among xApps 120A- n may be detected at RCI 150, e.g., from performance observations (e.g., KPIs 140A- n ).

[0109] To evaluate the observations at the RIC 150, the CMS 130 can be configured to monitor RAN 110 performance, thereby enabling the RIC 150 to act as an “xApp-agnostic” observer of the results of the xApp 120A- n n The RIC 150 can be configured to determine when changes in the KPI 140A- n are caused by adverse effects of the xApp 120A- n and when such changes are produced by natural transitions in the performance of the RAN 110 that are independent of the xApp 120A- n For example, when changes in traffic at the RAN 110 occur, changes in the KPI 140A- may naturally result / migrate from current RAN 110 control algorithms, and thus such natural changes should be identified and understood to establish changes in the baseline behavior of the RAN 110.

[0110] Figure 2 As shown, the system 300 presents an xApp conflict management system according to embodiments. The system 300 can include a conflict detection component 240, including a performance management (PM) engine component 320, communicatively coupled to a conflict detection sub-component 330, which is further communicatively coupled to a conflict xApp detection component 340. Inputs to the conflict detection component 240 can include KPI 140A- n and KPM 150A- n (e.g., according to Figure 2 , connector 294), xApp 120A- n CRTL / CMD (e.g., according to Figure 2 , connector 290), and xApp 120A- n descriptor information (e.g., data 121A- n extracted directly from the xApp 120A- n and / or extracted from xApp 120A data in the information database 250). The conflict detection component 240 can further include processes 245, which can be utilized by any of the PM engine component 320, conflict detection sub-component 330, and conflict xApp detection component 340 (as well as any components in the CMS 130). The processes 245 can include any operations, functions, workflows, etc., as well as ML and AI techniques configured to detect xApp 120A- n conflicts. Based on the respective inputs into the conflict detection component 240, as well as the operation of the PM engine component 320, conflict detection sub-component 330, and conflict xApp detection component 340, the conflict detection component 240 can generate conflict xApp 120A-​n one or more detected instances and any naturally occurring changes in the operation of the RAN 110.

[0111] The process 245 can include one or more recurrent neural network (RNN) models that can be used to determine changes in the KPI 140A- n result from conflicts among the plurality of xApps 120A- n or from changes in the operating environment of the RAN 110 (e.g., natural changes) that are independent of interactions among the plurality of xApps 120A- n The RNN models in the process 245 can also be used to forecast changes in performance of the KPI 140A- n as part of conflict detection by the conflict detection component 240. The RIC can be configured to establish correlations between xApp 120A- n actions and changes in the performance of the RAN 110. When the plurality of xApps 120A- n are operating on the same target (e.g., target 212A, according to Preventive ), the prediction of the impact on the KPI 140A- n can be a highly complex task, where the prediction is applied to implement one or more ML techniques in the process 245.

[0112] Based on the estimated correlations between the xApps 120A- n and changes in the performance of the RAN 110, the RIC 150 can identify xApps 120A- n that cause opposite directions of performance. To train the appropriate ML solution in the process 245 to detect conflicting applications (i.e., xApps 120-n), the classification information can be derived from the inputs described above: KPI 140A- n and KPM 150A- n , xApp 120A- n CRTL / CMD, xApp 120A- n descriptor information (e.g., data 121A- n ), etc.

[0113] 7. Conflict Management - Examples and Operation

[0114] Conflict management involves Coping measures and Rule-based Conflict Resolutionboth. The main aspects of both preventive and reactive measures are conflict prediction and conflict detection, respectively. In section 2.1 and section 5“Preventive measures”, various example rule-based conflict management solutions are presented, where the conflict management solution is able to be executed after a conflict has been detected by the xApp 120A- n Two categories of solutions are also presented, ML-based Conflict Resolution and Rule-based Conflict Resolution Strategy (e.g. with the process 245), and both categories of solutions can be used as preventive and / or reactive measures.

[0115] 7.1. ML-based Conflict Resolution Strategy can be used to resolve conflict issues without degrading performance (e.g. KPI 140A- n performance). n

[0116] An example rule-based conflict mitigation strategy can be represented as the following sequence of actions / steps:

[0117] 1. Trigger a specific deployment policy for the conflicting xApp 120A- n ;

[0118] 2. Provide recommendations to adjust the xApp 120A- n ;

[0119] 3. Adjust the xApp 120A- n subscription to avoid conflict control actions / subscription guidance; and

[0120] 4. Specify xApp 120A- n priority among the conflicting applications.

[0121] 7.2. Dimensioning can be complex and can require complex interactions by the process 245. These methods can be used in cases / scenarios where a specific xApp 120A- n may degrade RAN 110 and / or KPI 140A- n performance. With ML-based conflict mitigation strategies, conflict mitigation rules are not limited to priority evaluation and subscription adjustment, whereby an ML-based model (e.g. process 245) can be trained to provide intervention commands to the E2 node 115.

[0122] 8. Example embodiments

[0123] 8.1. Preventive measures

[0124] The following provides an example of a preventive measure for the xApp 120A- n ​an example onboarding process. The following process can reduce the chances of (multiple) direct conflicts between the onboarding xApp 120A- n and the currently subscribed xApp 120A- n . Each xApp 120A- n can provide various information / standards (e.g., as described in Section 5.1) during the onboarding process (e.g., onboarding to the RIC 150) with the RAN 110. n

[0125] The information (e.g., data 121A- n provided by the xApp 120A- n (e.g., extracted by the onboarding component 210) can be compared to the current xApp 120A- n subscription (e.g., in the subscription database 260 and / or the xApp information database 250) to ensure consistency of operation, and any xApp 120A- n subscription request that is inconsistent with the current xApp 120A- n can be rejected. The subscription database 260 can include information structures (e.g., in data 121A- n ) of the xApps 120A- n deployed on the RAN 110. When a first xApp (e.g., xApp 120A and data 121A) is presented for subscription, the information (e.g., data 121B- n ) stored in the subscription database 260 about the deployed xApps 120B- n can be used as a reference (e.g., by the subscription management component 220, the conflict management component 230) to check the consistency of the information provided by the first xApp (i.e., xApp 120A). In the case where it is determined (e.g., by the subscription management component 220, the conflict management component 230) that the deployed xApp 120A- n can support the operation of the xApp 120A, the xApp 120A can be subscribed. In the case where it is determined (e.g., by the subscription management component 220, the conflict management component 230) that the deployed xApp 120A- n does not support the operation of the xApp 120A / may have conflicts with it, the xApp 120A can be rejected from being subscribed / operated on the RAN (e.g., by the onboarding component 210 or the conflict management component 230). By leveraging the known information (e.g., historical data 121A- n about the deployed xApps 120B- n ​) to check information / requirements of the xApp 120A, enabling a quick review of the xApp 120A, which enables the various embodiments presented herein to be applicable to RT and near-RT implementations at the RIC 150.

[0126] The RIC 150 API can be used by the xApp 120A- n to access information elements (EIs) of the associated E2SM (E2 Service Model). The RIC 150 provides decoupled APIs from specific implementation solutions. Further, the xApp 120A- n can provide a descriptor (e.g., in any data 121A- n ) that includes configuration, control (level and type of control), target KPI 140A- n category and subcategory, and xApp classification. The descriptor data provides necessary data to enable management of the xApp 120A- n , including subscription management, conflict management, and orchestration, e.g., based on comparing operational data (e.g., data 121A) of a first xApp (e.g., xApp 120A) to (i) operational data (e.g., data 121B) of a second xApp (e.g., xApp 120B) previously deployed or currently deployed or (ii) operational data (e.g., data 121B- n ) of multiple xApps (e.g., xApp 120B- n ) previously deployed or currently deployed.

[0127] The presented embodiments enable Restrictive Framework which limits the number of xApps 120A- n allowed for the same class / KPI 140A- n category. The use of size notation can reduce the likelihood of unresolved conflicts due to the co-deployment of xApps 120A- n .

[0128] To mitigate potential conflicts, Figure 3 can be utilized by the onboarding component 210 and / or the subscription management component 220, whereby the onboarding component 210 and / or the subscription management component 220 limit the selection range rather than freely selecting all information open to the xApp 120A- n . With the restrictive framework approach, the onboarding component 210 and / or the subscription management component 220 can specify a list of target KPIs 140A- n for the xApp 120A- n , to base the xApp 120A- nThe classification is selected and also specifies a list of allowed actions for the xApp 120A- n to select based on the target KPI 140A- n .

[0129] 8.2. Mitigation measures

[0130] A further description of the structure and operation of the conflict detection component 240 is presented below. The conflict detection component 240 can be used to implement mitigation measures. In embodiments, to take mitigation measures, first the conflicting xApps 120A- n are identified, where the conflict detection component 240 and / or the conflict management component 230 then implements various rule-based and ML-based conflict mitigation strategies, as previously mentioned in section 7.

[0131] As previously mentioned, in accordance with Figure 4 , the conflict detection component 240 can include a PM engine component 320 for performance change prediction to implement conflicts at the conflict detection component 240 based on observed KPIs 140A- n and predicted KPIs 140A- n (e.g., as KPMs 150A- n ) to identify xApps 120A- n causing adverse performance. Figure 5 , the system 400 provides a structural framework for the PM engine component 320. The PM engine component 320 can be configured to utilize a process 245 to use previous KPMs 150A- n , mandatory xApp 120A- n control commands, and xApp 120A- n descriptor information (e.g., in data 121A- n ) including proposed criteria (as presented in section 5.1) to predict KPIs 140A- n in advance. In embodiments, the predicted KPIs 140A- n can be generated by the PM engine component 320 and used as a baseline behavior (e.g., by the conflict management component 230) to detect any potential performance degradation resulting from conflicts among xApps 120A- n .

[0132] Figure 5 , the system 500 presents a high-level structure of a conflict detection subcomponent 330 in accordance with embodiments. As Figure 6 indicated, predicted KPIs 140A- n and observed KPIs 140A- nthat can be input into the conflict detection sub-component 330, whereby the conflict detection sub-component 330 can be configured to determine whether there is any conflict between the xApps 120A- n that have been accepted for deployment and / or are currently deployed on the RAN 110. Any potential correlation between the set of provided predicted KPIs 140A- n and observed KPIs 140A- n that exist can be identified by one or more ML models in the process 245, whereby, in conjunction with an estimate of any degradation in KPIs 140A- n resulting from a conflict between the xApps 120A- n , the presence of a conflict between the xApps 120A- n can be identified. Any identified degradation in KPIs 120A- can be utilized by the conflict management component 230.

[0133] n In the event that a conflict between the xApps 120A- n is detected during the post-monitoring process, the source of the conflict between the xApps 120A- Figure 6 can be identified. n The system 600 presents a structural framework for a conflict xApp detection component 340 configured to detect conflicting xApps 120A- n according to an embodiment. The conflict xApp detection component 340 can be configured to identify one or more correlations between the respective operation of the xApps 120A- n and corresponding changes in performance of the KPIs 140A- n . The conflict xApp detection component 340 can also be configured to use such inputs as observed KPIs 140A- n , predicted KPIs 140A- n , conflict-based degraded KPIs 140A- n , accepted xApp 120A- n control commands, xApp 120A- ML-based Resolution Strategy descriptor information, etc., to determine xApps (e.g., xApps 120A) that cause opposite / negative performance directions. As n shown, the output of the conflict xApp detection component 340 can be a probability that an xApp 120A- causes opposite performance, where the output is an input to the conflict management component 230.

[0134] 8.3. Conflict Management

[0135] Reference Action SpaceAny suitable ML technique can be utilized at process 245, such as reinforcement learning (RL) models. One or more RL models can be configured to select the KPI 140A- n The highest performance control commands. In the example RL model implementation, Reward The conflict that can be defined as the proposed action in xApp 120A- n Union of lists. Figure 7 120A- set to conflict with xApp n Target KPI 140A- n The weighting function. Target KPI 140A- n It can be based on policies implemented by operators of RAN 110, defined utility functions, etc.

[0136] Example RL-based mitigation algorithm frameworks can be provided as follows:

[0137] 1. Define the state space as the subscription conflict xApp 120A-n (here defined as xApp) v Idle / active status and associated target KPIs 140A- n value:

[0138] ,

[0139] in It is for xApp v The target KPI value, and It is in time t xApp v The idle / active status indicator, and V It is a set of conflicting xApps (e.g., xApp 120B conflicting with xApp 120A). n ).

[0140] 2. Define the reference action space as a union of lists of conflicting xApps of the proposed actions:

[0141] ,

[0142] in It is xApp v The action proposed at time t.

[0143] 3. Based on operator strategies or defined utility functions, set rewards as conflict-related xApp target KPIs (140A-). n Weighting function:

[0144] ,

[0145] It is in time t The reward value at that location.

[0146] 4. Implement any appropriate ML (e.g., reinforcement learning (RL), such as deep Q-network (DQN) methods) (e.g., in process 245) to find the action that maximizes the reward.

[0147] For all conflicts xApp 120A- n The action space is logical (e.g., turning on / off, reducing / increasing guidance, etc.), and the above approaches / methods can be modified to improve overall performance. Therefore, from the winner xApp (e.g., xApp120A- n The selected action can be associated with that specific xApp (e.g., xApp 120A-). n The actions proposed by the winner xApp (e.g., xApp 120A) differ from those proposed by the winner xApp. In an embodiment, the conflict management component 230 can be configured to select a logical action from a list of allowed actions, in contrast to the action proposed by the winner xApp (e.g., xApp 120A).

[0148] The state space and action space of the modified RL-based mitigation algorithm can be defined as follows:

[0149] i) Define the state space as a subscription conflict xApp 120A- n Idle / active status and target KPI 140A-n value, and each xApp 120A- n The proposed action. The term is used below:

[0150] ,

[0151] in It is for xApp v Target KPI 140A- n value, It is xApp v Idle / active status indicator It is in time t xApp v The proposed action, and V It is a set of conflicting xApps.

[0152] ii) Define the reference action space as a union of lists of conflicting xApps that are allowed to perform actions:

[0153] ,

[0154] in It is in time t For xAppv a set of allowed actions.

[0155] As mentioned, various processes 245 can be configured to determine information regarding operational conflicts, make decisions, etc. between two or more xApps 120A- n As previously mentioned, processes 245 can include AI, ML, and inference techniques / techniques means employing probabilistic and / or statistical-based analysis to predict or infer an action that a user desires to be automatically performed. Various embodiments presented herein can utilize various ML-based schemes for performing various aspects thereof, e.g., potential conflicts between a first xApp 120A and a second xApp 120B, and further, conflicts between respective xApps 120A- n running on the RAN 110, as mentioned, can be facilitated via automated classifier systems and processes.

[0156] As used herein, the terms “predict,” “infer,” “reason,” “determine,” etc. generally refer to a process of reasoning or inferring a state of a system, environment, and / or user from a set of observations captured via events and / or data. For example, inference can be employed to identify a particular context or action, or can generate a probability distribution over states. Inference can be probabilistic - that is, based on computing a probability distribution over states of interest based on consideration of data and events. Inference can also refer to techniques employed by various embodiments presented herein for constructing higher-level events from a set of events and / or data. Such inference results in the construction of new events or actions from a set of observed events and / or stored event data, whether or not the events are closely related in time, and whether or not the events and data are from one or multiple event and data sources.

[0157] In various embodiments presented herein, the CMS 130 can obtain operational data (e.g., data 121A- n , KPIs 140A- n , KPMs 150A- n ) from xApps 120A- n regarding parameters, metrics, use cases, etc. that respective xApps 120A- n are configured to control / adjust. Processes 245 can include AI, ML, and inference techniques / techniques means employing probabilistic and / or statistical-based analysis to predict or infer an action that a user desires to be automatically performed. Various embodiments presented herein can utilize various ML-based schemes for performing various aspects thereof, e.g., determining that a conflict exists between xApps 120A- n , as previously mentioned herein, can be facilitated via automated classifier systems and processes.

[0158] A classifier is a function that maps an input attribute vector, x = ( x 1, x 2, x 3, x 4, x n ) to a class label class( x ). The classifier can also output a conclusion that the input belongs to a class, i.e., f( x ) = confidence(class( x )). Such classification can employ probabilistic and / or statistical based analysis (e.g., consider a posteriori analysis) to predict or infer an action that a user desires to have the system perform (e.g., a conflict resolution between xApps 120A-n).

[0159] A support vector machine (SVM) is an example of a classifier that can be employed. An SVM operates by finding a hyper-plane in the space of possible inputs, which optimally separates the triggered input events from the non-triggered events. Intuitively, this makes the classification correct for testing data that is near, but not identical to the training data. Other directed and undirected model classification approaches include, e.g., naϊve Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models, providing different independent models that can be employed. Classification as used herein includes statistical regression that is utilized to develop models of priority.

[0160] From the subject specification, it is easy to understand that various embodiments can employ classifiers that are explicitly trained (e.g., via a generic training data) as well as implicitly trained (e.g., via observing xApp 120A- n behavior, RAN 110 behavior, receiving external information, etc.). For example, SVMs are configured via a learning or training phase within a classifier constructor and feature selection module. Thus, the classifier(s) can be used to automatically learn and perform a number of functions, including but not limited to determining according to a predetermined criteria, e.g., whether a run conflict exists, performance of KPI 140A- n , (multiple) run objectives of respective xApps 120A- n , direct conflicts, indirect conflicts, implicit conflicts, etc.

[0161] As described above, inferences can be made and actions performed based on a large number of information. For example, information / data (e.g., data 121A- n ) regarding run xApps 120A- n , historical usage, predicted usage, etc., as xApps 120A- ncontinues, enabling the analytics to determine a convergence pattern, to be able to reason about power conflicts between respective xApps 120A- n

[0162] Figure 8 Figures illustrate a method 700 for determining whether a runtime conflict will occur by running / executing an xApp on a RAN, in accordance with one or more embodiments described herein.

[0163] At 710, a first xApp (e.g., xApp 120A) requests to be loaded onto a RAN (e.g., RAN 110) to enable the xApp to control one or more parameters, use cases, etc. on the RAN.

[0164] At 720, the first xApp can be configured to provide first information (e.g., data 121A) to a loading component (e.g., loading component 210). The first information can detail which parameters, use cases, metrics, KPIs (e.g., KPIs 140A- n

[0165] At 730, in embodiments, other information (e.g., by loading component 210) can be obtained from other xApps (e.g., xApps 120A- n have been presented for loading, have been loaded, are deployed, etc.), where the other information can be stored (e.g., by loading component 210) in a database (e.g., database 250, subscription database 260). For example, second information related to a second xApp can be stored in the database and subsequently compared to the first information of the first xApp.

[0166] At 740, the first information can be compared to runtime configuration information of the RAN to determine whether the xApp can be supported by the RAN. In embodiments, the runtime configuration information for the RAN can be derived from respective xApps that are currently deployed / prior deployed at the RAN. For example, the first information of the first xApp can be compared to information (e.g., data 121B- n ) available from other xApps (e.g., xApps 120B- n ). Based on this, it can be possible to determine what the RAN can support based on information (e.g., data 121B- n ) on which other xApps were rejected from loading (e.g., by loading component 210). If the determination is “no”, the RAN cannot support the first xApp, then the method 700 can proceed to 745, where the first xApp can be rejected from loading (e.g., by loading component 210). At 747, a warning (e.g., warning 236A- n ​​) can be generated by the warning component (e.g., warning component 235) to inform an entity such as a network operator that the first xApp was rejected for onboarding. At 748, a database (e.g., database 250 and / or database 260) can be updated with corresponding information (e.g., data 121A) regarding the first xApp being rejected for onboarding.

[0167] At 740, in the event that it is determined (e.g., by onboarding component 210) that the RAN can support the first xApp, the method 700 can proceed to 750. At 750, first information (e.g., data 121A) regarding the first xApp can be compared to other information (e.g., data 121B- n ) to determine (e.g., by subscription management component 220 in conjunction with conflict management component 230) whether the first xApp conflicts with any of the other xApps. For example, first information (e.g., data 121A) of the first xApp (e.g., xApp 120A) can be compared to second information (e.g., data 121B) of a second xApp (e.g., xApp 120B) to determine whether a conflict exists.

[0168] At 760, a determination can be made (e.g., by conflict management component 230) as to whether a conflict exists between the first xApp and the second xApp. If the case is “yes,” i.e., a conflict exists, then the first xApp can be rejected for subscribing to the RAN, while the method 700 returns to 745, as previously described, in which (multiple) warnings and database updates can be configured to convey the conflict between the first xApp and the second xApp.

[0169] At 760, in the event that it is determined (e.g., by conflict management component 230) that no conflict exists between the first xApp and the second xApp, then the method can proceed to 770, whereupon the first xApp can be onboarded (e.g., by subscription management component 220) onto the RAN. The method 700 can return to 747, as previously described, in which, in embodiments, an indicator (e.g., by alert 236A- n ) can be generated and sent (e.g., by warning component(s) 235), and further, at 748, a database (e.g., database 250 and / or database 260) is updated (e.g., data 121A- n ) to indicate that the first xApp has been onboarded / deployed / running / executed, in which no conflict exists between the first xApp and the second xApp.

[0170] Figure 9 FIGURE 8 illustrates a method 800 for determining whether a running conflict will occur by running / executing an xApp on a RAN, in accordance with one or more embodiments described herein.

[0171] At 810, the first xApp (e.g., xApp 120A) can be configured to provide first information (e.g., data 121A) to a subscription component (e.g., subscription management component 220), as previously described. The first information can detail which metrics, parameters, use cases, KPIs (e.g., any of KPIs 140A- n through 140N) that the first xApp is to be deployed to adjust, etc. (e.g., targets 212A-

[0172] At 820, the second xApp (e.g., xApp 120B) can be configured to provide second information (e.g., data 121B) to the subscription component (e.g., subscription management component 220). The first information can detail which metrics, parameters, use cases, KPIs (e.g., any of KPIs 140A- n through 140N) that the second xApp is to be deployed to adjust, etc.

[0173] At 825, the first metrics to be adjusted by the first xApp can be compared (e.g., by conflict management component 230) to the second metrics to be adjusted by the second xApp. In embodiments, the first metrics and the second metrics can have a common control target (e.g., targets 212A-

[0174] At 830, the existence of a conflict on the RAN (e.g., RAN 110) and the size of the conflict can be determined (e.g., by conflict component 230). In the event that the operation of the first xApp would detrimentally affect the operation of the second xApp with respect to the common target, another determination can be made (e.g., by conflict component) as to whether the first xApp and the second xApp can coexist. In the event that the conflict would render the second xApp unable to effectively control the common target, then the method 800 can proceed to 840, whereupon the first xApp can be denied (e.g., by conflict management component 230) from operating on the RAN concurrently with the second xApp.

[0175] At 830, in the event that the operation of the first xApp can negatively affect the control of the target by the second xApp, but the first xApp and the second xApp can be configured to be co-deployed on the RAN, then the method 800 can proceed to 850.

[0176] At 850, a first priority of operation can be assigned (e.g., by subscription management component 220) to the first xApp (e.g., as part of data 121A), where the priority can be assigned a first level, e.g., "high."

[0177] At 860, a second priority level can be assigned (e.g., by the subscription management component 220) to the second xApp (e.g., as part of the data 121B), where the priority level can be assigned a second level, e.g.,“low.”

[0178] At 870, the first xApp and the second xApp can run on the RAN based on their respective first priority and second priority, respectively. In an embodiment, when information related to the first metric is present at the RAN, the first priority can be used to control the running of the first xApp, otherwise the second xApp with lower priority is run. In another embodiment, the first priority and the second priority can be established based on time. For example, the first xApp is configured to run for a first duration of time, then the second xApp is configured to run for a second duration of time.

[0179] At 880, when the first xApp is running based on the first priority, the running duration of the first xApp can be monitored. In the case where the first running duration has not expired, the method 800 can return to 870 to further monitor the running of the first xApp.

[0180] At 880, in the case where the first running duration has expired, then the method 800 can proceed to 890 for running the second xApp with lower priority for a second duration of time.

[0181] At 895, where the second xApp is running based on the second priority, the running duration of the second xApp can be monitored. In the case where the second running duration has not expired, the method 800 can return to 890 to further monitor the running of the second xApp. At 895, in the case where the second running duration has expired, the method 800 can return to 870 to re-run the first xApp with the first duration of time.

[0182] Figure 10 FIG. 9 illustrates a method 900 for determining whether a running conflict will occur by running / executing xApps on a RAN, according to one or more embodiments described herein.

[0183] At 910, as previously described, a first xApp (e.g., xApp 120A) can be configured to provide first information (e.g., data 121A) to a subscription component (e.g., subscription management component 220). The first information can be able to specify which metrics, parameters, use cases, KPIs (e.g., any of the KPIs 140A- n

[0184] ​At 920, a second xApp (e.g., xApp 120B) can be configured to provide second information (e.g., data 121B) to a subscription management component (e.g., subscription management component 220). The second information can detail which metrics, parameters, use cases, KPIs (e.g., any of KPIs 140A- n

[0185] At 925, a request to run the first xApp can be made. The first metrics to be adjusted by the first xApp can be compared (e.g., by conflict management component 230) to the second metrics to be adjusted by the second xApp. In embodiments, the first metrics and the second metrics can have a common control objective (e.g., objective 212A).

[0186] At 930, the existence of a conflict on the RAN (e.g., RAN 110) can be determined by a conflict component (e.g., conflict management component 230). In the event that the running of the first xApp detrimentally affects the running of the second xApp with respect to the common objective, then method 900 can proceed to 940, where the first xApp can be denied (e.g., by conflict management component 230) from running on the RAN.

[0187] At 930, in the event that the determination is "no," i.e., the running of the first xApp does not negatively affect the control of the second xApp on the objective, then method 900 can proceed to 945. In embodiments, the first xApp and the second xApp can be considered distinct.

[0188] At 945, given that the first xApp and the second xApp are co-deployed, a review of the running of the RAN can be made. As previously noted, direct co-running conflicts between xApps can be easily perceived, but indirect and implicit conflicts can be difficult to detect / identify. In embodiments, other metrics (e.g., third metrics) can be affected by the running of the first xApp and the second xApp. The running of the third metrics can be monitored to see if the third metrics are negatively affected by the co-deployment of the first xApp and the second xApp.

[0189] ​At 950, a determination can be made as to the running of the third metric, e.g., is the third metric running worse compared to the previous case (where the first xApp and the second xApp were not co-deployed)? In the event that it is determined that the co-deployment of the first xApp and the second xApp does not adversely affect the third metric, the method 900 can proceed to 955, which can then maintain the co-deployment of the first xApp and the second xApp. Step / action 955 can also return to 945 for further / subsequent determinations as to whether the co-deployment of the first xApp and the second xApp affects the running of the RAN. Thus, the RAN can continuously monitor the running thereon to detect that a conflict can not have existed at the time of co-deploying the first xApp and the second xApp, but the conflict develops / reveals itself over time.

[0190] At 950, in the event that the determination is "yes", i.e., the co-deployment of the first xApp and the second xApp does not adversely affect the third metric, the method 900 can proceed to 960 to determine the impact of the co-deployed first xApp and second xApp (individually or in combination) on the third metric.

[0191] At 965, in the event that the determination is "no", i.e., the first xApp and / or the second xApp is not responsible for the poor running of the third metric, the method 900 can return to 955 for further monitoring of the co-deployed first xApp and second xApp, as previously described.

[0192] At 965, in the event that the determination is "yes", i.e., the first xApp and / or the second xApp affects the running of the third metric, the method 900 can proceed to 970, which can then analyze to adjust the running of the co-deployed first xApp and second xApp to isolate the respective impact of the first xApp and the second xApp on the third metric, which can be performed by a conflict detection component, e.g., the conflict detection component 240.

[0193] At 975, in the event that the determination is "yes", i.e., the adjustment to the first xApp and / or the second xApp can affect (e.g., benefit) the third metric, the method 900 can return to 955, which can then maintain the modified running of the first xApp and / or the second xApp.

[0194] At 975, in the event that the determination is "no", i.e., the adjustment to the first xApp and / or the second xApp does not affect the third metric, the method 900 can proceed to 980, which can then perform further analysis to determine that the impact on the running of the third metric is a result of natural changes in the RAN, as previously described.

[0195] ClassA method 1000 is illustrated for deploying xApps on a RAN based on KPI categories, in accordance with one or more embodiments described herein.

[0196] At 1010, the respective KPIs can be categorized into Class , whereby each KPI can have its own Figure 11 .

[0197] At 1020, to prevent too many xApps (e.g., xApps 120A- n ) from being assigned to a particular KPI (e.g., KPI 140A- n , such as metrics, use cases, etc., and / or each of the targets 212A and 212B), each KPI can be assigned a maximum number of xApps that can operate according to that KPI. Limiting the number of xApps that can be associated with a particular KPI can limit the likelihood of conflicts between xApps operating using the particular KPI.

[0198] At 1030, when an xApp is requesting to operate (e.g., as part of a subscription), the KPI / metric (e.g., first metric) of focus of the xApp can be identified (e.g., in data 121A) by the onboarding component (e.g., onboarding component 210).

[0199] At 1040, a determination can be made as to whether the maximum number of xApps that can be assigned to a particular KPI has been reached, e.g., by the onboarding component. For example, has the maximum number of xApps that can be assigned to the first KPI / metric been reached? If the determination is “yes,” i.e., the maximum number of xApps for the first KPI / metric has been reached, then the method 1000 can proceed to 1050, whereupon the requesting onboarding xApp (e.g., xApp 120A) can be denied operation by the onboarding component.

[0200] At 1040, in the case where the determination is “no,” i.e., the maximum number of xApps for the first KPI / metric has not been reached, then the method 1000 can proceed to 1060, whereupon the requesting onboarding xApp (e.g., xApp 120A) can be authorized to operate on the RAN by the onboarding component.

[0201] 9. Example use environment

[0202] Figure 11An example wireless communication system 1100 is illustrated in accordance with one or more embodiments described herein. The example wireless communication system 1100 includes a communication service provider network(s) 1110, a network node 1131, and user equipment (UE) 1132, 1133. A backhaul link 1120 connects the communication service provider network(s) 1110 and the network node 1131. The network node 1131 is capable of communicating with the UE 1132, 1133 within its service area 1130. The dashed arrows from the network node 1131 to the UE 1132, 1133 represent downlink (DL) communication to the UE 1132, 1133. The solid arrows from the UE 1132, 1133 to the network node 1131 represent uplink (UL) communication.

[0203] Generally, reference to Figure 11 , the non-limiting term "user equipment" can refer to any type of device capable of communicating with the network node 1131 in the cellular or mobile communication system 1100. The UE 1132, 1133 can have one or more antennas with vertical and horizontal elements. Examples of the UE 1132, 1133 include a target device, a device-to-device (D2D) UE, a machine type UE or UE capable of machine-to-machine (M2M) communication, a personal digital assistant (PDA), a tablet computer, a mobile terminal, a smart phone, a laptop computer mounted equipment (LME), a universal serial bus (USB) dongle for mobile communication, a computer with mobile capability, a mobile device such as a cellular phone, a laptop computer with laptop embedded equipment (LEE) such as a mobile broadband adapter, a tablet computer with a mobile broadband adapter, a wearable device, a virtual reality (VR) device, a heads-up display (HUD) device, a smart car, a machine type communication (MTC) device, an augmented reality headset, etc. The UE 1132, 1133 can also include an IOT device that communicates wirelessly.

[0204] In various embodiments, system 1100 includes a communication service provider network(s) 1110 served by one or more wireless communication network providers. The communication service provider network(s) 1110 can include a "core network." In example embodiments, UEs 1132, 1133 can be communicatively coupled to the communication service provider network(s) 1110 via a network node 1131. Network node 1131 can be in communication with UEs 1132, 1133, thus providing connectivity between UEs 1132, 1133 and a broader cellular network. UEs 1132, 1133 can send transmission type recommendation data to network node 1131. The transmission type recommendation data can include a recommendation to transmit data via a closed loop multiple input output (MIMO) mode and / or a rank 1 precoder mode.

[0205] Network node 1131 can have a cabinet and other protective enclosures, computing devices, antenna masts, and multiple antennas for performing various transmission operations (e.g., MIMO operations) and for directing / manipulating signal beams. Network node 1131 can include one or more base station devices that implement the features of the network node. The network node can serve multiple cells, depending on the configuration and type of antennas. In example embodiments, UEs 1132, 1133 can send and / or receive communication data to network node 1131 via wireless links.

[0206] Communication service provider network(s) 1110 can facilitate providing wireless communication services to UEs 1132, 1133 via network node 1131 and / or various additional network devices (not shown) included in one or more communication service provider networks 1110. The one or more communication service provider networks 1110 can include various types of different networks, including but not limited to: cellular networks, femtocell networks, picocell networks, microcell networks, Internet Protocol (IP) networks, Wi-Fi service networks, broadband service networks, enterprise networks, cloud-based networks, millimeter wave networks, etc. For example, in at least one implementation, system 1100 can be or include a large-scale wireless communication network spanning various geographic regions. In accordance with this implementation, the one or more communication service provider networks 1110 can be or include a wireless communication network and / or various additional devices and components of a wireless communication network (e.g., additional network devices and cells, additional UEs, network server devices, etc.).

[0207] The network nodes 1131 can be connected to one or more communication service providers' networks 1110 via one or more backhaul links 1120. The one or more backhaul links 1120 can comprise wired link components such as Tl / E1 telephone lines, Digital Subscriber Line (DSL) (e.g., synchronous or asymmetric DSL (ADSL)), fiber trunk lines, coaxial cable, etc. The one or more backhaul links 1120 can also comprise wireless link components such as, but not limited to, line-of-sight (LOS) or non-LOS links, which can include terrestrial air interfaces or deep space links (e.g., satellite communication links for navigation). In some embodiments, the backhaul links 1120 can be implemented via a "transport network." In another embodiment, the network nodes 1131 can be part of an integrated access and backhaul network. This can allow for easier deployment of dense networks of self-backhauling 5G cells in a more integrated manner by building on many of the control and data channels / processes defined to provide access to UEs 1132, 1133.

[0208] The wireless communication system 1100 can employ various cellular systems, technologies, and modulation modes to facilitate wireless radio communication between devices (e.g., UEs 1132, 1133 and network nodes 1131). While example embodiments can be described with respect to 5G New Radio (NR) systems, embodiments can be applicable to any Radio Access Technology (RAT) or multi-RAT system in which UEs operate using multiple carriers, e.g., LTE FDD / TDD, GSM / GERAN, CDMA2000, etc.

[0209] For example, the system 1100 can operate in accordance with any 5G, next generation communication technology, or existing communication technology, various examples of which are listed above. In this regard, various features and functions of the system 1100 are applicable, where devices (e.g., UEs 1132, 1133 and network nodes 1131) of the system 1100 are configured to communicate wireless signals using one or more multi-carrier modulation schemes in which data symbols can be transmitted simultaneously on multiple frequency subcarriers (e.g., OFDM, CP-OFDM, DFT-spread OFDM, UFMC, FMBC, etc.). Embodiments are applicable to single carrier as well as multi-carrier (MC) or carrier aggregation (CA) operation of UEs. The term "carrier aggregation (CA)" is also referred to as (e.g., interchangeably) "multi-carrier system," "multi-cell operation," "multi-carrier operation," "multi-carrier" transmission and / or reception. Note that some embodiments are equally applicable to multi-RAB (radio bearer) on some carriers (i.e., data and voice scheduled simultaneously).

[0210] In various embodiments, the system 1100 can be configured to provide and utilize 5G or later generation wireless networking features and functions. 5G wireless communication networks are expected to meet the demand for exponential growth in data traffic and to allow for billions of connected devices with little to no latency (e.g., single digit millisecond latency). Compared to 4G, 5G supports more diverse and demanding applications. For example, in addition to various types of data communication between conventional UEs (e.g., phones, smart phones, tablet computers, PCs, televisions, Internet-enabled televisions, AR / VR head-mounted displays (HMDs), etc.) supported by 4G networks, 5G networks can also be used to support data communication between intelligent vehicles associated with a self-driving vehicle environment and machine type communication (MTC). Given the vastly different communication requirements of these different traffic scenarios, the ability to dynamically configure waveform parameters based on the traffic scenario, while preserving the advantages of multi-carrier modulation schemes (e.g., OFDM and related schemes), can contribute significantly to the high speed / capacity and low latency requirements of 5G networks. With a waveform that splits the bandwidth into multiple sub-bands, different types of services can be placed in different sub-bands with the most suitable waveform and numerology, resulting in improved spectral efficiency for 5G networks.

[0211] To meet the requirements of data-centric applications, features of 5G networks can include: increased peak bit rates (e.g., 20 Gbps), greater number of connected devices per unit area (e.g., high

[0212] 5G access networks can utilize higher frequencies (e.g., > 6 GHz) to help increase capacity. Currently, much of the millimeter wave (mmWave) spectrum (bands of spectrum between 30 GHz and 300 GHz) is underutilized. Millimeter waves have a short wavelength, ranging from 9 millimeters to 1 millimeter, and these mmWave signals experience severe path loss, penetration loss, and attenuation. However, the shorter wavelength at mmWave frequencies also allows for packing more antennas in the same physical size, which allows for massive spatial multiplexing and highly directional beamforming.

[0213] Performance can be improved if both the transmitter and receiver are equipped with multiple antennas. Multi-antenna technology can significantly increase the data rates and reliability of wireless communication systems. The use of Multiple-Input Multiple-Output (MIMO) technology, which was introduced in 3GPP and is already in use (including with LTE), is a multi-antenna technology that can improve the spectral efficiency of transmissions, thereby significantly boosting the overall data carrying capacity of wireless systems. The use of MIMO technology can improve mmWave communications and has been widely recognized as a potentially important component for access networks operating at higher frequencies. MIMO can be used to achieve diversity gain, spatial multiplexing gain, and beamforming gain. For these reasons, MIMO systems are an important part of third and fourth generation wireless systems and are used in 5G systems.

[0214] To provide additional context for various embodiments described herein, Figure 12 And the following discussion is intended to provide a brief, general description of a suitable computing environment 1100 in which various embodiments can be implemented. While the above has been described in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that the embodiments also can be implemented in combination with other program modules and / or as a combination of hardware and software.

[0215] Generally, program modules include routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the methods can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputers, mainframe computers, IoT devices, distributed computing systems, and comparable devices, each of which can be operatively coupled to one or more associated devices.

[0216] The embodiments illustrated in the present disclosure also can be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0217] Computing devices typically include a variety of media, which can include computer-readable storage media, machine-readable storage media, and / or communications media, which are used to store and / or transfer information between computing devices. The terms computer-readable storage media and machine-readable storage media are used herein in the same sense as used in the industry to refer to physical storage media that is used to store instructions that implement the methods described herein. In contrast, the term communications media is used herein to refer to signal media, which are used to transfer information between computing devices. The terms computer-readable storage media and machine-readable storage media do not encompass transitory media unless otherwise specifically stated.

[0218] Computer-readable storage media can include, but is not limited to, random access memory (RAM), read only memory (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid state drives or other solid state storage devices, or other tangible and / or non-transitory media which can be used to store desired information. In this regard, the terms tangible or non-transitory herein as applied to storage, memory or computer-readable media, are to be understood not to be synonymous with or

[0219] Computer-readable storage media can be accessed by one or more local or remote computing devices, e.g., via access requests, queries or other data retrieval protocols, for various operations in connection with the information stored by the media.

[0220] Communication media typically embodies computer-readable instructions, data structures, program modules or other structured or unstructured data in a data signal such as a modulated data signal, e.g., a carrier wave or other transport mechanism, and includes any information delivery or transport media. The term "modulated data signal" or signal refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media, such as a wired network or direct- wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0221] References Figure 12The example environment 1200 for implementing various embodiments of the aspects described herein includes a computer 1202 that includes a processing unit 1204, a system memory 1206, and a system bus 1208. The system bus 1208 couples system components including, but not limited to, the system memory 1206 to the processing unit 1204. The processing unit 1204 can be any of various commercially available processors, and can include dedicated cache memory. Dual microprocessors and other multi-processor architectures can also be employed as the processing unit 1204.

[0222] The system bus 1208 can be any of several types of bus structures including an address bus, a data bus, a control bus, and an external bus using various commercially available bus architectures, including an Industry Standard Architecture (ISA), Extended ISA (EISA), Micro Channel Architecture (MCA), Peripheral Component Interconnect (PCI), a Universal Serial Bus (USB), advanced graphics port (AGP), and / or a proprietary bus having a variation of the above bus structures. The system memory 1206 includes ROM 1210 and RAM 1212. A basic input / output system (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read only memory (EPROM), EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer 1202, such as during start-up. The RAM 1212 can also include high-speed RAM such as static RAM for caching data.

[0223] The computer 1202 further includes an internal hard disk drive (HDD) 1214 (e.g., EIDE, SATA), one or more external storage devices 1216 (e.g., a magnetic floppy disk drive (FDD) 1216, a memory stick or flash drive reader, a memory card reader, etc.), and an optical disk drive 1250 (e.g., which can read from or write to a CD-ROM, DVD, BD, etc.). While the internal HDD 1214 is illustrated as being within the computer 1202, the internal HDD 1214 can also be configured for external use in an appropriate chassis (not shown). Additionally, while not shown in the environment 1200, a solid state drive (SSD) can be used in addition to or in place of the HDD 1214. The HDD 1214, external storage device(s) 1216, and optical disk drive 1250 can connect to the system bus 1208 via an HDD interface 1224, an external storage interface 1226, and an optical disk drive interface 1228, respectively. The interface 1224 for external drive implementation can include at least one or both of a Universal Serial Bus (USB) and an Institute of Electrical and Electronics Engineers (IEEE) 1294 interface technology. Other external drive connection technology is within the contemplation of the embodiments described herein.

[0224] The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth for the computer 1202. For the computer 1202, the drives and storage media accommodate the storage of any data in a suitable digital format. While the foregoing description of computer- readable storage media describes various types of storage devices in terms of their respective types of computer-readable storage media, one of ordinary skill in the art will appreciate that other types of computer-readable storage media that are now known or that become available in the future, including magnetic cassettes, optical tapes, and solid-state random access memories, can be used in the example operating environment, and that albeit further, any such storage media can contain the computer-executable instructions for implementing the methodologies described herein.

[0225] A number of program modules can be stored in the drives and RAM 1212, including an operating system 1230, one or more application programs 1232, other program modules 1234, and program data 1236. All or portions of the operating system, applications, modules, and / or data can also be cached in the RAM 1212. The systems and methods described herein can be implemented with various commercially available operating systems or combinations of operating systems.

[0226] The computer 1202 can optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary can emulate a hardware environment for the operating system 1230, and the emulated hardware can optionally differ from the hardware illustrated in ​ In such embodiments, the operating system 1230 can include one of a number of virtual machines (VMs) hosted at the computer 1202. Further, the operating system 1230 can provide a runtime environment to the applications 1232, such as a Java runtime environment or the.NET framework. A runtime environment is a consistent execution environment that allows the applications 1232 to run on any operating system that includes the runtime environment. Similarly, the operating system 1230 can support containers, and the applications 1232 can be in the form of containers, which are lightweight, independent, executable software packages that include, for example, code for the application, a runtime, system tools, system libraries, and settings.

[0227] Further, the computer 1202 can include a security module, such as a trusted processing module (TPM). For example, with the TPM, a boot component hashes the next boot component in time, and waits for a match of the result to a secure value, before loading the next boot component. This process can occur at any layer in the code execution stack of the computer 1202, for example, at the application execution level or at the operating system (OS) kernel level, thereby enabling security at any level of code execution.

[0228] A user can enter commands and information into the computer 1202 through one or more wire / wireless input devices, e.g., a keyboard 1238, a touch screen 1240, and a pointing device, such as a mouse 1242. Other input devices (not shown) can include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, or other remote control, a joystick, a virtual reality controller and / or virtual reality headset, a gamepad, a stylus, an image input device, e.g., a camera(s), a gesture sensor input device, a vision motion sensor input device, an emotion or facial detection device, a biometric input device, e.g., a fingerprint or iris scanner, or the like. These and other input devices are often connected to the processing unit 1204 through an input device interface 1244 that can be coupled to the system bus 1208, but can be connected by other interfaces, such as a parallel port, an IEEE 1294 serial port, a game port, a USB port, an IR port, a BLUETOOTH® interface, etc.

[0229] A monitor 1246 or other type of display device is also connected to the system bus 1208 via an interface, such as a video adaptor 1248. In addition to the monitor 1246, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0230] The computer 1242 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer(s) 1250. The remote computer(s) 1250 can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computer 1202, although, for purposes of brevity, only a memory / storage device 1252 is illustrated. The logical connections depicted include wire / wireless connectivity to a local area network (LAN) 1254 and / or larger networks, e.g., a wide area network (WAN) 1256. Such LAN and WAN networking environments are commonplace in offices and companies and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, e.g., the Internet.

[0231] When used in a LAN networking environment, the computer 1202 can be connected to the local network 1254 through a wire / wireless communication network interface or adaptor 1258. The adaptor 1258 can facilitate wire or wireless communication to the LAN 1254, which can also include a wireless access point (AP) disposed thereon for communicating with the adaptor 1258 in wireless mode.

[0232] When used in a LAN or WAN networking environment, the computer 1202 can be connected to the LAN 1254 through a network adapter 1258. When used in a WAN networking environment, the computer 1202 can include a modem 1260 or other means for establishing communications over the WAN 1256, such as by way of the Internet. The modem 1260, which can be internal or external and a wired or wireless device, can be connected to the system bus 1208 via the input device interface 1244. In a networked environment, program modules depicted relative to the computer 1202, or portions thereof, can be stored in the remote memory / storage device 1252. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

[0233] When used in a LAN or WAN networking environment, the computer 1202 can access cloud storage systems or other network-based storage systems in addition to, or instead of, the external storage devices 1216 described above. Generally, a connection between the computer 1202 and a cloud storage system can be established over the LAN 1254 or WSN 1256, for example, through the adapter 1258 or modem 1260, respectively. When the computer 1202 is connected to an associated cloud storage system, the external storage interface 1226 can manage storage provided by the cloud storage system with the aid of the adapter 1258 and / or modem 1260, as it would other types of external storage. For example, the external storage interface 1226 can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer 1202.

[0234] The computer 1202 can communicate with any wireless devices or entities operatively disposed in wireless communication, such as printers, scanners, desktop and / or portable computers, portable data assistants, communications satellites, any device or location associated with a wireless detection

[0235] The above description includes non-limiting examples of various embodiments. Of course, it is not possible to describe every conceivable combination of components or methodologies for purposes of describing the disclosed subject matter, and one of ordinary skill in the art will recognize that many further combinations and permutations of various embodiments are possible. The disclosed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

[0236] With respect to various functions performed by the above-described components, devices, circuits, systems, etc., unless otherwise specified, the terms describing such components are intended to also include any structural equivalents (e.g., functionally equivalent) of the disclosed structures that perform the same or similar functionality, regardless of structure. Moreover, although a particular feature of the disclosed subject matter can have been disclosed in only one of several implementations, such feature can be combined with one or more other features of the other implementations, as can be desirous in any particular case.

[0237] The terms "exemplary" and / or "illustrative," as can be used herein, are intended to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as "exemplary" and / or "illustrative" is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent structure and / or operations. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the above description.

[0238] The term "or," as used herein, is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the X at least employs A; and X at least employs B. Additionally, the terms "a" and "an," as used herein, are generally intended to mean "one or more" unless otherwise specified or clear from context. At least one of the terms "comprising," "including," and "containing" shall be

[0239] The term "set," as employed herein, does not include an empty set, i.e., a set with no elements. Accordingly, a "set" in the present disclosure includes one or more elements or entities. Likewise, the term "group," as utilized herein, refers to a collection of one or more entities.

[0240] The terms "first," "second," "third," etc. as used in the claims, unless otherwise specified, are used for clarity, and do not necessarily mean that the components need to be in a time sequence. For example, "a first determination," "a second determination," and "a third determination" do not mean that the first determination has to be made before the second determination, or vice versa, etc.

[0241] As used in this description, in some embodiments, the terms "component," "system" and the like are intended to refer to or include a computer-related entity or an entity related to an operational apparatus with one or more specific functionalities, wherein the entity can be either hardware, a combination of hardware and software, software, or an entity running on software, in execution. As an example, a component can be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a computer-executable instruction, a program, and / or a computer. Both an application running on a server and the server can be a component but the disclosure is not so limited.

[0242] One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between two or more computers. In addition, these components can execute from various computer readable media having various data structures stored thereon. The components can communicate via local and / or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and / or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, which is operated by a software application or firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. In yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that conveys at least portions of the functionality of the electronic component. While various components have been illustrated as separate components, it will be understood that multiple components can be implemented as a single component, or a single component can be implemented as multiple components, without departing from example embodiments.

[0243] The term "facilitating" as used herein in the context of a system, device, or component "facilitating" one or more actions or operations relates to the nature of complex computing environments in which multiple components and / or multiple devices can be involved in some computing operation. Non-limiting examples of actions that can or can not involve multiple components and / or multiple devices include: sending or receiving data, establishing a connection between devices, determining intermediate results toward obtaining a result, etc. In this regard, a computing device or component can facilitate an operation by playing any role in implementing the operation. Thus, when operations of a component are described herein, it will be understood that where an operation is described as being facilitated by a component, the operation can optionally be accomplished with the cooperation of one or more other computing devices or components, such as but not limited to sensors, antennas, audio and / or visual output devices, other devices, etc.

[0244] Furthermore, various embodiments can be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable (or machine-readable) device or computer-readable (or machine-readable) storage / communication media. A computer-readable storage medium can include, but is not limited to, magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips), optical disks (e.g., compact disk (CD), digital versatile disk (DVD)), smart cards, and flash memory devices (e.g., card, stick, key drive). Of course, those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope or spirit of the various embodiments.

[0245] In addition, terms such as "mobile device apparatus," "mobile station," "mobile," "subscriber station," "access terminal," "terminal," "handset," "communication device," "mobile device" (and / or terms of similar meaning) can refer to a wireless device that a user or mobile device uses to receive or convey data, control, voice, video, sound, gaming, or substantially any data stream or signaling stream. The above terms are used interchangeably herein and with reference to the drawings. Likewise, the terms "access point," "base station," "BS," "BS transceiver," "BS device," "cell site," "cell site device," "gNode B (gNB)," "evolved Node B (eNode B, eNB)," "Home Node B (HNB)," and the like, refer to wireless network components or devices that send and / or receive data, control, voice, video, sound, gaming, or substantially any data stream or signaling stream from one or more subscriber stations. The data streams and signaling streams can be packet-switched or frame-based.

[0246] In addition, the terms "device," "communication device," "mobile device," "subscriber," "customer entity," "customer," "customer entity," "entity," and the like are used interchangeably herein and throughout, unless context warrants particular distinction among the terms. It should be understood that such terms can refer to human entities or automated components supported through artificial intelligence (e.g., capabilities of complex mathematical algorithms supported by AI) that support the simulation of visual, voice recognition, and the like.

[0247] It should be noted that although various aspects and embodiments are described herein in the context of 5G, O-RAN, or other generations of networks, the disclosed aspects are not limited to 5G or O-RAN implementations and are applicable to next-generation implementations of other networks, such as sixth-generation (6G) or other wireless systems. In this regard, aspects or features of the disclosed embodiments can be utilized in substantially any wireless system technology. These wireless communication technologies can include Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCMDA), CDMA2000, Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Multi-Carrier CDMA (MC-CDMA), Single-Carrier CDMA (SC-CDMA), Single-Carrier FDMA (SC-FDMA), Orthogonal Frequency Division Multiplexing (OFDM), Discrete Fourier Transform Extended OFDM (DFT Extended OFDM), Filter Bank-Based Multi-Carrier (FBMC), Zero-Tail DFT Extended OFDM (ZT DFT-s-OFDM), Generalized Frequency Division Multiplexing (GFDM), Fixed-Mobile Convergence (FMC), Universal Fixed-Mobile Convergence (UFMC), Unique Word OFDM (UW-OFDM), and Unique Word DFT Extended OFDM (UW DFT-Spread-OFDM, Cyclic Prefix OFDM (CP-OFDM), Resource Block Filtered OFDM, Wi-Fi, Global Microwave Access Interoperability (WiMAX), Wireless Local Area Network (WLAN), General Packet Radio Service (GPRS), Enhanced GPRS, 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE), 5G, 3rd Generation Partnership Project 2 (3GPP2), Ultra Mobile Broadband (UMB), High-Speed ​​Packet Access (HSPA), Evolved High-Speed ​​Packet Access (HSPA+), High-Speed ​​Downlink Packet Access (HSDPA), High-Speed ​​Uplink Packet Access (HSUPA), Zigbee, or another IEEE 802.12 technology.

[0248] The description of illustrative embodiments of the disclosure provided herein, including the descriptions of the described in the Abstract, are not intended to be exhaustive or to limit the disclosed embodiments to the precise form disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible within the scope of such embodiments and examples, as will be recognized by those skilled in the art. In this regard, while the subject matter has been described in connection with various embodiments and corresponding drawings, it will be understood, in light of the foregoing disclosure, that other similarly suited embodiments or uses are possible, and that certain modifications, or additions can be made to the described embodiments without departing from the scope of the disclosed subject matter. Accordingly, the disclosed subject matter is not intended to be limited to any single embodiment described herein, but rather is to be accorded the widest scope consistent with the claims set forth below.

Claims

1. A method comprising: receiving, by a device comprising a processor, a request to load a first application (xApp), wherein the first xApp is configured to adjust a first metric of a radio access network (RAN); and determining, by the device, whether the adjustment to the first metric causes a conflict with a current operation of the RAN.

2. The method of claim 1, further comprising: determining, by the device, whether the RAN can support the adjustment to the first metric by the first xApp; and in response to the RAN being determined to be unable to support the adjustment to the first metric by the first xApp, denying, by the device, a load request from the first xApp to operate the first xApp at the RAN.

3. The method of claim 1, further comprising: determining, by the device, a second metric adjusted by a second xApp, wherein the first metric of the first xApp and the second metric of the second xApp have a common control objective; and in response to the first metric of the first xApp and the second metric of the second xApp being determined, by the device, to have a common control objective, further determining, by the device, whether the first metric of the first xApp adversely affects operation of the common control objective based on operation of the common control objective adjusted by the second metric of the second xApp.

4. The method of claim 3, further comprising: in response to the first metric of the first xApp being determined to adversely affect the operation of the common control objective based on the operation of the common control objective adjusted by the second metric of the second xApp, denying, by the device, a load request from the first xApp to operate the first xApp at the RAN.

5. The method of claim 3, further comprising: in response to the first metric of the first xApp being determined to adversely affect the operation of the common control objective based on the operation of the common control objective adjusted by the second metric of the second xApp, applying, by the device, a first priority to the first xApp and a second priority to the second xApp, wherein the first priority has a higher priority than the second priority; executing, by the device, the first xApp based on the higher priority; terminating, by the device, operation of the first xApp; and executing, by the device, the second xApp.

6. The method of claim 5, wherein the operation of the first xApp is terminated based on a configured duration of time.

7. The method of claim 1, further comprising: identifying, by the device, a second metric adjusted by a second xApp, wherein the first metric and the second metric are different; and ​ ​ determining, by the device, that a third metric running at the device is being negatively impacted by an interaction resulting from the first metric being adjusted by the first xApp and the second metric being adjusted by the second xApp.

8. The method of claim 7, further comprising: terminating, by the device, execution of the first xApp.

9. The method of claim 1, wherein the RAN is an open RAN (O-RAN).

10. A system comprising: at least one processor; and memory coupled to the at least one processor and having instructions stored thereon, wherein, responsive to the at least one processor, the instructions facilitate performance of operations comprising: identifying that a first metric of a radio access network (RAN) is controlled by a first application (xApp); identifying that a second metric of the RAN is controlled by a second xApp; and determining whether control of the second metric is adversely affected by control of the first metric by the first xApp.

11. The system of claim 10, wherein the operations further comprise: terminating execution of the first xApp responsive to determining that the control of the second metric by the second xApp is adversely affected by control of the first metric by the first xApp.

12. The system of claim 10, wherein the operations further comprise: running the first xApp for a first time period responsive to determining that the control of the second metric by the second xApp is adversely affected by the control of the first metric by the first xApp; and running the second xApp for a second time period, wherein the first time period and the second time period are non-overlapping and different.

13. The system of claim 10, wherein the operations further comprise: determining that a third metric runs at the RAN responsive to determining that the control of the second metric by the second xApp is not adversely affected by the control of the first metric by the first xApp; determining whether the running of the third metric at the RAN is adversely affected by a combination of the first metric being controlled by the first xApp and the second metric being controlled by the second xApp; and terminating execution of the first xApp responsive to determining that the running of the third metric at the RAN is adversely affected by the combination of the first metric being controlled by the first xApp and the second metric being controlled by the second xApp.

14. The system of claim 10, wherein the first metric has a key performance indicator (KPI) configured to identify running of the first metric, and wherein the first metric relates to at least one of: coverage of the RAN, capacity of the RAN, or energy-related performance of the RAN.

15. The system of claim 10, wherein the system is one of: a real-time RAN intelligence controller (RIC), a near real-time RIC, or a non-real-time RIC. ​ 16. A computer program product, the computer program product being stored on a non-transitory computer readable medium and comprising machine executable instructions that, in response to being executed, cause a machine to perform operations comprising: identifying a first operational characteristic of a first application (xApp); identifying a second operational characteristic of a second xApp, wherein the first xApp and the second xApp are configured to be executed via a radio access network (RAN); and determining whether the first operational characteristic of the first xApp is a threshold that is likely to negatively affect the second operational characteristic of the second xApp in the event that the first xApp and the second xApp are co-deployed on the RAN.

17. The computer program product of claim 16, wherein the operations further comprise: in response to determining that the first operational characteristic of the first xApp is a threshold that is likely to negatively affect the second operational characteristic of the second xApp in the event that the first xApp and the second xApp are co-deployed on the RAN: rejecting loading the first xApp on the RAN.

18. The computer program product of claim 16, wherein the operations further comprise: in response to determining that the first operational characteristic of the first xApp is not a threshold that is likely to negatively affect the second operational characteristic of the second xApp in the event that the first xApp and the second xApp are co-deployed on the RAN: co-deploying the first xApp and the second xApp on the RAN, thereby resulting in a co-deployment of the first xApp and the second xApp.

19. The computer program product of claim 18, wherein the operations further comprise: monitoring a running of a metric at the RAN; determining whether the running of the metric at the RAN is adversely affected by the co-deployment of the first xApp and the second xApp; and in response to the metric being determined to be adversely affected by the co-deployment of the first xApp and the second xApp, terminating a running of the first xApp.

20. The computer program product of claim 15, wherein the machine is one of: a real-time RAN intelligence controller (RIC), a near real-time RIC, or a non-real-time RIC.

Images