Collision mitigation for radio access networks

Abstract

The described techniques are generally directed to conflict management of applications implemented on a radio access network (RAN). Various embodiments are presented to enable identification of potential conflicts (e.g., where an application is being loaded) and current conflicts (e.g., where two or more applications have been in operation). Conflicts may directly affect control targets, e.g., two applications are attempting to control the same target. Conflicts may indirectly affect control objectives, for example, two applications affect a first metric and a second metric, but a third metric is affected. The collision resolution method includes preventing application loading, terminating operation of the application, identifying a cause independent of the application, rolling back operation of the RAN to a previous condition (e.g., a pre-collision condition), and the like. A collision resolution method may be performed at a RAN Intelligent Controller (RIC).

Description

TECHNICAL FIELD

[0001] This application claims priority to U.S. Non-Provisional Patent Application No. 18 / 338,595, filed June 21, 2023, entitled “CONFLICT MITIGATION OF A RADIO ACCESS NETWORK,” the entirety of which priority application is hereby incorporated by reference herein. BACKGROUND

[0002] A radio access network (RAN) provides wide area wireless connectivity for mobile devices. A RAN can be composed of devices manufactured by different vendors. In view of the potential large scale and complexity of RANs developed to meet the growing demand for cellular communications, various vendor alliances have been formed with the goal of generating specifications to facilitate configuration, techniques, methods, devices, etc. for various communications over the RAN. Such alliances include the Third Generation Partnership Project (3GPP), Fourth Generation Long Term Evolution (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. The 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 operability networks.

[0004] The above description of background is provided only as an overview of some of the problems of the current technology and is not intended to be an exhaustive motivation for the various embodiments. Additional background information can become apparent upon reading the following detailed description. SUMMARY

[0005] The following presents a simplified summary of the disclosed subject matter to provide a basic understanding of one or more of the various 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 nor to delineate the scope of the various embodiments. Its sole purpose is to present some concepts of the disclosure in a streamlined manner as a prelude to the more detailed description that is to follow.

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

[0007] According to one or more embodiments, a computer-implemented method is provided that includes monitoring, by a device comprising a processor, operation of a first control parameter, wherein the first control parameter is configured to control operation of a feature of a network device that is part of a radio access network (RAN), and detecting, by the device, a threshold degradation in performance of the operation of the feature resulting from use of the first control parameter based on a defined performance metric. In one embodiment, the RAN is an open RAN. In another embodiment, the device can be located in one of a real-time RAN intelligence controller (RIC), a near real-time RIC, or a non-real-time RIC.

[0008] In embodiments, the method can further include identifying, by the device, a first operation of a first application (xApp) configured to adjust the first control parameter, and further identifying, by the device, a second operation of a second xApp to adjust the first control parameter. In addition, in response to determining that the first operation and the second operation conflict resulting in detrimental operation of the first control parameter, embodiments can include terminating, by the device, the first operation of the first xApp, and further rolling back, by the device, the operation of the feature to a stored configuration from before the first xApp was implemented, wherein the first control parameter is modifiable by the second operation of the second xApp.

[0009] In another embodiment, the method can further include identifying, by the device, one or more conditions of the adjustment to the operation of the feature to implement the rollback, the first xApp, the second xApp, and the conflict, and further storing, by the device, rollback information, wherein the rollback information includes information representative of the adjustment, the first xApp, the second xApp, the first control parameter, the first operation of the first xApp, the second operation of the second xApp, and the conditions of the conflict.

[0010] In another embodiment, the method can further include (i) receiving, by the device, a request to onboard a third xApp, (ii) retrieving, by the device, subscription information of the third xApp based on the onboarding request, wherein the subscription information includes a second control parameter to be adjusted by the third xApp, and a third operation of the third xApp configured to adjust operation using the second control parameter, (iii) comparing, by the device, the subscription information of the third xApp to the rollback information, (iv) determining, by the device, that the first control parameter and the second control parameter are the same parameter, and (v) generating, by the device, a warning indicating that the third xApp is configured to adjust operation using the first control parameter, wherein it has been determined that use of the first control parameter has been involved in a conflict between the first xApp and the second xApp previously. In another embodiment, the method can further include rejecting, by the device, the onboarding request of the third xApp based on the third xApp being configured to adjust the first control parameter, and determining that the first control parameter is associated with the rollback.

[0011] Another embodiment can utilize a system that includes at least one processor, and a memory coupled to the at least one processor and having stored thereon instructions which, when executed by the at least one processor, facilitate performance of operations comprising: receiving a load request from a first application (xApp), wherein the load request is for access to a service of a radio access network (RAN), and further determining that the load request is directed to a control parameter for which rollback data has been determined to be applicable. In an embodiment, the RAN is an open RAN. In another embodiment, the system is one of a real-time RAN intelligent controller (RIC), a near real-time RIC, or a non-real-time RIC.

[0012] In an embodiment, the operations can further comprise extracting first information from the load request, and further comparing the first information in the load request to previously stored data, wherein the previously stored data comprises a rollback event applicable to the control parameter. In an embodiment, the operations can further comprise: responsive to determining that the load request is directed to the control parameter for which rollback data has been determined to be applicable, rejecting the load request. In another embodiment, the operations can further comprise: generating alert data representing an alert indicating that the first xApp is directed to the control parameter for which rollback data has been determined to be applicable. In another embodiment, the operations can further comprise: obtaining the rollback data from a data repository, wherein the data repository further comprises a plurality of rollback events applicable to the control parameter.

[0013] In an embodiment, the rollback data can relate to an operational conflict between a second xApp configured to adjust the control parameter and a third xApp configured to adjust the control parameter.

[0014] Another embodiment can include a computer program product stored on a non-transitory computer readable medium and comprising machine executable instructions which, when executed, cause a machine to perform operations comprising: detecting a first state of a metric, wherein the metric relates to an operational condition of a radio access network (RAN); further detecting a second state of the metric in accordance with a defined criterion, wherein the second state of the metric is subsequent in time to the first state, and is an operationally worse state than the first state; and further identifying that the operationally worse state of the metric is a result of an operation of a first application (xApp) configured to adjust the metric and an operation of a second xApp configured to adjust the metric.

[0015] In another embodiment, the operations can further include: (i) identifying a first operational impact of the first xApp on one or more operations performed by the network devices via the RAN; (ii) identifying a second operational impact of the second xApp on the one or more operations performed by the network devices via the RAN; (iii) responsive to determining, in accordance with the second defined criteria, that the first xApp has a more detrimental impact on the one or more operations performed by the network devices via the RAN than the second xApp, terminating operation of the first xApp; and (iv) further rolling back operation of the network devices of the RAN to an operational state associated with a time prior to implementation of the first xApp by the network devices via the RAN.

[0016] In another embodiment, the operations can further include: (i) receiving a load request from a third xApp; (ii) identifying that the third xApp is configured to adjust usage of the metric; (iii) comparing the configuration of the third xApp to the configuration of the first xApp; (iv) based on a result of the comparison, determining, in accordance with the defined similarity criteria, that the configuration of the third xApp is threshold similar to the configuration of the first xApp; and (v) responsive to determining that the third xApp is threshold similar to the first xApp, rejecting the load request from the third xApp. In another embodiment, the operations can further include generating and transmitting a warning that loading of the third xApp in accordance with the load request has been rejected. BRIEF DESCRIPTION OF DRAWINGS

[0017] Many of the attendant features and advantages of embodiments presented will be further appreciated when viewed in connection with the following detailed description, when read in conjunction with the accompanying drawings, wherein like reference numerals refer to like parts throughout the several views, and wherein:

[0018] Figure 1 A system is presented in accordance with embodiments that includes various components / devices and various types of interactions / analyses that can be performed for conflict management between various xApps deployed on a RAN.

[0019] Figure 2 A system is presented in accordance with embodiments that includes various components / devices and various types of interactions / analyses that can be performed for conflict management between various xApps deployed on a RAN.

[0020] Figure 3 A process is presented in accordance with embodiments that illustrates various stages in determining xApp conflicts and rollbacks.

[0021] Figure 4 An xApp conflict management system is presented in accordance with embodiments.

[0022] Figure 5 A system is presented in accordance with embodiments that includes various components / devices and various types of interactions / analyses that can be performed for conflict management between various xApps deployed on a RAN.

[0023] Figure 6 A high level structure of a conflict detection subcomponent according to an embodiment is presented.

[0024] Figure 7 A structural framework of a conflict xApp detection component configured to detect a conflict xApp according to an embodiment is presented.

[0025] Figure 8 A method for determining whether an operational conflict occurs by implementing an xApp on a RAN is illustrated according to one or more embodiments described herein.

[0026] Figure 9 A method for determining whether an operational conflict occurs by implementing an xApp on a RAN is illustrated according to one or more embodiments described herein.

[0027] Figure 10 A method for determining whether an operational conflict occurs by implementing an xApp on a RAN is illustrated according to one or more embodiments.

[0028] Figure 11 A method for deploying an xApp on a RAN based on a KPI class is illustrated according to one or more embodiments described herein.

[0029] Figure 12 A method for deploying an xApp on a RAN is illustrated according to one or more embodiments described herein.

[0030] Figure 13 A method for deploying an xApp on a RAN is illustrated according to one or more embodiments described herein.

[0031] Figure 14 An example wireless communication system is illustrated according to one or more embodiments described herein.

[0032] Figure 15 An example environment for implementing various embodiments presented herein is presented. DETAILED DESCRIPTION

[0033] One or more embodiments will be described below with reference to the accompanying drawings, in which like elements are referred to with like reference numerals, and in which: For explanatory purposes, numerous specific details are set forth in the following description in order to provide a thorough understanding of the various embodiments. It can be feasible, however, to practice the various embodiments without these specific details (e.g., without the specific networking environment or standards being applied). In other instances, well-known structures and devices are shown in block diagram form in order to facilitate describing these embodiments.

[0034] Various embodiments presented herein relate to leveraging a conflict management system (CMS) in conjunction with conflict detection and mitigation strategies. The CMS can be configured to be implemented in 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 configured to support multi-xApp interaction are presented. A combination of preventive and reactive measures makes possible the coordinated deployment of xApps with interaction. Based on detected conflicts and / or predicted conflicts, xApp subscriptions / deployment at the RAN can be adjusted to avoid conflicting control actions. xApp subscription management enables operators to adjust their deployment strategy of xApps. Furthermore, when priority evaluation and subscription adjustment can not be an effective solution, implementing 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, individual xApps can provide descriptors including any of: configuration information, control (level and type of control) information, target key performance indicator (KPI) categories and subcategories, xApp classification, etc. The CMS can use the provided descriptors to trigger preventive measures.

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

[0038] According to respective systems / techniques presented herein, where a multi-xApp interaction framework, respective ML techniques can be leveraged to learn / identify a “projection” of performance changes. ML can also predict KPIs ahead of time to establish baseline behavior. One or more ML techniques / models can be deployed to enable correlation between xApp actions and performance changes, and further determine xApps that cause opposite performance directions.

[0039] During the onboarding process, a restrictive framework can be leveraged where the RIC restricts the selection range, rather than freely selecting all information open to the xApp that is requesting onboarding. Thus, the RIC can specify a target KPI list to select from the xApp based on App classification, and can also specify an allowed action list to select from the xApp based on target KPIs. Furthermore, according to various embodiments presented herein, scale control can be leveraged to limit the number of xApps allowed for the same class / KPI category.

[0040] Terminology

[0041] xApp : An application that can be deployed at the O-RAN (e.g., at the RIC) and configured to optimize / automate RAN operations in conjunction with supporting use cases for reducing total cost of ownership (TCO) for an operator (e.g., a mobile operator), enhancing quality of experience (QoE) for customers, etc.

[0042] Class / KPI Category : The respective KPIs can be divided into various Class , such that each KPI can have its own Class . Each xApp (e.g., xApps 120A- n ) can be assigned / associated with the KPIs that are the focus of the operation of the respective xApp. Accordingly, based on classifying a first xApp (e.g., during onboarding) to a certain KPI, and determining the operational impact of the first xApp on one or more xApps that have already been classified for that particular KPI, potential conflicts for the KPI can be quickly identified. Moreover, to maintain operational efficiency of the RAN and to mitigate potential unforeseen conflicts, the number of xApps that are supported / implemented 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 not) will occur.

[0043] Dimensioning : Limiting the number of xApps based on the KPI classification of the respective xApps.

[0044] Key Performance Indicator (KPI) : Provides a measure of quantifiable performance for a particular goal. KPIs can relate to accessibility, availability, integrity, mobility, retainability, etc.

[0045] Key Performance Metric (KPM) : Provides a measure of performance for a KPI.

