Systems, frameworks, and methods for collision detection and mitigation in communication networks

Abstract

An apparatus associated with a network controller in an open-radio access network (O-RAN) is disclosed herein. The apparatus is configured to receive a request from a RAN function application from a plurality of RAN function applications associated with a network controller. The request indicates a change in one or more parameters associated with the RAN function application. The apparatus is configured to determine, based on the parameter dependency model, whether a conflict will occur due to a change in the one or more parameters. The parameter dependency model defines dependencies between a plurality of parameters associated with a plurality of RAN function applications. The apparatus is further configured to trigger one or more coordination actions based on the mitigation rule set upon determining that a conflict will occur due to a change in the one or more parameters.

Description

Cross Reference to Related Applications

[0001] This application claims priority to Indian Patent Application No. 202311089960 filed on March 21, 2024, which claims priority to Indian Provisional Patent Application No. 202311089960 filed on December 29, 2023, the entire contents of both applications are incorporated herein by reference. TECHNICAL FIELD

[0002] The present disclosure relates to conflict detection and mitigation in a communication network. BACKGROUND

[0003] As is known, a Radio Access Network (RAN) Intelligent Controller (RIC) is one component of the Open-Radio Access Network (O-RAN) architecture responsible for controlling and optimizing RAN functions. The O-RAN Alliance, which is a global community of mobile network operators, vendors, and research and academic institutions focused on open RAN standards and interoperability, has defined a set of use cases and applications supported by the RIC. The RIC is divided into non-real-time and near-real-time components. The non-real-time RAN Intelligent Controller (non-RT-RIC) is an element of the Operator Centralized Service Management and Orchestration (SMO) framework defined by the O-RAN Alliance. On the other hand, the near-RT RIC is located within a telco edge or regional cloud and can typically enable network optimization operations that take 10 milliseconds to 1 second to complete.

[0004] Figure 1 A general O-RAN architecture 100 associated with RICs (near-RT RIC and non-RT RIC) is illustrated. The non-RT RIC acts as a control point for a non-real-time control loop and operates within the SMO framework at a time scale greater than 1 second. The functions of the non-RT RIC can be implemented through an application called rApp. The non-RT RIC can be connected to the near-RT RIC through an Al interface. The near-RT RIC operates at a time scale between 10 milliseconds and 1 second. The functions of the near-RT RIC can be implemented through an application called xApp.

[0005] The near-RT RIC can also be connected to an E2 node (e.g., an O-RAN Centralized Unit (O-CU) and an O-RAN Distributed Unit (O-DU)) through an E2 interface. The SMO framework can manage and orchestrate various RAN elements. For example, the SMO can orchestrate an O-RAN Cloud (O-Cloud). The O-Cloud can refer to a physical RAN node that hosts a collection of RICs, O-CUs, O-DUs, and supporting environments and components.

[0006] Near-RT-RIC and non-RT-RIC can be used in various applications to achieve time-critical optimization goals. Applications can modify various parameters, directly or indirectly affecting the performance of other applications. This leads to conflicts.

[0007] Regarding near-RT RIC, conflicts can be direct, indirect, and implicit. Direct conflicts can be directly observed through conflict mitigation. Indirect conflicts can be observed based on dependencies between parameters and resources associated with an application (xApp in the case of near-RT RIC). Implicit conflicts may be difficult to observe directly, and dependencies between various xApps may not be obvious. An example of a direct conflict may include two or more xApps requesting different settings for the same configuration of one or more parameters of a control objective. Another example of a direct conflict may include a new request from an xApp that conflicts with a runtime configuration resulting from a previous request by another xApp or the same xApp. An example of an indirect conflict may include different xApps optimizing the same metric for different configuration parameters according to their respective objectives, which may lead to unintentional network effects. An example of an implicit conflict may include different xApps optimizing different metrics and (re)configuring different parameters, where optimizing the metric may have implicit and undesirable effects on the metric optimized by another xApp.

[0008] Regarding non-RT RIC, conflicts may occur when an application (rApp) provides conflicting A1 policies or conflicting O1 and O2 related configurations. Traditional application logic for conflict mitigation is complex and hard-coded. Traditional technologies lack a comprehensive framework for conflict detection and mitigation. For example, direct conflicts are handled by the application, while in the case of indirect conflicts, conflict resolution is achieved through operator rollback of these actions. Furthermore, there is no explicit conflict resolution framework for implicit conflicts.

[0009] However, as mentioned above, traditional techniques lack a comprehensive framework for conflict detection and mitigation. Therefore, it is desirable to address the aforementioned shortcomings or other deficiencies, or at least provide a useful alternative to overcome these shortcomings. Summary of the Invention

[0010] This summary is provided to introduce a series of concepts in a simplified format, which will be further described in the specific embodiments of this disclosure. This summary is not intended to identify any key or fundamental inventive concepts of the invention, nor is it intended to define the scope of this disclosure.

[0011] This document discloses an apparatus associated with a network controller in an Open Radio Access Network (O-RAN). The apparatus is configured to receive a request from one of a plurality of RAN function applications associated with the network controller. The request indicates a change in one or more parameters associated with the plurality of RAN function applications. The apparatus is further configured to determine, based on a parameter dependency model associated with the apparatus, whether a conflict will occur due to a change in one or more parameters. The parameter dependency model defines the dependencies between the plurality of parameters associated with the plurality of RAN function applications. The apparatus is also configured to, after determining that a conflict will occur due to a change in one or more parameters, trigger one or more coordination actions based on a mitigation rule set associated with the parameter dependency model.

[0012] This document discloses a method comprising: receiving a request from a RAN function application, which is one of multiple RAN function applications associated with a controlled network in an Open Radio Access Network (O-RAN). The request indicates a change in one or more parameters associated with the multiple RAN function applications. Furthermore, the method comprises: determining, based on a parameter dependency model, whether a conflict will occur due to a change in one or more parameters. The parameter dependency model defines the dependencies between the multiple parameters associated with the multiple RAN function applications. Additionally, the method comprises: after determining that a conflict will occur due to a change in one or more parameters, triggering one or more coordination actions based on a mitigation rule set associated with the parameter dependency model.

[0013] The disclosed apparatus and methods allow for the use of parameter dependency models and mitigation rule sets integrated with network controllers (i.e., near-RT RIC and non-RT RIC) to resolve direct and indirect conflicts, thereby providing flexible configuration for conflict detection and mitigation.

[0014] To further illustrate the advantages and features of this disclosure, a more specific description will be given with reference to the specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only typical embodiments of this disclosure and should not be considered as limiting its scope. This disclosure will be described and explained with additional specificity and detail in conjunction with the accompanying drawings. Attached Figure Description

[0015] The features, aspects, and advantages of certain exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, wherein like reference numerals denote like elements, and wherein: Figure 1 The diagram illustrates a general O-RAN architecture associated with RICs (near-RT RICs and non-RT RICs) in communication networks based on existing technologies; Figure 2A block diagram of a network controller according to an embodiment of the present disclosure is illustrated; Figure 3 The illustration shows a block diagram of a network controller according to an embodiment of the present disclosure when the network controller is a near-RT RIC; Figures 4A-4B The illustration shows a detailed process flow of conflict detection and mitigation performed by a near-RT RIC using a parameter dependency model and a mitigation rule set according to an embodiment of the present disclosure; Figures 5A-5B The illustration shows a call flow interaction between an xApp and a near-RT-RIC for loading a parameter dependency model and mitigation rule set according to an embodiment of the present disclosure; Figures 5C-5D The illustration shows a call flow interaction between an xApp and a device for at least one of an E2 subscription request and an E2 control request, according to an embodiment of the present disclosure; Figures 5E-5F The illustration shows a call stream interaction between an xApp and a device for an E2 boot request according to an embodiment of the present disclosure; Figure 6 The figure illustrates a block diagram of a network controller according to another embodiment of the present disclosure when the network controller is a near-RT RIC; Figures 7A-7B The illustration shows a call flow interaction for E2 subscription and control requests between an xApp, a platform layer device, and a CDMF xApp according to an embodiment of the present disclosure; Figures 7C-7D The illustration shows a processing flow for an E2 boot request between an xApp, a platform layer device, and a CDMF xApp according to an embodiment of the present disclosure; Figure 8 The illustration shows a block diagram of a network controller according to an embodiment of the present disclosure when the network controller is a non-RT RIC; Figures 9A-9B The illustration shows a detailed process flow of conflict detection and mitigation for the A1 parameter by a non-RT RIC using a parameter dependency model and a mitigation rule set according to an embodiment of the present disclosure; Figures 9C-9D The illustration shows a detailed process flow of conflict detection and mitigation of O1 and O2 parameters by a non-RT RIC using a parameter dependency model and a mitigation rule set according to an embodiment of the present disclosure; Figure 10 The figure illustrates a block diagram of a network controller according to another embodiment of the present disclosure when the network controller is a non-RT RIC; Figure 11 The illustration depicts a framework for coordination according to embodiments of the present disclosure; and Figures 12A-12CThe illustration depicts a process flow of a method for conflict detection and mitigation according to embodiments of the present disclosure. Detailed Implementation

[0016] The following detailed description of exemplary embodiments is provided with reference to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementation to the precise forms disclosed. Modifications and alterations are possible based on the foregoing disclosure, or may be derived from the practice of implementation. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Moreover, in the flowcharts and operational descriptions provided below, it will be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be switched, provided that such modifications do not affect the ultimate scope of protection of the invention.

[0017] It is evident that the systems and / or methods described herein can be implemented in various forms of hardware, software, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit these implementations. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to any specific software code. It should be understood that software and hardware can be designed to implement the systems and / or methods based on the descriptions herein.

