Conflict management in a network

Abstract

Provided are apparatus, method, and device for automatically manage conflicts. According to example embodiments, the apparatus may be configured to; obtain a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtain a conflict policy definition defining priorities of the plurality of applications relative to each other; and determine, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

Description

CONFLICT MANAGEMENT IN A NETWORK CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to Singaporean Patent Application No. 10202400583X, filed with the Singaporean Patent Office on March 1, 2024, the entire contents of which are incorporated herein by reference. FIELD

[0002] The present disclosure relates to conflict management in a network. BACKGROUND

[0003] The information disclosed in this background section is only for enhancement of understanding of the general background of the disclosure and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0004] A radio access network (RAN) is an important component in a telecommunications system, as it connects end-user devices (or user equipment) to other parts of the network. The RAN includes a combination of various network elements (NEs) that connect end-users to a core network. Further, the RAN is responsible for providing wireless access to mobile devices, as well as providing resources and guarantee mobility in the network. The RAN is also part of a mobile network that connects users to the core network and provides them with radio signals for communication and resource handling. It enables the transmission of data and voice between these devices and the core network over the air interface, using technologies such as LTE, 5G, etc. RANis responsible for managing the quality and coverage of a wireless network, and includes components such as base stations, cell towers, and other radio access infrastructure.

[0005] The RAN also contains various algorithms that together ensure the scheduling of the resources and guarantee the transmission and reception of the messages over the air interface (from the base station) in consideration of the channel quality and mobility requirements. Traditionally, hardware and / or software of a particular RAN is vendor specific.

[0006] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software to a telecommunications system. Since different vendors are involved, the type of hardware and / or software provided may also be different. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NE could be virtualized in software form (e.g., virtual machine (VM)-based), or could be in physical hardware form (e.g., non-VM based). In other words, the O-RAN technology provides openness to RAN, where multiple different vendors are involved to provide hardware and / or software to a telecommunications system. The main benefits of the openness in O-RAN include increased vendor diversity, reduced vendor lock-in, lower costs for network deployment and operation, and improved network performance. Vendor diversity is enabled by open interfaces defined in the O- RAN, through which different vendors can develop various parts of the framework or applications.

[0007] As a result, the openness in O-RAN architecture allows for different vendors to develop a plurality of different applications (e.g., rApps, xApps, Network Functions, algorithms, and the like) and deploy them to the network (e.g., in the Near-RT RIC, Non-RT RIC, and / or the like), where such plurality of different applications interact and perform various operations together within the network.SUMMARY

[0008] Example embodiments of the present disclosure automatically manage conflicts in a network. As such, example embodiments of the present disclosure allow one or a combination of mechanisms to be appropriately selected for solving a specific type of conflicts, while considering a wide range of types of conflicts.

[0009] According to example embodiments, an apparatus is provided. The apparatus may be configured to: obtain a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtain a conflict policy definition defining priorities of the plurality of applications relative to each other; and determine, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

[0010] According to example embodiments, a method is provided. The method may include: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to each other; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

[0011] According to example embodiments, a non-transitory computer-readable recording medium is provided. The non-transitory computer-readable recording medium may have recordedthereon instructions executable by an apparatus to cause the apparatus to perform a method including: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to each other; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

[0012] Additional aspects will be set forth in part in the description that follows and, in part, will be apparent from the description, or may be realized by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Features, aspects, and advantages of embodiments of the disclosure will be described below with reference to the accompanying drawings, in which like reference numerals denote like elements, and wherein:

[0014] FIG. 1A illustrates an example system architecture, according to one or more example embodiments;

[0015] FIG. 1B illustrates an example system architecture, according to one or more example embodiments;

[0016] FIG. 2 illustrates an example system architecture, according to one or more example embodiments;

[0017] FIG. 3 illustrates a block diagram of example components in a RAN Intelligent Controller (RIC), according to one or more example embodiments;

[0018] FIG. 4 illustrates a flow diagram of an example method for managing conflicts, according to one or more example embodiments;

[0019] FIG. 5 illustrates an example conflict matrix, according to one or more example embodiments;

[0020] FIG. 6 illustrates a flow diagram of an example method for determining conflict mitigation schedule, according to one or more example embodiments;

[0021] FIG. 7 illustrates a flow diagram of an example method for performing a change impact evaluation, according to one or more example embodiments;

[0022] FIG. 8 illustrates a flow diagram of an example method for performing a rollback and oscillation mitigation, according to one or more example embodiments; and

[0023] FIG.9 illustrates an example embodiment of an apparatus, according to one or more example embodiments. DETAILED DESCRIPTION

[0024] The following detailed description of example embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations. Further, 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). Additionally, the flowchart and description of operations provided belowrelate to one of the various embodiments. It should be noted that it is possible to make other embodiments that do not exactly match the flowchart and its description. It is understood that in other embodiments one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least in part). Further, the order of one or more operations may be switched, as long as these modifications may not affect the resulting scope of the invention.

[0025] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, software, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0026] Even though particular combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of implementations includes each dependent claim in combination with every other claim in the claim set.

[0027] No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, 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.” Also,as used herein, the terms “has,” “have,” “having,” “include,” “including,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise. Furthermore, expressions such as “at least one of [A] and [B],” “[A] and / or [B],” or “at least one of [A] or [B]” are to be understood as including only A, only B, or both A and B. Further still, where only one item is intended, the term “one” or similar language is used.

[0028] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0029] It shall be noted that, descriptions of example embodiments of the present disclosure may include terms and names defined in one or more standard organizations, such as the 3rd Generation Partnership Project (3GPP) standard organization, the European Telecommunications Standards Institute (ETSI) standard organization, the Open Radio Access Network (O-RAN) Alliance standard organization, and the like. For instance, the terms “rApp”, “xApp”, “Non-RT RIC”, “Near-RT RIC”, and the like, as well as the associated features and operations, are to be interpreted as consistent with those specified in one or more technical specifications.

[0030] Further, although some embodiments of the present disclosure may be described herein with reference specific components of 5G system, it can be understood that the scope of the present disclosure should not be limited thereto. Specifically, example embodiments of the present disclosure may also apply to any suitable network elements in any suitable telecommunicationsystem, such as a 4G LTE system, a 6G system, and the like, without departing from the scope of the present disclosure.

[0031] As described above in relation to FIG. 1, the O-RAN technology has emerged to provide openness to RAN, where multiple different vendors are involved to provide hardware and / or software to a telecommunications system. The openness in O-RAN architecture allows for different vendors to develop a plurality of different applications (e.g., rApps, xApps, Network Functions, algorithms, and the like) and deploy them to the network (e.g., in the Near-RT RIC, Non-RT RIC, and / or the like), where such plurality of different applications interact and perform various operations together within the network.

[0032] In this regard, since the plurality of applications are developed by different vendors, their operations and deployment may conflict with each other.

[0033] In the related art, conflicts between different applications are generally categorized into three types: Direct Conflict (DRC); Indirect Conflict (INC); and Implicit Conflict (IMC). The DRC refers to a type of conflict where different applications make decisions that affect the same set of parameters. For example, to optimize coverage and / or to compensate for cell outage, two different applications may make different conflicting changes to an antenna’s tilt. The INC refers to a type of conflict where different applications make decisions to modify parameters that affect the same operation (i.e., through dependencies). For example, two different applications may assign the same Physical Cell Identity (PCI) to two different cells, thereby causing mobility management errors. The IMC refers to a type of conflict where different applications make decisions with conflicting objectives and goals. For example, an application may influence RAN operations with the goal of optimizing interference at the expense of service offering to the users,while another application may influence RAN operations with the goal of improving the service offering to the users at the expense of interference.

[0034] When any of the above categorized conflicts are detected, one or more of the conflicting applications is turned off to allow another conflicting application to perform its operation first. Once the first conflicting application to perform its operation, another conflicting application may then be allowed to perform its operation.

[0035] In this regard, the above approach for conflict management in the related art may have the following shortcomings. The above categorized types of conflicts do not consider conflicts where changes may result in repetitive (oscillating) changes, or conflicts that affect the same geographical areas. Further, the above solution for turning off / on the conflicting applications may not be appropriate for resolving certain types of conflicts and / or may not be sufficient to fully resolve the conflict without additional mechanisms.

[0036] Accordingly, system, methods, devices, and the like, provided in the example embodiments of the present disclosure automatically manage conflicts in a network.

[0037] According to example embodiments, the apparatus may obtain a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications, and obtain a conflict policy definition defining priorities of the plurality of applications relative to each other. Further, the apparatus may then determine, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

[0038] Ultimately, example embodiments of the present disclosure automatically manage conflicts in a network, which allows for one or a combination of mechanisms to be appropriately selected for solving a specific type of conflicts, while considering wide range of types of conflicts.

[0039] It is contemplated that features, advantages, and significances of example embodiments described hereinabove are merely a portion of the present disclosure, and are not intended to be exhaustive or to limit the scope of the present disclosure.

[0040] Further descriptions of the features, components, configuration, operations, and implementations of the system of the present disclosure, according to one or more example embodiments, are provided in the following. Example System Architecture

[0041] FIG. 1A illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 1A, the system architecture may include at least one Service Management and Orchestration (SMO) framework 102 that includes at least one non-real- time RAN Intelligent Controller (Non-RT RIC) 104, at least one near-real-time RIC (Near-RT RIC) 106, at least one O-RAN Distributed Unit (O-DU) 108, at least one O-RAN Radio Unit (O- RU) 110, at least one O-RAN Centralized Unit (O-CU) 112, and at least one O-Ran Cloud (O- Cloud) 114. The components may be communicatively coupled to another component(s) within the system architecture via a respective interface(s) shown in FIG. 1A.

[0042] It is contemplated that the system architecture may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some implementations, the system architecture may further include an open evolved NodeB (O-eNB) that is communicatively coupled to the SMOframework 102 and the Near-RT RIC 106, the system architecture may include a plurality of O- DUs 108 each of which is communicatively coupled to the O-CU 112, and the like.

[0043] The RAN functions in the system may be controlled and optimized by at least one RIC. The RIC may be a software-defined component that implements modular applications to facilitate the multivendor operability, as well as to automate and optimize RAN operations. As shown in FIG.1A, the RIC may be divided into two types, i.e., the Non-RT RIC 104 and the Near- RT RIC 106. In the following, descriptions of the Non-RT RIC 104 are provided, followed by the descriptions of the Near-RT RIC 106.

[0044] The Non-RT RIC 104 may refer to a logical function within the SMO framework 102 that drives the content carried across the A1 interface to enable non-real-time control and optimization of RAN elements and resources. The A1 interface may refer to a logical interface between the Non-RT RIC 104 and the Near-RT RIC 106, which enables the Non-RT RIC 104 to provide policy-based guidance (objective, resource) to the Near-RT RIC 106 and enables the Near- RT RIC 106 to provide one or more feedbacks to the Non-RT RIC 104 to monitor the status of one or more policies.

[0045] In some example, implementations, the Non-RT RIC 104 may be the control point of a non-real-time control loop and may operate on a timescale greater than 1 second within the SMO framework 102. The functionalities of the Non-RT RIC 104 may include, for example, providing policy-based guidance and enrichment across the A1 interface, performing data analytics, Artificial Intelligence / Machine Learning (AI / ML) models training and inference for RAN optimization, and / or recommending configuration management actions. As further described below, the Non-RT RIC 104 may access or communicate with other SMO frameworkfunctionalities or components via A1 interface, O1 interface, O2 interface, and one or more interfaces associated with one or more open fronthaul planes.

[0046] According to example embodiments, the functionalities of the Non-RT RIC 104 may be implemented through at least one modular, Non-RT RIC application, such as an rApp. Example descriptions related to the rApp are provided below in relation to FIG. 2.