[0046] Node and 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 RAN packet processing functions, the DU implements baseband processing functions at each cell site, and the RU provides radio functions at the antenna site. While the RU is located at the antenna site, the location of the CU and the DU is not fixed to any particular geographic area or site. The DU can be co-located with the RU located locally, or the DU can be located miles away from the RU, such that the connection between the DU and the RU can be implemented through any suitable technology (e.g., fiber). The CU and the DU can be located in the “cloud,” such as a data center that can be close to the RU or far away from the RU.

[0047] O-cloud : An operational layer that includes hardware and software components that 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 prior to deployment / implementation of potentially adverse xApps, thereby preventing xApps that can negatively impact RAN operations from being loaded / deployed / implemented.

[0049] RAN Intelligent Controller (RIC): RIC is an O-RAN component configured to control and optimize RAN functions. RIC enables automation / optimization of RAN operations with respect to the onboarding of multi-vendor / third-party xApps, e.g., use cases with respect to reducing mobile operator’s TCO, enhancing customer QoE, etc. RIC can control what xApps are deployed on the RAN. For some contexts, e.g., Non-RT RIC functions include service and policy management, RAN analytics, and model training for Near-RT RIC. In this regard, Non-RT-RIC enables non-real-time (e.g., a first time range, such as > 1 second) control of RAN elements and their resources through applications (e.g., specialized applications referred to as xApps). For example, Near-RT RIC functions enable near-real-time optimization, control, and data monitoring of CU and DU nodes within a near-real-time time scale (e.g., a second time range, such as between 10 milliseconds to 1 second, that is shorter than the first time range). In this regard, Near-RT RIC facilitates optimization actions to control RAN elements and their resources that typically require approximately 10 milliseconds to approximately 1 second to complete, although different time ranges can be selected. Near-RT RIC can receive policy guidance from Non-RT RIC and provide policy feedback to Non-RT RIC through specialized applications referred to as xApps. In this regard, Real-Time RIC (RTRIC) is designed to handle network functions at a real-time time scale (e.g., representing a third time range, such as less than 10 milliseconds, that is shorter than both the first time range and the second time range).

[0050] Reaction Action : Conflict management performed when multiple xApps are deployed / implemented, thereby identifying and resolving interactions among the multiple xApps and their impact on respective KPIs.

[0051] Rollback : Returning the operation of the RAN to a previous operational state. For example, determining that the operation of a first xApp and the operation of a second xApp are in conflict. To mitigate the conflict, terminating the operation of the first xApp and returning all settings configured by the operation of the first xApp to the configuration prior to implementing the first xApp (e.g., the condition prior to the conflict).

[0052] n is any positive integer.

[0053] 1. SUMMARY

[0054] While the impetus of O-RAN is to open up the RAN, the openness of the RAN architecture and protocols can lead to: (i) xApps can not be supported by the RAN; (ii) various conflicts when multiple applications (xApps) are co-deployed on the RAN; (iii) xApps can adversely affect / cause degradation in performance of another xApp and / or RAN performance. The system provider / operator can not be aware of the potential conflicts that can arise from co-deploying certain xApps on the same RAN site. Conflicting xApps can cause degradation in performance in the RAN and / or RIC. A conflict 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 cause the first and second xApps to get into a “ping-pong” state where the first xApp constantly overrides the second xApp’s decisions / configurations (and vice versa) causing degradation in performance of the RIC and / or RAN.

[0055] The various embodiments presented herein are configured to observe the behavior of xApps to identify / infer potential and existing conflicts among various xApps and further 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, a warning / alarm can be generated whenever a problematic combination of xApps is deployed / likely to be deployed on a RAN site to help avoid direct and indirect conflicts. In embodiments, by leveraging current or historical data about the operation of two or more xApps, a warning / alarm can be issued to prevent a combination of xApps from being broken and the deleterious effects on RAN operation.

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

[0057] As shown, Figure 1 A RAN 110 is presented for respective xApps 120A- n 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 110 is communicably coupled to a service management orchestration (SMO) layer / component 135, where the SMO 135 can be configured to control configuration and automation aspects of the RAN 110 and respective components / elements of the RIC 150. The SMO 135 can also be configured to coordinate respective xApps 120A- ndeployment, in an example scenario, which can involve SMO 135 regarding the possibility of conflicts occurring during deployment of respective xApps 1207- n in conjunction with RIC 150 operations.

[0058] RIC 150 can be configured to control and optimize functions at RAN 110, including loading of xApps 120A- n to be implemented at RAN 110. As further described, RIC 150 can also include a conflict management system (CMS) 130 configured to identify potential and existing conflicts between various xApps 120A- n during potential deployment and current deployment of one or more xApps 120A- n on RAN 110. As further described, xApps 120A- n can affect operations of various KPIs 140A- n at RAN 110, e.g., as determined by key performance metrics KPM 145A- n . In an ideal situation, RAN 110 would be configured to support operations of multiple xApps 120A- n . However, deployment of a first application (e.g., xApp 120A) can affect deployment of a second application (e.g., xApp 120B) on RAN 110 and adversely affect one or more of KPIs 140A- n as shown in Figure 1 Each xApp 120A- n can be configured with specific attributes, use cases, metrics, etc., for which xApp 120A-n is designed, where respective attributes, use cases, etc., of interest for each xApp 120A- n are represented as data 121A- n , where respective data 121A- n is associated with respective xApp 120A- n , e.g., xApp 120A has associated data 121A, xApp 120B has data 121B, xApp 120n has data 121n, etc.

[0059] System 100 can also include O-cloud 160 configured to coordinate this infrastructure layer of functions for RAN 110, SMO 135, and RIC 150.

[0060] Figure 1 Three high-level scenarios are presented: (1) loading, (2) subscription / pre-deployment, (3) deployment and operation:

[0061] (1) Onboarding : xApp 120A is to be deployed on RAN 110. However, during the process of xApp 120A onboarding / subscribing to RAN 110 (e.g., controlling operational parameters on RAN 110), CMS 130 can determine whether the respective one or more operations to be performed by xApp 120A are (i) supported by RAN 110, and / or (ii) even if supported, can have a detrimental impact on RAN 110 and / or the operations of other xApps 120B already deployed on RAN 110. n In the event that the control parameters / targets / operations of xApp 120A are not supported by RAN 110, the subscription of xApp 120A at RAN 110 can be rejected.

[0062] (2) Subscription / Pre-Deployment : In the event that xApp 120B can be deployed on RAN 110, CMS 130 can be configured to determine whether there is one or more operational conflicts between xApp 120B and xApp 120C that is deployed / will be deployed. In the event that CMS 130 determines that there is an operational conflict between xApp 120B and xApp 120C, there can be various responses, such as not deploying one of xApp 120B or xApp 120C, deploying xApp in the event that the operations of xApp B are prioritized over xApp C, and so forth, as further described.

[0063] (3) Deploy and Operate : multiple xApps 120A- n are deployed and are operating on RAN 110, such that CMS 130 can evaluate the operational effects of one or more of xApps 120A- n . The operations of one or more of xApps 120A-n can be evaluated based on the impact of the respective xApps 120A-n on one or more KPIs 140A- n and / or KPMs 150A- n . Accordingly, xApps that are negatively impacting the operations of one or more of KPIs 140A- n and / or the operations of any of xApps 120A- n (e.g., xApp 120N) can be isolated and their operations terminated, delayed, postponed, and so forth, as further described.

[0064] As Figure 1As shown in the middle, the CMS 130 and the RAN 110 can be communicatively coupled to a computer system 180. The computer system 180 can include a processor 182 and a memory 184, where the processor 182 can execute various computer-executable components, functions, operations, etc. described herein. The memory 184 can be utilized to store various computer-executable components, functions, code, etc., as well as information regarding any of: the xApps 120A- n , the KPIs 140A- n , the KPMs 150A- n , operational state information of the O-RAN (e.g., the RAN 110, the RIC 150, the SMO 135, as further described), the processes 245 (as further described), the data 121A- n stored in the information database 250 and the subscription database 260 (as further described), thresholds, alerts / warnings / notifications, etc.

[0065] 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 and data between any of the components included in the system 100. The I / O component 186 can be communicatively coupled to remote devices and systems. In embodiments, the I / O component 186 can be configured to transmit various alerts / warnings regarding conflicts between the xApps 120A- n (e.g., the warnings / alerts / information 236A- n ).

[0066] In embodiments, the computer system 180 can also include a human-machine interface (HMI) 188 (e.g., a display, a graphical user interface (GUI)), which 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 regarding information / settings, etc. of the xApps 120A- n .

[0067] In accordance with the respective components in the system 100, conflict mitigation can involve detecting, avoiding, and / or resolving conflicting interactions between different xApps 120A- n . nmay involve changing one or more operational parameters at the RAN 110 (or SMO 135, RIC 150, etc., as further described), where the goal of the optimization is 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, co-deployment of two or more xApps 120A- n may result in conflicting actions. In another scenario, while a first operational goal of an xApp 120A and a second operational goal of an xApp 120B can be different, co-deployment of the xApp 120A with the xApp 120B can result in conflicting actions, which can also adversely affect the operation of the RAN 110. Thus, when deploying two or more xApps 120A- n , conflict management and resolution is of interest, particularly in cases where the respective xApps 120A- n are created by different vendors, which can be given the decomposed nature of the O-RAN system.

[0068] In accordance with the O-RAN environment presented in Figure 1 , the xApps 120A- n may 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 reduce repetition, while various embodiments presented herein can specifically refer to one or more xApps 120A- n being presented / deployed / implemented on the RAN 110, RIC 150, etc., given the general nature of the xApps 120A- n , which can be implemented on the RAN 110, SMO 135, RIC 150, etc., reference to utilization of xApps 120A- n on the RAN 110, SMO 135, RIC 150, O-cloud 160, etc., equally applies to application on any of the respective components described herein.

[0069] Various embodiments presented herein can be utilized for real-time (RT), near-RT, and / or non-RT implementations of the RIC, e.g., as presented in a conventional RAN architecture. In a conventional system, to resolve xApps 120A- nimplementation solutions for conflicts between xApps 120A- 120N deployed on RAN 110 are not available in near-RT or RT, and various embodiments presented herein are directed to solving this problem. Various embodiments presented herein provide a management architecture that identifies and resolves conflict issues with CMS 130 according to one or more operational requirements of RAN 110, operational requirements of respective xApps 120A- 120N, RIC 150 API requirements, vendor-agnostic methods, and so forth. n

[0070] 1.1. Conflict Overview

[0071] An overview of some of the conflicts that can exist between various xApps 120A- 120N deployed on RAN 110 is provided below. As mentioned, respective xApps 120A- 120N can be configured to optimize a particular metric (e.g., KPI 140A- 140N) at RAN 110 with a single parameter or a set of parameters. Each xApp 120A- 120N can have a specific control objective (e.g., objective 212A in n ). For example, two or more xApps 120A- 120N deployed as part of a Radio Resource Management (RRM) application can have control objectives (e.g., objectives 212A in n ) that are cells, user equipment (UE), bearers, and so forth. Further, control content of RRM can include access control, bearer control, handover control, resource allocation, Quality of Service (QoS) control, and so forth. Further, control commands can have a control time span, which indicates a valid control duration. Thus, at any time, there can be conflicts between control commands of respective xApps 120A- 120N, for example, because they are related to RRM. n n Figure 2 n Figure 2 n

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

[0073] 1.1.a. Direct Conflict:

[0074] A direct conflict can occur between multiple xApps 120A- 120N and can be directly observed by CMS 130. Examples of direct conflicts are presented below: n i) One or more parameters of control objectives (e.g., objectives 212A in

[0075] Figure 2 n ​​​​​​​​​Different setting requests are received. The CMS 130 can be configured to process the respective requests and decide which request to implement based on priority and / or other metrics.

[0076] ii) Current possibly implemented configurations (e.g., previous requests have been implemented and operations are 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, adding the new request can cause a conflict in view of the previous request.

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

[0078] As further described, direct conflicts can be mitigated by pre-action coordination by the CMS 130. Accordingly, the CMS 130 can implement specific changes and / or a series of changes of applications to prevent conflicts from occurring between respective xApps 120A- n .

[0079] 1.1.b. Indirect conflicts:

[0080] Conflicts between multiple xApps 120A- n may not be directly observable. However, some dependencies between target parameters (e.g., targets 212A in Figure 2 ) and resources of different xApps 120A- n may be observed. 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 is that different xApps 120A- n optimize the same metric for different parameters based on respective targets of respective xApps 120A-n. Such a scenario can not result in conflicting parameter settings, but the configuration of a first xApp 120P can impact system metrics (e.g., targets 212A, KPIs 140A, KPMs 145A) that can be equivalent to a parameter change targeted by another xApp 120Q. For example, antenna tilt and cell individual offset (CIO) are two different control actions, where a configuration of antenna tilt (e.g., target 212A in Figure 2 ) is targeted by xApp 120P, and cell individual offset (CIO) (e.g., target 212B in Figure 2 ) is targeted by xApp 120Q, but both control actions can impact handover function(s).

[0081] As further described, mitigation of indirect conflicts can be achieved through post-action verification. In an example scenario, a change is applied by a respective xApp 120A- n and the target metric (e.g., KPI 140A- n ) is observed. As further described, mitigation of indirect conflicts can be achieved through post-action verification. In an example scenario, a change is applied by a respective xApp 120A- n and the target metric (e.g., KPI 140A- n ) is observed. Based on the observed metric, the CMS 130 can make responsive corrections, such as rolling back the control action(s) / control parameter(s), where rolling back involves returning the operation of the RAN 110 to a state prior to the detection of the conflict and / or the implementation / deployment of the conflicting xApp (e.g., xApp 120A).

[0082] 1.1.c. Implicit conflicts:

[0083] Such conflicts are not directly visible, and moreover, dependencies between multiple xApps 120A- n cannot be directly observed. In essence, different xApps 120A- n utilize different parameters to optimize different metrics. In such a scenario, optimization of a first metric can adversely affect other metrics optimized by other xApps 120A- n . For example, a throughput metric for guaranteed bit rate (GBR) users can degrade the metric for non-GBR users or overall cell throughput.

[0084] As further described, since operational dependencies between two or more xApps 120A- n are difficult to predict / observe, mitigation of implicit conflicts can not be achievable via analytical modeling (e.g., by the CMS 130) prior to deployment of the xApps 120A- n . Accordingly, inter-application dependencies between two or more xApps 120A- n can be identified at the CMS 130 utilizing AI and ML based coordination schemes (e.g., in accordance with implementations of the process 245, as further described). In embodiments, a conflict detection scheme can be provided, for example, based on end-to-end (E2E) system performance and network intent, specific use cases, and the like (e.g., by the CMS 130).

[0085] In embodiments, each xApp 120A- ntarget. However, defining utility metrics can assist in the conflict coordination phase of xApps 120A- n checking. Utility metrics can include the importance of the target metrics and the importance of the use case that xApps 120A-n are related to. In embodiments, CMS 130 can employ various ML-based methods (e.g., in process 245, as further described) to pre-evaluate the probability of a downgrade metric / metric set given a proposed change in the operating environment that xApps 120A- n and / or xApps 120A- n are to be implemented to estimate the probability of a downgrade metric / metric set given the probability of an expected improvement in the metric / metric set.

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

[0087] 2. Preventive and Reactive Measures

[0088] In accordance with the aforementioned issues regarding unpredictable interactions between xApps 120A- n , the respective deployment of xApps 120A- n , the open-architecture structure of RAN 110, etc., the various embodiments presented herein can utilize a combination of preventive (pre-action) measures and reactive (post-action) measures.

[0089] 2.1. Preventive measures can be applied to avoid implementing / deploying two or more xApps 120A - n that have directly conflicting or overlapping functionality, which may detrimentally affect the operation of the corresponding xApp 120A - n , RAN 110, etc. Based on the information generated at this stage, the preventive measures enable the operator to determine a predeployment strategy for its corresponding xApp120A - n .

[0090] 2.2. Reactive measures can be implemented to detect xApps 120A - n with conflicting decisions, where co - deployment by a first xApp (e.g., xApp 120A) and a second xApp (e.g., xApp 120B) results in a change in KPI 140A - n that may be essentially opposite, antithetical, or incompatible.

[0091] By leveraging preventive and / or reactive measures, the operator of xApp 120A - n can be notified (e.g., via HMI 188, warning 236A - n) of the interaction of the corresponding xApp 120A - n (whether in conflict, during loading, etc.), as well as any recommendations (e.g., ML / AI - derived recommendations) generated by one or more components presented in the corresponding embodiments herein (e.g., loading component 210, subscription management component 220, conflict detection component 240, conflict management component 230, etc.). Additionally, post - action verification of the interaction between two or more deployed and operating xApps 120A - n (e.g., generated by CMS 130) enables the operator to adjust the deployment strategy including the corresponding xApp 120A - n . <00003​​​​​​​​​Any conflicts between them. CMS 130 may include a loading component 210 communicatively coupled to xApp information database 250 and subscription database 260 (e.g., where databases 250 and 260 may be included in memory 184). In another embodiment, CMS 130 may also include a subscription management component 220 coupled to subscription database 260 and also coupled to conflict management component 230. Figure 2 As shown, the subscription management component 220 can be configured to work with xApp 120A- n Interaction. In another embodiment, the collision detection component 240 may be connected to the collision management component 230, and further connected to either RAN 110 or E2 terminal (E2T) 270, and further monitor xApp 120A- n / with xApp 120A- n Interaction.

[0094] As further described herein (e.g., according to...) Figure 4 to Figure 8 The collision detection component 240 can be configured with various ML and AI technologies (e.g., Figure 4 Process 245) to enable xApp 120A from multiple deployments n Detection of conflicts. For example... Figure 2 As shown, information database 250 and subscription database 260 can be connected via connector 289, and subscription database 260 can be connected to conflict management component 230 via connector 288, thereby enabling them to freely share information about xApp 120A- n Information. As mentioned, information database 250 and subscription database 260 can be configured to store information previously loaded / requested from xApp 120A- n The information obtained (e.g., data 121A-) n ), of which the stored data 121A- n This can be used as historical data, which can be compared with data (e.g., data 121A) for the current xApp (e.g., xApp 120A). In the embodiment, although shown at the conflict management component 230, any subcomponent of CMS 130 can utilize the threshold relationship 231A- n Or regarding xApp 120A- nother defined criteria of the determined likelihood of conflict (e.g., possible, impossible, similarity of xApps, etc.) between any of the xApps 120A-n. The CMS 130 can also include a warning component 235 configured to generate and transmit warnings / alerts / notifications 236A- n .

[0095] In another embodiment, the CMS 130 can also include a rollback component 248, where the rollback component 248 can be configured to monitor the operation of the RAN 110 (and / or nodes 115, etc.) and, if needed, roll back (reset) the operation of the RAN 110 to an operational condition prior to the implementation of an xApp (e.g., the first xApp 120A). The rollback component 248 can be configured to communicate with any of the components in the CMS 130, as well as with the nodes 115, SMO 130, E2T 270, RIC 150, xApps 120A- n , etc. to enable the rollback component 248 to obtain operational data 241A- n . n about the operation of any of the devices, components, etc. in the communication system presented herein. The operational data 241A- n , data 121A- n , targets 212A- n , thresholds 231A- n , KPIs 140A- n , KPMs 150A- n , etc. can be stored in databases 250 and 260 and can include operational data / settings about the operation of the xApps 120A- .

[0096] Accordingly, in the event that the xApp 120A has an operational conflict with one or more other xApps 120B- n , the operation of the xApp 120A can be terminated, where the RAN 110 is returned to a previous operational condition that is not affected by the operation of the xApp 120A. In an embodiment, any of the components included in the CMS 130 can monitor the operation of the RAN 110 and store data, for example, as operational data 241A- nwith respect to the corresponding operational conditions being implemented at any given time, e.g., operational data 241A for Tl (first time instant) = operational conditions of RAN 110 prior to implementation of first xApp 120A on RAN 110; operational data 241B for T2 (second time instant) = operational conditions of RAN 110 after implementation of first xApp 120A on RAN 110; operational data 241C for T3 (third time instant) = operational conditions of RAN 110 when first xApp 120A implemented on RAN 110 conflicts with second xApp 120B; operational data 241D for T4 (fourth time instant) = operational conditions of RAN 110 when metrics are affected by first xApp 120A and / or second xApp 120B implemented on RAN 110; operational data 241E for T5 (fifth time instant) = operational conditions of RAN 110 when operation of first xApp 120A is terminated on RAN 110, etc. Thus, as a function of the operation of terminating xApp 120A- n , the operational conditions, etc. of RAN 110 can be returned to a previous state of operation by rollback component 248.

[0097] The interaction and operation of the respective components are represented by step operations (1) - (3), as further described.

[0098] At (1), one or more xApps 120A- n are being submitted for loading / implementation on RAN 110 via connection 233. In an example embodiment, loading component 210 can be configured to receive xApp 120A (e.g., first xApp) where xApp 120A- n is desired to be deployed on RAN 110. Loading component 210 can be configured to examine xApp 120A- n to determine one or more characteristics (e.g., operational characteristics, e.g., in data 121A) of xApp 120A. Loading component 210 can also be configured to compare one or more characteristics of xApp 120A with information (e.g., data 121B- nThe loading component 210 is compared to determine whether RAN 110 can support one or more features of xApp 120A. In one embodiment, in response to determining that RAN 110 can support one or more features of xApp 120A, the loading component 210 can be configured to approve the loading of xApp 120A for subsequent deployment of xApp 120A. In another embodiment, in response to determining that RAN 110 cannot support one or more features of xApp 120A, the loading component 210 can be configured to reject the loading of xApp 120A.

[0099] At (2), before deploying the first xApp (e.g., xApp 120A), the first xApp can be checked for any potential negative interactions with other xApps 120A-n that can be deployed on RAN110. As shown, the subscription management component 220 can be configured to interact with xApp 120A-n. n (e.g., via connection 280), conflict management component 230 (e.g., via subscription bootstrapping connection 282), RAN 110 / E2T 370 (e.g., via connection 284), and / or subscription database 260 (e.g., via connection 286). Before deploying xApp 120A, the corresponding characteristics of xApp 120A (e.g., data 121A) can be linked to xApp 120B stored in subscription database 260. n The corresponding features (e.g., data 121B-) n Comparison, where xApp 120B- n It can be currently deployed or previously deployed on RAN 110. The corresponding action / confirmation can be communicated via alarm / warning 236A-n.

[0100] At (3), the corresponding xApp 120A- has been deployed here. n Thus, the conflict detection component 240 can be configured to detect conflicts with the corresponding xApp 120A- n One or more interactions between them and further information about the corresponding xApp 120A- n To monitor and evaluate the operational impact on system components (such as RAN 110) of xApp 120A- n The operation. In this embodiment, the collision detection component 240 can monitor the xApp 120A- n Multiple interactions between RAN 110 and E2T 270, as shown by control / command (CTRL / CMD) connection 290. Furthermore, collision detection component 240 can also monitor interactions originating from RAN 110 (and E2T 270) with xApp 120- ninteractions, as shown by KPM / EVENT connector 292. Further, KPMs 145A- n may be received at conflict detection component 240 from RAN 110 (and E2T 370), as shown by KPM connector 294. Conflict detection component 240 can interact with conflict management component 230 through conflict xApp detection connection 296. The respective actions / determinations can be communicated through alerts / warnings 236A- n .

[0101] 4. Co-deployment and application priority

[0102] In embodiments, conflict management component 230 can be configured to control one or more xApp 120A- n interactions with components / parameters. In embodiments, conflict management component 230 can be configured to determine that a first xApp 120A interacts with a component / parameter (e.g., target 212A), and in addition, a second xApp 120B also interacts with the same component / parameter. Conflict management component 230 can be configured to utilize Application Priority priority features. In embodiments, 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 embodiments, the priority settings can be configured (e.g., as utility metrics) as part of the programming of the xApps 120A- n , deployment settings can be configured at deployment and applied to the xApps 120A- High Priority , etc. Accordingly, conflict management component 230 can be configured to, for example, when receiving the first xApp 120A with a Low Priority High Priority metric and the second xApp 120B with a Low command when xApp 120A issues a command, prevent Priority APP Category xApp 120B from issuing command(s) for a certain time interval.

[0103] Conflict management component 230 can also be configured to adjust the xApp 120A- n subscriptions to avoid the control actions of the conflict implemented by the respective xApp 120A- n . Co-deployment rules are not limited to priority evaluation and subscription adjustment, and can also train ML-based models (e.g., in process 245 in conflict detection component 240) to provide intervention commands to E2 nodes (e.g., in E2T 270), e.g., CUs 117, DUs 118, RUs 119, etc.

[0104] 5. Precaution - Example

[0105] Precaution avoids implementing xApps 120A- n with functionally conflicting or overlapping. Precaution allows the operator to determine the deployment strategy in such xApps 120A- n . In a regular O-RAN system, specific implementation solutions for xApps 120A- n may not be available to the RIC 150 and / or the conflict management component 230. According to various embodiments presented herein, the application of precaution can involve (e.g., to the RIC 150) defining a set of criteria to obtain a high-level understanding of one or more functions of the xApp 120A- n .

[0106] 5.1. Criteria

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

[0108] Target KPI Category and Subcategory : including but not limited to use cases defined by O-RAN.

[0109] Coverage, Capacity, Energy : KPI 140A- n categories include Coverage and so on. KPI 140A- Accessibility KPI related to n can include features such as accessibility, retention, mobility, and so on.

[0110] a) Retainability KPI — Tracking whether a user can access a requested service and the quality of service available.

[0111] b) Mobility KPI — Measuring whether the network is able to maintain the network service promised to the user, e.g., drop rate, service drop rate.