[0018] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the possible disclosures. In fact, many of these features can be combined in ways not specifically referenced in the claims and / or not disclosed in the specification. Although each dependent claim listed below may be directly dependent on only one claim, the possible disclosures include combinations of each dependent claim with every other claim in the claim set.

[0019] Unless explicitly stated otherwise, no element, action, or instruction used herein should be construed as critical or necessary. Furthermore, as used herein, the articles “a” and “an” are intended to include one or more items and may be used interchangeably with “one or more.” If only one item is intended to be used, then “one” or similar language is used. Additionally, as used herein, the terms “have,” “possess,” “have,” “include,” “contain,” etc., are intended to be open-ended terms. Furthermore, unless explicitly stated otherwise, the phrase “based on” is intended to mean “at least partially based on.” Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” should be understood to include only A, include only B, or include both A and B.

[0020] The foregoing disclosure provides illustrations and descriptions, but is not intended to be exhaustive or to limit implementations to the precise forms disclosed. Modifications and alterations are possible based on the foregoing disclosure, or can be derived from the practice of implementation.

[0021] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0022] Figure 2 A block diagram of a network controller 200 according to an embodiment of the present disclosure is illustrated. The network controller 200 may be associated with a radio access network (RAN) or an open-RAN (O-RAN). The RAN facilitates communication between user equipment (UE) and the core network. The RAN may be associated with cellular networks such as 4G Long Term Evolution (LTE) and 5G. The network controller 200 may be configured to manage services within the RAN. In this disclosure, the terms "network controller" and "network management entity" are used interchangeably. In one embodiment, the network controller 200 may be configured to manage resource allocation and optimization for one or more UEs in a network. In one embodiment, the network controller 200 may be configured to facilitate the orchestration and optimization of radio resources to enable functions such as dynamic spectrum sharing, network slicing, and resource allocation. The network controller 200 may communicate with various other network entities, such as gNodeBs (gNBs), central units (CUs), and distributed units (DUs).

[0023] In one embodiment, network controller 200 may be a RAN Intelligent Controller (RIC). In one embodiment, the RIC may include a near real-time RIC (near-RT RIC) and a non-real-time RIC (non-RT RIC). The RIC can be configured to make decisions about radio resources, such as optimizing spectrum usage, adjusting parameters, and adapting to network conditions. Network controller 200 may also be associated with a Service Management and Orchestration (SMO) unit. The SMO can be configured to manage end-to-end services across the network, such as service provisioning, resource allocation, and service orchestration.

[0024] In some embodiments, the network controller 200 may be implemented as a virtualized software unit in a hardware or cloud environment. In some embodiments, the network controller may be implemented as a dedicated hardware unit.

[0025] Network controller 200 may include means 202 for parameter conflict detection and request processing in a communication network associated with network controller 200. Means 202 may be configured to resolve direct and indirect conflicts. Means 202 may alternatively be referred to as a conflict detection and mitigation (CDMF) unit. Network controller 200 may include multiple RAN function applications 204a-204n (collectively referred to as 204). Means 202 may communicate with the multiple RAN function applications 204.

[0026] The network controller 200 can also be associated with a parameter dependency model 206 and a mitigation rule set 208. The parameter dependency model 206 and the mitigation rule set 208 can be used to detect conflicts and trigger coordination actions. In one embodiment, the parameter dependency model 206 and the mitigation rule set 208 can be predefined.

[0027] Network controller 200 may include one or more processors 210 (also referred to as processor 210), a communication unit 212 (e.g., a communicator or communication interface), and a storage unit (e.g., memory 214). Communication unit 212 may perform functions for sending and receiving signals. Processor 210 and memory 214 may be communicatively coupled to device 202. Memory 214 may include executable instructions that, when executed by processor 210, cause the device to perform the functions described in this disclosure. For example, processor 210 may be a single processing unit or multiple units, all of which may include multiple computing units. Processor 210 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuit systems, and any device that manipulates signals based on operating instructions. Among other functions, processor 210 is configured to retrieve and execute computer-readable instructions and data stored in memory. Processor 210 may include one or more processors. In this configuration, one or more processors 210 can be general-purpose processors, such as a central processing unit (CPU), application processor (AP), etc., or AI-specific processors, such as a neural processing unit (NPU). Processor 210 can control the processing of input data based on predefined operating rules or artificial intelligence (AI) models stored in non-volatile memory and volatile memory (i.e., memory 214). The predefined operating rules or AI models are obtained through training or learning.

[0028] Memory 214 may include any non-transitory computer-readable medium known in the art, including, for example, volatile memory (such as static random access memory (SRAM) and dynamic random access memory (DRAM)) and non-volatile memory (such as read-only memory (ROM), erasable programmable ROM, flash memory, hard disk, optical disk and magnetic tape).

[0029] In conjunction with processor 210, device 202 can be configured to receive requests from RAN function applications (e.g., 204a) among a plurality of RAN function applications 204. The request may indicate a change in one or more parameters associated with the plurality of RAN function applications 204. In one embodiment, device 202 may communicate with the plurality of RAN function applications 204 via an application programming interface (API). In one embodiment, the request may be received via an R1 interface. In a non-limiting example, the request may include an E2 subscription request, an E2 control request, an E2 boot request, etc.

[0030] In conjunction with processor 210, device 202 can also be configured to determine whether a conflict will occur due to a change in one or more parameters. Device 202 may determine the occurrence of a conflict based on parameter dependency model 206. In one embodiment, parameter dependency model 206 defines dependencies between multiple parameters associated with multiple RAN function applications 204. In one embodiment, a change in one or more parameters may include a change in existing parameters or a subscription to a new parameter. In one embodiment, device 202 utilizes parameter dependency model 206 and identifies whether a change in a parameter conflicts with other parameters among the multiple parameters in parameter dependency model 206. The terms “parameter dependency model” and “parameter dependency graph” are used interchangeably in this disclosure.

[0031] In one embodiment, parameter dependency model 206 may be generated by the operator during network design and linked to device 202. The operator may load parameter dependency model 206 into network controller 200 for use by device 202. In one embodiment, parameter dependency model 206 may be generated by one or more RAN function applications 204 based on a generative artificial intelligence (AI) model. In one embodiment, the generative AI model may be stored in memory 214 and accessed by the multiple RAN function applications 204.

[0032] In one embodiment, in conjunction with processor 210, device 202 may also be configured to identify one or more parameters associated with a request received from RAN function application 204a. Depending on whether network controller 200 is a near-RT RIC or a non-RTTRIC, the one or more parameters may be identified based on multiple factors. In a non-limiting example, the one or more parameters may be identified based on RAN function ID, E2 service model (E2SM) object identifier (OID), parameter path in a specific format, parameter value to be set, O1 resource uniform resource identifier (URI), A1 policy ID, etc.

[0033] Furthermore, device 202 can be configured to determine whether one or more identified parameters exist in a library of parameter dependency models 206. In one embodiment, parameter dependency models 206 can be stored in memory 214.

[0034] Furthermore, the dependency of one or more parameters on other parameters, such as key performance indicators (KPIs), strategy parameters, configuration parameters, and control parameters, can be identified. Device 202 can be configured to determine whether a conflict will occur based on the dependency of one or more parameters on other parameters (one or more of the KPIs, strategy parameters, configuration parameters, and control parameters).

[0035] In one embodiment, policy parameters, configuration parameters, and control parameters can be exposed as parameters through one or more open interfaces, including but not limited to A1, O1, and E2 interfaces. Apparatus 202 can be configured to identify, based on parameter dependency model 206, whether one or more identified parameters are dependent on one or more other parameters associated with at least one of apparatus 202, multiple RAN function applications 204 running in network controller 200, and controlled network functions. In one embodiment, controlled network functions may include E2 nodes such as RAN Distributed Cells (DUs), RAN Centralized Cell Control Planes (CU-CPs), and RAN Centralized Cell User Planes (CU-UPs).

[0036] When it is determined that a conflict will occur due to a change in one or more parameters, device 202 can be configured to trigger one or more coordination actions. These coordination actions can be triggered based on a mitigation rule set 208. The mitigation rule set 208 can be associated with a parameter dependency model 206 and can define the coordination actions to be performed when a parameter conflict is encountered. The mitigation rule set 208 can be used when a conflict is determined to exist. When it is determined that a conflict will not occur due to a change in one or more parameters, device 202 can be configured to accept a change in one or more parameters.

[0037] In one embodiment, the mitigation rule set 208 may be generated by the operator during network design and linked to device 202. In another embodiment, the mitigation rule set 208 may be generated by one or more RAN function applications 204 based on a generative AI model.

[0038] In one embodiment, device 202 may utilize mitigation rule set 208 to determine whether acceptance of a change in one or more parameters is permitted. If acceptance of a change in one or more parameters is not permitted, mitigation rule set 208 may define an action to reject the change in one or more parameters. If acceptance of a change in one or more parameters is permitted, mitigation rule set 208 may define an action to accept the change in one or more parameters.

[0039] In a non-limiting example, one or more coordination actions include stopping one or more RAN function applications 204, adjusting the configuration of one or more RAN function applications 204, and adjusting the operation of E2 nodes associated with network controller 200.