[0047] In addition to the communication with the Near-RT RIC 106 via the A1 interface, the SMO framework 102 (as well as the Non-RT RIC 104 and / or the rApp implemented therein) may communicate with the O-CU 112, the O-DU 108, and the O-RU 110 via the O1 interface (not shown). In this regard, the O1 interface may refer to a logical interface between the SMO framework 102, the Near-RT RIC 106, the O-CU 112, the O-DU 108, and the O-RU 110, which enables the SMO framework 102 (as well as the Non-RT RIC 104 and the rApp implemented therein) to provide Fault, Configuration, Accounting, Performance, and Security (FCAPS) and other management operations, such as network monitoring, network discovery, and the like, to the Near-RT RIC 106, the O-CU 112, the O-DU 108, and the O-RU 110. Additionally, the O1 interface enables the Near-RT RIC 106, the O-CU 112, the O-DU 108, and the O-RU 110 to provide information or observable(s) that may be utilized by the Non-RT RIT 104 (or the rApp) to manage policies, to train one or more AI / ML models, and the like. According to example embodiments in which the O-eNB is included in the system architecture, the SMO framework may be communicatively coupled to the O-eNB via the O1 interface.

[0048] Further, the SMO framework 102 (as well as the Non-RT RIC 104 and / or the rApp implemented therein) may communicate with the O-Cloud 114 via the O2 interface. In this regard, the O2 interface may refer to a logical interface between the SMO framework 102 and the O-Cloud114, which may be a collection of physical RAN nodes that host the Non-RT RIC 104, the Near- RT RIC 106, the O-CU 112, and the O-DU 108, the supporting software components (e.g., the operating systems and runtime environments), and the SMO framework 102 itself. In other words, the SMO framework 102 may manage the O-Cloud 114 from within, and the O2 interface may be the interface between the SMO framework 102 and the O-Cloud 114 it resides in. Through the O2 interface, the SMO framework 102 (as well as the Non-RT RIC 104 and / or the rApp implemented therein) may provide infrastructure management services (IMS) and deployment management services (DMS) for the O-Cloud 114. According to example embodiments, the O-Cloud 114 may be a set of hardware and software configured to provide cloud computing resources and virtualization infrastructure to host and run O-RAN network functions.

[0049] Furthermore, the SMO framework 102 (as well as the Non-RT RIC 104 and / or the rApp implemented therein) may communicate with the O-RU 110 via an open fronthaul (O-FH) management plane (M-Plane) interface (not shown). In this regard, the O-FH M-Plane may enable the SMO framework 102 (as well as the Non-RT RIC 104 and / or the rApp implemented therein) to perform one or more FCAPS operations on the O-RU 110.

[0050] Next, the descriptions of the Near-RT RIC 106 are provided. The Near-RT RIC 106 may refer to a logical function that enables near-real-time control and optimization of RAN elements and resources. For instance, the Near-RT RIC 106 may provide the near-real-time control and optimization via fine-grained (e.g., UE basis, Cell basis) data collection and actions over the E2 interface. In some example, implementations, the Near-RT RIC 106 may operate on a timescale between 10 milliseconds and 1 second and may be coupled with the O-CU 112 and the O-DU 108via the E2 interface. The Near-RT RIC 106 may use the E2 interface to control the underlying RAN elements (E2 nodes / network functions (NFs)) over a near-real-time control loop.

[0051] As described above, the O1 interface may refer to a logical interface between the SMO framework 102 and the Near-RT RIC 106. According to example embodiments, the O1 interface may be an Operation and Maintenance interface implemented through standards or proprietary interfaces using the Network Configuration Protocol (NETCONF) or any other network management protocol. According to example embodiments, the network management protocol may be used for Provisioning Management Services to create: Managed Object Instance, Delete Managed Object Instance, Modify Managed Object Instance Attributes and / or Read Managed Object Instance Attributes. According to example embodiments, the O1 interface may implement at least one of a plurality of services including: fault supervision management, performance assurance management, trace management, file management, heartbeat management, physical network function (PNF) startup and registration management, and / or PNF software management. According to example embodiments, the O1 interface may include reporting Performance Management (PM) counters or Fault Management (FM) alarms from the Near-RT RIC 106 to the SMO framework 102.

[0052] Further, as described above, the A1 interface may refer to a logical interface between the Non-RT RIC 104 and the Near-RT RIC 106. According to example embodiments, the A1 interface may enable the Non-RT RIC 104 to provide policy-based guidance, Machine Learning (ML) model management and enrichment information to the Near-RT RIC 106 for optimizing the RAN. According to example embodiments, the A1 interface may include a protocol stack including one or a plurality of layers such as Internet Protocol (IP), Transmission ControlProtocol (TCP), Hypertext Transfer Protocol Secure (HTTPS), JavaScript Object Notation (JSON) and / or any other proprietary or standards layers.

[0053] According to example embodiments, the Near-RT RIC 106 may host one or more applications, such as the xApp, to implement functions such as quality of service (QoS) optimization, mobility optimization, slicing optimization, interference mitigation, load balancing, security, and the like. Example descriptions related to the xApp are provided below in relation to FIG. 2.

[0054] Next, the descriptions of the O-CU 112, the O-DU 108, and the O-RU 110 are provided. Generally, the O-CU 112, the O-DU 108, and the O-RU 110 may constitute a base station, such as a gNodeB (gNB) of 5G NR or a node in Next Generation Radio Access Network (NG- RAN), an Evolved Node B (eNodeB) of a 4G LTE network, a base station of a 6G network, and the like.

[0055] The communication between the O-CU 112 and the O-DU 108 may be performed via an F1 interface, while the communication between the O-DU 108 and the O-RU 110 may be performed via one or more O-FH Control (C), User (U), Synchronization (S), and Management (M) plane interfaces. In some implementations, the C, U, and S planes may be consolidated and referred to as the “CUS-plane”. According to example embodiments, the system may include a plurality of O-DUs 108, and the O-CU 112 may be communicatively coupled to the plurality of O-DUs 108 via the F1 interface. Similarly, the system may include a plurality of O-RUs 110, and the O-DU 108 may be communicatively coupled to the plurality of O-RUs 110 via one or more of the O-FH C / U / S / M plane interfaces.

[0056] According to example embodiments, the O-CU 112 and the O-DU 108 may be defined in software form and may be deployed in one or more network nodes. For instance, the O- CU 112 and the O-DU 108 may be deployed in one or more servers in the form of virtualized network function (VNF), containerized and / or cloud-native function (CNF), and the like. According to example embodiments, the O-CU 112 and the O-DU 108 may be deployed in the same network node (e.g., same server) and / or may be located at a similar geographical location (e.g., be deployed in different servers in the same data center). According to example embodiments, the O-CU 112 and the O-DU 108 may be deployed in different network nodes and / or may be located at different geographical locations. For instance, the O-CU 112 may be deployed in one or more central servers (i.e., servers in one or more central data centers), and the O-DU 108 may be deployed in one or more edge servers (i.e., servers in one or more edge data centers).

[0057] The O-DU 108 may receive radio signals from an end user (via one or more UEs and one or more cells) and may provide operation or support for lower layers of protocol stacks RLC layer 126, MAC layer 128, High-Physical layer 130, and Low-Physical layer 132 accordingly. As an example, the O-DU 108 may perform one or more scheduling operations. The O-CU 112 may communicatively couple the O-DU 108 to a core network (e.g., 4G Evolved Packet Core (EPC) network, 5G Core network, etc.) and may receive the radio signals from the O-DU 108, thereby providing operation or support for higher layers of protocol stacks SDAP layer 120, RRC layer 122, and PDCP layer 124 accordingly. The O-CU 112 may be disaggregated into the O-CU control plane (C-Plane) 118 and the O-CU user plane (U-Plane) 116.

[0058] Further, a single O-DU 108 may host or serve multiple network cells formed by multiple O-RUs 110. According to example embodiments, the O-DU 108 may implement variousradio technologies, such as massive multiple-input multiple-output (MIMO), beamforming, and the like, to optimize radio communication among the multiple cells and the O-CU 112. In some implementations, the O-DU 108 may concurrently host or serve hundreds of cells at a time.

[0059] The O-RU 110 may be a physical node that converts radio signals from antennas to digital signals that can be transmitted over the Front Haul to the O-DU 108. In this regard, a network cell described herein may correspond to one or more radio units responsible for providing wireless coverage and signal transmission within the network cell. The network cell may include a macro cell, a micro cell, a pico cell, a femto cell, and / or any other suitable type of network cell. Each of the cells may have an associated coverage area, in which at least one O-RU 110, at least one antenna system, and any other suitable type of transport network element (TNE), may be deployed therein.

[0060] FIG. 1B illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG.1B, the system architecture in FIG.1B may be similar to the system architecture in FIG. 1A with an addition of a real-time RIC (RT RIC) 134.

[0061] The RT RIC 134 may operate with a shorter time delay compared to the Near-RT RIC 106. According to example embodiments, the RT RIC 134 may operate over a real-time control loop with a latency of less than 10 milliseconds (ms). The RT RIC 134 may include interfaces K1, K2, K3, K4, and K5.

[0062] The K1 interface may refer to a logical interface between the RT RIC 134 and the SMO framework 102. According to example embodiments, the K1 interface may be an Operation and Maintenance interface implemented through standards or proprietary interfaces using the Network Configuration Protocol (NETCONF) or any other network management protocol.According to example embodiments, the network management protocol may be used for Provisioning Management Services to create: Managed Object Instance, Delete Managed Object Instance, Modify Managed Object Instance Attributes and / or Read Managed Object Instance Attributes. According to example embodiments, the K1 interface may implement at least one of a plurality of services including: fault supervision management, performance assurance management, trace management, file management, heartbeat management, physical network function (PNF) startup and registration management, and / or PNF software management. According to example embodiments, the K1 interface may include reporting Performance Management (PM) counters or Fault Management (FM) alarms from the RT RIC 134 to the SMO framework 102.

[0063] The K2 interface may refer to a logical interface between the Non-RT RIC 104 and the RT RIC 134. According to example embodiments, the K2 interface may enable the Non-RT RIC 104 to provide policy-based guidance, Machine Learning (ML) model management and enrichment information to the RT RIC 134 for optimizing the RAN. According to example embodiments, the K2 interface may include a protocol stack including one or a plurality of layers such as Internet Protocol (IP), Transmission Control Protocol (TCP), Hypertext Transfer Protocol Secure (HTTPS), JavaScript Object Notation (JSON) and / or any other proprietary or standards layers.

[0064] The K3 interface may refer to a logical interface between the Near-RT RIC 106 and the RT RIC 134. According to example embodiments, the K3 interface may enable the Near-RT RIC 106 to provide policy-based guidance, Machine Learning (ML) model management and enrichment information to the RT RIC 134 for optimizing the RAN. According to exampleembodiments, the K3 interface may include a protocol stack including one or a plurality of layers such as Internet Protocol (IP), Transmission Control Protocol (TCP), Hypertext Transfer Protocol Secure (HTTPS), JavaScript Object Notation (JSON) and / or any other proprietary or standards layers. According to example embodiments, the K3 interface may be modelled as the O-RAN standard-compliant E2 interface (i.e., E2AP over SCTP).

[0065] The K4 interface may refer to a logical interface between the RT RIC 134 and the O-DU 108. According to example embodiments, the K4 interface may enable different services of the RT RIC 134 (e.g., report, insert, control, and policy) and support various functions, such as interface management, service update, and the like.

[0066] The K5 interface may refer to a logical interface between the RT RIC 134 and the O-RU 110. According to example embodiments, the K5 interface may be used for exchanging data and / or control information between the RT RIC 134 and the O-RU 110 by implementing the O- FH C / U / S / M planes.