[0112] c) Capacity — Measuring the performance of the network during the movement of the user throughout the network, e.g., handover success.

[0113] Number of Users, Number of Data Radio Bearers (DRBs), Spectrum Efficiency, Channel Utilization KPI 140A- n related to Energy Power Saving, Transmission Reception Point (TRP) Power, Distributed Unit / Centralized Unit (DU / CU) Power Consumption and so on. Moreover, Control Level KPI 140A- n related to Control Type Indirect and so on.

[0114] Implicit : For each xApp 120A- n , the control level can be categorized as user-level actions and / or aggregated level (e.g., cluster, site, sector, cell, slice, etc.) configuration.

[0115] Figure 3 : The criteria include a list of RAN 110 control (RC) actions, a list of RAN 110 parameters, and so forth.

[0116] The aforementioned criteria can be provided to the RIC 150 by the xApp 120A- n , e.g., during the onboarding process (e.g., as data 121A at the onboarding component 210). The conflict management component 230 can utilize the criteria provided by the xApp 120A- n to initiate rule-based conflict mitigation strategies (e.g., priority assessment based on utility metrics, subscription adjustment, and so forth, as described herein). A non-limiting list of example conflict mitigation strategies will be provided below in 8.3 Conflict Management.

[0117] 6. Reaction Measures - Examples and Operations

[0118] As mentioned, due to the potential complexity of interactions between deployed xApps 120A- n , post-action verification can require targeted ML and AI solutions (e.g., implemented via the process 245 at the conflict detection component 240, as further described), to identify Figure 1 and Figure 2 conflicts. In embodiments, conflicts between xApps 120A- n may be detected at the RIC 150, e.g., as a function of performance observations (e.g., KPIs 140A- n ).

[0119] To access observations at the RIC 150, the CMS 130 can be configured to monitor the performance of the RAN 110, thereby enabling the RIC 150 to act as an “xApp-agnostic” observer on the outcomes of the xApps 120A- n . The RIC 150 can be configured to determine when changes in the KPIs 140A- n are caused by adverse effects of the xApps 120A- n , and when they are caused by natural shifts in the performance of the RAN 110 that are independent of the xApps 120A- n . For example, when traffic changes at the RAN 110, the KPIs 140A- nChanges in the baseline behavior of the RAN 110 can naturally arise / migrate from current RAN 110 control algorithms, accordingly, such natural changes should be identified and understood to determine changes in the baseline behavior of the RAN 110.

[0120] Turning to Figure 3 , the flowchart 300 presents various stages in determining xApp conflicts and rollbacks, in accordance with one or more embodiments. In embodiments, the example scenario represents an xApp 120A- n that has been deployed for operation on the RAN 110. Figure 3 that changes the scenario (2) and (3) in the RAN 110, Figure 3 that changes the scenario (2) and (3) in the RAN 110).

[0121] At Figure 3 (1), the first xApp 120A can generate a control message 310, where the control message 310 is configured with commands / data (e.g., data 121A) to change one or more operational parameters (e.g., KPI 140A- n ) at the RAN 110.

[0122] At Figure 2 (2), the CMS 130 can check the respective features at the RAN 110 that the xApp 120A is configured to change (e.g., data 121A). Based on a comparison with operational data (e.g., in data 121B- n ) about current operations and previously implemented xApp 120B- n stored in the xApp information database 250, the xApp onboarding component 210 can determine whether the xApp 120A will generate a conflict. In the event that a conflict is determined to be possible, the xApp onboarding component 210 can reject onboarding of the xApp 120A. Alternatively, in the event that the xApp onboarding component 210 does not detect any conflicts (e.g., direct or indirect conflicts), the xApp 120A can be onboarded / implemented on the RAN 110.

[0123] At Figure 3 (3), the CMS 130 can forward the control message 310 to the component(s) that the control message 310 is related to, e.g., at the RAN 110, at the E2 node 115 (e.g., DU 118). The CMS 130 can also be configured to monitor the operation of the component(s) that the control message 310 is related to (e.g., at the RAN 110, at the E2 node 115 (e.g., DU 118)) via one or more KPI 140A- n / KPM 140A- n .

[0124] At Figure 3 (4), in the example scenario, the E2 node 115 can report the current state of the E2 node 115 via one or more KPIs 140A- n of the current state of the RAN 110 to the conflict detection component 240). The CMS 130 (e.g., conflict detection component 240) can be configured to receive the KPIs 140A- Figure 4 In an embodiment, the KPIs 140A can indicate that the operation of the KPIs 140A has deteriorated (e.g., a threshold degradation 231A- n has been triggered, e.g., as compared to the data 121B- n and / or previously measured KPIs 140A- n / KPMs 150A- n stored in the database 260), which indicates that a conflict has occurred between the operation of the xApp 120A and the operation of at least one other xApp 120B- n operating on the RAN 110. In another embodiment, the operation degradation can occur at one or more components of the RAN 110, the KPIs 140A- n / KPMs 150A- n reflect the current and / or previous operation of the RAN 110. n

[0125] At Figure 2 (5), based on the determined conflict between the xApp 120A and at least one other xApp 120B- n operating on the RAN 110, the conflict management component 230 can be configured to issue a rollback command 320 that indicates any one of: (a) terminating the operation of the xApp 120A, and additionally, (b) rolling back the operation of the RAN 110 to an operational condition in which the KPIs 140A- n are operating as expected (e.g., prior to the xApp 120A implementation), e.g., the RAN 110 and / or the E2 node 115 are not in degraded operation. The rollback component 248 can be configured to receive the rollback command 320 and return the RAN 110, etc., to the previous operational condition, e.g., where the rollback component 248 can be configured to examine the operational data 241A- n to identify the previous operational condition, as previously described.

[0126] At Figure 2 ​(6) The conflict management component 230 can also be configured to generate an alarm 236A detailing the current situation, such as the termination of xApp 120A's operation and the rollback of RAN 110's operation to its previous state. Alarm 236A can be transmitted to an external system via I / O 186 and can be used to update operational data in the xApp information database 250 and / or subscription database 260.

[0127] like Figure 2 As shown, system 400 presents an xApp conflict management system according to an embodiment. System 400 may include a conflict detection component 240, which includes a performance management (PM) engine component 420 communicatively coupled to a conflict detection sub-component 430, which in turn is communicatively coupled to a conflict xApp detection component 440. Inputs to the conflict detection component 240 may include KPI 140A- n And KPM 150A- n (For example, according to) Preventive Connector 294 in xApp120A- n CRTL / CMD (e.g., according to Reaction Connector 290 in the middle), and xApp 120A- n Descriptor information (e.g., directly from xApp 120A- n The extracted data 121A-n and / or xApp 120A data from information database 250. The conflict detection component 240 may also include a process 245, which can be utilized by any component of the PM engine component 420, the conflict detection sub-component 430, and the conflict xApp detection component 440 (and any component in CMS 130). Process 245 may include operations, functions, workflows, etc., and is configured to detect xApp 120A- n Conflict detection can be achieved through either ML or AI technologies / technologies. Based on the corresponding inputs to the conflict detection component 240, and the operations of the PM engine component 420, the conflict detection sub-component 430, and the conflict xApp detection component 440, the conflict detection component 240 can generate one or more detected conflict xApp120A- n Examples of such instances, and any natural changes that occur during the operation of RAN 110.

[0128] Process 245 may include one or more recurrent neural network (RNN) models that can be used to determine KPI 140A- n The changes in the middle are due to multiple xApp 120A- nIs the conflict caused by the conflict between them, or by a change in the operating environment of RAN 110 (e.g., natural changes) that affects multiple xApp 120A- n The interactions between them are independent. The RNN model in process 245 can also be used to predict KPIs 140A- n The performance change is due to the collision detection performed by the collision detection component 240. The RIC 150 can be configured to establish xApp 120A- n The correlation between actions and changes in the operational performance of RAN 110. When multiple xApp 120A- n Acting on the same target (e.g., according to) Rule-based Conflict Resolution When the target is 212A, the forecast for KPI 140A- n The impact can be a very complex task, and prediction is suitable for implementing one or more ML techniques in process 245.

[0129] Based on xApp 120A- n The estimated correlation between actions and performance changes in RAN 110, RIC 150 can identify xApp 120A- that leads to the opposite performance direction. n To train a suitable ML solution for detecting conflicts in process 245, the xApp 120A- n The classification information can be obtained from the above input: KPI 140A- n And KPM 150A- n xApp120A- n CRTL / CMD, xApp 120A- n Descriptor information (e.g., data 121A-) n )etc.

[0130] 7. Conflict Management—Examples and Practices

[0131] Conflict management involves ML-based Conflict Resolution measures and Rule-based Conflict Resolution Strategy Measures. The main aspects of both preventative and reactive measures are conflict prediction and conflict detection, respectively. Sections 2.1 and 5 of the preventative measures section present various examples of rule-based conflict management solutions, where the conflict management solution can be implemented after a conflict has been detected (xApp 120A-). n It was then executed. ML-based Conflict Resolution Strategy and Dimensioning (For example, using process 245) Two types of solutions are further presented and can be used as preventive and / or reactive measures.

[0132] 7.1. When xApp 120A-n Subscription adjustments can be utilized when resolving conflict issues without degrading performance (e.g., KPI 140A- n . Restrictive Framework

[0133] Rule-based conflict resolution policy examples can be expressed as a sequence of the following actions / steps:

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

[0135] 2. Provide a suggestion to adjust the xApp 120A- n ;

[0136] 3. Adjust the xApp 120A- n subscription to avoid conflicting control actions / subscription steering; and

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

[0138] 7.2. Figure 4 may be complex and can require sophisticated interactions by the process 245. These methods can be used to prevent or limit situations / cases where a particular xApp 120A- n may degrade the performance of the RAN 110 and / or KPI 140A- n . With ML-based conflict resolution policies, conflict resolution rules are not limited to priority evaluation and subscription adjustment, so a ML-based model (e.g., process 245) can be trained to provide intervention commands to the E2 node 115.

[0139] 8. Example Embodiments

[0140] 8.1. Preventive Measures

[0141] The following provides an example on-boarding procedure for xApps 120A- n . The following procedure can mitigate the chances of direct conflict(s) between newly on-boarded xApps 120A- n and currently subscribed xApps 120A- n . The respective xApps 120A- n may provide various information / criteria (e.g., as described in Section 5.1) during the on-boarding procedure (e.g., on-boarding to the RIC 150) of the xApps 120A- n and the RAN 110.

[0142] The following can be utilized by the xApps 120A-​n information (e.g., data 121A- n ) extracted by the onboarding component 210) is compared with the current xApp 120A- n subscribed (e.g., in the subscription database 260 and / or the xApp information database 250) to ensure consistency of operation, and any xApp 120A- n that is inconsistent with the current xApp 120A- n is rejected for subscription request. The subscription database 260 can include information structures (e.g., in data 121A- n ) for xApps 120A- n deployed on the RAN 110. When a first xApp (e.g., xApp 120A and data 121A) is presented for subscription, information (e.g., data 121B- n ) stored in the subscription database 260 about 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 consistency of information provided by the first xApp (xApp 120A). In case (e.g., by the subscription management component 220, the conflict management component 230) determines that the deployed xApp 120A- n can support implementation of the xApp 120A, the xApp 120A can be subscribed. In case (e.g., by the subscription management component 220, the conflict management component 230) determines that the deployed xApp 120A- n does not support implementation of the xApp 120A / there can be a conflict with it, (e.g., by the onboarding component 210 or the conflict management component 230) can reject the xApp 120A for subscription / implementation on the RAN 110. By utilizing known information (e.g., historical data 121A- n ) about deployed xApps 120B- n to check information / requirement(s) of the xApp 120A, a fast check of the xApp 120A is achieved, which enables the various embodiments presented herein to be applicable for real-time and near real-time implementation at the RIC 150.