[0040] As described above, the network controller 200 may include near-RT RIC and non-RT RIC. Figure 3 The illustration shows a block diagram of a network controller 200 when it is a near-RT RIC 300 according to an embodiment of the present disclosure. The near-RT RIC 300 includes, as referenced above... Figure 2 For brevity, not all components of the network controller 200 are depicted. The near-RT RIC 300 includes means 202 for detecting, mitigating, and processing requests in the communication network to resolve direct and indirect conflicts. The near-RT RIC 300 may additionally include a subscription manager 302. When the network controller 200 is a near-RT RIC 300, multiple RAN function applications 204 include multiple xApps 304a, 304b, ..., 304n (collectively referred to as 'xApp 304'). Means 202 may communicate with multiple xApps 304 via multiple APIs. The near-RT RIC 300 may also be communicatively coupled to a controlled network function (i.e., E2 node 306). The E2 node 306 may include CU-CP, CU-UP, and DU. In one embodiment, the near-RT RIC 300 may be communicatively coupled to the E2 node 306 via an E2 termination unit 308. Subscription manager 302 can be configured to manage subscriptions from xApp 304 to E2 node 306. Subscription manager 302 can also be configured to merge identical subscriptions from various xApps 304 into a single subscription to E2 node 306.

[0041] In the illustrated embodiment, device 202 is included at the framework level within near-RT RIC 300, i.e., forming part of near-RT RIC framework 310. Device 202 is associated with parameter dependency model 206 and mitigation rule set 208. In one embodiment, parameter dependency model 206 and mitigation rule set 208 are predefined. In another embodiment, parameter dependency model 206 and mitigation rule set 208 are generated by the operator during network design and linked to device 202. That is, the operator can generate parameter dependency model 206 and mitigation rule set 208 and load parameter dependency model 206 and mitigation rule set 208 for use by device 202. In one embodiment, parameter dependency model 206 and mitigation rule set 208 are generated by one or more xApps 304 based on a generative AI model. The generative AI model can be stored in memory 214.

[0042] As described above, parameter dependency model 206 can be used to detect conflicts. Parameter dependency model 206 defines the dependencies between multiple parameters associated with multiple xApp 304s. In one embodiment, parameter dependency model 206 defines the dependency between the E2 parameter and the O1 parameter associated with multiple xApp 304s.

[0043] In some embodiments, one or more of the plurality of xApps 304s may send a request to device 202. For example, device 202 may receive a request from xApp 304a indicating a change in one or more parameters associated with the near RT RIC 300. In a non-limiting example, the request may include an E2 subscription request, an E2 control request, an E2 bootstrapping request, etc. Upon receiving the request from xApp 304a, device 202 may refer to parameter dependency model 206 to detect potential conflicts due to changes in one or more parameters. In one embodiment, device 202 may refer to historical parameters subscribed to or set via a previous control request. In one embodiment, device 202 may identify one or more parameters and determine whether the identified one or more parameters are dependent on KPIs, policy parameters, configuration parameters, and control parameters.

[0044] If device 202 determines that a conflict may occur, one or more coordination actions may be triggered based on mitigation rule set 208. In one embodiment, the request may be rejected when a conflict is detected. In another embodiment, if no conflict is detected, a success indication may be sent to xApp 304a, and the received request may be recorded in memory 214 for comparison with future requests.

[0045] In a non-limiting example, coordinated actions may include stopping multiple xApp 304s, adjusting the configuration of xApp 304 (a list of parameters and values ​​is fed in), stopping xApp 304s in reverse order of loading until the KPI bounces, changing the baseline O1 configuration of E2 node 306 (a list of parameters and values ​​is fed in), rolling back the E2 action sequence recorded at E2 node 306 one at a time until the next rollback trigger of SMO (E2 nodes support recording operations performed via the E2 and O1 interfaces in chronological order), and rolling back the E2 action sequence recorded at E2 node 306 in “N” increments until the next rollback trigger of SMO (E2 nodes support recording operations performed via the E2 and O1 interfaces in chronological order).

[0046] In one embodiment, device 202 may be configured to determine, based on mitigation rule set 208, that acceptance of changes in one or more parameters is permitted. Furthermore, device 202 may determine a change request in a relevant parameter associated with at least one other xApp (e.g., xApp 304b). Device 202 may then send a relevant parameter request to xApp 304b, indicating a request to accept changes in the relevant parameter.

[0047] In one embodiment, xApp 304b can accept changes in relevant parameters. In this case, device 202 can receive a relevant parameter acceptance response from xApp 304b indicating that the changes in relevant parameters are accepted. Upon receiving the relevant parameter acceptance response, device 202 accepts the changes in one or more parameters in the request sent by xApp 304a. xApp 304a can then send the request to E2 node 306 upon receiving a success indication from device 202.

[0048] In one embodiment, xApp 304b can reject changes in the relevant parameters. In this case, device 202 can receive a relevant parameter rejection response from xApp 304b indicating that changes in the relevant parameters are rejected. After receiving the relevant parameter rejection response, device 202 rejects changes in one or more parameters in the request sent by xApp 304a.

[0049] Therefore, all subscriptions to parameter change events and requests for parameter changes are subject to conflict detection and mitigation via device 202. Figure 3 The apparatus described in this embodiment allows for conflict detection and mitigation at the platform level. In this embodiment, the focus is not on conflict resolution; instead, the focus can be on preparing the logic behind the application so that it can operate according to the platform's requests and commands.

[0050] Figures 4A-4BThe diagram illustrates the detailed process flow of conflict detection and mitigation performed by the near-RT RIC 300 using parameter dependency model 206 and mitigation rule set 208. Initially, at step 402, device 202 may receive a request for parameter changes from xApp 304a. At step 404, one or more parameters may be identified based on RAN function ID, E2 service model (E2SM) object identifier (OID), parameter path in a specific format, parameter value to be set, etc.

[0051] At step 406, it is determined whether the parameter exists in the library of parameter dependency model 206. If the parameter does not exist in parameter dependency model 206, the parameter change is accepted at step 408, and the process ends. If the parameter exists in parameter dependency model 206, it is determined at step 410 whether the parameter has any dependency on any KPI. If there is no dependency, the process proceeds to step 414. If there is a dependency on any KPI, at step 412, relevant key performance measurement (KPM) statistics can be obtained from the associated E2 node 306 using E2SM KPM, and the process proceeds to step 414.

[0052] At step 414, it is determined whether the parameter has any dependency on any O1 configuration of the associated E2 node 306. If there is no dependency, the parameter change is accepted at step 408, and the process ends. In the case of a dependency, the E2 node O1 baseline configuration is obtained at step 416. At step 418, based on parameter dependency model 206, it is determined whether the parameter value conflicts due to the dependency. In one embodiment, the dependency may include E2 parameters, O1 parameters, or KPIs. If there is no conflict, the parameter change is accepted at step 408.

[0053] In the event of a conflict, the mitigation rule set 208 is checked at step 420. If the rule does not allow the value to be accepted at step 422, the parameter change is rejected at step 424. If the mitigation rule set 208 allows the value to be accepted, it is determined at step 426 whether the mitigation rule set 208 needs to change the relevant E2 parameter to accept the change. If no change is needed, the parameter change is accepted at step 428. If a change is needed, a conditional success indication is sent to xApp 304a at step 430, and at step 432, xApps that have already set the relevant E2 parameter (e.g., xApp 304b) are notified of the change value. At step 434, it is determined whether other applications (i.e., xApp 304b) have accepted the requested change. If other xApps 304b have not yet accepted the requested change, xApp 304a is notified at step 436 that the parameter change has been rejected. If xApp 304b accepts the requested change, xApp 304a is notified at step 438 that the parameter change has been accepted. Then, the process ends.

[0054] refer to Figures 5A-5F The illustration shows call flow interactions between multiple xApp 304s and the near RT RIC 300 or device 202 according to various embodiments of the present disclosure. Figures 5A-5B The diagram illustrates the process flow between xApp 304a-304b and near-RT-RIC 300 for loading the parameter dependency model 206 and mitigation rule set 208 into device 202. Near-RT-RIC 300 can communicate with Service Management and Orchestrator (SMO) 500a. Near-RT-RIC 300 may include components such as O1 termination unit 500b, shared database 500c, xApp 304a, xApp 304b, device 202, and E2 termination unit 308.

[0055] At step 501, the near-RT RIC framework is started. At step 502, O1 termination unit 500b sends a NETCONF CALLHOME message to SMO 500a. At step 503, NETCONFSESSION ESTABLISHMENT messages are exchanged between O1 termination unit 500b and SMO 500a. At step 504, SMO 500a sends the near-RT RIC platform configuration to O1 termination unit 500b. At step 505, SMO 500a sends a NETCONF GET E2 node information to O1 termination unit 500b.