[0067] FIG. 2 illustrates an example system architecture, according to one or more example embodiments. As illustrated in FIG. 2, the system architecture in FIG. 2 may be similar to the system architecture in FIG. 1B with the following changes. The O-DU 108 is a plurality of O-DUs 108 including O-DU 108-1 and O-DU 108-2, and the O-RU 110 is a plurality of O-RUs 110 including O-RU 110-1, O-RU 110-2, O-RU 110-3, and O-RU 110-4. Further, as shown in FIG.2, the Non-RT RIC 104 includes a RAN Application Platform (rApp) 202, the Near-RT RIC 106 includes an eXtended Application Platform (xApp) 204, and the RT RIC 134 includes a Next Generation Platform (zApp) 206. It may be understood that the above number of O-DUs, O-RUs,rApp, xApp, and zApp are provided as an example for descriptive purpose, and is not intended to limit the scope in any way. In particular, the number of the above elements can be any number.

[0068] The rApp 202 may be a standalone algorithm used in the management and / or control of the RAN. According to example embodiments, the rApp 202 may include applications designed to run on the Non-RT RIC 104, where the rApp 202 may leverage the functionalities available in the SMO framework 102 and / or the Non-RT RIC 104 to provide value added services related to RAN operation and optimization, such as policy management, radio resource management, data analytics, and providing enrichment information. Such value added services may help creation of policies that the Non-RT RIC 104 delivers down to the Near-RT RIC 106 through the A1 interface. According to example embodiments, the SMO framework 102 may support open software interfaces to facilitate rApp communications which run on the Non-RT RIC 104 software platforms.

[0069] According to example embodiments, the Non-RT RIC 104 may include a Non-RT RIC framework that may be configured to provide or implement one or more services to the rApp 202 through the R1 interface (not shown). The R1 interface may refer to an open logical interface between the rApp 202 and the Non-RT RIC framework. The R1 interface supports the exchange of data or information, as well as the collection and delivery of data between the rApp 202 and the Non-RT RIC framework. The one or more services, which may also be referred to as “R1 services” herein, may include policy management services, service registration and discovery services, authentication and authorization services, AI / ML workflow services, RAN OAM-related services, A1 related services, and O2 related services. The R1 interface allows multi-vendor rApps tomanage or add the R1 services, and facilitate inter-connection between rApps and Non-RT RIC framework supplied by different vendors.

[0070] The xApp 204 may be a standalone algorithm used in the management and / or control of the RAN. According to example embodiments, the xApp 204 may consist of one or more microservices, which may be independent of the Near-RT RIC 106 and may be provided by any third party. The E2 interface enables a direct association between the xApp 204 and other RAN functionalities (e.g., O-CU 112, O-DUs 108, etc.), thereby enabling the xApp 204 to provide information or data to the RAN functionalities for further utilization. According to example embodiments, the Near-RT RIC 106 may consist of multiple xApps 204 and a set of platform functions that are commonly used to support the specific functions hosted by the multiple xApps 204. In this regard, the Near-RT RIC platform may communicate with the xApps 204 via one or more application programming interfaces (APIs). Further, the Near-RT RIC platform may be configured to route A1 policy management messages to the registered xApps 204 based on A1 policy type and operator policies.

[0071] The zApp 206 may be a standalone algorithm used in the management and / or control of real-time control loop of the RAN.

[0072] FIG. 3 illustrates a block diagram of example components in a RAN Intelligent Controller (RIC) 302, according to one or more example embodiments. As illustrated in FIG. 3, the RIC 302 may include the following modules: at least one interface termination 304, at least one open Application Programming Interface (API) 306, at least two applications 308-1 and 308- 2 (collectively referred to as applications 308), at least one messaging infrastructure 310, at least one conflict management 312, at least one subscription management 314, at least one ArtificialIntelligence (AI) / Machine Learning (ML) engine 316, at least one sensor management 318, at least one shared data lake 320, at least one data exposure 322, at least one hardware management 324, and at least one Application Programming Interface (API) enhancement 326.

[0073] It is contemplated that the RIC 302 may include more / fewer components than illustrated, and / or may be configured in a different manner, without departing from the scope of the present disclosure. For instance, in some implementations, the RIC 320 may include a plurality of interface termination 304 corresponding to each of the interfaces of the RIC 302, a plurality of applications 306, and the like.

[0074] According to example embodiments, the RIC 302 may include one of: Non-RT RIC, Near-RT RIC, and RT RIC as described above in relation to FIG. 1 to FIG. 2.

[0075] The interface termination 304 may refer to a termination point of an interface connecting the RIC 302 to other elements within the network. For example, if the RIC 302 corresponds to the Near-RT RIC which is connected to the A1 interface, E2 interface, and the O1 interface, the interface termination 304 may be a plurality of interface terminations 304 including A1 interface termination, E2 interface termination, and the O1 interface termination.

[0076] The open API 306 may include an API that is exposed by the RIC 302 using the application 308.

[0077] The applications 308 may refer to an application, an algorithm, a network function, and the like used by the RIC 302 in the management and / or control of the RAN. According to example embodiments, the applications 308 may interact and obtain services from the RIC 302. According to example embodiments, the applications 308 may include one of rApp, xApp, and zApp as described above in relation to FIG. 1 to FIG. 2.

[0078] The messaging infrastructure 310 may refer to a messaging framework that enables the application 308 to communicate with the internal submodules of the RIC 302. The messaging infrastructure 310 may be implemented in any manner.

[0079] The conflict management 312 may be configured to manage (mitigate) one or more conflicts occurring between the applications 308. According to example embodiments, the one or more conflicts may be caused by different requests (i.e., change) initiated by different applications. The conflict management 312 may communicate with any one or more of the modules of the RIC 302 in order to manage the one or more conflicts. For example, the conflict management 312 may communicate with the subscription management 314 in order to obtain subscription and priority information, where such information may be utilized when managing the one or more conflict.

[0080] According to example embodiments, the conflict management 312 may be configured to manage one or more conflicts occurring between one of the applications 308 and an application outside of the RIC 320. For example, the RIC 302 may correspond to the Near-RT RIC and the conflict management 312 may be configured to manage one or more conflicts occurring between an xApp and an rApp. According to example embodiments, the conflict management 312 may be configured to manage one or more conflicts occurring between applications outside of the RIC 320. For example, the RIC 302 may correspond to the Near-RT RIC and the conflict management 312 may be configured to manage one or more conflicts occurring between a zApp and an rApp. According to example embodiments, the conflict management 312 may be configured to manage all conflicts occurring between any applications within the network.

[0081] The subscription management 314 may be configured to store subscription time information while the application 308 is onboarded. According to example embodiments, thesubscription time information may include but is not limited to access permissions (application priority) for the open API 306.

[0082] The AI / ML engine 316 may be configured to perform processes related to training and inference for AI / ML services. According to example embodiments, the AI / ML engine 316 may include one or more machine learning models. According to example embodiments, the AI / ML engine 316 may include one or more deep learning techniques. According to example embodiments, the AI / ML engine 316 may be configured to process data received from one or more modules in the RIC 302. According to example embodiments, the AI / ML engine 316 may be configured to process data present in the shared data lake 320 and to create policies and configurations. Accordingly, the shared data lake may be part of an information architecture of the AI / ML engine 316.

[0083] It may be understood that the process related to training for AI / ML services may refer to a process where one or more machine learning models are trained based on data received by the AI / ML engine 316, such that the one or more machine learning models may learn information regarding the data. It may also be understood that the process related to inference for AI / ML services may refer to a process where the trained one or more machine learning models make predictions based on real-time data to produce actionable results. For example, in deep learning where a model relies on feedback to learn from incorrect conclusions, a deep neural network (DNN) may learn how to analyze a set of data and make predictions about the data.

[0084] The sensor management 318 may be configured to receive sensor data from one or more sensors associated with the RIC 302. For example, the sensor management 318 may receive input data from all sensors installed at a cell site. The one or more sensors associated with the RIC302 may include any kind of sensors, and the sensor data may include any kind of measurement data obtained from the one or more sensors. For example, the sensor data may include cabinet temperature, wind load, antenna tilt, clutter images, and the like.

[0085] The data exposure 322 may refer to a service that is configured to control an exposure of data within the RIC 320. According to example embodiments, the data exposure 322 may be configured to control an exposure of data to the application 308. For example, the data exposure 322 may determine the length of time that a particular set of data should be stored in the RIC 320. According to example embodiments, the data exposure 322 may implement data sharing techniques, such as push and pull operations.

[0086] For example, the data exposure 322 may control the configuration data pushed by the SMO to the Near-RT RIC (RIC 320) to manage nodes, as well as control the external configuration updates received from the managed nodes and reported to the SMO. It may be understood that performance data may be reported to the SMO to enable data analytics and data collection for AI / ML services, where the SMO can select KPIs (also referred to as counters) to be reported and the frequency of the reporting. Further, interfaces, such as O1 interface, may support performance management service, which collects the counters and make calculations on the counters to derive a KPI. The KPIs may be computed based on underlying measurement counters exposed by the RAN nodes. These KPIs are then evaluated and / or used in rApps, xApps, zApps, and the like to gauge a specific condition.

[0087] The hardware management 324 may be configured to receive hardware data from one or more hardware associated with the RIC 320. For example, the hardware management 324 may receive hardware data from all hardware installed at a cell site. The one or more hardwareassociated with the RIC 302 may include any kind of hardware, and the hardware data may include any kind of information related to the one or more hardware. For example, the hardware data may include average / peak CPU / memory utilization, average / peak utilization of Fronthaul interface, and the like.

[0088] The API enhancement 326 may be configured to perform process related to API enhancements within the RIC 302.

[0089] In view of the above, example embodiments of the present disclosure allow for different types of conflicts to be managed and mitigated, while considering wide range of types of conflicts. Example Operations for Managing Conflicts in the Present Disclosure

[0090] In the following, several example operations are performable by an apparatus of one or more example embodiments of the present disclosure are described with reference to FIG. 4 to FIG. 8.

[0091] FIG.4 illustrates a flow diagram of an example method 400 for managing conflicts, according to one or more example embodiments. One or more operations in method 400 may be performed by the apparatus of one or more example embodiments of the present disclosure. The apparatus may be configured to manage conflicts.

[0092] According to example embodiments, the apparatus may include a Non-RT RIC configured to implement at least one Non-RT RIC Application (rApp), a Near-RT RIC configured to implement at least one Near-RT RIC Application (xApp), or a RT RIC configured to implement at least one RT RIC Application (zApp). According to example embodiments, the apparatus may include the rApp, the xApp, or the zApp itself. According to example embodiments, the apparatusmay include a network function managed by the Non-RT RIC, Near-RT RIC, or RT RIC. According to example embodiments, one or more operations in method 400 may be performed by the conflict management module.

[0093] As illustrated in FIG. 4, at operation S410, the apparatus may be configured to obtain a plurality of application advertisements. The plurality of application advertisements may be obtained from a plurality of applications, and may describe information related to the plurality of applications.

[0094] According to example embodiments, the plurality of applications may include one or more of an application, an algorithm, and the like used by the apparatus in the management and / or control of the RAN. According to example embodiments, the plurality of applications may include one or more of rApp, xApp, and zApp.

[0095] According to example embodiments, the information described in the plurality of application advertisements may include one or more of: name of an application, name of a vendor of an application, version number of an application, service in a network to be accessed by an application (e.g., R1 RAN-OAM related services, E2SM-RC, and the like), parameters in a network to be impacted by an application (e.g., E2SM-RC parameters, O1 CM parameters, and the like), key performance indicator (KPI) of an application, type of network element to be worked on by an application (e.g., O-CU, O-DU, O-RU, macro cell, indoor cell, and the like), scheduling constraint of an application, and attributes related to an application. Here, the scheduling constraint may refer to a time schedule when the changes to be implemented for the application should not be implemented. For example, if the application would like to implement service impacting changes, such service impacting changes should not be implemented during day time (i.e., hightraffic). Further, the attributes related to an application may include any kinds of attributes that are related to the application, such as service impacting change consideration, and the like.