[0143] xApp 120A- n may use the API of the RIC 150 to access information elements (EIs) of the associated E2SM (E2 Service Model). The RIC 150 provides an API that is decoupled from a particular implementation solution. Further, the xApp 120A- n may provide a descriptor (e.g., in any data 121A- nThe descriptor includes configuration, control (control level and type), target KPI 140A- n categories and subcategories, and xApp classification. The descriptor data provides the necessary data to enable management of the xApp 120A- n (e.g., xApp 120A) based on comparing operational data (e.g., data 121A) of the first xApp (e.g., xApp 120A) with (i) operational data (e.g., data 121B) of a second xApp (e.g., xApp 120B) previously or currently deployed, or (ii) operational data (e.g., data 121B- n ) of multiple xApps (e.g., xApp 120B- n ) previously or currently deployed, including subscription management, conflict management, and orchestration.

[0144] The proposed embodiments enable Figure 5 the number of xApps 120A- n targeted to the same class / KPI 140A- n category. The use of scale control reduces the likelihood of unhandled conflicts due to the co-deployment of xApps 120A- n .

[0145] To mitigate potential conflicts, the onboarding component 210 and / or the subscription management component 220 can utilize Figure 6 Figure 5 so that the onboarding component 210 and / or the subscription management component 220 limit the selection range, rather than letting the xApps 120A-n freely select all information. With the restrictive framework approach, the onboarding component 210 and / or the subscription management component 220 can specify, based on the xApp 120A- n classification, a list of target KPIs 140A- n for the xApp 120A- n to select from; and it can also specify, based on the target KPI 140A- n , a list of allowed actions for the xApp 120A- to select from.

[0146] 8.2. Reaction Measures

[0147] A further description of the structure and operation of the conflict detection component 240 is presented below. The conflict detection component 240 can be utilized in implementing reaction measures. In an embodiment, to perform a reaction measure, first the conflicting xApps 120A- nwherein the conflict detection component 240 and / or the conflict management component 230 subsequently implement various rule-based and ML-based conflict mitigation strategies, as previously mentioned in Section 7.

[0148] As previously mentioned, in accordance with Figure 7 , the conflict detection component 240 can include a PM engine component 420 for performance change prediction to implement conflicts based on the KPIs 140A- n and predicted KPIs 140A- n observed at the conflict detection component 240 (e.g., as KPMs 150A- n ) to identify xApps 120A- n that cause adverse performance. Figure 6 , the system 500 provides a structural framework for the PM engine component 420. The PM engine component 420 can be configured to utilize the processes 245 to use previous KPMs 150A- n , implemented xApp 120A- n control commands, and xApp 120A- n descriptor information (e.g., in the data 121A- n ) (including proposed criteria (e.g., 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 420 and used as a baseline behavior (e.g., by the conflict management component 230) to detect any potential performance degradation caused by conflicts between xApps 120A- n .

[0149] ML-based Resolution Strategy , the system 600 presents a high-level structure of the conflict detection subcomponent 430 in accordance with embodiments. As Reference Action Space shown, the predicted KPIs 140A- n and observed KPIs 140A- n can be input into the conflict detection subcomponent 430, whereby the conflict detection subcomponent 430 can be configured to determine whether there are any conflicts between xApps 120A- n that have been accepted for deployment and / or are currently being deployed on the RAN 110. Any potential correlations between the set of provided predicted KPIs 140A- n and observed KPIs 140A- n can be identified by one or more ML models in the processes 245, and from which xApps 120A- nwhether there is a conflict between xApps 120A, and an estimate of any degradation in KPIs 140A caused by conflicts between xApps 120A n . Any identified performance degradation in KPIs 120A n can be utilized by the conflict management component 230.

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

[0151] 8.3. Conflict Management

[0152] For Figure 9 , any suitable ML technique such as a reinforcement learning (RL) model can be utilized at process 245. One or more RL models can be configured to pick control commands that result in the highest performance of KPIs 140A n . In an example RL model implementation, Figure 10 can be defined as a union of the conflict xApp 120A n list of proposed actions. Figure 11 is set to a weighted function of target KPIs 140A n of the conflict xApp 120A n . The target KPIs 140A-n may be based on policies implemented by the operator of the RAN 110, defined utility functions, etc.

[0153] An example of an RL-based mitigation algorithm framework can be provided as follows:

[0154] 1. Define the state space as the idle / active state of the conflicting xApps 120A- n defined as xApp and its associated target KPI 140A- n values:

[0155] ,

[0156] where is the target KPI value of xApp and is the idle / active state indicator of xApp at time t , V is the set of conflicting xApps (e.g., xApp 120B- n conflicting with xApp 120A).

[0157] 2. Define the reference action space as the union of the conflicting xApp list of proposed actions:

[0158] ,

[0159] where is the proposed action of xApp at time t .

[0160] 3. Set the reward as a weighted function of the target KPI 140A- n of the conflicting xApps based on the operator’s policies or defined utility functions:

[0161] ,

[0162] where is the reward value at time t .

[0163] 4. Implement any suitable ML (e.g., reinforcement learning (RL), such as a deep Q network (DQN) method) (e.g., in process 245) to find the action that maximizes the reward.

[0164] For all conflicting xApps 120A- nwhose action spaces are logical actions (e.g., turn on / off, decrease / increase steering, etc.) can modify the aforementioned methods / techniques to improve overall performance. Accordingly, the action selected from the winner xApp (e.g., xApp 120A- n ) can be different from the proposed action by that particular xApp (e.g., xApp 120A- n ). In embodiments, the conflict management component 230 can be configured to select a logical action from the allowed action list that is opposite the proposed action of the winning xApp (e.g., xApp 120A).

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

[0166] i) Define the state space as the idle / active status of the conflicting xApps 120A- n , the target KPI 140A- n values, and the proposed action of each xApp 120A- n . The following utilizes the terms:

[0167] ,

[0168] where is the target KPI 140A- value for xApp n , is the idle / active status indicator for xApp , is the proposed action for xApp at time t , and V is the set of conflicting xApps.

[0169] ii) Define the reference action space as the union of the allowed action lists of the conflicting xApps:

[0170] ,

[0171] where is the set of allowed actions for xApp at time t .

[0172] As mentioned, various processes 245 can be configured to address two or more xApps 120A- nThe process involves determining information and making predictions based on operational conflicts. As previously mentioned, process 245 may include AI, ML, and inference technologies / systems that employ probabilistic and / or statistical analysis to predict or infer actions that the user expects to perform automatically. The various embodiments presented herein can utilize various ML-based approaches to implement their aspects, such as potential conflicts between the first xApp 120A and the second xApp 120B, and further, corresponding xApp 120A implemented on RAN 110. n Conflicts between them, as mentioned, can be facilitated by automatic classifier systems and processes.

[0173] As used herein, the terms “prediction,” “inference,” “reasoning,” “determination,” etc., generally refer to the process of reasoning or inferring the state of a system, environment, and / or user based on a set of observations captured via events and / or data. For example, reasoning can be used to identify specific contexts or actions, or it can generate probability distributions over states. Reasoning can be probabilistic—that is, calculating probability distributions over states of interest based on considerations of data and events. Reasoning can also refer to techniques used to construct higher-level events from sets of events and / or data. Such reasoning enables the construction of new events or actions based on sets of observed events and / or stored event data, regardless of whether these events are closely related in time or whether the events and data originate from one or more event and data sources.

[0174] In the various embodiments presented herein, CMS 130 can be derived from xAPP 120A- n Obtain information about the corresponding xAPP120A- n Operational data configured for control / adjustment, such as parameters, metrics, and use cases (e.g., data 121A-). n KPI140A- n KPM 150A- n Process 245 may include AI, ML, and inference technologies / systems that employ probabilistic and / or statistical analysis to predict or infer actions that the user expects to perform automatically. The various embodiments presented herein can utilize various ML-based approaches to implement their aspects; for example, as previously mentioned herein, automatic classifier systems and processes can facilitate the determination of xAPP120A- n The existence of conflict between them.

[0175] A classifier is a function that takes an input vector of attributes as input. x = ( x 1, x 2, x 3, x 4, xn ) mapped to a class label class( x ). The classifier can also output a confidence that the input belongs to a certain class, i.e., f( x ) = confidence(class( x )). Such classification can employ probabilistic and / or statistical-based analysis to determine or infer a user's desire to have an action performed (e.g., a conflict resolution solution between xApps 120A- n ).

[0176] Support Vector Machines (SVMs) are an example of classifiers that can be employed. SVMs operate by finding a hyperplane in the space of possible inputs that optimally separates the triggering input events from the non-triggering events. Intuitively, this makes the classification correct for testing data that is near, but not exactly on the training data. Other directed and undirected model classification approaches include, e.g., naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, and probabilistic classification models providing different patterns of independence can be employed. The classification approach used in this document includes statistical regression that is utilized to develop predictive models of priority.

[0177] As can be readily appreciated from this specification, 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 can be 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, e.g., whether there is an operational conflict, performance of KPI 140A- n , operational goals of respective xApps 120A- n , direct conflicts, indirect conflicts, implicit conflicts, etc., in accordance with predetermined criteria.

[0178] As described above, inferences can be made and actions performed based on a large amount of information. For example, information / data (e.g., data 121A- n ) regarding implementation of xApps 120A- n , historical usage, predicted usage, etc., as the operation of xApps 120A- n continues, analysis can be implemented to determine a convergence pattern, such that potential conflicts between respective xApps 120A- n can be inferred.

[0179] ClassFIG. illustrates a method 800 for determining whether an operational conflict occurs by implementing an xApp on a RAN, in accordance with one or more embodiments described herein.

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

[0181] At 820, the first xApp can be configured to provide first information (e.g., data 121A) to an on-boarding component (e.g., on-boarding component 210). The first information can detail which parameter, use case, metric, KPI (e.g., any of KPIs 140A- n - the first xApp is being deployed to adjust, etc.

[0182] At 830, in embodiments, other information can be obtained (e.g., by on-boarding component 210) from other xApps (e.g., xApps 120A- n - are presented for on-boarding, are on-boarded, deployed, etc.), where the other information can be stored (e.g., by on-boarding 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.

[0183] At 840, the first information can be compared to operational configuration information of the RAN to determine whether the RAN supports the xApp. In embodiments, the operational configuration information for the RAN can be derived from respective xApps that are currently deployed / were previously 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 thereon, it can be determined what the RAN can support based on information about which other xApps (e.g., data 121B- n） - were rejected from on-boarding (e.g., by on-boarding component 210). In a case where it is determined that the RAN cannot support the first xApp (NO), the method 800 can proceed to 845, where the first xApp can be rejected from on-boarding (e.g., by on-boarding component 210). At 847, a warning group (e.g., warning component 235) can generate a warning (e.g., warning 236A- n) to notify entities such as network operators that the onboarding of the first xApp was rejected. At 848, the database (e.g., databases 250 and / or 260) can be updated (e.g., by onboarding component 210) with respective information (e.g., data 121A) regarding the first xApp being rejected for onboarding.

[0184] At 840, in the event that the RAN is determined (e.g., by onboarding component 210) to be able to support the first xApp, the method 800 can proceed to 850. At 850, the 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, the first information (e.g., data 121A) of the first xApp (e.g., xApp 120A) can be compared to the second information (e.g., data 121B) of the second xApp (e.g., xApp 120B) to determine whether a conflict exists.

[0185] At 860, 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. In the event that a conflict exists (YES), the subscription of the first xApp to the RAN can be rejected, with the method 800 returning to 845 as previously described, where the warning(s) and the database can be configured to convey the conflict between the first xApp and the second xApp.

[0186] At 860, in the event that a conflict is determined (e.g., by conflict management component 230) not to exist between the first xApp and the second xApp, the method can proceed to 870, where the first xApp can be onboarded onto the RAN (e.g., by subscription management component 220). The method 800 can return to 847 as previously described, where in embodiments an indicator (e.g., alert 236A- n ) can be generated and transmitted (e.g., by warning component 235), and further, at 848, the database (e.g., databases 250 and / or 260) is updated (e.g., data 121A- n ) to indicate that the first xApp was onboarded / deployed / implemented without a conflict between the first xApp and the second xApp. It should be noted that the actions performed at steps 847 and 848 can be performed by any of the operations presented in this application, for example, notifications and update / storage operational data can be generated at any of the events that can occur in the RAN 110, nodes 115, CMS 130, RIC, SMO 135, O-cloud 160, E2T 270.

[0187] Figure 12 FIG. 9 illustrates a method 900 for determining whether an operational conflict occurs by implementing an xApp on a RAN, in accordance with one or more embodiments described herein.

[0188] As previously described, at 910, 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 detail which metric, parameter, use case, KPI (e.g., any of KPIs 140A- n), and / or the like (e.g., target 212A) the first xApp is being deployed to adjust. n

[0189] At 920, a 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 second information can detail which metric, parameter, use case, KPI (e.g., any of KPIs 140A-n), and / or the like the second xApp is being deployed to adjust.

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

[0191] At 930, the existence of a conflict and the magnitude of the 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 implementing the first xApp would detrimentally affect the operation of the second xApp with respect to controlling the common target, it can be further determined (e.g., by the conflict component) whether the first xApp and the second xApp can coexist. In the event that the conflict would result in the second xApp being unable to effectively control the common target, the method 900 can proceed to 940, whereupon (e.g., by conflict management component 230) the first xApp can be rejected from being implemented on the RAN. At 945, a database (e.g., in databases 250 and / or 260) can be updated (e.g., by onboarding component 210) with respective information (e.g., data 121A, information about the respective conflicting xApp 120A- n, and / or the like) about the first xApp being rejected from onboarding. n

[0192] ​​At 930, in case 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, the method 900 can proceed to 950.

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

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

[0195] At 970, the first xApp and the second xApp can be implemented on the RAN based on their respective first and second priorities. In an embodiment, when there is information related to the first metric at the RAN, the first xApp can be operated using the first priority; otherwise, the second xApp with the lower priority can be implemented. In another embodiment, the first and second priorities can be established based on time. For example, the first xApp is configured to operate for a first duration, and then the second xApp is configured to operate for a second duration.

[0196] At 980, with the first xApp implemented based on the first priority, the duration of the operation of the first xApp can be monitored. In case the duration of the first implementation has not expired, the method 900 can return to 970 to further monitor the operation of the first xApp.

[0197] At 980, in case the duration of the first implementation has expired, the method 900 can proceed to 990 for implementing the second xApp with the second duration and the low priority.

[0198] At 995, with the second xApp implemented based on the second priority, the duration of the operation of the second xApp can be monitored. In case the duration of the second implementation has not expired, the method 900 can return to 990 to further monitor the operation of the second xApp. At 995, in case the duration of the second implementation has expired, the method 900 can return to 970 to re-implement the first xApp with the first duration.

[0199] Figure 13 FIG. 1 illustrates a method 1000 for determining whether an operation conflict occurs by implementing xApps on a RAN, according to one or more embodiments described herein.

[0200] As previously described, at 1010, 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 detail which metric, parameter, use case, KPI (e.g., any of KPIs 140A-n), etc. (e.g., target 212A) the first xApp is being deployed to adjust. n

[0201] At 1020, a second xApp (e.g., xApp 120B) can be configured to provide second information (e.g., data 121B) to the subscription management component (e.g., subscription management component 220). The second information can detail which metric, parameter, use case, KPI (e.g., any of KPIs 140A-n), etc. (e.g., target 212A) the second xApp is being deployed to adjust.

[0202] At 1025, implementation of the first xApp can be requested. The first metric to be adjusted by the first xApp can be compared (e.g., by conflict management component 230) to the second metric to be adjusted by the second xApp. In embodiments, the first metric and the second metric can have a common control target (e.g., target 212A).

[0203] At 1030, a determination can be made by a conflict component (e.g., conflict management component 230) of the existence of a conflict on the RAN (e.g., RAN 110). In the event that implementing the first xApp would have a detrimental impact on the operation of the second xApp with respect to controlling the common target, method 1000 can proceed to 1040, where implementation of the first xApp on the RAN can be denied (e.g., by conflict management component 230). At 1042, corresponding information about the conflict can be recorded (e.g., by a logging component in databases 250 and / or 260), such as information about one or more features controlled by the first xApp, one or more features controlled by the second xApp, the nature of the conflict, etc.

[0204] At 1030, in the event that it is determined that implementation of the first xApp will not negatively impact the control of the target by the second xApp, method 1000 can proceed to 1045. In embodiments, the first xApp and the second xApp can be considered distinct.

[0205] ​At 1045, the operation of the RAN can be checked based on the first and second xApps being co-deployed. As previously mentioned, direct conflicts between the co-operations of the xApps can be easily discerned, but indirect and implicit conflicts can be difficult to detect / identify. In embodiments, other metrics (e.g., a third metric) can be impacted by the operations of the first and second xApps. The operation of the third metric can be monitored to see if the third metric is negatively impacted by the co-deployment of the first and second xApps.

[0206] At 1050, a determination can be made as to the operation of the third metric, e.g., is the operation of the third metric worse compared to the previous situation where the first and second xApps were not co-deployed? In the event that the determination is that the co-deployment of the first and second xApps does not adversely impact the third metric, the method 1000 can proceed to 1055, whereupon the co-deployment of the first and second xApps can be maintained. The step / act 1055 can further return to 1045 for further / subsequent determinations as to whether the co-deployment of the first and second xApps impacts the operation of the RAN. Accordingly, the RAN can continuously monitor its operation to detect conflicts that can not exist when the first and second xApps are co-deployed, but over time, the conflicts develop / emerge.

[0207] At 1050, in the event that the determination is that the co-deployment of the first and second xApps does adversely impact the third metric (“yes”), the method 1000 can proceed to 1060 to determine the impact of the co-deployed first and second xApps (individually or in combination) on the third metric.

[0208] At 1065, in the event that the first and / or second xApps are not responsible for the poor operation of the third metric (“no”), the method 1000 can return to 1055 for further monitoring of the co-deployed first and second xApps, as previously mentioned.

[0209] At 1065, in the event that the first and / or second xApps are impacting the operation of the third metric (“yes”), the method 1000 can proceed to 1070, whereupon an analysis can be made by a conflict detection component (e.g., the conflict detection component 240) to adjust the operation of the co-deployed first and second xApps to isolate the respective impact of the first and second xApps on the third metric.

[0210] At 1075, in a case where it is determined that adjusting the first xApp and / or the second xApp can have an impact (e.g., a favorable one) on the third metric ("YES"), the method 1000 can return to 1055, whereupon the modified operation of the first xApp and / or the second xApp can be maintained.

[0211] At 1075, in a case where it is determined that adjusting the first xApp and / or the second xApp can have an impact (e.g., a favorable one) on the third metric ("YES"), the method 1000 can return to 1055, whereupon the modified operation of the first xApp and / or the second xApp can be maintained.

[0212] Figure 14 FIG. 11 illustrates a method 1100 for deploying xApps on a RAN based on KPI classes, in accordance with one or more embodiments described herein.

[0213] At 1110, the respective KPIs can be divided into Figure 14 such that each KPI can have its own class.

[0214] At 1120, to prevent an excessive number of xApps (e.g., xApps 120A- n ) from being assigned to a particular KPI (e.g., KPI 140A- n , such as a metric, use case, etc., and / or each of the targets 212A and 212B), each KPI can be assigned a maximum number of xApps that can operate on that KPI. Limiting the number of xApps that can be associated with a particular KPI can limit the likelihood of conflicts between xApps operating with that particular KPI.

[0215] At 1130, when an xApp is requesting onboarding (e.g., as part of a subscription), the KPI / metric (e.g., the first metric) that the xApp is interested in can be identified (e.g., in the data 121A) by the onboarding component (e.g., the onboarding component 210).

[0216] At 1140, it can be determined (e.g., by the onboarding component) whether the number of xApps that can be assigned to a particular KPI has been reached. For example, has the maximum number of xApps that can be assigned to the first KPI / metric been reached? In a case where it is determined that the maximum number of xApps for the first KPI / metric has been reached ("YES"), the method 1100 can proceed to 1150, whereupon the onboarding component can reject the xApp (e.g., xApp 120A) that is requesting onboarding. At 1152, details about the KPI class limit being reached can be stored (e.g., by the onboarding component) in a database (e.g., the databases 250 and / or 260).

[0217] At 1140, in a case where it is determined that the maximum number of xApps for the first KPI / metric has not been reached ("NO"), the method 1100 can proceed to 1160, whereupon the onboarding component can authorize the onboarding xApp (e.g., xApp 120A) to implement the RAN.

[0218] Figure 14 FIG. 13 illustrates a method 1300 for deploying an xApp on a RAN, in accordance with one or more embodiments described herein.

[0219] At 1210, one or more operating conditions of the RAN (e.g., RAN 110) or node (e.g., any of the nodes 115) can be recorded (e.g., by the rollback component 248). The one or more operating conditions (e.g., as operating data 241A- n ) can be stored (e.g., in the database 250 and 250) as previously described, e.g., at times T1, T2, T3, T4, T n , etc.

[0220] At 1220, a first xApp (e.g., xApp 120A) can be implemented on the RAN, node, etc., where the first xApp can be configured to control operation of a first control parameter, which can also be configured to control an operating characteristic of the RAN, node, etc.

[0221] At 1230, the operation of the RAN, node, etc. can be monitored and checked (e.g., by any of the CMS 130, subscription management component 220, conflict detection component 240, etc.) with the first xApp operation.

[0222] At 1240, in response to determining that the operation of the RAN, node, device, etc. is not degraded (NO), the method 1200 can proceed to 1250, where the implementation of the first xApp can be maintained for further operation monitoring / checking at 1230.

[0223] At 1240, in response to determining that the operation of the RAN, node, device, etc. is degraded (YES) (e.g., KPI 140A indicates degraded operation), the method 1200 can proceed to 1260, whereupon the operation of the first xApp can be terminated (e.g., by the conflict management component 230).

[0224] At 1270, rollback instructions (e.g., rollback instructions 320) can be generated and transmitted (e.g., by the conflict management component 230) to rollback the operation of the RAN, node, etc. to a previous operational state, e.g., prior to the implementation of the first xApp. Based on the rollback instructions (e.g., received and processed by the rollback component 248), the operational rollback can be performed (e.g., received and processed by the rollback component 248) with the operation returning from the current state (e.g., in the operational data 241A) to the previous state (e.g., in the operational data 241B) with the rollback instructions.

[0225] At 1280, the cause for the rollback can be identified (e.g., by the conflict management component 230 in conjunction with the rollback component 248) and stored (e.g., data 121A- n ), where the stored data can include information in the rollback instructions, the first xApp, the second xApp, timing, subscription information, determined conflicts, etc. The information / data stored at the time of the rollback can be used as historical data from which future implementations of xApps can be compared, e.g., during onboarding.

[0226] At 1290, a notification (e.g., alert 236A- n ) can be generated (e.g., by the alert component 235 under instructions from the conflict management component 230, the rollback component 248, etc.) and transmitted to one or more components, e.g., at the RAN, node, etc., to indicate that a rollback operation has occurred.

[0227] Figure 15 FIG. illustrates a method 1300 for deploying an xApp on a RAN, in accordance with one or more embodiments described herein.

[0228] At 1310, an onboarding request can be received by an onboarding component (e.g., at the onboarding component 210) to implement a first xApp (e.g., xApp 120A) on a RAN (e.g., RAN 110), a node (e.g., any of the nodes 115), or other system / device associated with the RAN (e.g., SMO 130, RIC 150, E2T 270, CMS 130, etc.).

[0229] At 1320, as part of the onboarding process, the first xApp can be examined (e.g., by the onboarding component) to identify / determine (e.g., in data 121A- n ) one or more control parameters / features / targets (e.g., targets 212A- n ) etc. that the first xApp is configured to control.

[0230] At 1330, the onboarding component can be configured to compare the control parameter in the first xApp to historical data (e.g., data 121B- n , operational data 241A- n , previous KPIs 140A- n , previous KPMs 150A- n , etc.) to determine previous operational history / interactions, compare to the control parameter, for example, to determine whether implementation of the first xApp can cause a conflict, and whether there is a previous rollback of an xApp 120A- n , etc. related to the control parameter. In checking the historical data, the onboarding component can be configured to access a data store (e.g., any of databases 250 / 260). In embodiments, the historical data can be generated by components / devices included in the RAN, RIC, SMO, etc., as well as by one or more user devices interacting with the RAN and node elements (e.g., any of nodes 115).

[0231] At 1340, in response to, for example, a determination by the onboarding component that there is no previous history regarding a rollback or conflict related to the control parameter (NO), the method 1300 can proceed to 1350, whereby the first xApp can be implemented.

[0232] At 1340, in response to, for example, a determination by the onboarding component that there is previous history regarding a rollback or conflict related to the control parameter (YES), the method 1300 can proceed to 1360. Thereupon, for example, by the onboarding component, a rollback component (e.g., rollback component 248), a conflict management component (e.g., conflict management component 230), a subscription management component (e.g., subscription management component 230), etc., can determine whether implementation of the first xApp and how the first xApp would adjust / modify the control parameter would cause a conflict. At 1360, in response to a determination that the first xApp would not cause a conflict (NO), the method 1300 can return to 1350 for implementation of the xApp.

[0233] At 1360, in response to a determination that a conflict would occur if the first xApp were implemented (YES), the method 1300 can proceed to 1370, thereupon, for example, by the onboarding component, implementation of the first xApp can be rejected.

[0234] At 1380, rollback information / operational history data (e.g., data 121A- n , operational data 241A- n ) can be updated with the rejection of the onboarding of the first xApp and / or the successful implementation of the first xApp to maintain the historical data for future operational checks / subscription requests / onboarding requests, etc.

[0235] 9. Example use environments

[0236] Figure 15 FIG. illustrates an example wireless communication system 1400 according to one or more embodiments described herein. The example wireless communication system 1400 includes a communication service provider network(s) 1410, a network node 1431, and user equipment (UE) 1432, 1433. A backhaul link 1420 connects the communication service provider network(s) 1410 and the network node 1431. The network node 1431 can communicate with the UEs 1432, 1433 within its service area 1430. The dashed arrows pointing from the network node 1431 to the UEs 1432, 1433 represent downlink (DL) communication with the UEs 1432, 1433. The solid arrows pointing from the UEs 1432, 1433 to the network node 1431 represent uplink (UL) communication.

[0237] Generally, reference is made to ​ The non-limiting term “user equipment” can refer to any type of device capable of communicating with a network node 1431 in a cellular or mobile communication system 1400. The UEs 1432, 1433 can have one or more antenna panels with vertical and horizontal elements. Examples of UEs 1432, 1433 include target devices, device-to-device (D2D) UEs, machine type UEs or UEs capable of machine-to-machine (M2M) communication, personal digital assistants (PDAs), tablet computers, mobile terminals, smart phones, laptop installed equipment (LME), universal serial bus (USB) dongles implemented for mobile communications, computers with mobile capability, mobile devices such as cellular phones, laptops with laptop embedded equipment (LEE) such as mobile broadband adapters, tablets with mobile broadband adapters, wearable devices, virtual reality (VR) devices, head-mounted display (HUD) devices, smart cars, machine type communication (MTC) devices, augmented reality head-mounted displays, and the like. The UEs 1432, 1433 can also include IoT devices that communicate wirelessly.

[0238] In various embodiments, the system 1400 includes a communication service provider network(s) 1410 served by one or more wireless communication network providers. The communication service provider network(s) 1410 can include a "core network." In example embodiments, the UEs 1432, 1433 can be communicably coupled to the communication service provider network(s) 1410 via a network node 1431. The network node 1431 can communicate with the UEs 1432, 1433, thus providing connectivity between the UEs 1432, 1433 and a broader cellular network. The UEs 1432, 1433 can transmit transmission type suggestion data to the network node 1431. The transmission type suggestion data can include suggestions to transmit data via a closed loop multiple input multiple output (MIMO) mode and / or a rank 1 precoder mode.

[0239] The network node 1431 can have a cabinet and other protective enclosures, computing devices, antenna towers, and multiple antennas for performing various transmission operations (e.g., MIMO operations) and for directing / guiding signal beams. The network node 1431 can include one or more base station devices that implement features of the network node. Depending on the configuration and type of antennas, the network node can serve several cells. In example embodiments, the UEs 1432, 1433 can transmit and / or receive communication data to the network node 1431 via wireless links.

[0240] The communication service provider network(s) 1410 can facilitate providing wireless communication services to the UEs 1432, 1433 via the network node 1431 and / or various other network devices (not shown) included in the one or more communication service provider networks 1410. The one or more communication service provider networks 1410 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, the system 1400 can be or include a large-scale wireless communication network spanning multiple geographic regions. In accordance with this implementation, the one or more communication service provider networks 1410 can be or include wireless communication networks and / or various additional devices and components of wireless communication networks (e.g., additional network devices and cells, additional UEs, network server devices, etc.).

[0241] The network nodes 1431 can be connected by one or more backhaul links 1420 to one or more communication service providers' networks 1410. The one or more backhaul links 1420 can include wired link components, such as Tl / E1 telephone lines, Digital Subscriber Line (DSL) (e.g., synchronous or asynchronous), Asymmetric DSL (ADSL), fiber-optic backbones, coaxial cable, and the like. The one or more backhaul links 1420 can also include wireless link components, such as but not limited to line-of-sight (LOS) or non-line-of-sight (non-LOS) links, which can include air or deep space links (e.g., satellite communication links for navigation). In some embodiments, the backhaul links 1420 can be implemented via a "transport network." In another embodiment, the network nodes 1431 can be part of an integrated access and backhaul network. By building on many of the control and data channels / processes defined for providing access to UEs 1432, 1433, this can allow for easier deployment of dense, self-backhauling 5G cell networks in a more integrated manner.

[0242] The wireless communication system 1400 can employ various cellular systems, technologies, and modulation modes to facilitate radio communications between devices (e.g., UEs 1432, 1433 and network nodes 1431). 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 a UE operates using multiple carriers, such as LTE FDD / TDD, GSM / GERAN, CDMA2000, etc.

[0243] For example, the system 1400 can operate in accordance with any 5G, next generation communication technology, or existing communication technology, with the above list enumerating various examples. In this regard, various features and functions of the system 1400 are applicable where devices (e.g., UEs 1432, 1433 and network nodes 1431) of the system 1400 are configured to transmit wireless signals using one or more multi-carrier modulation schemes in which data symbols can be simultaneously transmitted 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., used interchangeably with) "multi-carrier system," "multi-cell operation," "multi-carrier operation," "multi-carrier" transmission and / or reception. It should be noted that some embodiments are also applicable to multi-RAB (radio bearer) on some carriers (i.e., simultaneous scheduling of data and voice).

[0244] In various embodiments, the system 1400 can be configured to provide and employ 5G or later wireless networking features and functionality. 5G wireless communication networks are expected to meet the exponentially growing data traffic demands and allow for gigabyte data speeds for millions of devices with near-zero (e.g., single-digit millisecond) latency. Compared to 4G, 5G supports more diverse traffic scenarios. For example, in addition to various types of data communications among regular UEs (e.g., cellphones, smartphones, tablets, PCs, TVs, smart TVs, AR / VR head-mounted displays (HMDs), etc.) supported by 4G networks, 5G networks can also be used to support data communications among smart cars associated with self-driving car environments, as well as machine type communications (MTC). Given the huge difference in communication requirements for these different traffic scenarios, the ability to dynamically configure waveform parameters based on traffic scenarios while preserving the advantages of multi-carrier modulation schemes (e.g., OFDM and related schemes) can provide significant contributions to the high-speed / large-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 accommodated in different sub-bands with the most suitable waveform and frequency ratio, thus improving the spectrum utilization for 5G networks.

[0245] To meet the application requirements for data centers, features of 5G networks can include increased peak bit rates (e.g., 20 Gbps), greater data capacity per unit area (e.g., higher system spectral efficiency - e.g., about 3.5 times the spectral efficiency of long-term evolution (LTE) systems), higher capacity allowing more devices to be connected simultaneously on the fly, lower battery / power consumption (which reduces energy and consumption costs), better connections regardless of where users are geographically, a greater number of devices, lower infrastructure development costs, and higher communication reliability. Thus, 5G networks can allow for tens of megabits per second data rates to be supported for tens of thousands of users; e.g., providing 1 Gbps (gigabits per second) rates simultaneously to tens of employees on the same office floor; supporting hundreds of thousands of concurrent connections to support massive sensor deployments; improved coverage; enhanced signaling efficiency; lower latency compared to LTE.

[0246] 5G access networks can utilize higher frequencies (e.g., > 6 GHz) to help boost capacity. Currently, most of the millimeter wave (mmWave) spectrum (spectrum bands between 30 GHz and 300 GHz) is yet to be fully utilized. Millimeter waves have short wavelengths, ranging from 9 millimeters to 1 millimeter, and these millimeter wave signals experience severe path loss, penetration loss, and fading. However, the short wavelengths at mmWave frequencies also allow for packing more antennas in the same physical dimensions, which allows for massive spatial multiplexing and high directional beamforming.

[0247] 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 was introduced in 3GPP and has been used, including with LTE, which is a multi-antenna technology that can improve the spectral efficiency of transmissions, thereby significantly increasing the overall data carrying capacity of a wireless system. The use of MIMO technology can improve millimeter wave communications and has been widely recognized as a potentially important component in access networks operating in 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 have been used in 5G systems.

[0248] To provide more context for the various embodiments described herein, ​ The following discussion of background art is intended to provide the

[0249] 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, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.

[0250] The embodiments illustrated herein can also 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.

[0251] Computing devices typically include a variety of media, which can include computer-readable storage media, machine-readable storage media, and / or communications media, as used herein, the terms "computer-readable storage media" and "machine-readable storage media" are used interchangeably with one another and include any available storage media that can be accessed by a computer or a machine, as opposed to a propagating signal per se. By way of example, and not limitation, computer-readable or machine-readable storage media can include volatile or non-volatile storage media, removable or non-removable storage media, erasable or non-erasable storage media, or a combination thereof. By way of example, and not limitation, computer-readable or machine-readable storage media can include volatile memory, such as random access memory (RAM), non-volatile memory, such as read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disk (DVD), blu-ray disk (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 medium that can be used to store desired information. In this regard, the terms "tangible" or "non-transitory" herein as applied to a storage device, memory, or computer-readable medium does not dictate that the method be implemented only on storage devices, memories, or computer-readable media lacking a transitory signal per se.

[0252] Computer-readable storage media includes, 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 disk (DVD), blu-ray disk (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 medium that can be used to store desired information. In this regard, the terms "tangible" or "non-transitory" herein as applied to a storage device, memory, or computer-readable medium should be understood not to be limited to only storage devices, memories, or computer-readable media that are non-transitory in nature, and does not abrogate the right to all standard storage devices, memories, or computer-readable media that are not solely propagating transitory signals per se.

[0253] 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 information stored by the media.

[0254] 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" means 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.

[0255] References ​The example environment 1500 for implementing various embodiments of the aspects described herein includes a computer 1502, which includes a processing unit 1504, a system memory 1506, and a system bus 1508. The system bus 1508 couples system components including, but not limited to, the system memory 1506 to the processing unit 1504. The processing unit 1504 can be any of various commercially available processors, and can include

[0256] The system bus 1508 can be any of various bus structures including a memory bus with or without a memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory 1506 includes ROM 1510 and RAM 1512. A basic input / output system (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, which BIOS contains the basic routines that help to transfer information between elements within the computer 1502, such as during startup. The RAM 1512 can also include high-speed RAM such as static RAM for caching data.

[0257] The computer 1502 further includes an internal hard disk drive (HDD) 1514 (e.g., EIDE, SATA), one or more external storage devices 1516 (e.g., a magnetic floppy disk drive (FDD) 1516, a memory stick or flash drive reader, a memory card reader, etc.), and an optical disk drive 1520 (e.g., which can read from or write to a CD-ROM, DVD, BD, etc.). While the internal HDD 1514 is illustrated as being within the computer 1502, the internal HDD 1514 can also be configured for external use in an appropriate chassis (not shown). Additionally, while not shown in the environment 1500, a solid state drive (SSD) can be used in addition to or in place of the HDD 1510. The HDD 1514, external storage device(s) 1516, and optical disk drive 1520 can each be connected to the system bus 1508 via an HDD interface 1524, an external storage interface 1526, and an optical drive interface 1528, respectively. The interface 1524 implemented for the external drive can include at least one or both of a Universal Serial Bus (USB) and / or an Institute of Electrical and Electronics Engineers (IEEE) 1594 interface technology. Other external drive connection technologies are also contemplated within the embodiments described herein.

[0258] The drives and their associated computer readable media provide nonvolatile storage of data, data structures, computer-executable instructions, and so forth for the computer 1502. For the computer 1502, the drives and

[0259] A number of program modules can be stored in the drives and RAM 1512, including an operating system 1530, one or more application programs 1532, other program modules 1534, and program data 1536. All or portions of the operating system, applications, modules, and / or data can also be cached in the RAM 1512. The systems and methods described herein can be implemented with various commercially available operating systems or combinations of operating systems.

[0260] The computer 1502 can optionally include analog front ends. For example, a hypervisor (not shown) or other middleware can emulate a hardware environment for the operating system 1530, and the emulated hardware can optionally differ from the hardware illustrated in FIG. 1. In such embodiments, the operating system 1530 can include one of a number of virtual machines (VMs) hosted at the computer 1502. Further, the operating system 1530 can provide a runtime environment for the applications 1532, such as a Java runtime environment or a.NET framework. A runtime environment is a consistent execution environment that allows the applications 1532 to run on any operating system that includes the runtime environment. Similarly, the operating system 1530 can support containers, and the applications 1532 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. ​

[0261] Further, the computer 1502 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 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 1502, for example, it can be applied at the application execution level or at the operating system (OS) kernel level, thereby enabling security at any code execution level.

[0262] ​A user can enter commands and information into the computer 1502 through one or more wire / wireless input devices, e.g., a keyboard 1538, a touch screen 1540, and a pointing device such as a mouse 1542. 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 visual movement sensor input device, an emotional or facial detection device, a biometric input device (e.g., fingerprint or iris scanner), and the like. These and other input devices are often connected to the processing unit 1504 through an input device interface 1544 that can be coupled to the system bus 1508, but can be connected by other interfaces such as a parallel port, an IEEE 1594 serial port, a game port, a USB port, an IR interface, a Bluetooth® interface, etc.

[0263] A monitor 1546 or other type of display device can also be connected to the system bus 1508 via an interface, such as a video adapter 1548. In addition to the monitor 1546, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0264] The computer 1502 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer(s) 1550. The remote computer(s) 1550 can be a workstation, a server computer, etc. A router can be used to connect the computer 1502 to the remote computer(s) 1550 by way of the LAN 1554 and / or the Internet 1556. The LAN and the Internet 1556 both employ logical connections from the computer 1502 through a wired and / or wireless communication medium.

[0265] When used in a LAN networking environment, the computer 1502 can be connected to the local network 1554 through a wired and / or wireless communication network interface or adapter 1558. The adapter 1558 can facilitate wired or wireless communication to the LAN 1554, which can also include a wireless access point (AP) disposed therein for communicating with the adapter 1558 in wireless mode.

[0266] When used in a WAN networking environment, the computer 1502 can include a modem 1560 or can be connected to a communications server on the WAN 1556 via other means, such as by an internet service provider (ISP) and can communicate with the WAN 1556 via the modem 1560. The modem 1560 can be internal or external, and a wired or wireless device that can be connected to the system bus 1508 via the input device interface 1544. In a networked environment, the depicted program modules or portions thereof can be stored in the remote memory / storage device 1552, which can be accessed by the computer 1502 via the network interface 1558. 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.

[0267] When used in a LAN or WAN networking environment, the computer 1502 can access cloud storage systems or other network-based storage systems in addition to, or instead of, the external storage device 1516 described above. Generally, a connection between the computer 1502 and a cloud storage system can be established over the LAN 1554 or WAN 1556, for example, by the adapter 1558 or the modem 1560, respectively. In connecting the computer 1502 to an associated cloud storage system, the external storage interface 1526 can manage storage devices provided by the cloud storage system by means of the adapter 1558 and / or the modem 1560, as it manages other types of external storage. For example, the external storage interface 1526 can be configured to provide access to cloud storage resources as if those resources had been physically connected to the computer 1502.

[0268] The computer 1502 is operable with any wireless devices or entities using any of a plurality of short or long range wireless communication protocols, including, without limitation, Bluetooth®, Wi-Fi, 3G, 4G, 5G, Zigbee, and WiMAX. Thus, the communication can be a one-way communication in which numerous devices or entities transmit information to the computer 1502 and / or a two-way communication in which the computer 1502 can transmit information to devices or entities.

[0269] The above description includes non-limiting examples of various embodiments. Of course, not all possible combinations of components or method steps can be described, and one of ordinary skill in the art can recognize that 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.

[0270] With respect to various functions performed by the above-described components, devices, circuits, systems, and the like, unless otherwise indicated, terms used in describing such components, including references to "means" are intended to refer to any structure (e.g., functional equivalents, etc.) that performs the described function of the component, in addition to the structure described. Furthermore, although a particular feature of the disclosed subject matter can have been disclosed with respect to only one of several implementations, such feature can be combined with one or more other features of the other implementations as can be desired and advantageous for any given or particular application.

[0271] The terms "exemplary" and / or "illustrative," as used herein, are intended to refer to examples, instances, or illustrations. Unless otherwise indicated, the subject matter disclosed herein is not intended to be limited to the examples disclosed in this section. 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 processes. Furthermore, the words "include," "has," "contains," and other similar words, when used in a "claim," are intended to be inclusive, in a manner similar to the way the term "comprising" is interpreted when used as an open transition word in a "claim." Additionally, the use herein of terms such as "include," "comprise," "have," "contain," and other similar words is not intended to exclude or preclude the presence of other elements or features.

[0272] The term "or," as used herein, is intended to mean an inclusive "or" rather than an exclusive "or." That is, unless specified otherwise, or as is clear from the context, the phrase "X employs A or B" is intended to mean that X employs A or B or both A and B. Moreover, the use of the term "a," as well as other singular terms such as "an" and "the," is not intended to exclude the presence of zero or more than one of the referenced element, unless otherwise specified or the context clearly indicates otherwise. For example, the term "a" is used herein to refer to one or more than one element, unless otherwise specified or the context clearly indicates otherwise.

[0273] As employed herein, the term "set" does not include an empty set, i.e., a set that has no elements. Thus, a "set" in the present disclosure includes one or more elements or entities. Likewise, the term "group" as utilized herein refers to a set of one or more entities. The terms "set" and "group" are used interchangeably herein.

[0274] The use of the terms "first," "second," "third," etc. to describe various elements in the claims are used merely for clarity and are not intended to or imply any temporal or chronological order to the described components. For example, a "first determination," a "second determination," and a "third determination" are not intended to or imply that the first determination should occur prior to the second determination, that the second determination should occur prior to the third determination, and so forth.

[0275] As used in this disclosure, 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 in execution that performs the functionality. 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, computer-executable instructions, a program, and / or a computer. By way of illustration, both an application running on a server and the server can be a component.

[0276] 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. 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. As 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 components. 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.

[0277] The term "facilitate" as used herein in the context of a system, device, or component "facilitating" one or more actions or operations, pertains to the nature of complex computing environments in which multiple components and / or multiple devices can be involved in some computing operations. 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 to obtain a final result, etc. In this regard, a computing device or component can facilitate an operation by playing any role in completing the operation. Thus, when operations of a component are described herein, it will be understood that if an operation is described as being facilitated by the component, the operation can also optionally be completed in cooperation with other computing device or component(s), such as but not limited to sensors, antennas, audio and / or visual output devices, other devices, etc.

[0278] 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.

[0279] Furthermore, terms such as "mobile device equipment," "mobile station," "mobile," "subscriber station," "access terminal," "terminal," "handset," "communication device," "mobile device" (and / or similar terminology) can refer to a wireless device utilized by a subscriber or mobile device of a wireless communication service to receive or convey data, control, voice, video, audio, games, or substantially any data stream or signaling stream. The foregoing terms are utilized interchangeably herein and with reference to the related drawings. Likewise, the terms "access point," "base station," "BS transceiver," "BS device," "cell site," "cell site device," "gNode B (gNB)," "evolved Node B (eNode B, eNB)," "Home Node B (HNB)," and / or the like, refer to a wireless network component or device that transmits and / or receives data, control, voice, video, audio, games, or substantially any data stream or signaling stream from one or more subscriber stations. The data and signaling streams can be packet-switched streams or frame-based streams.

[0280] Furthermore, the terms "device," "communication device," "mobile device," "subscriber," "customer entity," "consumer," "entity," and / or the like are used interchangeably herein. It should be understood that such terms can refer to human entities or automated components supported through artificial intelligence (e.g., a capacity to make inference based on complex mathematical formalisms supported by AI) that can provide simulated visual, audio, and / or olfactory interaction for the consumer as part of an AI-based service.

[0281] It should be noted that although various aspects and various embodiments are described herein in the context of 5G, O-RAN, or other generation networks, the disclosed aspects are not limited to 5G or O-RAN implementations and can be applied in other next generation network implementations, such as sixth generation (6G) or other wireless systems. In this regard, aspects or features of the disclosed embodiments can be applied to substantially any wireless communication technology. Such wireless communication technologies include Universal Mobile Telecommunications System (UMTS), Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), CDMA2000, Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single-Carrier FDMA (SC-FDMA), Discrete Fourier Transform Spread OFDM (DFT-spread OFDM), Filter Bank Multi-Carrier (FBMC), Zero Tail DFT-Spread OFDM (ZT DFT-s-OFDM), Generalized Frequency Division Multiplexing (GFDM), Fixed Mobile Convergence (FMC), Universal Fixed Mobile Convergence (UFMC), Unique Word OFDM (UW-OFDM), Unique Word DFT-Spread OFDM (UW DFT-Spread-OFDM), Cyclic Prefix OFDM (CP-OFDM), Resource Block Filter OFDM, and Wireless Fidelity (Wi-Fi), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), General Packet Radio Service (GPRS), Enhanced GPRS, Third Generation Partnership Project (3GPP), Long Term Evolution (LTE), 5G, Third 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 other Institute of Electrical and Electronics Engineers (IEEE) 802.12 technologies.

[0282] The description of the illustrative embodiments of the disclosure provided in this document describing the embodiments, including the descriptions in the abstract, is not intended to be exhaustive or to be limited to the precise form disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of the embodiments and examples. In this regard, while the subject matter has been described in connection with various embodiments and corresponding figures (if applicable), it should be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or additional functions of the disclosed methods without deviating from the spirit of the subject matter. Accordingly, the disclosed methods should not be limited to any single embodiment, but rather the general scope of the subject matter described in the appended claims.

Claims

1. A method comprising: The operation of a first control parameter is monitored by a device including a processor, wherein the first control parameter is configured to control the operation of a characteristic of a network device, the network device being part of a radio access network (RAN); as well as Based on a defined performance metric, the device detects a threshold degradation in the performance of the operation of the feature derived from the use of the first control parameter.

2. The method according to claim 1, further comprising: The device identifier is configured to perform a first operation of a first application (xApp) to adjust the first control parameter; The second operation of the second xApp, which is operated by the device identifier to adjust the first control parameter; as well as In response to determining that the conflict between the first operation and the second operation results in a harmful operation affecting the first control parameter: The device terminates the first operation of the first xApp, and The device rolls back the operation of the feature to a configuration stored prior to the implementation of the first xApp, wherein the first control parameter can be modified by the second operation of the second xApp.

3. The method according to claim 2, further comprising: The device identifier is used to implement the rollback adjustment of the operation of the feature, the first xApp, the second xApp, and one or more of the conflicting conditions; as well as The device stores rollback information, which includes information representing the adjustment, the first xApp, the second xApp, the first control parameter, the first operation of the first xApp, the second operation of the second xApp, and the conflicting conditions.

4. The method according to claim 3, further comprising: The device receives a request to load a third xApp; The device retrieves the subscription information of the third xApp based on the loading request, wherein the subscription information includes a second control parameter to be adjusted by the third xApp, and a third operation of the third xApp configured to use the second control parameter to adjust the operation; The device compares the subscription information of the third xApp with the rollback information; The device determines that the first control parameter and the second control parameter are the same parameter; as well as The device generates a warning indicating that the third xApp is configured to adjust its operation using the first control parameter, wherein the use of the first control parameter has been determined to have been previously involved in a conflict between the first xApp and the second xApp.

5. The method according to claim 4, further comprising: Based on the fact that the third xApp is configured to adjust the first control parameter, and the first control parameter is determined to be associated with rollback, the device rejects the loading request of the third xApp.

6. The method of claim 1, wherein the RAN is an open RAN.

7. The method of claim 1, wherein the device is located in one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC.

8. A system comprising: At least one processor, and A memory coupled to the at least one processor and having instructions stored thereon, wherein, in response to the at least one processor, the instructions facilitate the execution of operations including: Receive a load request from a first application (xApp), wherein the load request is for access to services of a radio access network (RAN); and It is determined that the load request points to rollback data, and the control parameters that can be applied to it have been identified.

9. The system of claim 8, wherein the operation further comprises: Extract the first information from the load request; as well as The first information in the load request is compared with previously stored data, wherein the previously stored data includes rollback events that can be applied to the control parameters.

10. The system of claim 9, wherein the operation further comprises: In response to the control parameters that have been determined to apply to the rollback data, the load request is rejected.

11. The system of claim 9, wherein the operation further comprises: Generate warning data, which indicates that the first xApp has determined that the rollback data can be applied to the control parameters thereto.

12. The system of claim 9, wherein the rollback data relates to an operational conflict between a second xApp configured to adjust the control parameters and a third xApp configured to adjust the control parameters.

13. The system of claim 9, wherein the operation further comprises: The rollback data is obtained from a data repository, and the data repository also includes multiple rollback events that can be applied to the control parameters.

14. The system of claim 8, wherein the RAN is an open RAN.

15. The system of claim 8, wherein the system is one of a real-time RAN intelligent controller (RIC), a near-real-time RIC, or a non-real-time RIC.

16. A computer program product stored on a non-transitory computer-readable medium and comprising machine-executable instructions, wherein, in response to execution, the machine-executable instructions cause a machine to perform operations, the operations comprising: The first state of the detection metric, wherein the metric relates to the operating conditions of the radio access network (RAN); The second state of the metric is detected according to the defined criteria, wherein the second state of the metric is after the first state in time and is in an operationally worse state than the first state; as well as The worse operational state of the metric is the result of the operation of a first application (xApp) configured to adjust the metric and the operation of a second xApp configured to adjust the metric.

17. The computer program product of claim 16, wherein the defined criteria are the first defined criteria, and wherein the operation further comprises: Identify the first operational effect of the first xApp on one or more operations performed via the network device of the RAN; The second operational effect of the second xApp on one or more operations performed by the network device via the RAN is identified; In response to determining, according to the second defined criteria, that the detrimental effect of the first xApp on the one or more operations performed by the network device via the RAN is greater than the detrimental effect of the second xApp on the one or more operations, the operation of the first xApp is terminated; as well as The operation of the network device in the RAN is rolled back to the operational state associated with the time prior to the implementation of the first xApp via the network device in the RAN.

18. The computer program product of claim 16, wherein the operation further comprises: Receive a load request from the third-party xApp; The third xApp is identified as being configured to adjust the use of the metric; The configuration of the third xApp is compared with the configuration of the first xApp; Based on the comparison results, according to the defined similarity criteria, it is determined that the configuration of the third xApp is threshold similar to the configuration of the first xApp; as well as In response to determining that the third xApp and the first xApp are similar in threshold, the loading request from the third xApp is rejected.

19. The computer program product of claim 18, wherein the operation further comprises: Generate and transmit a warning that the third xApp has been refused to load according to the loading request.

20. The computer program product of claim 16, wherein the RAN is an open RAN.

Images