[0056] At step 506, O1 termination unit 500b requests the currently connected E2 node 306 from E2 termination unit 308 (e.g., Figure 3(As shown in the diagram). At step 507, E2 termination unit 308 sends an E2 node information response to O1 termination unit 500b. At step 508, O1 termination unit 500b sends a NETCONF GET response containing E2 node information to SMO 500a. At step 509, SMO 500a sends the baseline O1 configuration of E2 node 306 as a key-value pair to O1 termination unit 500b.

[0057] At step 510, the O1 termination unit 500b sends the received information for E2 node baseline configuration to the shared database 500c for storage. At step 511, the E2 node baseline configuration is stored as key-value pairs, where the key is the XPath of the O1 attribute and the Value is the attribute's value. At step 512, the SMO 500a loads the parameter dependency model 206 and the mitigation rule set 208 into the device 202.

[0058] Figures 5C-5D The diagram illustrates the processing flow between xApp 304a-304b and device 202 for at least one of E2 subscription requests and E2 control requests. The near-RT-RIC 300 can communicate with E2 node 306 and may include components such as xApp 304a, xApp 304b, and device 202.

[0059] At step 520, xApp 304a sends an E2 subscription request or E2 control request to device 202 indicating a change in parameters.

[0060] At step 521, device 202 checks parameter dependency model 206. For example, device 202 may determine that a parameter is dependent on KPI, and device 202 retrieves KPM from E2 node 306 by sending an E2 subscription request (KPM) at step 522 and receiving an E2 subscription response (KPM) at step 523.

[0061] In the event of a conflict in the parameters according to the parameter dependency model 206, the device 202 checks whether the mitigation rule set 208 allows the acceptance of the parameters, as shown in step 524.

[0062] If the parameters are allowed, CDMF checks whether the relevant parameters in xApp 304b need to be changed, as shown in step 525.

[0063] If the parameters need to be coordinated with xApp 304b, at step 526, device 202 notifies xApp 304b of the necessary parameter changes, and at step 527 sends an E2 subscription response or E2 control response indicating temporary success to xApp 304a.

[0064] When xApp 304b is ready to change the relevant parameters, at step 528, xApp 304b sends a ready-to-change-relevant-parameters response (relevant-parameters acceptance response) to device 202. At steps 529-530, device 202 forwards the request to E2 node 306 and receives a success response from E2 node 306. At step 531, device 202 sends a success response to xApp 304a.

[0065] If xApp 304b is not ready to change the relevant parameters, the device sends a rejection response to xApp 304a, as shown in step 532.

[0066] If no coordination of parameters is required, device 202 forwards the E2 subscription / control request to E2 node 306, receives a success response from E2 node 306, and sends the success response to xApp 304a, as shown in steps 533 to 535.

[0067] If the parameter is rejected, a rejection response is sent to xApp 304a, as shown in step 536.

[0068] If there are no parameter conflicts, device 202 forwards the E2 subscription / control request to E2 node 306, receives a success response from E2 node 306, and sends the success response to xApp 304a, as shown in steps 537-539.

[0069] In some embodiments, xApp 304 may send an E2 bootstrapping request to the near RT RIC 300 before sending an E2 subscription request or an E2 control request. If a parameter change is conflicting and requires coordination with another xApp (xApp 304b), an E2 bootstrapping request may be sent from the near RT RIC 300 to xApp 304b to coordinate the parameter change. In some embodiments, the parameter dependency model 206 may be automatically generated by multiple xApps 304 based on a generative AI model, wherein the input or prompts to the generative AI model are a set of intents and goals.

[0070] Figures 5E-5F The diagram illustrates the processing flow for E2 boot requests between xApp 304a to 304b and device 202. The near-RT-RIC 300 can communicate with E2 node 306 and may include components such as xApp 304a, xApp 304b, and device 202.

[0071] At step 540, xApp 304a may send an E2 boot request to device 202. At step 541, device 202 may check for conflicts in parameter dependency model 206.

[0072] In the event of a conflict in the parameters according to the parameter dependency model 206, at step 542, the device 202 checks whether the mitigation rule set 208 allows the acceptance of the parameters.

[0073] If the parameters are allowed, at step 543, device 202 uses the relevant parameter request to check whether the parameters need to be changed in another xApp (i.e., xApp 304b).

[0074] If the parameters need to be coordinated with xApp 304b, in step 544, device 202 sends an E2 boot (modify) message to xApp 304b.

[0075] If xApp 304b accepts the modification, at step 545, xApp 304b sends an acceptance message (related parameter acceptance response) to device 202. Furthermore, at step 546, device 202 sends an E2 boot response to xApp 304a indicating that there are no conflicts or that the conflicts have been resolved.

[0076] If xApp 304b does not accept the modification, at step 547, device 202 sends an E2 boot response to xApp 304a indicating that a conflict has been detected and requires coordination with xApp 304b, but this is not possible.

[0077] Furthermore, if the parameters do not need to be coordinated (as a result of step 542), the device 202 sends an E2 boot response to xApp 304a indicating that there is no conflict or the conflict has been resolved, as shown in step 548.

[0078] Furthermore, if the parameter is rejected (as a result of step 543), the device 202 sends an E2 boot response to xApp 304a indicating the detected conflict, as shown in step 549.

[0079] Furthermore, if there are no parameter conflicts (as a result of step 541), the device 202 sends an E2 boot response to xApp 304a indicating that there are no conflicts or that the conflicts have been resolved, as shown in step 550.

[0080] In some embodiments, the parameter dependency model 206 and the mitigation rule set 208 may be encoded in a machine-readable data format and loaded into the device 202. In a non-limiting example, the machine-readable data format is a JavaScript Object Notation (JSON) document conforming to the JSON schema. The JSON schema defines a syntax that enables the definition of parameter dependencies and relationships, and the actions to be performed when these dependencies or relationships are not satisfied in the JSON document (i.e., when a conflict occurs). For each parameter dependency rule defined in the parameter dependency model 206, an action to be performed according to the parameter dependency rule when a conflict is detected is provided. Therefore, both direct and indirect conflicts can be resolved.

[0081] In a non-limiting example, coordinated actions may include stopping xApp 304a, adjusting the configuration of xApp 304a (a list of input parameters and values), stopping multiple xApps 304a in reverse loading order until the KPI bounces, changing the baseline O1 configuration of E2 node 306 (a list of parameters and values ​​is fed in), rolling back the E2 action sequence recorded at E2 node 306 one at a time until the next rollback trigger of SMO (the E2 node is expected to support recording operations performed via the E2 and O1 interfaces in chronological order), and rolling back the E2 action sequence recorded at E2 node N times at a time until the next rollback trigger of SMO (the E2 node is expected to support recording operations performed via the E2 and O1 interfaces in chronological order).

[0082] Figure 6 The illustration shows another block diagram of the network controller 200 when it is a near-RT RIC 300, according to another embodiment of the present disclosure. The near-RT RIC 300 includes as referenced above. Figure 2 The network controller 200 is a component of the aforementioned network controller 200. The near-RT RIC 300 includes means 202 for detecting, mitigating, and processing requests in the communication network to resolve direct and indirect conflicts. The near-RT RIC 300 may additionally include a subscription manager 302. The near-RT RIC 300 includes multiple xApps 304a, 304b, ..., 304n (collectively referred to as 'xApp 304'). The near-RT RIC 300 may also be communicatively coupled to a controlled network function (i.e., an E2 node 306) via an E2 termination unit 308.

[0083] Figure 6 The near-RT RIC 300 shown can correspond to Figure 3 The near-RT RIC 300 shown, however, in Figure 6 In the illustrated embodiment, device 202 (corresponding to Figure 3The device 202 itself is implemented as a special xApp at the application level, as shown in box 602. Hereinafter, the special xApp may be referred to as CDMF xApp 602. The functionality of the device 202 described above can be implemented using CDMFxApp 602. Furthermore, the near-RT RIC 300 may include a frame-level device or a platform-level device 604. Figure 6 The apparatus described in the embodiments can enable the loading of various conflict mitigation logics in the form of applications. Therefore, platform-level changes can be avoided, reducing platform complexity. Furthermore, operators can select the optimal conflict detection and mitigation application from multiple options based on the implementation requirements in different scenarios.

[0084] The RT RIC 300 routes each E2 subscription request and E2 control request to the CDMF xApp 602. Figures 7A-7B The diagram illustrates the processing flow for E2 subscription and control requests between xApp 304a-304b, platform layer device 604, and CDMF xApp 602. The near-RT RIC 300 can communicate with E2 node 306 and may include components such as xApp 304a (alternately referred to as xApp1), xApp 304b (alternately referred to as xApp2), CDMF xApp 602, and platform layer device 604.

[0085] like Figures 7A-7B As shown, at step 710, CDMF xApp 602 and platform layer device 604 exchange messages to register the conflict detection and mitigation service provided by CDMF xApp 602. At step 711, xApp 304a sends an E2 subscription request (parameters and actions) or an E2 control request (parameters to be changed) to platform layer device 604. At step 712, platform layer device 604 forwards the request from xApp 304a to CDMF xApp 602. At step 713, CDMF xApp 602 checks whether there is a conflict in parameter dependency model 206.

[0086] In the event of a conflict in the parameters according to the parameter dependency model 206, at step 714, CDMF xApp 602 determines whether the mitigation rule set 208 allows the acceptance of the parameters.

[0087] If the parameter acceptance is permitted, at step 715, CDMF xApp 602 checks whether the parameter needs to be changed in another xApp (i.e., xApp 304b).

[0088] If the parameters require coordination with xApp 304b, then at step 716, CDMF xApp 602 notifies platform layer device 604 that the relevant parameter change requires coordination with xApp 304b. Furthermore, at step 717, platform layer device 604 notifies xApp 304b of the requirement for the relevant parameter change. At step 718, platform layer device 604 sends an E2 subscription / control response indicating temporary success to xApp 304a.

[0089] When xApp 304b is ready to change the relevant parameters, at step 719, xApp 304b sends a message indicating readiness to change the relevant parameters to platform layer device 604 (relevant parameter acceptance response). Furthermore, at step 720, platform layer device 604 forwards the E2 subscription / control request to E2 node 306. At step 721, E2 node 306 sends a successful E2 subscription / control response to platform layer device 604. Additionally, at step 722, platform layer device 604 sends a successful E2 subscription / control response to xApp 304a.

[0090] If xApp 304b is not ready to change the relevant parameters, at step 723, platform layer device 604 sends an E2 subscription / control response indicating rejection to xApp 304a.

[0091] If parameter coordination is not required, at step 724, CDMF xApp 602 notifies platform layer device 604 that a conflict has been detected and resolved. Furthermore, at step 725, platform layer device 604 forwards the E2 subscription / control request to E2 node 306. At step 726, E2 node 306 sends a successful E2 subscription / control response to platform layer device 604. Furthermore, at step 727, platform layer device 604 sends a successful E2 subscription / control response to xApp 304a.

[0092] If the parameter is rejected, at step 728, CDMF xApp 602 notifies platform layer device 604 that the parameter has been rejected. Furthermore, at step 729, platform layer device 604 sends an E2 subscription / control response indicating rejection to xApp 304a.

[0093] In the absence of a conflict, at step 730, CDMF xApp 602 notifies platform layer device 604 that no conflict has been detected. Furthermore, at step 731, platform layer device 604 forwards the E2 subscription / control request to E2 node 306. At step 732, the E2 node sends a successful E2 subscription / control response to platform layer device 604. Furthermore, at step 733, platform layer device 604 sends a successful E2 subscription / control response to xApp 304a.

[0094] Figures 7C-7D The diagram illustrates the processing flow for E2 boot requests between xApp 304a-304b, platform layer device 604, and CDMF xApp 602. The near-RT RIC 300 can communicate with E2 node 306 and may include components such as xApp 304a, xApp 304b, CDMF xApp 602, and platform layer device 604.

[0095] At step 740, CDMF xApp 602 and platform layer device 604 exchange multiple messages to register the conflict detection and mitigation service provided by CDMFxApp 602. At step 741, xApp 304a sends an E2 boot request to platform layer device 604. At step 742, platform layer device 604 forwards the request from xApp 304a to CDMF xApp 602. At step 743, CDMF xApp 602 checks whether there is a conflict in parameter dependency model 206.

[0096] If there is a conflict in the parameters according to the parameter dependency model 206, then at step 744, CDMF xApp602 determines whether the mitigation rule set 208 allows the acceptance of the parameter.

[0097] If the parameter acceptance is permitted, at step 745, CDMF xApp 602 checks whether the parameter needs to be changed in another xApp (i.e., xApp 304b).

[0098] If the parameters require coordination with xApp 304b, at step 746, CDMF xApp 602 notifies platform layer device 604 that the relevant parameter changes require coordination with xApp 304b. Furthermore, at step 747, platform layer device 604 sends an E2 boot (modification) message to xApp 304b.

[0099] If xApp 304b accepts the modification, at step 748, xApp 304b sends an acceptance message to platform layer device 604. At step 749, platform layer device 604 sends an E2 boot response to xApp 304a indicating that there are no conflicts or that the conflicts have been resolved.

[0100] If xApp 304b does not accept the modification, at step 750, platform layer device 604 sends an E2 boot response to xApp 304a indicating that a conflict has been detected, and requires coordination with xApp 304b, but this is not possible.

[0101] If parameter coordination is not required, at step 751, CDMF xApp 602 notifies platform layer device 604 that a conflict has been detected and resolved. At step 752, platform layer device 604 sends an E2 boot response to xApp 304a indicating that there is no conflict or the conflict has been resolved.

[0102] If the parameter is rejected, at step 753, CDMF xApp 602 notifies platform layer device 604 that a conflict has been detected and the parameter has been rejected. At step 754, platform layer device 604 sends an E2 boot response indicating the detected conflict to xApp 304a.

[0103] In the absence of a conflict, at step 755, CDMF xApp 602 notifies platform layer device 604 that no conflict has been detected. At step 756, platform layer device 604 sends an E2 boot response to xApp 304a indicating that there is no conflict or that the conflict has been resolved.

[0104] CDMF xApp 602 performs conflict detection and mitigation based on the parametric dependency model 206 and the mitigation rule set 208. This approach helps reduce the complexity of platform / framework implementations for conflict management. Furthermore, the conflict detection and mitigation functionality can be tightly coupled with applications loaded into the near-RT RIC 300, which will be frequently updated by application vendors. Moreover, moving the conflict detection and mitigation functionality to the application layer helps improve lifecycle management efficiency and multi-vendor interoperability. Additionally, since CDMF xApp 602 can decode E2 subscription or E2 control requests from other xApps, loading CDMF xApp 602 into the near-RT RIC 300 is based on at least one of trusted certificates and OAuth2.0 tokens.

[0105] In some embodiments, when the network controller 200 is a non-RT RIC, the device 202 can be implemented in a non-RT RIC. Figure 8The illustration shows a block diagram of a network controller 200 when it is a non-RT RIC 800, according to an embodiment of the present disclosure. The non-RT RIC 800 includes, as referenced above... Figure 2 The components of the network controller 200 are described, and for brevity, not all components are depicted. A non-RT RIC may be associated with an SMO. The non-RT RIC 800 includes means 202 for parameter conflict detection, mitigation, and request processing in the communication network to resolve direct and indirect conflicts. When the network controller 200 is a non-RT RIC 800, multiple RAN function applications 204 include multiple rApp 804a, rApp 804b, ..., rApp 804n (collectively referred to as 'rApp 804'). Means 202 can communicate with multiple rApp 804s via an R1 interface. The non-RT RIC 800 can also be communicatively coupled to controlled network functions (i.e., E2 nodes 806) via an O1 interface. E2 nodes 806 may include CU-CP, CU-UP, and DU. In one embodiment, the non-RT RIC 800 can be communicatively coupled to the E2 node 806 via a RAN OAM configuration management (CM) / performance management (PM) / fault management (FM) unit 808, which is configured to acquire network-related performance information, acquire the current network configuration, and provide changes to the network configuration.

[0106] Device 202 can also connect to the near-RT RIC 300 (such as via the A1 interface) Figure 3 (As shown in the illustration). In one embodiment, the non-RT RIC 800 can be communicatively coupled to the near-RT RIC 300 via the A1 termination unit 810. Furthermore, the device 202 can communicate with the O-cloud 812 via the O2 interface. In one embodiment, the non-RT RIC 800 can be communicatively coupled to the O-cloud 812 via a Network Functions Orchestrator (NFO) coupled with an O-cloud Orchestration and Management (FOCOM) unit 814, which is configured to manage resources in the O-cloud while receiving services from the Infrastructure Management Service (IMS) associated with the O-cloud. Furthermore, the NFOFOCOM unit 814 can be configured to manage the distribution of O-cloud software and provide orchestration for O-cloud lifecycle processes. In the illustrated embodiment, the device 202 is included at the framework level within the non-RT RIC 800, i.e., forming part of the non-RT RIC framework 816.

[0107] In the non-RT RIC 800, device 202 is associated with parameter dependency model 206 and mitigation rule set 208. In one embodiment, parameter dependency model 206 and mitigation rule set 208 may be generated by the operator during network design and linked to device 202. In another embodiment, parameter dependency model 206 and mitigation rule set 208 are generated by one or more rApp 804s based on a generative AI model that can be stored in memory 214.

[0108] As described above, parameter dependency model 206 can be used to detect conflicts. Parameter dependency model 206 defines the dependencies between multiple parameters associated with multiple rApp 804s. In one embodiment, parameter dependency model 206 defines the dependencies between one or more of the O1, O2, and A1 parameters associated with multiple rApp 804s.

[0109] In some embodiments, one or more rApps 804 may send a request to device 202. For example, device 202 may receive a request from rApp 804a indicating a change in one or more parameters associated with a non-RT RIC 800. Upon receiving the request from rApp 804a, device 202 may refer to parameter dependency model 206 to detect potential conflicts arising from changes in one or more parameters. If device 202 determines that a conflict may occur, one or more coordination actions may be triggered based on mitigation rule set 208.

[0110] In one embodiment, one or more coordinated actions include one or more of the following: stopping one or more of the plurality of rApps 804, adjusting the configuration of one or more of the plurality of rApps 804, and adjusting the operation of the E2 node 806 associated with the non-RT RIC 800.

[0111] In one embodiment, device 202 may identify one or more parameters in a request received from rApp 804a. In one embodiment, device 202 may identify A1 policy dependencies and detect conflicts in A1 parameters, as indicated by arrow AA, and refer to below. Figures 9A-9B Furthermore, in another embodiment, device 202 can detect a conflict between at least one of the O1 and O2 parameters, as indicated by arrows BB and CC, and as described below regarding... Figures 9C-9D Further details are provided.

[0112] In one embodiment, device 202 can determine whether one or more identified parameters exist in parameter dependency model 206, and whether one or more parameters are dependent on one or more of KPIs, strategy parameters, configuration parameters, and control parameters. Device 202 can then determine whether a conflict will occur. In one embodiment, the request can be rejected when device 202 determines a conflict will occur. In one embodiment, the request can be accepted when device 202 determines a conflict will not occur, i.e., changes to one or more parameters can be accepted. In one embodiment, if no conflict is detected, a success indication can be sent to rApp 804a, and the received request can be recorded in memory 214 for comparison with future requests.

[0113] In one embodiment, device 202 can be configured to determine, based on mitigation rule set 208, that acceptance of changes in one or more parameters is permitted. Furthermore, device 202 can determine a change request in a relevant parameter associated with at least one other rApp (e.g., rApp 804b). Device 202 can then send a relevant parameter request to rApp 804b, indicating a request to accept changes in the relevant parameter. In one embodiment, rApp 804b can accept the change in the relevant parameter. In this case, device 202 can receive a relevant parameter acceptance response from rApp 804b indicating acceptance of the change in the relevant parameter. Upon receiving the relevant parameter acceptance response, device 202 accepts the change in one or more parameters from the request sent by rApp 804a. rApp 804a can then send the request to E2 node 806 upon receiving a success indication from device 202.

[0114] In one embodiment, rApp 804b can reject changes to relevant parameters. In this case, device 202 can receive a relevant parameter rejection response from rApp 804b indicating that changes to relevant parameters are rejected. Upon receiving the relevant parameter rejection response, device 202 rejects changes to one or more parameters in the request sent by rApp 804a. Therefore, in the non-RT RIC 800, all subscriptions to parameter change events and requests for parameter changes are conflict detected and mitigated by device 202.

[0115] Figures 9A-9BThe illustration shows a detailed process flow of conflict detection and mitigation for A1 parameters performed by a non-RT RIC 800 using a parameter dependency model 206 and a mitigation rule set 208 according to an embodiment of the present disclosure. The apparatus 202 can identify A1 policy dependencies. The parameter dependency model 206 can model the A1 policy type and the dependent A1 policy ID, while the mitigation rule set 208 can define mitigation actions corresponding to the parameter dependency model 206.

[0116] Initially, at step 902, device 202 may receive requests for policy A1 from multiple rApps 804. At step 904, policy A1 may be identified based on policy type ID and policy ID.

[0117] At step 906, it is determined whether the strategy type and strategy ID exist in the library of parameter dependency model 206. If the strategy type and strategy ID do not exist in parameter dependency model 206, the A1 strategy is accepted at step 908, and the process ends. If the strategy type and strategy ID exist in parameter dependency model 206, it is determined at step 910 whether there is a dependency on any KPI or statistics. If there is no dependency, the process proceeds to step 914. If there is a dependency, at step 912, relevant O1 performance measurement (PM) statistics can be obtained from the associated E2 node 806 using an O1 performance measurement job, and the process proceeds to step 914.

[0118] At step 914, it is determined whether there are any dependencies on the O1 configuration of the associated E2 node 806. If there are no dependencies, the A1 policy is accepted at step 908, and the process ends. If there are dependencies, the E2 node O1 baseline configuration is obtained at step 916. At step 918, it is determined whether the policy conflicts due to dependencies according to parameter dependency model 206. For example, the dependency could be another A1 policy. If there are no conflicts, the A1 policy is accepted at step 908.

[0119] In the event of a conflict, the mitigation rule set 208 is checked at step 920. If, at step 922, the mitigation rule set 208 does not allow policy acceptance, then at step 924, the A1 policy is rejected. If the mitigation rule set 208 allows policy acceptance, then at step 926, it is determined whether the mitigation rule set 208 needs to roll back another A1 policy. If no rollback is needed, then at step 928, the A1 policy is accepted. If a rollback is needed, then at step 930, a conditional success indication is sent to rApp 804a, and at step 932, the rApp application that set the relevant A1 policy is notified to roll back the policy. At step 934, it is determined whether other applications (such as rApp 804b) have accepted the requested change. If rApp 804b does not accept the requested change, then at step 936, rApp 804a is notified that the A1 policy change has been rejected. If rApp 804b has accepted the requested change, then at step 938, rApp 804a is notified that the A1 policy change has been accepted. The process then ends.

[0120] Figures 9C-9D The illustration shows a detailed process flow of conflict detection and mitigation of O1 and O2 parameters by a non-RT RIC 800 using a parameter dependency model 206 and a mitigation rule set 208 according to an embodiment of the present disclosure. In one embodiment, the O1 parameter can be identified by the xPath configured for O1. In one embodiment, the O2 parameter can be identified by a configured HTTP resource uniform resource identifier (URI).

[0121] Initially, at step 942, a request for changes to the O1 / O2 parameters can be received from the non-RT RIC 800. At step 944, the parameters can be identified based on the O1 CM xPath or the O2 resource URI.

[0122] At step 946, it is determined whether the parameter exists in the library of parameter dependency model 206. If the parameter does not exist in parameter dependency model 206, the parameter change is accepted at step 948, and the process ends. If the parameter exists in parameter dependency model 206, it is determined at step 950 whether the parameter is dependent on any KPI or statistics. If there is no dependency, the process proceeds to step 954. If there is a dependency, at step 952, the relevant O1 performance measurement (PM) can be obtained from the associated E2 node 806, and the process proceeds to step 954.

[0123] At step 954, it is determined whether the parameter value conflicts due to dependency based on parameter dependency model 206. For example, the dependency could be another O2 or O1 parameter or a KPI. If there is no conflict, the parameter change is accepted at step 948. If there is a conflict, the mitigation rule set 208 is checked at step 956.

[0124] If, at step 958, the mitigation rule set 208 does not allow the acceptance of a value, then at step 960, the parameter change is rejected. If, at step 962, the mitigation rule set 208 determines whether the relevant O2 / O1 parameters need to be changed to accept the change. If no change is needed, the parameter change is accepted at step 964. If a change is needed, then at step 966, a conditional success indication is sent to the non-RT RIC 800, and at step 968, rApp 804a is notified to set the relevant O2 / O1 parameters to the changed value. At step 970, it is determined whether other applications, such as rApp 804b, have accepted the requested change. If rApp 804b has not accepted the requested change, at step 972, the non-RT RIC 800 is notified that the parameter change has been rejected. If rApp 804b has accepted the requested change, at step 974, the non-RT RIC 800 is notified that the parameter change has been accepted. Then, the process ends.

[0125] Figure 10 The illustration shows another block diagram of a network controller 200 according to another embodiment of the present disclosure when the network controller 200 is a non-RT RIC 800. The non-RT RIC 800 includes the above-referenced... Figure 8 The non-RT RIC 800 components mentioned above. Figure 10 The non-RT RIC 800 depicted in the image can correspond to Figure 8 The non-RT RIC 800 shown, however, in Figure 10 In the illustrated embodiment, device 202 (corresponding to Figure 3 The device 202 itself is implemented at the application level as a special rApp, as shown in box 1002. Hereinafter, the special rApp may be referred to as CDMF rApp 1002. The functionality of the device 202 described above can be implemented using CDMF rApp 1002. Furthermore, the non-RT RIC 800 may include platform layer device 1004.

[0126] CDMF rApp 1002 performs conflict detection and mitigation based on parameter dependency model 206 and mitigation rule set 208. In one embodiment, platform layer device 1004 detects some simple direct conflicts at the platform level. Platform layer device 1004 forwards R1 RAN OAM-related service requests, O2-related service requests, or A1-related service requests from all conflict-managed rApps 804 to CDMF rApp 1002 for further processing, which may include detecting application-level conflicts, indirect conflicts, and implicit conflicts. Conflict detection and mitigation according to the illustrated embodiment allows for a reduction in the complexity of platform implementations for conflict management. Furthermore, conflict detection and mitigation functionality can be tightly coupled with applications loaded onto non-RT RIC platforms that are frequently updated by application vendors; moving conflict detection and mitigation functionality to the application layer will help improve lifecycle management efficiency and multi-vendor interoperability.

[0127] Regarding implicit conflicts, this disclosure provides a framework for continuously monitoring KPIs and coordinating a return to a stable state after identifying an unfavorable state for a KPI. Figure 11 A framework 1100 for coordination according to embodiments of the present disclosure is depicted. In one embodiment, the framework 1100 may be associated with a network controller 200, such as a near-RT RIC 300 or a non-RT RIC 800. In one embodiment, the framework 1100 may include an SMO 1102 connected to an O-cloud 1104 and an E2 node network function (NF) 1106. In one embodiment, the SMO 1102 may be configured to deploy a RAN function application 204, such as xApp 304, through an interface of the O-cloud 1104. In one embodiment, this interface may be an O2 DMS interface. Based on the framework 1100, a list of KPIs to be monitored and mitigation actions to be performed in the event of KPI non-compliance can be determined.

[0128] In one embodiment, RAN function applications 204 in multiple RAN function applications can be loaded via SMO 1102. Furthermore, a list of monitored KPIs and KPI target values ​​can be fed into SMO 1102 in an appropriate format, such as JSON or Extensible Markup Language (XML). After the deployment of the RAN function applications, SMO 1102 can be configured to periodically retrieve measurements or acquire flow measurements from associated E2 nodes and monitor KPI values. KPI values ​​can be compared to predefined target values. In one embodiment, the target values ​​are stored in memory 214. If it is determined that KPI values ​​do not consistently meet the predefined target values ​​over multiple monitoring periods, SMO 1102 can be configured to initiate a coordination action. In one embodiment, the monitoring period can be, for example, five monitoring periods of a predefined duration. In one embodiment, the triggered coordination action can be fed into SMO 1102 via a JSON / XML document. Thus, the effectiveness of RAN function applications 204 and KPI degradation are monitored. KPIs can be monitored after conflict resolution to ensure that resolution does not adversely affect the communication network. In the event of KPI downgrading, a rollback operation can be enabled, thereby resolving implicit conflicts.

[0129] Figure 12A The illustration depicts a process flow of a method 1200 for conflict detection and mitigation according to an embodiment of the present disclosure. In one embodiment, the steps of method 1200 may be performed by device 202, as referenced above. Figures 2-10 As stated above.

[0130] Initially, at step 1202, a request is received from a RAN function application (e.g., RAN function application 204a), which is one of multiple RAN function applications 204 associated with the network controlled in the O-RAN. The request may indicate a change in one or more parameters associated with the multiple RAN function applications 204.

[0131] At step 1204, it is determined whether a conflict will occur due to a change in one or more parameters. This determination can be based on parameter dependency model 206. The parameter dependency model defines the dependencies between multiple parameters associated with multiple RAN function applications 204.

[0132] In one embodiment, to determine whether the conflict will occur, method 1200 may include Figure 12BThe steps 1204a to 1204d are shown. At step 1204a, based on a received request from a RAN function application, one or more parameters associated with the request are identified. At step 1204b, it is determined whether the identified one or more parameters exist in parameter dependency model 206. At step 1204c, the method includes identifying whether one or more parameters are dependent on one or more of a KPI, policy parameter, configuration parameter, and control parameter associated with at least one of the plurality of RAN function applications 204 running in the network controller 200. The dependency of one or more parameters may be determined based on parameter dependency model 206. At step 1204d, based on the dependency of one or more parameters on the KPI, policy parameter, configuration parameter, and control parameter, it is determined whether a conflict will occur.

[0133] In one embodiment, after determining that a conflict will not occur due to a change in one or more parameters, the change in one or more parameters is accepted.

[0134] refer to Figure 12A In step 1206, when it is determined that a conflict will occur due to a change in one or more parameters, one or more coordination actions are triggered based on the mitigation rule set 208.

[0135] In one embodiment, one or more coordination actions include one or more of the following: stopping one or more RAN function applications 204, adjusting the configuration of one or more RAN function applications 204, and adjusting the operation of E2 nodes associated with network controller 200.

[0136] In one embodiment, method 1200 may include, in order to trigger one or more coordinated actions, a coordinated action. Figure 12C The steps 1206a to 1206g are shown. At step 1206a, the method includes: determining, based on the mitigation rule set 208, that acceptance of changes in one or more parameters is permitted. At step 1206b, the method includes: determining a requirement for changes in relevant parameters associated with at least one other RAN function application (e.g., RAN function application 204b) among a plurality of RAN function applications 204. At step 1206c, the method includes: sending a relevant parameter request to at least one other RAN function application (RAN function application 204b), the relevant parameter request indicating a request for acceptance of changes in relevant parameters.

[0137] At least one other RAN function application may accept or reject a request to change a relevant parameter. At step 1206d, the method includes: receiving a relevant parameter acceptance response from at least one other RAN function application, indicating that a change in the relevant parameter is accepted. At step 1206e, the method includes: accepting a change in one or more parameters in response to receiving the relevant parameter acceptance response.

[0138] At step 1206f, the method includes: receiving a related parameter rejection response from at least one other RAN function application, indicating that a change in a related parameter is rejected. At step 1206g, the method includes: rejecting a change in one or more parameters in response to receiving the related parameter rejection response.

[0139] In one embodiment, to trigger one or more coordinated actions, the method includes: determining, based on mitigation rule set 208, that acceptance of changes in one or more parameters is not permitted. Furthermore, the method includes: rejecting changes in one or more parameters.

[0140] Although Figures 12A-12C The steps described above are shown and described in a specific order, but according to various embodiments, these steps may appear in variations of the order. Furthermore, with Figures 12A-12C Detailed descriptions of each step have been included in the relevant section. Figures 2-10 The relevant descriptions are omitted here for the sake of brevity.

[0141] This disclosure provides apparatus and methods for conflict detection and mitigation. A flexible configuration for conflict detection, mitigation, and monitoring is provided, rather than hard-coded logic. A parameter dependency model and mitigation rule set can be loaded into the apparatus and integrated with network controllers (i.e., near-RT RICs and non-RT RICs). Direct and indirect conflicts can be resolved using the parameter dependency model and mitigation rule set. [1] An apparatus associated with a network controller in an Open Radio Access Network (O-RAN), the apparatus being configured to: Receive a request from one of the RAN function applications associated with the network controller, the request indicating a change in one or more parameters associated with the multiple RAN function applications; Based on a parameter dependency model associated with the device, it is determined whether a conflict will occur due to a change in one or more parameters, wherein the parameter dependency model defines the dependencies between multiple parameters associated with multiple RAN function applications; and After determining that a conflict will occur due to a change in one or more parameters, one or more coordination actions are triggered based on a set of mitigation rules associated with the parameter dependency model. [2] According to the apparatus of [1], in order to determine whether a conflict will occur, the apparatus is configured as follows: Based on the request received from the RAN function application, identify one or more parameters associated with the request; Determine whether one or more of the identified parameters exist in the parameter dependency model; Based on the parameter dependency model, it identifies whether one or more identified parameters are dependent on one or more of the following: key performance indicators (KPIs), policy parameters, configuration parameters, and control parameters associated with at least one of the device, controlled network function (E2 node), and multiple RAN function applications running in the network controller; and Based on the dependency of one or more parameters on one or more of the KPIs, strategy parameters, configuration parameters, and control parameters, determine whether a conflict will occur. [3] An apparatus according to either [1] or [2], wherein: Policy parameters, configuration parameters, and control parameters are exposed as parameters through one or more open interfaces. One or more open interfaces include one or more of the A1 interface, O1 interface, and E2 interface, and Controlled network functions (E2 nodes) include one or more of the following: RAN Distributed Unit (DU), RAN Centralized Unit Control Plane (CU-CP), and RAN Centralized Unit User Plane (CU-UP). [4] The apparatus according to any one of [1] to [3], wherein: The network controller is one of a near real-time radio access network intelligent controller (near RT-RIC) or a non-real-time radio access network intelligent controller (non-RT-RIC). When the network controller is a near-RT-RIC, multiple RAN function applications include xApp, and When the network controller is not RT-RIC, multiple RAN function applications include rApp. [5] According to the apparatus of [1], wherein the apparatus is further configured to: accept a change in one or more parameters after determining that a conflict will not occur due to a change in one or more parameters. [6] According to the apparatus of [1], the apparatus is configured to trigger one or more coordinated actions as follows: Based on the mitigation rule set, determine whether changes to one or more parameters are permitted. Determine the requirements for changes in relevant parameters associated with at least one other RAN function application from multiple RAN function applications; Send a related parameter request to at least one other RAN function application, the related parameter request indicating a request to accept changes in the related parameters; From at least one other RAN function application, receive a relevant parameter acceptance response indicating that a change in the relevant parameter is accepted; and In response to receiving relevant parameters, accept a response and accept changes to one or more parameters. [7] According to the apparatus of [5], wherein the apparatus is configured as follows: From at least one other RAN function application, receive a parameter rejection response indicating that a change in the relevant parameter is rejected; and After receiving a rejection response for the relevant parameters, reject the changes to one or more parameters. [8] According to the apparatus of [1], the apparatus is configured to trigger one or more coordinated actions as follows: Based on the mitigation rule set, determine that changes to one or more parameters are not permitted; and Reject changes to one or more parameters. [9] An apparatus according to any one of [1] to [8], wherein: When the network controller is a near-RT-RIC, one of the devices at the frame level or application level is included in the near-RT-RIC, and The parameter dependency model defines the dependency between the E2 parameter and the O1 parameter.

[10] An apparatus according to any one of [1] to [8], wherein: When the network controller is a non-RT-RIC, one of the devices at the frame level or application level is included in the non-RT-RIC, and The parameter dependency model defines the dependency between one or more of the parameters O1, O2, and A1.

[11] An apparatus according to any one of [1] to

[10] , wherein the parameter dependency model and the mitigation rule set are encoded in a machine-readable data format, and wherein the parameter dependency model is configured as one of the following: Automatically generated by one or more RAN function applications based on a generative artificial intelligence (AI) model, or It is generated by the operator during network design and linked to the device.

[12] According to the apparatus of [1], one or more of the coordinated actions include one or more of the following: stopping one or more RAN function applications among a plurality of RAN function applications, adjusting the configuration of one or more RAN function applications among a plurality of RAN function applications, and adjusting the operation of the E2 node associated with the network controller.

[13] A method comprising: Receive a request from a RAN function application, which is one of multiple RAN function applications associated with a controlled network in the Open Radio Access Network (O-RAN), and the request indicates a change in one or more parameters associated with the multiple RAN function applications. Based on a parameter dependency model, it is determined whether a conflict will occur due to a change in one or more parameters, where the parameter dependency model defines the dependencies between multiple parameters associated with multiple RAN function applications; and After determining that a conflict will occur due to a change in one or more parameters, one or more coordination actions are triggered based on a set of mitigation rules associated with the parameter dependency model.

[14] According to the method of

[13] , determining whether a conflict will occur includes: Based on the request received from the RAN function application, identify one or more parameters associated with the request; Determine whether one or more of the identified parameters exist in the parameter dependency model; Based on the parameter dependency model, it identifies whether one or more identified parameters are dependent on one or more of the following: key performance indicators (KPIs), policy parameters, configuration parameters, and control parameters associated with the network controller and at least one of the multiple RAN function applications running in the network controller; and Based on the dependency of one or more parameters on one or more of the KPIs, strategy parameters, configuration parameters, and control parameters, determine whether a conflict will occur.

[15] The method according to any one of

[13] to

[14] further includes: After determining that a conflict will not occur due to changes in one or more parameters, accept the changes in one or more parameters.

[16] According to the method of

[13] , triggering one or more coordinated actions includes: Based on the mitigation rule set, determine whether changes to one or more parameters are permitted. Determine the requirements for changes in relevant parameters associated with at least one other RAN function application from multiple RAN function applications; Send a related parameter request to at least one other RAN function application, the related parameter request indicating a request to accept changes in the related parameters; From at least one other RAN function application, receive a relevant parameter acceptance response indicating that a change in the relevant parameter is accepted; and In response to receiving relevant parameters, accept a response and accept changes to one or more parameters.

[17] The method according to

[16] includes: From at least one other RAN function application, receive a parameter rejection response indicating that a change in the relevant parameter is rejected; and After receiving a rejection response for the relevant parameters, reject the changes to one or more parameters.

[18] According to the method of

[13] , triggering one or more coordinated actions includes: Based on the mitigation rule set, determine that changes to one or more parameters are not permitted; and Reject changes to one or more parameters.

[19] According to the method of

[13] , one or more of the coordination actions include one or more of the following: stopping one or more RAN function applications in a plurality of RAN function applications, adjusting the configuration of one or more RAN function applications in a plurality of RAN function applications, and adjusting the operation of the E2 node associated with the network controller.

[20] According to any one of

[13] to

[19] , wherein: Policy parameters, configuration parameters, and control parameters are exposed as parameters through one or more open interfaces, including one or more of the A1, O1, and E2 interfaces. The network controller is one of a near real-time radio access network intelligent controller (near RT-RIC) or a non-real-time radio access network intelligent controller (non-RT-RIC). Multiple RAN function applications include one of xApp and rApp. The parameter dependency model and mitigation rule set are encoded in a machine-readable data format, and The parameter dependency model is configured to be automatically generated by one or more RAN function applications based on a generative artificial intelligence (AI) model, or generated by the operator during network design.

[0142] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and performs network management functions to control elements. These elements can be at least one of a hardware device or a combination of a hardware device and a software module.

[0143] It should be understood that terms ending with "unit" or "module" can refer to a unit used to perform at least one function or operation, and can be implemented in hardware, software, or a combination of hardware and software.

[0144] While this disclosure is described in specific language, it is not intended to impose any limitations. As will be apparent to those skilled in the art, various working modifications can be made to the method to achieve the inventive concept taught herein.

[0145] The accompanying drawings and the foregoing description provide examples of embodiments. Those skilled in the art will understand that one or more of the described elements can be well combined into a single functional element. Alternatively, certain elements may be separated into multiple functional elements. Elements in one embodiment may be added to another embodiment. For example, the order of the processes described herein may be changed and is not limited to the manner described herein.

[0146] Furthermore, the actions in any flowchart do not need to be executed in the order shown; nor is it necessary to execute all actions. Additionally, actions that do not depend on other actions can be executed in parallel with other actions. The scope of the embodiments is by no means limited to these specific examples. Many variations can exist, whether explicitly given in the specification, such as differences in structure, size, and material use. The scope of the embodiments is at least as broad as that given by the following claims.

[0147] The technical solutions for the benefits, other advantages, and problems have been described above with reference to specific embodiments. However, these technical solutions for the benefits, advantages, and problems, as well as any (multiple) components that may cause any benefit, advantage, or technical solution to occur or become more apparent, should not be construed as key, essential, or essential features or components of any or all claims.

[0148] The description of the specific embodiments above will fully reveal the general nature of the embodiments herein, enabling others to readily modify and adapt such specific embodiments to various applications by applying present knowledge without departing from the general concept. Therefore, such adaptations and modifications should and are intended to be understood within the equivalent meaning and scope of the disclosed embodiments. It should be understood that the wording or terminology used herein is for descriptive purposes and not for limitation. Therefore, although embodiments herein have been described according to at least one embodiment, those skilled in the art will recognize that the embodiments herein can be practiced with modifications within the spirit and scope of the embodiments described herein.

Claims

1. An apparatus associated with a network controller in an Open Radio Access Network (O-RAN), the apparatus being configured to: Receive a request from one of the RAN function applications associated with the network controller, the request indicating a change in one or more parameters associated with the multiple RAN function applications; Based on a parameter dependency model associated with the device, it is determined whether a conflict will occur due to the change in one or more parameters, wherein the parameter dependency model defines the dependencies between multiple parameters associated with the multiple RAN function applications; as well as After determining that the conflict will occur due to the change in one or more parameters, one or more coordination actions are triggered based on a set of mitigation rules associated with the parameter dependency model.

2. The apparatus of claim 1, wherein, in order to determine whether the conflict will occur, the apparatus is configured to: Based on the request received from the RAN function application, identify the one or more parameters associated with the request; Determine whether the identified one or more parameters exist in the parameter dependency model; Based on the parameter dependency model, identify whether the identified one or more parameters are dependent on one or more of the following: key performance indicators (KPIs), policy parameters, configuration parameters, and control parameters associated with at least one of the device, the controlled network function (E2 node), and the plurality of RAN function applications running in the network controller; as well as Based on the dependence of one or more of the parameters on one or more of the KPI, the strategy parameters, the configuration parameters, and the control parameters, it is determined whether the conflict will occur.

3. The apparatus according to claim 2, wherein: The strategy parameters, configuration parameters, and control parameters are exposed as parameters through one or more open interfaces. The one or more open interfaces include one or more of the A1 interface, O1 interface, and E2 interface, and The controlled network function (E2 node) includes one or more of the following: RAN Distributed Unit (DU), RAN Centralized Unit Control Plane (CU-CP), and RAN Centralized Unit User Plane (CU-UP).

4. The apparatus according to claim 1, wherein: The network controller is one of a near real-time radio access network intelligent controller (near RT-RIC) or a non-real-time radio access network intelligent controller (non-RT-RIC). When the network controller is the near-RT-RIC, the multiple RAN function applications include xApp, and When the network controller is the non-RT-RIC, the multiple RAN function applications include rApp.

5. The apparatus of claim 1, wherein the apparatus is further configured to: accept the change in one or more parameters after determining that the conflict will not occur due to the change in the one or more parameters.

6. The apparatus of claim 1, wherein in order to trigger the one or more coordinated actions, the apparatus is configured to: Based on the mitigation rule set, it is determined whether the acceptance of the change in one or more parameters is permitted. Determine the requirement for changes in relevant parameters associated with at least one other RAN function application from the plurality of RAN function applications; Send a related parameter request to the at least one other RAN function application, the related parameter request indicating a request to accept the change in the related parameters; From the at least one other RAN function application, receive a relevant parameter acceptance response indicating that the change in the relevant parameters is accepted; as well as In response to receiving the relevant parameters, accept the change in one or more of the parameters.

7. The apparatus of claim 6, wherein the apparatus is configured to: From the at least one other RAN function application, receive a relevant parameter rejection response indicating that the change in the relevant parameter is rejected; and Upon receiving a rejection response for the relevant parameters, the change in one or more of the parameters is rejected.

8. The apparatus of claim 1, wherein in order to trigger the one or more coordinated actions, the apparatus is configured to: Based on the mitigation rule set, it is determined that the acceptance of the change in one or more parameters is not permitted; and Reject the change in one or more of the parameters.

9. The apparatus according to claim 1, wherein: When the network controller is the near-RT-RIC, the device is included in the near-RT-RIC at either the frame level or the application level, and The parameter dependency model defines the dependency between the E2 parameter and the O1 parameter.

10. The apparatus according to claim 1, wherein: When the network controller is the non-RT-RIC, the device is included in the non-RT-RIC at either the frame level or the application level, and The parameter dependency model defines the dependency between one or more of the O1, O2, and A1 parameters.

11. The apparatus of claim 1, wherein the parameter dependency model and the mitigation rule set are encoded in a machine-readable data format, and wherein the parameter dependency model is configured as one of the following: Automatically generated by one or more RAN function applications based on a generative artificial intelligence (AI) model, or It is generated by the operator during network design and linked to the device.

12. The apparatus of claim 1, wherein the one or more coordination actions include one or more of the following: stopping one or more of the plurality of RAN function applications, adjusting the configuration of one or more of the plurality of RAN function applications, and adjusting the operation of the E2 node associated with the network controller.

13. A method comprising: A request is received from a RAN function application, which is one of multiple RAN function applications associated with a controlled network in an Open Radio Access Network (O-RAN), and the request indicates a change in one or more parameters associated with the multiple RAN function applications. Based on a parameter dependency model, it is determined whether a conflict will occur due to the change in one or more parameters, wherein the parameter dependency model defines the dependencies between multiple parameters associated with the multiple RAN function applications; as well as After determining that the conflict will occur due to the change in one or more parameters, one or more coordination actions are triggered based on a set of mitigation rules associated with the parameter dependency model.

14. The method of claim 13, wherein determining whether the conflict will occur comprises: Based on the request received from the RAN function application, identify the one or more parameters associated with the request; Determine whether the identified one or more parameters exist in the parameter dependency model; Based on the parameter dependency model, identify whether the identified one or more parameters are dependent on one or more of the following: key performance indicators (KPIs), policy parameters, configuration parameters, and control parameters associated with the network controller and at least one of the plurality of RAN function applications running in the network controller; as well as Based on the dependence of one or more of the parameters on one or more of the KPI, the strategy parameters, the configuration parameters, and the control parameters, it is determined whether the conflict will occur.

15. The method of claim 13, further comprising: After determining that the conflict will not occur due to the change in the one or more parameters, accept the change in the one or more parameters.

16. The method of claim 13, wherein triggering the one or more coordinated actions comprises: Based on the mitigation rule set, it is determined whether the acceptance of the change in one or more parameters is permitted. Determine the requirement for changes in relevant parameters associated with at least one other RAN function application from the plurality of RAN function applications; Send a related parameter request to the at least one other RAN function application, the related parameter request indicating a request to accept the change in the related parameters; From the at least one other RAN function application, receive a relevant parameter acceptance response indicating that the change in the relevant parameters is accepted; as well as In response to receiving the relevant parameters, accept the change in one or more of the parameters.

17. The method of claim 16, comprising: From the at least one other RAN function application, receive a relevant parameter rejection response indicating that the change in the relevant parameters is rejected; as well as Upon receiving a rejection response for the relevant parameters, the change in one or more of the parameters is rejected.

18. The method of claim 13, wherein triggering the one or more coordinated actions comprises: Based on the mitigation rule set, it is determined that the acceptance of the change in one or more parameters is not allowed; as well as Reject the change in one or more of the parameters.

19. The method of claim 13, wherein the one or more coordination actions include one or more of the following: stopping one or more of the plurality of RAN function applications, adjusting the configuration of one or more of the plurality of RAN function applications, and adjusting the operation of the E2 node associated with the network controller.

20. The method of claim 13, wherein: The policy parameters, configuration parameters, and control parameters are exposed as parameters through one or more open interfaces, including one or more of the A1, O1, and E2 interfaces. The network controller is one of a near real-time radio access network intelligent controller (near RT-RIC) or a non-real-time radio access network intelligent controller (non-RT-RIC). The multiple RAN function applications include one of xApp and rApp. The parameter dependency model and the mitigation rule set are encoded in a machine-readable data format, and The parameter dependency model is configured to be automatically generated by one or more RAN function applications based on a generative artificial intelligence (AI) model, or generated by the operator during network design.

Images