[0096] For example, the apparatus may be configured to receive a first application advertisement from an rApp and a second application advertisement from an xApp, where the first application advertisement may include the name of the rApp and the service in a network to be accessed by the rApp, and the second advertisement may include the name of the xApp and the service in a network to be accessed by the xApp.

[0097] Here, it may be understood that the changes to be implemented for an application may refer to changes to be implemented to one or more parameters within the network, which the application would like to make. For example, the application may want to change an antenna’s tilt.

[0098] The plurality of application advertisements may be obtained using any means. For example, an application advertisement may be obtained from an application descriptor retrieved from the application during onboarding and registration process of the application, during service registration process of the application, and / or during service subscription / request process (e.g., E2 subscription) of the application. In another example, an application advertisement may be obtained through Application Programming Interface (API), such as a dedicated R1 service API or RIC API (e.g., Near-RT RIC API).

[0099] According to example embodiments, the plurality of application advertisements may be obtained by a subscription management module of the apparatus, where the conflict management module of the apparatus may then obtain the plurality of application advertisements from the subscription management module.

[0100] Accordingly, the above process allows the information regarding the plurality of applications to be advertised to the apparatus, where such information may be utilized for managing conflicts, managing deployment of the plurality of applications, and the like. The method then proceeds to operation S420.

[0101] At operation S420, the apparatus may be configured to obtain a conflict matrix. The conflict matrix may specify one or more conflicts between a first application and a second application of the plurality of applications. The first application may be one of the plurality of applications and the second application may be another of the plurality of applications.

[0102] According to example embodiments, the one or more conflicts may include one or more of: Direct Conflict (DRC), Indirect Conflict (INC), Implicit Conflict (IMC), Oscillating Conflict (OSC), and Scope Conflict (SCC).

[0103] The DRC may refer to a type of conflict where different applications make decisions that affect the same set of parameters. For example, to optimize coverage and / or to compensate for cell outage, two different applications may make different conflicting changes to an antenna’s tilt. The INC may refer to a type of conflict where different applications make decisions to modify parameters that affect the same operation (i.e., through dependencies). For example, two different applications may assign the same Physical Cell Identity (PCI) to two different cells, thereby causing mobility management errors. The IMC may refer to a type of conflict where different applications make decisions with conflicting objectives and goals. For example, an application may influence RAN operations with the goal of optimizing interference at the expense of service offering to the users, while another application may influence RAN operations with the goal of improving the service offering to the users at the expense of interference.The OSC may refer to a type of conflict where changes caused by different applications cause repetitive changes. For example, short / long-term mobility load balancing mitigations or handover optimization actions may cause repetitive changes. The SCC may refer to a type of conflict where different applications make decisions that affect the same geographical area.

[0104] According to example embodiments, each of the one or more conflicts specified in the conflict matrix may be associated with one or more metrics. The one or more metrics may define the objectives of the applications involved in the associated conflict. For example, the one or more metrics may be the base KPIs which the applications intend to improve in the network. In particular, for example, the one or more metrics may include a capacity KPI (e.g., related to network traffic) expressed in Erlang programming language, and a quality KPI (e.g., related to drop call rate) expressed in percentage.

[0105] FIG.5 illustrates an example conflict matrix 500, according to one or more example embodiments. As shown in FIG.5, the conflict matrix 500 specifies a plurality of conflicts that are occurring between a plurality of applications. In particular, Application 1 has conflicts [DRC & SCC] and [INC & SCC] with Application 2, Application 1 has conflict [DRC & NO SCC] with Application 3, and Application 2 has conflicts [DRC & NO SCC] and [INC & SCC] with Application 3.

[0106] It may be understood that the descriptions associated with FIG. 5 are provided as an example for descriptive purpose, and is not intended to limit the scope in any way. In particular, the conflict matrix can include any number of combination of conflicts (i.e., any number of columns) and any number of combination of applications (i.e., any number of rows). Further, the number of conflicts specified in each slot can be any number, and the number of applicationsspecified in each slot can be any number (i.e., showing conflicts between 3 or more applications). Furthermore, the conflict matrix may be in any form other than a matrix, as long as the relationship between the conflicts and the applications are specified.

[0107] According to example embodiments, the conflict matrix may be obtained by receiving the conflict matrix from a user. According to example embodiments, the user may include applications (e.g., rApp / xApp / zApp) vendors, RIC platform vendors, operators, and the like. In particular, the user may develop and update the conflict matrix by evaluating potential conflicts between different applications. According to example embodiments, the conflict matrix may be received from the user via a standardized interface before an application begins its operations. For example, for Near-RT RIC, the conflict matrix may be received from the SMO (which handles Life Cycle Management (LCM) of xApps) via O1 and O2 interfaces. In another example, for Non-RT RIC, the conflict matrix may be received from the SMO via SMO internal service interface to Non-RT RIC framework.

[0108] According to example embodiments, the conflict matrix may be obtained by generating the conflict matrix based on one or more machine learning models. According to example embodiments, the conflict matrix may be generated automatically using the AI / ML engine and one or more machine learning models based on historical data (i.e., through monitoring and learning the behaviors of the plurality of applications). For example, historical data may include data related to past changes have impacted system performance and incurred oscillation, where the AI / ML engine and one or more machine learning models may utilize such data to generate the conflict matrix. According to example embodiments, the conflict matrix may be generated automatically using the AI / ML engine and one or more machine learning models basedon the information described in the plurality of application advertisements. According to example embodiments, the conflict matrix may be generated automatically using the AI / ML engine and one or more machine learning models based on a result of change impact evaluation (see below in relation to operation S460). According to example embodiments, when the apparatus corresponds to the rApp, the xApp, or the zApp, the generated conflict matrix may be implemented to a RIC via a standardized interface and Application Programming Interface (API), such as R1 service API, Near-RT RIC API, and the like.

[0109] According to example embodiments, a plurality of conflict matrices may be obtained and combined together.

[0110] Accordingly, the above process provides essential information regarding conflicts that may occur in the network, namely which applications are in conflict with each other and what type of conflict is being occurred. The method then proceeds to operation S430.

[0111] At operation S430, the apparatus may be configured to obtain a plurality of application policy definitions. Each of the plurality of application policy definitions may be declarative policies, statements, and the like defining one or more operational parameters of the corresponding application. According to example embodiments, the application policy definition may also define limits, ranges, weights, and KPI associated with the one or more operational parameters. According to example embodiments, the one or more operational parameters may be configured by the user.

[0112] According to example embodiments, when there are more than one KPIs associated with an application policy definition (i.e., an application would like to optimize two or more KPIs), the application policy definition may also define the application’s intent and policies related to thepriorities of the KPIs. For example, the application may want to optimize Quality of Service (QoS) performance and energy saving, and the application policy definition may define the application’s intent and policies related to the priorities of the QoS performance and energy saving (e.g., prioritize QoS performance over energy saving).

[0113] According to example embodiments, the application policy definition may also define a severity flag. The severity flag may specify an importance (severity) level associated with an application. For example, during a network outage, an application that helps resolve the network outage may have a severity flag defined in its application policy definition to be at a highest level. According to example embodiments, the severity flag may be an optional setting by a user.

[0114] According to example embodiments, the application policy definition may be obtained by receiving the application policy definition from a user. According to example embodiments, the user may include applications (e.g., rApp / xApp / zApp) vendors, RIC platform vendors, operators, and the like. According to example embodiments, the application policy definition may be received from the user via a standardized interface before an application begins its operations. For example, for Near-RT RIC, the application policy definition may be received from the SMO (which handles Life Cycle Management (LCM) of xApps) via O1 and O2 interfaces. In another example, for Non-RT RIC, the application policy definition may be received from the SMO via SMO internal service interface to Non-RT RIC framework.

[0115] According to example embodiments, the application policy definition may be obtained by generating the application policy definition based on one or more machine learning models. According to example embodiments, the application policy definition may be generated automatically using the AI / ML engine and one or more machine learning models based onhistorical data. According to example embodiments, when the apparatus corresponds to the rApp, the xApp, or the zApp, the generated application policy definition may be implemented to a RIC via a standardized interface and Application Programming Interface (API), such as R1 service API, Near-RT RIC API, and the like.

[0116] According to example embodiments, the application policy definition may be obtained by receiving a portion of the application policy definition from a user and by generating another portion of the application policy definition based on one or more machine learning models. For example, the user may provide two operational parameters of the application policy definition. In this regard, since there are more than one operational parameters, weights associated with each of the two operational parameters may be automatically generated based on one or more machine learning models through monitoring system performance and driving policies, KPI targets and KPI priorities representing the optimized state which the system target to achieve.

[0117] Accordingly, the above process allows the information regarding the operational parameters of the plurality of applications to be received by the apparatus, where such information may be utilized for managing conflicts, managing deployment of the plurality of applications, and the like. The method then proceeds to operation S440.

[0118] At operation S440, the apparatus may be configured to obtain a conflict policy definition. The conflict policy definition may be declarative policies, statements, and the like defining priorities of the plurality of applications relative to each other.

[0119] According to example embodiments, the conflict policy definition may be obtained by receiving the conflict policy definition from a user. In particular, the user may define and specify the priorities of the plurality of applications relative to each other in the conflict policydefinition, and provide the conflict policy definition to the apparatus. According to example embodiments, the user may include applications (e.g., rApp / xApp / zApp) vendors, RIC platform vendors, operators, and the like. According to example embodiments, the conflict policy definition may be received from the user via a standardized interface before an application begins its operations. For example, for Near-RT RIC, the conflict policy definition may be received from the SMO (which handles Life Cycle Management (LCM) of xApps) via O1 and O2 interfaces. In another example, for Non-RT RIC, the conflict policy definition may be received from the SMO via SMO internal service interface to Non-RT RIC framework.

[0120] According to example embodiments, the conflict policy definition may be obtained by determining the conflict policy definition based on the plurality of application policy definitions. According to example embodiments, the conflict policy definition may be determined based on the plurality of application policy definitions using the one or more machine learning models. According to example embodiments, the conflict policy definition may be automatically determined using the AI / ML engine and one or more machine learning models based on the plurality of application policy definitions and historical data (i.e., through monitoring and learning the behaviors of the plurality of applications). According to example embodiments, when the apparatus corresponds to the rApp, the xApp, or the zApp, the determined conflict policy definition may be implemented to a RIC via a standardized interface and Application Programming Interface (API), such as R1 service API, Near-RT RIC API, and the like.

[0121] For example, based on the operational parameters, severity flag, and the like defined in the plurality of application policy definitions, the apparatus may determine thatapplication 1 is more important than application 2. Accordingly, the conflict policy definition may define that application 1 has higher priority than application 2.

[0122] According to example embodiments, the conflict policy definition may also specify one or more conflict management and coordination mechanisms that are applicable to the plurality of applications (see below in relation to operation S450). According to example embodiments, a plurality of conflict policy definitions may be obtained and combined together.

[0123] Accordingly, the above process provides essential information regarding the applications that may conflict with each other, namely the priority and importance of the applications relative to each other, where such information may be utilized in managing conflicts. The method then proceeds to operation S450.

[0124] At operation S450, the apparatus may be configured to determine a conflict mitigation schedule. The conflict mitigation schedule may be determined based on the conflict matrix and the conflict policy definition, and may schedule implementations of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

[0125] According to example embodiments, the one or more conflict management and coordination mechanisms may refer to mechanisms, method, processes, and the like for implementing the changes of the plurality of applications. According to example embodiments, the one or more conflict management and coordination mechanisms may include one or more of: serial execution, prioritization of algorithms, scheduled-based, geo-diversification, and least change. Serial execution mechanism may refer to a mechanism where applications are executed in order (e.g., engagement of the applications are activated / deactivated; applications are turned on / off,and the like in order). Prioritization of algorithms mechanism may refer to a mechanism where applications are executed based on their priorities. Scheduled-based mechanism may refer to a mechanism where applications are executed at different scheduled window of time (periodic or singular). According to example embodiments, during the time outside of the scheduled window, an application may be turned off and stay in a monitor mode until it is called upon again (e.g., when the scheduled window arrives). Geo-diversification mechanism may refer to a mechanism where applications (which are conflicting) are allowed to be executed if their geographical scopes are made distinct (e.g., two cells pointing away from each other with the same Physical Cell Identity (PCI) assignment). Least change mechanism may refer to a mechanism that identifies when the changes of the applications are resulting in oscillation of changes, and that minimizes such oscillation of changes.

[0126] According to example embodiments, the one or more conflict management and coordination mechanisms may be combined with each other. For example, serial execution may be combined with scheduled-based or prioritization of algorithm, prioritization of algorithm may be combined with scheduled-based or serial execution, scheduled-based may be combined with serial execution or prioritization of algorithm, geo-diversification may be combined with scheduled-based or prioritization of algorithm, and least change may be combined with scheduled- based, prioritization of algorithm, or serial execution.

[0127] According to example embodiments, the conflict mitigation schedule may be determined based on the conflict matrix and the conflict policy definition using the one or more machine learning models. According to example embodiments, the conflict mitigation schedulemay be automatically determined using the AI / ML engine and one or more machine learning models based on the conflict matrix, the conflict policy definition, and historical data.

[0128] For example, based on the conflict matrix exemplified in FIG.5, the apparatus may determine that application 1 has conflicts with application 2. Further, based on the combination of conflicts occurring between application 1 and application 2 specified in the conflict matrix ([DRC & SCC] and [INC & SCC]), the apparatus may determine (e.g., using machine learning models based on historical data related to the combinations of conflicts [DRC & SCC] and [INC & SCC]) that serial execution mechanism and prioritization of algorithms mechanism should be used to resolve such combination of conflicts. Furthermore, based on the conflict policy definition, the apparatus may determine that application 1 has higher priority than application 2. In view of the above, the apparatus may determine a conflict mitigation schedule where application 1 is scheduled to turn on and implement its change first while application 2 is turned off, and that application 2 is scheduled to turn on and implement its change once application 1 completed the implementation of its change; where such scheduling resolves or at least partially resolves the combinations of conflicts [DRC & SCC] and [INC & SCC] occurring between application 1 and application 2.

[0129] According to example embodiments, the conflict mitigation schedule may be determined based on the conflict matrix and the conflict policy definition, as well as a plurality of severity flags. For example, during a network outage, application 1 which helps resolve the network outage may have a severity flag defined in its application policy definition to be at a highest level. In this regard, the conflict mitigation schedule may specify that serial execution mechanism should be used to resolve any conflicts occurring between application 1 and any otherapplications. Accordingly, the apparatus may determine a conflict mitigation schedule where application 1 is scheduled to turn on and implement its change first while all other applications that have any conflicts with application 1 are turned off, such that application 1 takes precedence over all other applications.

[0130] According to example embodiments, when the apparatus corresponds to the rApp, the xApp, or the zApp, the determined conflict mitigation schedule may be implemented to a RIC via a standardized interface and Application Programming Interface (API), such as R1 service API, Near-RT RIC API, and the like. In particular, the interfaces may redirect the schedules for implementations of changes of the plurality of applications to the plurality of applications, and / or may engage the plurality of applications at a specific time slot. According to example embodiments, the interfaces may be used by the plurality of applications to request for the schedules from the apparatus before implementing the changes.

[0131] Once the conflict mitigation schedule is determined, the plurality of applications may implement their changes based on the schedule accordingly.

[0132] Examples of operations for determining the conflict mitigation schedule are described below with reference to FIG. 6.

[0133] Accordingly, the above process allows for conflicts between different applications to be managed in a effective manner. The method then proceeds to operation S460.

[0134] At operation S460, the apparatus may be configured to perform a change impact evaluation. The change impact evaluation may be performed by evaluating an impact of implementing the changes of the plurality of applications.

[0135] According to example embodiments, the impact of implementing the changes of the plurality of applications may be evaluated using the one or more machine learning models. According to example embodiments, the impact of implementing the changes of the plurality of applications may be automatically evaluated using the AI / ML engine and one or more machine learning models based on historical data. According to example embodiments, the impact of implementing the changes of the plurality of applications may be evaluated using a digital twin.

[0136] According to example embodiments, the impact of implementing the changes of the plurality of applications may include changes to the performance of the network. For example, the impact of implementing the changes of the plurality of applications may include a change (decrease, increase, and the like) in one or more KPIs.

[0137] Examples of operations for performing the change impact evaluation are described below with reference to FIG. 7.

[0138] Accordingly, the above process allows for the impact of implementing the changes of the plurality of application to be evaluated. The method then proceeds to operation S470.

[0139] At operation S470, the apparatus may be configured to perform a rollback and oscillation mitigation. The rollback and oscillation mitigation may be performed by rolling back the implemented changes of the plurality of applications or preventing oscillation of changes. According to example embodiments, the rollback and oscillation mitigation may be performed based on a result of the change impact evaluation.

[0140] Examples of operations for performing the rollback and oscillation mitigation are described below with reference to FIG. 8.

[0141] Accordingly, the above process prevents the plurality of applications from implementing changes that may cause negative impact to the network.

[0142] Upon performing operation S470, the method 400 may be ended or be terminated. Alternatively, method 400 may return to operation S410, such that the apparatus may be configured to repeatedly perform, for at least a predetermined amount of time, the obtaining the plurality of application advertisements (at operation S410), the obtaining the conflict matrix (at operation S420), the obtaining the plurality of application policy definitions (at operation S430), the obtaining the conflict policy definition (at operation S440), the determining the conflict mitigation schedule (at operation S450), the performing the change impact evaluation (at operation S460), and the performing the rollback and oscillation mitigation (at operation S470).

[0143] For instance, more applications may enter the network and advertise themselves, and the apparatus may continuously (or periodically) receive the plurality of application advertisements, and then restart the obtaining the plurality of application advertisements (at operation S410), the obtaining the conflict matrix (at operation S420), the obtaining the plurality of application policy definitions (at operation S430), the obtaining the conflict policy definition (at operation S440), the determining the conflict mitigation schedule (at operation S450), the performing the change impact evaluation (at operation S460), and the performing the rollback and oscillation mitigation (at operation S470).

[0144] Accordingly, the above process allows for different types of conflicts to be managed and mitigated. In particular, the above process allows one or a combination of mechanisms to be appropriately selected for solving a specific type of conflicts, while considering wide range of types of conflicts.Example Operations for Determining a Conflict Mitigation Schedule in the Present Disclosure

[0145] FIG.6 illustrates a flow diagram of an example method 600 for determining conflict mitigation schedule, according to one or more example embodiments. One or more operations of method 600 may be part of operation S450 in method 400, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0146] As illustrated in FIG. 6, at operation S610, the apparatus may be configured to select one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix. According to example embodiments, the one or more conflict management and coordination mechanisms may be selected based on the one or more conflicts specified in the conflict matrix using the one or more machine learning models.

[0147] According to example embodiments, the one or more conflict management and coordination mechanisms may be selected to resolve one or more conflicts specified in the conflict matrix. For example, returning to FIG. 3, serial execution mechanism and prioritization of algorithms mechanism may be selected to resolve only the [DRC & SCC] conflicts between application 1 and application 2, or to resolve both the [DRC & SCC] and [INC & SCC] conflicts between application 1 and application 2.

[0148] According to example embodiments, different conflict management and coordination mechanism or different combination of conflict management and coordination mechanisms may be selected to resolve different conflicts specified in the conflict matrix. For example, returning to FIG. 5, serial execution mechanism and prioritization of algorithms mechanism may be selected to resolve the [DRC & SCC] and [INC & SCC] conflicts betweenapplication 1 and application 2, while scheduled-based mechanism may be selected to resolve the [DRC & NO SCC] and [INC & SCC] conflicts between application 2 and application 3.

[0149] According to example embodiments, the one or more conflict management and coordination mechanisms may be selected based on the one or more conflicts specified in the conflict matrix as well as one or more conflicts not specified in the conflict matrix. For example, returning to FIG. 5, the apparatus may determine that application 1 and application 3 have DRC conflict but do not have any SCC conflicts. In this regard, since there are no SCC conflicts between application 1 and application 3, geo-diversification may be selected to allow application 1 and application 3 to implement their changes at different geographical location to resolve DRC. The method then proceeds to operation S620.

[0150] At operation S620, the apparatus may be configured to obtain the priorities of the plurality of applications relative to each other, where the obtained priorities may be user-defined according to the conflict policy definition. In particular, the apparatus may review and analyze the conflict policy definition (which defines the priorities of the plurality of applications relative to each other) in order to determine / obtain the priorities of the plurality of applications relative to each other. The method then proceeds to operation S630.

[0151] At operation S630, the apparatus may be configured to schedule the implementation of the changes of the plurality of applications. The implementation of the changes of the plurality of applications may be scheduled based on the determined priorities and the selected one or more conflict management and coordination mechanisms.

[0152] For example, serial execution mechanism and prioritization of algorithms mechanism may be selected to resolve the [DRC & SCC] conflicts between application 1 andapplication 2 during operation S610. Then the priority of application 1 may be determined to be higher than the priority of application 2 during operation S620. Accordingly, the apparatus may schedule application 1 to turn on and implement its change first while application 2 is turned off, and schedule application 2 to turn on and implement its change once application 1 completed the implementation of its change; where such scheduling resolves or at least partially resolves the conflict [DRC & SCC] occurring between application 1 and application 2. Example Operations for Performing a Change Impact Evaluation in the Present Disclosure

[0153] FIG. 7 illustrates a flow diagram of an example method 700 for performing a change impact evaluation, according to one or more example embodiments. One or more operations of method 700 may be part of operation S460 in method 400, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0154] Here, a state of a network before implementing the changes of the plurality of applications may be referred to as a first state, and a state of the network after implementing the changes of the plurality of applications may be referred to as a second state.

[0155] As illustrated in FIG. 7, at operation S710, the apparatus may be configured to determine (e.g., measure, obtain, and the like) one or more key performance indicators (KPIs) during the first state. According to example embodiments, the one or more KPIs may be associated with the plurality of applications. According to example embodiments, the one or more KPIs may be determined using one or more machine learning models. According to example embodiments, the one or more KPIs may be automatically determined using the AI / ML engine and one or more machine learning models based on historical data. According to example embodiments, thespecific KPIs that is to be determined (i.e., at operation S710 as well as operation S720) may be selected by a user.

[0156] According to example embodiments, the one or more KPIs may be determined via any kind of Key Performance Measuring (KPM) collection and / or monitoring mechanism in a RIC, such as collection of measurement data on O1 / E2 interfaces. The method then proceeds to operation S720.

[0157] At operation S720, the apparatus may be configured to determine (e.g., measure, obtain, and the like) the one or more KPIs during the second state. The one or more KPIs may be determined during the second state in the similar manner as in operation S710. The method then proceeds to operation S730.

[0158] At operation S730, the apparatus may be configured to determine an impact of implementing the changes of the plurality of applications. The impact of implementing the changes of the plurality of applications may be determined based on the determined one or more KPIs during the first state and the determined one or more KPIs during the second state.

[0159] For example, the apparatus may determine a quality KPI during the first state and during the second state, where the quality KPI during the second state is lower than the quality KPI during the first state. Accordingly, the apparatus may determine that implementing the changes of the plurality of applications causes negative impact and lowers the performance of the network. In another example, the apparatus may determine a quality KPI during the first state and during the second state, where the quality KPI during the second state is higher than the quality KPI during the first state. Accordingly, the apparatus may determine that implementing the changes of the plurality of applications causes positive impact and improves the performance ofthe network. In another example, the apparatus may determine a quality KPI during the first state and during the second state, where the quality KPI during the second state is the same as the quality KPI during the first state. Accordingly, the apparatus may determine that implementing the changes of the plurality of applications causes negligible impact and does not substantively change the performance of the network.

[0160] According to example embodiments, the impact may be determined based on the determined one or more KPIs during the first state and the determined one or more KPIs during the second state using one or more machine learning models. According to example embodiments, the impact may be automatically determined using the AI / ML engine and one or more machine learning models based on historical data.

[0161] According to example embodiments, the impact of implementing the changes of the plurality of applications may be determined based on the determined one or more KPIs during the first state, the determined one or more KPIs during the second state, and a performance threshold. According to example embodiments, the impact of implementing the changes of the plurality of applications may be determined by determining an amount of change between the one or more KPIs during the first state and the one or more KPIs during the second state, and determining whether the determined amount of change exceeds the performance threshold. The performance threshold may define a threshold which the one or more KPIs is allowed to be changed. According to example embodiments, the performance threshold may be predefined by a user.

[0162] For example, the apparatus determine a quality KPI during the first state and during the second state, where the quality KPI during the second state is lower than the quality KPI duringthe first state by 5%, which is less than the performance threshold of 10%. Accordingly, the apparatus may determine that implementing the changes of the plurality of applications causes negative impact and lowers the performance of the network, but is within an acceptable range.

[0163] According to example embodiments, operations S710 to S730 may be performed for the change of each of the plurality of applications individually. According to example embodiments, operations S710 to S730 may be performed for the changes of all of the plurality of applications together. Example Operations for Performing a Rollback and Oscillation Mitigation in the Present Disclosure

[0164] FIG. 8 illustrates a flow diagram of an example method 800 for performing a rollback and oscillation mitigation, according to one or more example embodiments. One or more operations of method 800 may be part of operation S470 in method 400, and may be performed by the apparatus of one or more example embodiments of the present disclosure.

[0165] Here, a state of a network before implementing the changes of the plurality of applications may be referred to as a first state, and a state of the network after implementing the changes of the plurality of applications may be referred to as a second state.

[0166] As illustrated in FIG. 8, at operation S810, the apparatus may be configured to determine whether to perform a rollback (i.e., revert the network from the second state to the first state in order to rollback the implemented changes of the plurality of applications).

[0167] According to example embodiments, the apparatus may be configured to determine whether to perform the rollback based on a result of the change impact evaluation. For example, through change impact evaluation discussed above in relation to method 700, the apparatus maydetermine that implementing the changes of the plurality of applications causes negative impact and lowers the performance of the network. Accordingly, the apparatus may determine to perform the rollback and revert the network from the second state to the first state. In another example, through change impact evaluation discussed above in relation to method 700, the apparatus may determine that implementing the changes of the plurality of applications causes negative impact and lowers the performance of the network by 15% which exceeds the performance threshold of 10%. Accordingly, the apparatus may determine to revert the network from the second state to the first state.

[0168] Accordingly, in response to determining to perform the rollback, the apparatus may determine that the implemented changes should be reverted and the method proceeds to operation S820. On the other hand, in response to determining not to perform the rollback, the apparatus may determine that the implemented changes can be maintained and the method proceeds to operation S830.

[0169] At operation S820, the apparatus may be configured to perform the rollback. The rollback may be performed by reverting the network from the second state to the first state. According to example embodiments, the network may be reverted from the second state to the first state by reverting (undoing) the implemented changes of the plurality of applications..

[0170] At operation S830, the apparatus may be configured to track a number of changes resulting from implementing the changes of the plurality of applications. In particular, once the changes of the plurality of applications are implemented, such implemented changes may cause additional subsequent changes to the parameters of the network, where such additional subsequent changes may also cause even further additional subsequent changes to the parameters of thenetwork. Such occurrence may be referred to as oscillation of changes, where the state of the network may be changed each time the additional subsequent changes occur. Accordingly, the apparatus may be configured to track the number of changes that has occurred (i.e., the number of times the state of the network changes, the number of time the additional subsequent changes occur, and the like). The method then proceeds to operation S840.

[0171] At operation S840, the apparatus may be configured to determine whether an oscillation threshold has been reached. The determination may be based on the tracked number of changes. According to example embodiments, the oscillation threshold may define a threshold which the state of network is allowed to be changed (i.e., a threshold which the additional subsequent changes are allowed to occur). According to example embodiments, the oscillation threshold may be predefined by a user. According to example embodiments, the apparatus may be configured to monitor an amount / number of time the state of the network is changed, and compare the amount / number of time to the oscillation threshold in order to determine whether the oscillation threshold has been reached.

[0172] Accordingly, in response to determining that the oscillation threshold has been reached, the apparatus may determine that the state of the network should not be changed anymore and the method proceeds to operation S850. On the other hand, in response to determining that the oscillation threshold has not been reached, the apparatus may determine that the state of the network can still be changed and the method returns to operation S830 to continue to track the number of changes.

[0173] At operation S850, the apparatus may be configured to perform oscillation mitigation. According to example embodiments, the oscillation mitigation may be performed byreverting the network to the first state (i.e., the state before the changes of the plurality of applications (which cause the oscillation of changes) are implemented).

[0174] According to example embodiments, operations S810 to S850 may be performed for the change of each of the plurality of applications individually. According to example embodiments, operations S810 to S850 may be performed for the changes of all of the plurality of applications together. Various Aspects of Embodiments

[0175] According to example embodiments, one or a combination of mechanisms can be appropriately selected for solving a specific type of conflicts, while considering wide range of types of conflicts. As a result, different types of conflicts to be managed and mitigated.

[0176] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.

[0177] Some embodiments may relate to a system, a method, and / or a computer readable medium at any possible technical detail level of integration. Further, one or more of the above components described above may be implemented as instructions stored on a computer readable medium and executable by at least one processor (and / or may include at least one processor). The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

[0178] The computer readable storage medium can be a tangible device that can retain andstore instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0179] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readablestorage medium within the respective computing / processing device.

[0180] Computer readable program code / instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand- alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

[0181] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing thefunctions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0182] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0183] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a microservice(s) module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustration, and combinations of blocks in the block diagrams and / or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

[0184] It will be apparent that systems and / or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and / or methods were described herein without reference to specific software code-it being understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0185] FIG.9 illustrates an example embodiment of an apparatus 900, according to one or more example embodiments. As shown in FIG.9, the apparatus 900 may include a processor 910, a memory 920, a storage component 930, an input component 940, an output component 950, a communication interface 960, and a bus 970.

[0186] The processor 910, as used herein, means any type of computational circuit that may comprise hardware elements and software elements. The processor 910 may be embodied as a multi-core processor, a single core processor, or a combination of one or more multi-core processors and one or more single core processors, a distributed processing system, or the like. The processor 910 may be a Central Processing Unit (CPU) a graphics processing unit (GPU), anaccelerated processing unit (APU), an application-specific integrated circuit (ASIC), or another type of processing component.

[0187] Memory 920 includes a non-transitory computer readable medium. Memory 920 includes a random-access memory (RAM), a read only memory (ROM), and / or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and / or an optical memory) that stores information and / or instructions for use by processor 910. The memory 920 comprises machine-readable instructions which are executable by the processor 910. These machine-readable instructions when executed by the processor 910 causes the processor 910 to perform one or more method steps of an embodiment described herein.

[0188] Storage component 930 stores information and / or software related to the operation and use of the apparatus 900. For example, storage component 930 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, and / or a solid-state disk), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive.

[0189] Input component 940 is configured to receive information, such as user input. For example, the input component 940 may include, but not be limited to, a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, and / or a microphone. Additionally, or alternatively, the input component 940 may include a sensor for sensing information (e.g., a global positioning system (GPS), an accelerometer, a gyroscope, and / or an actuator).

[0190] Output component 950 is configured to provide output information from the apparatus 900. For example, the output component 950 may be, but not limited to, a display, a speaker, instructions to an external device, and / or one or more light-emitting diodes (LEDs).

[0191] Communication interface 960 is an interface that provides a communication connection to other devices, such as external devices and internal devices. The connection by the communication interface 960 can be a wired connection, a wireless connection, or a combination of wired and wireless connections, and can be a direct connection or an indirect connection via a communication network that exists between the apparatus 900 and other devices. In other words, the standard of the communication interface 960 is not limited.

[0192] The bus 970 acts as an interconnect between the processor 910, the memory 920, the storage component 930, the input component 940, the output component 950, and the communication interface 960 of the apparatus 900. The bus 970 may include a wired interconnection or a wireless interconnection.

[0193] The number and arrangement of components shown in FIG. 9 are provided as an example. In practice, apparatus 900 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 9. Additionally, or alternatively, a set of components (e.g., one or more components) of apparatus 900 may perform one or more functions described as being performed by another set of components of apparatus 900. Further, one or more method steps described in any of the embodiments may be performed utilizing a plurality of apparatus 900 in communication with one another.

[0194] Further, according to example embodiments, the apparatus 900 may include one or more elements from the system architecture described above in relation to FIG. 1 to FIG. 4. For example, the apparatus 900 may include at least the Non-RT RIC configured to implement at least one Non-RT RIC Application (rApp), near-real-time (Near-RT) RIC configured to implement atleast one Near-RT RIC Application (xApp), or RT RIC configured to implement at least one RT RIC Application (zApp). In another example, the apparatus 900 may include the rApp, the xApp, or the zApp itself.

[0195] According to example embodiments, the processor 910 may be configured to perform the above described operations in methods 500 to 800.

[0196] Various further respective aspects and features of embodiments of the present disclosure may be defined by the following items: Item [1]: An apparatus that may be configured to: obtain a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtain a conflict policy definition defining priorities of the plurality of applications relative to each other; and determine, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix. Item [2]: The apparatus according to item [1], wherein the apparatus may be configured to determine the conflict mitigation schedule by: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix; obtaining the priorities of the plurality of applications relative to each other, where the obtained priorities may be user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality ofapplications based on the determined priorities and the selected one or more conflict management and coordination mechanisms. Item [3]: The apparatus according to one of items [1]-[2], wherein the one or more conflicts specified in the conflict matrix may include one or more of: direct conflict (DRC), indirect conflict (INC), implicit conflict (IMC), oscillating conflict (OSC), and scope conflict (SCC). Item [4]: The apparatus according to one of items [1]-[3], wherein the one or more conflict management and coordination mechanisms may include one or more of: serial execution, prioritization of algorithms, scheduled-based, geo-diversification, and least change. Item [5]: The apparatus according to one of items [1]-[4], wherein the apparatus may be further configured to perform a change impact evaluation, wherein the change impact evaluation may be performed by evaluating an impact of implementing the changes of the plurality of applications. Item [6]: The apparatus according to item [5], wherein a state of a network before implementing the changes of the plurality of applications may be a first state, wherein a state of the network after implementing the changes of the plurality of applications may be a second state, and wherein the apparatus may be configured to perform the change impact evaluation by: determining one or more key performance indicators (KPIs) during the first state; determining the one or more KPIs during the second state; and determining an impact of implementing the changes of the plurality of applications based on the determined oneor more KPIs during the first state and the determined one or more KPIs during the second state. Item [7]: The apparatus according to one of items [5]-[6], wherein the apparatus may be further configured to perform a rollback and oscillation mitigation, wherein the rollback and oscillation mitigation may be performed by rolling back the implemented changes of the plurality of applications or preventing oscillation of changes. Item [8]: The apparatus according to item [7], wherein the apparatus may be configured to perform the rollback and oscillation mitigation by: determining whether to perform a rollback based on a result of the change impact evaluation; in response to determining to perform the rollback, performing the rollback; in response to determining to not perform the rollback, tracking a number of changes resulting from implementing the changes of the plurality of applications; determining whether an oscillation threshold has been reached based on the tracked number of changes; and in response to determining that the oscillation threshold has been reached, performing an oscillation mitigation. Item [9]: The apparatus according to one of items [1]-[8], wherein the apparatus may be further configured to: obtain a plurality of application advertisements describing information related to the plurality of applications, wherein the information described in the plurality of application advertisements may include one or more of: name of an application, name of a vendor of an application, version number of an application, service in a network to be accessed by an application, parameters in a network to be impacted by an application, key performance indicator (KPI) of an application, type of network element to be worked on by an application, scheduling constraint of an application, and attributesrelated to an application; and obtain a plurality of application policy definitions defining one or more operational parameters of the plurality of applications. Item

[0010] : A method that may include: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to each other; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix. Item

[0011] : The method according to item

[0010] , wherein the determining the conflict mitigation schedule may include: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix; obtaining the priorities of the plurality of applications relative to each other, where the obtained priorities may be user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality of applications based on the determined priorities and the selected one or more conflict management and coordination mechanisms. Item

[0012] : The method according to one of items

[0010] -

[0011] , wherein the one or more conflicts specified in the conflict matrix may include one or more of: direct conflict (DRC), indirect conflict (INC), implicit conflict (IMC), oscillating conflict (OSC), and scope conflict (SCC).Item

[0013] : The method according to one of items

[0010] -

[0012] , wherein the one or more conflict management and coordination mechanisms may include one or more of: serial execution, prioritization of algorithms, scheduled-based, geo-diversification, and least change. Item

[0014] : The method according to one of items

[0010] -

[0013] , wherein the method may further include performing a change impact evaluation, wherein the change impact evaluation may be performed by evaluating an impact of implementing the changes of the plurality of applications. Item

[0015] : The method according to item

[0014] , wherein a state of a network before implementing the changes of the plurality of applications may be a first state, wherein a state of the network after implementing the changes of the plurality of applications may be a second state, and wherein the performing the change impact evaluation may include: determining one or more key performance indicators (KPIs) during the first state; determining the one or more KPIs during the second state; and determining an impact of implementing the changes of the plurality of applications based on the determined one or more KPIs during the first state and the determined one or more KPIs during the second state. Item

[0016] : The method according to one of items

[0014] -

[0015] , wherein the method may further include performing a rollback and oscillation mitigation, wherein the rollback and oscillation mitigation may be performed by rolling back the implemented changes of the plurality of applications or preventing oscillation of changes.Item

[0017] : The method according to item

[0016] , wherein the performing the rollback and oscillation mitigation may include: determining whether to perform a rollback based on a result of the change impact evaluation; in response to determining to perform the rollback, performing the rollback; in response to determining to not perform the rollback, tracking a number of changes resulting from implementing the changes of the plurality of applications; and in response to determining that the oscillation threshold has been reached, performing an oscillation mitigation. Item

[0018] : The method according to one of items

[0010] -

[0017] , wherein the method may further include: obtaining a plurality of application advertisements describing information related to the plurality of applications, wherein the information described in the plurality of application advertisements may include one or more of: name of an application, name of a vendor of an application, version number of an application, service in a network to be accessed by an application, parameters in a network to be impacted by an application, key performance indicator (KPI) of an application, type of network element to be worked on by an application, scheduling constraint of an application, and attributes related to an application; and obtaining a plurality of application policy definitions defining one or more operational parameters of the plurality of applications. Item

[0019] : A non-transitory computer-readable recording medium that may have recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method including: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to eachother; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix. Item

[0020] : The non-transitory computer-readable recording medium according to item

[0019] , wherein the determining the conflict mitigation schedule may include: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix; obtaining the priorities of the plurality of applications relative to each other, where the obtained priorities may be user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality of applications based on the determined priorities and the selected one or more conflict management and coordination mechanisms.

[0197] It can be understood that numerous modifications and variations of the present disclosure are possible in light of the above teachings. It will be apparent that within the scope of the appended clauses, the present disclosures may be practiced otherwise than as specifically described herein. Additional Descriptions

[0198] 1. Introduction

[0199] The Radio Access Network (RAN) is responsible for providing wireless access to mobile devices, provide resources and guarantee mobility in the network. It is the part of a mobile network that connects users to the core network and provides them with radio signals for communication and resource handling. It enables the transmission of data and voice between thesedevices and the Core Network (CN) over the air interface, using technologies such as LTE, 5G, etc. RAN is responsible for managing the quality and coverage of a wireless network, and includes components such as base stations, cell towers, and other radio access infrastructure.

[0200] The RAN contains various algorithms that together ensure the scheduling of the resources and guarantee the transmission and reception of the messages over the air interface (from the base station) in consideration of the channel quality and mobility requirements.

[0201] RAN Intelligent Controller (RIC), as introduced in OpenRAN, is a technology used in the management of the Radio Access Network (RAN) in mobile telecommunications networks. The RIC is a centralized component that acts as a central (external) management function for the RAN, enabling the automation and optimization of network operations, reducing human intervention and manual tasks. The RIC can collect and analyze data from various RAN elements and use this information to make real-time decisions that improve network performance, coverage, and efficiency. The RIC can also use machine learning algorithms to learn and adapt to network conditions, making it an important component in the development of self-organizing and self- optimizing networks (SONs).

[0202] The RIC consists of two main building blocks (see figure 1): Non-Real-time RIC (NRT RIC); Near-Real-time RIC (nRT RIC).

[0203] Non-real-time RIC, as the name suggests, operates outside of real-time constraints and is used to manage less critical aspects of the RAN. Its applications may include algorithms that are used in network planning, configuration management, and post-processing analysis. One can find applications for interference management by down-tilting an antenna or changing user- defined parameter settings in the RAN that are not latency sensitive or etc. Also, some of the resultsof these algorithms can be used to inform Near-Real-Time RIC decisions (in the nRT RIC), allowing for the optimization and improvement of RAN performance over time.

[0204] Near-Real-Time RIC (nRT RIC) operates with a shorter time delay compared to the Non-Real-Time RIC, and is used to manage Near-Real-Time aspects of the RAN. The applications of nRT RIC may include algorithms that enable radio resource allocations, radio resource optimization, mobility optimization, and fault management. By implementing near real- time RIC, mobile networks can achieve a balance between the real-time demands of critical RAN operations and the processing time required for more complex tasks or tasks that require a wider network insight. This can result in improved RAN performance, as well as increased efficiency and flexibility in RAN management operations.

[0205] By separating real-time and non-real-time RIC functions, mobile networks can achieve greater efficiency and flexibility in their RAN management operations, as well as reduce the load on real-time systems and allowing them to focus on the most critical tasks.

[0206] A standalone algorithm used in the management or control of RAN in Non-Real- Time RIC is called RAN Application Platform (rAPP), while in Near-Real-Time RIC it is called eXtended Application Platform (xAPP). These applications can automate various RAN-related tasks. Both rAPPs and xAPPs these components allow for greater automation and optimization of the RAN operations and improve the network performance.

[0207] OpenRAN framework with its open interfaces enables various vendors to collaborate on the development of functions and applications.

[0208] The main benefits of OpenRAN include increased vendor diversity, reduced vendor lock-in, lower costs for network deployment and operation, and improved network performance.Vendor diversity is enabled by the open interfaces it has defined through which different vendors can develop various parts of the framework or applications.

[0209] However, with this openness, conflict in operations and actions could be expected. Therefore, a mechanism and framework for the mitigation of conflicting actions are required.

[0210] This patent idea is proposing a mechanism and framework for mitigating conflicts between different rApps or xApps from one or several different vendors.

[0211] 2. Conflict Definition and Management

[0212] The idea defines a conflict as:

[0213] An expected or an observed conflict between two applications (e.g. rApps / xApps / NFs) based on changes in configuration parameters that operate in run time or planned state on the same scope or parameter.

[0214] The idea is presenting a set of conflict management principles that are inspired by the three types of conflicts as defined in the O-RAN.W3.RICARCH-v02.00 and expanded it to five types that would improve the mechanism. These are: Direct Conflict (DRC) i.e. on the same parameter e.g. tilt changes through coverage optimization or cell outage compensation actions. Indirect Conflict (INC) i.e. through dependencies e.g. on neighbor on neighbor Physical Cell Identity conflicts. Implicit Conflict (IMC) i.e. indirect impacts e.g. interference optimization at the expense of service offering to the masses. Oscillating Conflict (OSC) i.e. changes that result in repetitive changes e.g. short-term and long-term mobility load balancing mitigations or handover optimization actions. Scope Conflict (SCC) i.e. changes to the same area.

[0215] To address these types of conflicts, a Conflict Management function is proposed. Conflict management and mitigation of the conflicts may be based on several differentmechanisms depending on the characteristic of the conflict. Some of the mechanisms are: Serial Executions (switch off / on). Prioritization of Algorithms. Scheduled-based (run at certain times during the day only). Geo-diversification (allow different applications to run in separate locations). Least Change (allow both algorithms to operate and monitor the setting that results in the least number of changes).

[0216] Further descriptions of these are found in chapter 2.4.

[0217] 2.1 Process

[0218] The diagram below illustrates the process of Conflict Management. The sequence of the steps is shown as example which can varies depends on development and operation scenarios and workflows. The detail for each step is left for implementation and no flow diagram is presented in this document.

[0219] Steps:

[0220] 1- Application Advertisement: Each application advertises the following information either in an application descriptor, which is retrieved during an app onboarding and registration process, or during service registration, or service subscription / request (e.g. E2 subscription), or through a dedicated R1 service API or Near-RT RIC API. Application name, vendor, version. Service to be accessed, e.g. R1 RAN-OAM related services, E2SM-RC. Parameters to be impacted, e.g. E2SM-RC parameters, O1 CM parameters. Optimizing KPI / s (chapter 2.3). Type of Network Element, e.g. O-CU, O-DU, O-RU, macro cell, indoor cell. Scheduling constraint. Other attributes (e.g. service impacting change consideration, etc.

[0221] 2- Conflict Matrix: Development of the Application Conflict matrix. The matrix would define whether two or more applications would have one of the types of conflicts (for thetypes see chapter 2.2). The Application Conflict Matrix shall be developed and updated by App (rApp / xApp) vendors, RIC platform vendors, or operators through evaluating potential conflicts, which could take place among multiple applications. The conflict matrix may be generated automatically bythe RIC platform or by another application (xApp / rApp) based on AI / ML through monitoring and learning the behaviours of the applications under supervision. In case of manual Application Conflict Matrix generation, it shall be configured onto the RIC platform potentially via a standardized interface before an application’s operations start. For Near-RT RIC, the matrix may be configured from SMO, which handles LCM of xApps, via O1 and O2 interfaces. For Non- RT RIC, it can be configured from SMO via SMO internal service interface to Non-RT RIC framework. In case of auto generation from another application, a dedicated R1 service API or Near-RT RIC API can be used.

[0222] 3- Application Policy Definition: Application specific configurable parameters and their limits, ranges, weights, and impacting KPIs are defined. In the presence of more than one KPI, this configuration also represents operator’s intents and policies in terms of priority of the KPIs to be optimized (e.g. more QoS performance and less energy saving versus more energy saving and less QoS performance). The policy, based on the advertised capabilities and attributes of the application as specified in step 1, needs to provision for the case of whether a service impacting change is allowed. When more than one configurable parameter is governing the behaviour of an application, the application parameter weights can also be generated automatically by the RIC platform or by another application (xApp / rApp) based on AI / ML through monitoring system performance and automatically drive policies, KPI targets and KPI priorities representing the optimized state the system target to achieve. In case of auto generation from another application,a dedicated R1 service API or Near-RT RIC API can be used. The application policy can be configured to the RIC platform potentially via a standardized interface before application operations start. For Near-RT RIC, the application policy can be configured from SMO, which handles LCM of xApps, via O1 and O2 interfaces. For Non-RT RIC, it can be configured from SMO via SMO internal service interface to Non-RT RIC framework.

[0223] 4- Conflict Policy Definition: the relative priorities of applications against each other and allowed change management mechanism are specified. For instance, if application A is is considered more important compared to Application B, then A is given more importance compared to B. The relative priority can also be generated automatically by the RIC platform or by another application (xApp / rApp) based on AI / ML through monitoring and analyse behaviours of the application under supervision, and user inputs in step 3. In case of auto generation from another application, a dedicated R1 service API or Near-RT RIC API can be used. The conflict policy can be configured to the RIC platform potentially via a standardized interface before application operations start. For Near-RT RIC, the matrix can be configured from SMO, which handles LCM of xApps, via O1 and O2 interfaces. For Non-RT RIC, the conflict policy can be configured from SMO via SMO internal service interface to Non-RT RIC framework.

[0224] 5- Conflict Mitigation Scheduler: Mechanism to determine the order and the mechanism of the application runs. And overview of the different mechanism is described in chapter 2.4. Should the severity flag have been set to the highest level, the application will have priority over all other applications and all other applications are stopped. Such an example is if the application helps the system during a network outage. In such a situation, the application takes precedence over all other applications. The conflict mitigation scheduling function takes place ineither the Non-RT RIC or Near-RT RIC frameworks or in another application (rApp / xApp). If taking place in another application dedicated R1 service API or Near-RT RIC API can be used, which redirects impacting operation into the conflict mitigation App who decides whether to accept the operation and forward to the targeting destination or not. The rApp or xApp can also request guidance from conflict mitigation function before initiating an impacting operation.

[0225] 6- Change Impact Evaluation: Mechanism to collect and evaluate the KPIs before the change and after the change. Collection and evaluation of KPIs before change can be done by the RIC platform or in another application (xApp / rApp) based on AI / ML. The conflict mitigation function in the RIC evaluates performance impact from different applications based on this configuration when conflict happens, it decides which impacting change from which application is allowed. A digital twin can potentially be used for what-if analysis, e.g. given App1’s change, what is the KPI impact VS App2. Collection and evaluation of the KPIs after the change may be done via existing KPM collection and monitoring mechanism in the RIC, e.g. based on measurement data collection on O1 interface or E2 interface. Either the RIC platform or another application can take the role of close loop performance monitoring and conflict mitigation.

[0226] 7- Rollback and Oscillation Mitigation: Mechanism to rollback a change that results if the performance degraded or prevents oscillation. The mechanism shall include steps to avoid oscillation by tracking the number of changes and their direction to determine if changes are oscillating. The maximum number of changes a parameter can make shall be a user-defined parameter. Either the RIC platform or another application (xApp / rApp) based on AI / ML can take the role of rollback and oscillation mitigation.

[0227] 2.2 Application Conflict Matrix

[0228] The mechanism is suggesting an Application Conflict matrix in which the algorithms / applications that would have an impact based on the category of impact are listed. This table would then be used to determine how the impact should be dealt with. Application DRC & DRC & INC & INC & No IMC & Combination SCC No SCC SCC SCCSCC…

[0229] 2.3 Conflict Metrics

[0230] For every conflict, the user may define metrics that define the objective of the application. These metrics are the base KPIs that the applications intend to improve in the network. For instance, the user can define: Metric-1 = Capacity KPI e.g. Traffic (expressed in Erlang). Metric-2 = Quality KPI e.g. Drop Call Rate (in terms of %).

[0231] 2.4 Conflict Management and Coordination Mechanism

[0232] Conflict management in SMO / Non-RT RIC or Near-RT RIC can be based on several different mechanisms that govern how a conflict shall be processed or mitigated. These depend on the characteristic of the conflict. The following mechanisms are defined, which can be employed in run time or a planned state: Serial Executions (switch off / on) – A mechanism to switch off and on may be employed to determine the order or activation of the engagement of the applications. This mode of operation mechanism may be combined with other modes e.g., scheduled-based or prioritization of algorithm. Prioritization of Algorithms – A mechanism that executes the applications based on a prioritization of the algorithms. A further relative priority canbe assigned between two or more applications that could fine-tune the governance of the execution of the applications. This mode of operation mechanism may be combined with other modes e.g. scheduled-based or serial execution of algorithm. Scheduled-based – A mechanism through which applications are executed at a specific time or in a reoccurring time. Outside of execution window, the application would be switch off and stay in a monitor mode until it is called upon again. This mode of operation mechanism may be combined with other modes e.g., serial execution or prioritization of algorithm. Geo-diversification – A mechanism to allow the execution of the conflicting applications if the conflicts is deemed acceptable if their geographical scopes are made distinct, e.g., two cells pointing away from each other with the same PCI assignment. This mode of operation mechanism may be combined with other modes e.g., scheduled-based or prioritization of algorithm. Least Change – A mechanism to identify that the changes of two or more applications are resulting in oscillation of changes. This mode of operation mechanism may be combined with other modes e.g. scheduled-based or prioritization of algorithm or serial execution.

Claims

What is claimed is:

1. An apparatus configured to: obtain a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtain a conflict policy definition defining priorities of the plurality of applications relative to each other; and determine, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

2. The apparatus according to claim 1, wherein the apparatus is configured to determine the conflict mitigation schedule by: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix; obtaining the priorities of the plurality of applications relative to each other, the obtained priorities being user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality of applications based on the determined priorities and the selected one or more conflict management and coordination mechanisms.

3. The apparatus according to claim 1, wherein the one or more conflicts specified in the conflict matrix comprise one or more of: direct conflict (DRC), indirect conflict (INC), implicit conflict (IMC), oscillating conflict (OSC), and scope conflict (SCC).

4. The apparatus according to claim 1, wherein the one or more conflict management and coordination mechanisms comprise one or more of: serial execution, prioritization of algorithms, scheduled-based, geo-diversification, and least change.

5. The apparatus according to claim 1, wherein the apparatus is further configured to perform a change impact evaluation, wherein the change impact evaluation is performed by evaluating an impact of implementing the changes of the plurality of applications.

6. The apparatus according to claim 5, wherein a state of a network before implementing the changes of the plurality of applications is a first state, wherein a state of the network after implementing the changes of the plurality of applications is a second state, and wherein the apparatus is configured to perform the change impact evaluation by: determining one or more key performance indicators (KPIs) during the first state; determining the one or more KPIs during the second state; and determining an impact of implementing the changes of the plurality of applications based on the determined one or more KPIs during the first state and the determined one or more KPIs during the second state.

7. The apparatus according to claim 5, wherein the apparatus is further configured to perform a rollback and oscillation mitigation, wherein the rollback and oscillation mitigation is performed by rolling back the implemented changes of the plurality of applications or preventing oscillation of changes.

8. The apparatus according to claim 7, wherein the apparatus is configured to perform the rollback and oscillation mitigation by: determining whether to perform a rollback based on a result of the change impact evaluation; in response to determining to perform the rollback, performing the rollback; in response to determining to not perform the rollback, tracking a number of changes resulting from implementing the changes of the plurality of applications; determining whether an oscillation threshold has been reached based on the tracked number of changes; and in response to determining that the oscillation threshold has been reached, performing an oscillation mitigation.

9. The apparatus according to claim 1, wherein the apparatus is further configured to: obtain a plurality of application advertisements describing information related to the plurality of applications, wherein the information described in the plurality of application advertisements comprises one or more of: name of an application, name of a vendor of an application, version number of an application, service in a network to beaccessed by an application, parameters in a network to be impacted by an application, key performance indicator (KPI) of an application, type of network element to be worked on by an application, scheduling constraint of an application, and attributes related to an application; and obtain a plurality of application policy definitions defining one or more operational parameters of the plurality of applications.

10. A method comprising: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to each other; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using one or more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

11. The method according to claim 10, wherein the determining the conflict mitigation schedule comprises: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix;obtaining the priorities of the plurality of applications relative to each other, the obtained priorities being user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality of applications based on the determined priorities and the selected one or more conflict management and coordination mechanisms.

12. The method according to claim 10, wherein the one or more conflicts specified in the conflict matrix comprise one or more of: direct conflict (DRC), indirect conflict (INC), implicit conflict (IMC), oscillating conflict (OSC), and scope conflict (SCC).

13. The method according to claim 10, wherein the one or more conflict management and coordination mechanisms comprise one or more of: serial execution, prioritization of algorithms, scheduled-based, geo-diversification, and least change.

14. The method according to claim 10, further comprising performing a change impact evaluation, wherein the change impact evaluation is performed by evaluating an impact of implementing the changes of the plurality of applications.

15. The method according to claim 14, wherein a state of a network before implementing the changes of the plurality of applications is a first state, wherein a state of the network after implementing the changes of the plurality of applications is a second state, and wherein the performing the change impact evaluation comprises:determining one or more key performance indicators (KPIs) during the first state; determining the one or more KPIs during the second state; and determining an impact of implementing the changes of the plurality of applications based on the determined one or more KPIs during the first state and the determined one or more KPIs during the second state.

16. The method according to claim 14, further comprising performing a rollback and oscillation mitigation, wherein the rollback and oscillation mitigation is performed by rolling back the implemented changes of the plurality of applications or preventing oscillation of changes.

17. The method according to claim 16, wherein the performing the rollback and oscillation mitigation comprises: determining whether to perform a rollback based on a result of the change impact evaluation; in response to determining to perform the rollback, performing the rollback; in response to determining to not perform the rollback, tracking a number of changes resulting from implementing the changes of the plurality of applications; determining whether an oscillation threshold has been reached based on the tracked number of changes; and in response to determining that the oscillation threshold has been reached, performing an oscillation mitigation.

18. The method according to claim 10, further comprising: obtaining a plurality of application advertisements describing information related to the plurality of applications, wherein the information described in the plurality of application advertisements comprises one or more of: name of an application, name of a vendor of an application, version number of an application, service in a network to be accessed by an application, parameters in a network to be impacted by an application, key performance indicator (KPI) of an application, type of network element to be worked on by an application, scheduling constraint of an application, and attributes related to an application; and obtaining a plurality of application policy definitions defining one or more operational parameters of the plurality of applications.

19. A non-transitory computer-readable recording medium having recorded thereon instructions executable by an apparatus to cause the apparatus to perform a method comprising: obtaining a conflict matrix specifying one or more conflicts between a first application and a second application of a plurality of applications; obtaining a conflict policy definition defining priorities of the plurality of applications relative to each other; and determining, based on the conflict matrix and the conflict policy definition, a conflict mitigation schedule for implementation of changes of the plurality of applications using oneor more conflict management and coordination mechanisms to resolve the associated one or more conflicts specified in the conflict matrix.

20. The non-transitory computer-readable recording medium according to claim 19, wherein the determining the conflict mitigation schedule comprises: selecting one or more conflict management and coordination mechanisms based on the one or more conflicts specified in the conflict matrix; obtaining the priorities of the plurality of applications relative to each other, the obtained priorities being user-defined according to the conflict policy definition; and scheduling the implementation of the changes of the plurality of applications based on the determined priorities and the selected one or more conflict management and coordination mechanisms.

Images