INTER-DOMAIN OPERATION IN OPEN RADIO ACCESS NETWORKS

A computer-implemented method includes creating an awareness module on a first near-Real-Time RAN Intelligent Controller (near-RT RIC) that controls a first domain. The first near-RT RIC identifies a second near-RT RIC that controls a second domain, which has a mutual impact on the first domain. The first near-RT RIC creates a first border state that represents attributes of the first near-RT RIC and the xApps of the first near-RT RIC. The first near-RT RIC receives from the second near-RT RIC, a second border state of the second near-RT RIC. The first near-RT RI generates, a policy for the first near-RT RIC and the second near-RT RIC by analyzing the first and second border states. The first near-RT RIC updates a parameter only if the policy allows a requesting xApp to update the parameter.

BACKGROUND

The present invention relates to computer technology, particularly to programmable networks and, even more specifically, to programmable radio access networks (RANs) that can use the open-RAN (O-RAN) network standards.

A RAN is a portion of a telecommunication system that typically connects user equipment (UE) devices, such as mobile phones, computers, or remotely controlled machines, and the telecommunication system's core network (CN). The RAN functionality is generally provided by hardware and/or software residing in a base station in proximity to a cell site. O-RAN refers to a disaggregated approach to deploying a RAN by using open and/or interoperable protocols and interfaces, which allows for increased flexibility over traditional RAN systems. O-RAN can be implemented with vendor-neutral hardware and software-defined technology based on open interfaces and industry-developed standards.

SUMMARY

According to one or more embodiments of the present invention, a computer-implemented method for addressing cross-domain conflicts in a radio access network (RAN) is described. The computer-implemented method includes creating on a first near-Real-Time RAN Intelligent Controller (near-RT RIC) an awareness module comprising a plurality of instructions, the first near-RT RIC controls a first domain. The method further includes identifying, by the first near-RT RIC, a second near-RT RIC that controls a second domain, wherein an update request from one or more xApps being executed by the first near-RT RIC and the second near-RT RIC has a mutual impact on the first domain and the second domain. The method further includes creating, by the first near-RT RIC, a first border state that represents attributes of the first near-RT RIC and the one or more xApps being executed by the first near-RT RIC. The method further includes receiving, by the first near-RT RIC from the second near-RT RIC, a second border state that represents attributes of the second near-RT RIC and the one or more xApps being executed by the second near-RT RIC. The method further includes generating, by the first near-RT RIC, a policy for the first near-RT RIC and the second near-RT RIC by analyzing the first border state and the second border state. In response to receiving, by the first near-RT RIC, a request from an xApp from the one or more xApps to update a parameter of the RAN, the parameter is updated based on the policy allowing the xApp to update the parameter, alternatively, the parameter is maintained unchanged based on the policy restricting the xApp to update the parameter.

In one or more embodiments of the present invention, the awareness module is created on the near-RT RIC by a non-Real-Time RAN Intelligent Controller (non-RT RIC).

In one or more embodiments of the present invention, the first near-RT RIC generates the policy using machine learning.

In one or more embodiments of the present invention, the first near-RT RIC updates the first border state in response to each action taken by any of the one or more xApps.

In one or more embodiments of the present invention, the first near-RT RIC and the second near-RT RIC communicate with each other via a communication link without using the non-RT RIC.

In one or more embodiments of the present invention, the first near-RT RIC sends the policy to the second near-RT RIC to cause the second near-RT RIC, in response to the request from the xApp from the one or more xApps to update the parameter of the RAN: update the parameter based on the policy allowing the xApp to update the parameter; and maintain the parameter unchanged based on the policy restricting the xApp to update the parameter.

In one or more embodiments of the present invention, the policy is a first policy, and wherein second near-RT RIC compares the first policy with a second policy generated by the second near-RT RIC based on one or more of prioritization and criticality.

In one or more embodiments of the present invention, the method further includes receiving, by the first near-RT RIC, one or more operational intents that specify desired operating ranges for one or more performance indicators. The policy is generated based on the first border state, the second border state, and the one or more operational intents.

In one or more embodiments of the present invention, the policy restrains the xApp to update the parameter within a particular range.

In one or more embodiments of the present invention, the xApp is a first xApp, and wherein the policy restrains the first xApp to update the parameter, and does not restrain a second xApp to update the parameter.

According to one or more embodiments of the present invention, a system includes a non-real-time radio access network intelligent controller (non-RT RIC) of a radio access network (RAN). The system further includes multiple near-real-time RAN intelligent controllers (near-RT RICs) of the RAN, the non-RT RIC controls one or more operations of the near-RT RICs, the near-RT RICs comprising a first near-RT RIC and a second near-RT RIC. The first near-RT RIC is configured to receive a module comprising a plurality of instructions to be used for resolving cross-domain conflicts, the first near-RT RIC controls a first domain. The first near-RT RIC is further configured to identify a second near-RT RIC that controls a second domain, wherein an update request from one or more xApps being executed by the first near-RT RIC and the second near-RT RIC has a mutual impact on the first domain and the second domain. The first near-RT RIC is further configured to create a first border state that represents attributes of the first near-RT RIC and the one or more xApps being executed by the first near-RT RIC. The first near-RT RIC is further configured to receive, from the second near-RT RIC, a second border state that represents attributes of the second near-RT RIC and the one or more xApps being executed by the second near-RT RIC. The first near-RT RIC is further configured to generate a policy for the first near-RT RIC by analyzing the first border state and the second border state. The first near-RT RIC is further configured to, based on the policy, in response to receipt of a request from an xApp from the one or more xApps to update a parameter of the RAN: update the parameter based on the policy allowing the xApp to update the parameter; and maintain the parameter unchanged based on the policy restricting the xApp to update the parameter.

According to one or more embodiments of the present invention, a computer program product includes a memory device with computer-executable instructions therein, the computer-executable instructions when executed by a processing unit perform a method for addressing cross-domain conflicts in a radio access network (RAN). The method includes creating on a first near-Real-Time RAN Intelligent Controller (near-RT RIC) an awareness module comprising a plurality of instructions, the first near-RT RIC controls a first domain. The method further includes identifying, by the first near-RT RIC, a second near-RT RIC that controls a second domain, wherein an update request from one or more xApps being executed by the first near-RT RIC and the second near-RT RIC has a mutual impact on the first domain and the second domain. The method further includes creating, by the first near-RT RIC, a first border state that represents attributes of the first near-RT RIC and the one or more xApps being executed by the first near-RT RIC. The method further includes receiving, by the first near-RT RIC from the second near-RT RIC, a second border state that represents attributes of the second near-RT RIC and the one or more xApps being executed by the second near-RT RIC. The method further includes generating, by the first near-RT RIC, a policy for the first near-RT RIC and the second near-RT RIC by analyzing the first border state and the second border state. In response to receiving, by the first near-RT RIC, a request from an xApp from the one or more xApps to update a parameter of the RAN, the parameter is updated based on the policy allowing the xApp to update the parameter, alternatively, the parameter is maintained unchanged based on the policy restricting the xApp to update the parameter.

Embodiments of the invention described herein address technical challenges in computing technology, particularly in fields of telecommunications and computing networks. One or more embodiments of the present invention facilitate improvements to radio access networks (RANs), particularly open-RAN (O-RAN) networks. Embodiments of the present invention provide technical solutions that facilitate automated resolution of inter-domain conflicts without direct involvement of a non-Real-Time RAN Intelligent Controller (non-RT RIC). Embodiments of the present invention facilitate inter-domain operation in O-RAN with direct communication between the near-Real-Time RAN Intelligent Controllers (near-RT RICs), by using one or more of border State Tracking, Border Digital Twin and Activity Register, Cross-domain Policy Generator, and continuous awareness, as described herein. One or more embodiments of the present invention further facilitate creation and maintaining of limited digital twins representing border areas of own domain and neighboring domains. Embodiments of the present invention further facilitate prediction of impact of activities from own domain on the neighboring domain and identification of optimal follow-up actions that prevent negative/unintended network impact. Further, one or more embodiments of the present invention facilitate delegation of decision-making responsibilities from the non-RT RIC to the near-RT RICs.

Embodiments of the present invention improve the O-RAN architecture by reducing response time compared to present techniques to resolve inter-domain conflicts via non-RT RIC, which may not be acceptable as applications demand faster response time for both application and scheduling layer. Further, embodiments of the present invention reduce signaling between the near-RT RICs and the non-RT RIC. Such signaling leads to congestions on A1 interface, especially when control loop utilization tends to surge. Accordingly, embodiments of the present invention prevent such signaling load. Additional advantages and improvements will be evident based on the description herein.

In the accompanying figures and following detailed description of the disclosed embodiments, the various elements illustrated in the figures are provided with two or three-digit reference numbers. With minor exceptions, the leftmost digit(s) of each reference number corresponds to the figure in which its element is first illustrated.

DETAILED DESCRIPTION

The description herein makes reference to the Third Generation Partnership Project (3GPP) system, the O-RAN Fronthaul Working Group, and the xRAN Fronthaul Working Group. The description herein uses abbreviations, terms, and technology defined in accord with 3GPP technology standards, O-RAN Fronthaul Working Group technology standards, and xRAN Fronthaul Working Group technology standards. As such, the 3GPP, O-RAN Fronthaul Working Group, and xRAN Fronthaul Working Group technical specifications (TS) and technical reports (TR) referenced herein are incorporated by reference in their entirety herein and define the related terms and architecture reference models that follow. References may also be made to CPRI, the Industry Initiative for a Common Public Radio Interface, and abbreviations, terms, and technology defined in the eCPRI technology standard may also be used consistent with 3GPP technology standards. The CPRI technical specification eCPRI specifications (e.g., V1.1 (2018 Jan. 10)) are also incorporated by reference in its entirety herein.

Embodiments of the invention described herein address technical challenges in computing technology, particularly in the fields of telecommunications and computing networks. One or more embodiments of the present invention facilitate improvements to radio access networks (RANs), particularly open-RAN (O-RAN) networks. Embodiments of the present invention provide technical solutions that facilitate automated resolution of inter-domain conflicts without the involvement of a non-Real-Time RAN Intelligent Controller (non-RT RIC). Embodiments of the present invention facilitate inter-domain operation in O-RAN with direct communication between the near-Real-Time RAN Intelligent Controllers (near-RT RICs) by using one or more of border state tracking, border digital twin and activity register, cross-domain policy generator, and awareness module, as described herein. One or more embodiments of the present invention further facilitate the creation and maintaining of limited digital twins representing border areas of own domain and neighboring domains. Embodiments of the present invention further facilitate predicting the impact of activities from own domain on the neighboring domain and identifying optimal follow-up actions that prevent negative/unintended network impact. Further, one or more embodiments of the present invention facilitate delegating decision-making responsibilities from the non-RT RIC to the near-RT RICs.

Embodiments of the present invention improve the O-RAN architecture by reducing response time compared to present techniques to resolve inter-domain conflicts via non-RT RIC, which may not be acceptable as applications demand faster response time for both the application and scheduling layer. Further, embodiments of the present invention reduce signaling between the near-RT RICs and the non-RT RIC. Such signaling leads to congestion on the A1 interface, especially when control loop utilization tends to surge. Accordingly, embodiments of the present invention prevent such congestion. Additional advantages and improvements will be evident based on the description herein.

Conventional RANs were built employing a single unit that processed the entirety of communication protocols for the RAN. The RAN network traditionally used application specific hardware for processing, making them difficult to upgrade and evolve. However, communication networks and needs evolved with the growing need to support increased capacity. Accordingly, there were (and still are) efforts to reduce RAN deployment costs and improve RAN equipment's scalability and upgradeability. Cloud-based Radio Access Networks (CRAN) are networks where a significant portion of the RAN layer processing is performed at a centralized/central unit (CU), sometimes also referred to as a baseband unit (BBU). Typically, the CU is located in the cloud on commercial off-the-shelf servers, while the RF and real-time critical functions are processed in a remote radio unit (RU or RRU) and a distributed unit (DU). In some embodiments, the DU can be part of the CU/BBU, depending on the functional split.

CRAN provides centralization and virtualization of RAN, with improvements over the earlier architecture of RAN. Such improvements include reduction in operating cost (e.g., because of resource pooling, enabling economies of scale, etc.), improvement in performance improvements (e.g., improved interference), remote upgradeability and management, and improved configurability of features (e.g., transition from 4G to 5G networks).

By using distributed cloud technology, CRAN ensures flexibility and scalability of the network and opens up the possibility to support modern end-user services, such as virtual reality, V2X, remote surgery, and many more, that have much stricter service level agreement (SLA) requirements compared to the legacy services. Operation processes in modern networks are automated because they are to occur at a sub-second time scale. The state-of-the-art networks must be able to support different use cases with various SLA requirements at the same time, e.g., high throughput, ultra-low latency, better signal quality, etc. In this respect, the technical challenges posed to modern networks include at least the following: optimize network utilization by scheduling resource allocations and implementing self-optimization rules at a sub-second time scale; and act swiftly on dynamic network conditions, such as traffic bursts or traffic shifts, to ensure the SLA for all the active services.

Automated network operations for self-decision making have become an essential and inevitable part of the overall network design. Indeed, modern network architectures integrate operation processes in their overall design and, as a result, include network infrastructure that is used to commute user traffic. The footprint of this infrastructure is increased compared to the legacy networks, which is driven by the increase in the network traffic amount and strict SLA requirements of the novel services. Further, modern network infrastructure has been improved to host automated operations processes. This infrastructure must be installed in the proximity of the end-users, and it must be redundant and fail-safe. Compared to the legacy networks, the amount of infrastructure for operations is significantly increased.

As a result, the overall network infrastructure in modern networks is significantly increased compared to legacy networks. O-RAN is one such example of a state-of-the-art modern network. Besides network infrastructure that is used to carry the user traffic in O-RAN (hosting RUs, O-DUs, and O-CUs, small cells, etc.), telecommunication operators have to introduce additional extensive network infrastructure to host the non-RT RICs and several near-RT RICs for faster decision-making control loops.

Broadly, an O-RAN is a nonproprietary version of a CRAN system that allows interoperation between network equipment provided by different vendors. The O-RAN alliance issues specifications and standards that the vendors are required to facilitate the operation of an O-RAN system.

A brief description of an O-RAN architecture is now described with reference toFIG.1. It is understood that other embodiments of the present invention can use different, fewer, or additional components than depicted herein without diverging from the technical solutions described herein. In some embodiments of the present invention, one or more components depicted herein may be combined or further split (distributed), again without diverting from the technical solutions described herein.

The O-RAN architecture100includes several components that inter-communicate over different interfaces. Each interface uses a different name per the O-RAN specification and includes the A1 interface, the O1 interface, the O2 interface, and the Open Fronthaul Management (M)-plane interface. The interfaces connect the Service Management and Orchestration (SMO) framework102to O-RAN network functions (NFs)104. The NFs104include, for example, near-RT RICs114, radio units116, and other components. The interfaces also connect the SMO102and the O-Cloud106. The O-Cloud106can be a cloud computing platform including a collection of physical infrastructure nodes to host the relevant O-RAN network functions (e.g., the near-RT RIC114, O-CU118, O-DU120), supporting software components (e.g., operating systems, virtual machines, container runtime engines, machine learning engines, etc.), and appropriate management and orchestration functions. It should be noted that the SMO102and the other components shown can connect with other components (e.g., an enrichment data source, NG-CORE, etc.) that are not depicted herein.

The SMO102includes the non-RT RIC112, which connects with the near-RT RIC114, for example, via the A1 interface. The SMO102can also connect with one or more of the NFs104. The O-RAN NFs104can be virtual network functions (VNFs) such as virtual machines or containers, implemented above the O-Cloud106layer and/or above one or more Physical Network Functions (PNFs). The O-RAN NFs104may be implemented using customized hardware; however, all the O-RAN NFs104support the O1 interface when interfacing with the SMO framework102.

Further, the SMO102manages the O-RAN Radio Unit (O-RU)116via the Open Fronthaul M-plane interface. The Open Fronthaul M-plane interface is an optional interface that is included for backward compatibility purposes in particular modes, such as the hybrid mode, as defined in O-RAN specifications.

Conventionally, the SMO102with the non-RT RIC112and the O-Cloud106are referred to as the “management portion/side” of the O-RAN100; and the near-RT RIC114, the O-DU120, the O-RU116, the O-CU118functions are referred to as “radio portion/side” of the O-RAN architecture100. In some embodiments of the invention, the radio portion/side also includes the gNB (not shown). The gNB410is an LTE eNB, a 5G gNB or ng-eNB that supports the E2 interface.

The O-RU116is a logical node hosting lower PHY layer entities/elements (Low-PHY layer) (e.g., FFT/iFFT, PRACH extraction, etc.) and RF processing elements based on a lower layer functional split. Virtualization of O-RU116is FFS. The O-CU118is a logical node hosting the RRC and the control plane (CP) part of the PDCP protocol. The O-CU118also hosts the user plane part of the PDCP protocol and the SDAP protocol. The O-DU120is a logical node hosting RLC, MAC, and higher PHY layer entities/elements (High-PHY layers) based on a lower-layer functional split. Conventionally, the O-CU118and the O-DU120are referred to as “E2” nodes because the near-RT RIC114connects with them via the E2 interface. In some cases, the gNB may also be included as an E2 node for the same reasons. The protocols over the E2 interface are based exclusively on Control Plane (CP) protocols. The E2 functions are grouped into the following categories: near-RT RIC services (REPORT, INSERT, CONTROL, and POLICY); near-RT RIC support functions, which include E2 Interface Management (E2 Setup, E2 Reset, Reporting of General Error Situations, etc.); and near-RT RIC Service Update (e.g., capability exchange related to the list of E2 Node functions exposed over E2).

In one or more embodiments of the present invention, the Uu interface is used between a UE (not shown), the gNB, and any other O-RAN components. The Uu interface is a 3GPP defined interface, which includes a complete protocol stack from L1 to L3. While only single components are shown herein, it is understood that the O-RAN100can include several UEs and/or several gNB, each of which may be connected to one another via respective Uu interfaces. Also, while not shown, the O-RAN architecture100can include other interfaces (E1, F1-c, NG-c, X2-c, etc.) that connect the components to other components (that are not shown, e.g., en-gNB, gNB-CU, etc.) and/or to components that are shown.

The non-RT RIC112is a logical function within the SMO framework102that enables non-real-time (>1 second operation times) control and optimization of RAN elements and resources; AI/machine learning (ML) workflow(s), including model training, inferences, and updates; and policy-based guidance of applications/features in the near-RT RIC114. In some embodiments of the present invention, the non-RT RIC112can be an ML training host to host the training of one or more ML models. ML training can be performed offline using data collected from the near-RT RIC, O-DU120, and O-RU116. The near-RT RIC114is a logical function that enables near-real-time (sub 1 second operation times) control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. The near-RT RIC114may include one or more AI/ML workflows, including model training, inferences, and updates.

O-RAN is built on the foundation of virtualization, automation, and cloud technologies. NFs104are disaggregated, and there are open interfaces between them. To be able to support modern services, O-RAN integrates automated operations into its overall architecture by providing three control loops of different time scales for different operation and optimization processes. The non-real-time control loop (involving the non-RT RIC112in SMO102) has an above-second timeframe, the near-real time control loop (involving the near-RT RICs114) has a sub-second timeframe, and finally, the real-time control loop (involving the O-DU120) has the timeframe that is below 10 ms.

The cloud-native nature of the NFs104in the O-RAN allows various deployment options, in which some or all functionalities can be bundled together as per the infrastructure availability and operator deployment preference. For more details regarding deployment options, one should refer to the Technical Specification document “O-RAN Architecture Description” from O-RAN WG1. Any O-RAN deployment scenario must ensure that the timing requirements of each of the three control loops are met.

O-RAN specifications further characterize the interfaces into a control plane, a management plane, a synchronization plane, and a user plane. Control Plane (C-plane) refers to real-time control between O-DU120and O-RU106, not including the IQ sample data (part of the User Plane). Management Plane (M-plane) refers to non-real-time management operations between the O-DU120and the O-RU106. Synchronization Plane (S-Plane) refers to traffic between the O-RU106or O-DU120to a synchronization controller, which is generally an IEEE-1588 Grand Master. Grandmaster not only represents a highly accurate source of synchronization for all network devices supporting the Precision Time Protocol (PTP), the Network Time Protocol (NTP), and the Simple Network Time Protocol (SNTP), etc., but it also offers a number of legacy time and frequency outputs for keeping non-networked devices in-sync. User Plane refers to IQ sample data transferred between O-DU120and O-RU106.

The C-and-U-plane Ethernet stack commonly uses a UDP (User Datagram Protocol) to carry eCPRI or RoE. If RoE is selected, it is carried over Ethernet L2 with a VLAN; eCPRI can be carried over Ethernet L2 or UDP. The C- and U-plane both have the highest priority via the VLAN (priority 7), and within the IP layer are defined as Expedited Forwarding.

The S-plane Ethernet stack uses Ethernet to carry PTP (Precision Time Protocol) and/or SyncE (Synchronous Ethernet) traffic, so that end mobile elements are time-synchronized. In 5G networks, for example, it is particularly important that each RU, especially RUs in the same segment or adjoining segments (locations where UE (User Equipment) may be in contact with multiple RUs), is time-synchronized, allowing the 5G network to maintain high throughput while downloading data from multiple RUs at once, or while transferring from one RU to another.

The M-plane Ethernet stack uses TCP (Transmission Control Protocol) to carry the management messages between the RU106and DU120. O-RAN defines a NETCONF/YANG profile to be carried over this layer via SSH (Secure Shell), allowing communication between the RU106and DU120.

The O-RAN100can be used by several users that can represent one or more user equipment, which can be of any type. For example, the users include IoT enabling devices (e.g., sensors, etc.), automated devices (e.g., factory appliances, home appliances, automated vehicles, etc.), user devices (e.g., phones, tablets, laptops, servers, etc.), or any other types of electronic devices that use the O-RAN100for communication. The components of O-RAN100use one or more hardware equipment, which can include computer servers, modems, routers, switches, computing devices, and any other hardware devices used to implement a networking infrastructure. The hardware devices may implement one or more components of the O-RAN100(seeFIG.1) as virtual machines, software developed network modules, machine learning modules, or any other combination thereof.

In O-RAN100, SMO102, non-RT RIC112, and near-RT RICs104continuously collect the network state. The RICs (102,104) host applications (130,132) that read the network state and govern the network behavior accordingly. These applications include rApps130on the non-RT RIC112and xApps132on near-RT RICS104, respectively.

rApps130, which reside in the centralized non-RT RIC112, are used for identifying network governing policies that require insight into the end-to-end network state or exhaustive computing resources for their calculation. Such attributes, policies, and insights are available only on the non-RT RIC112. In some embodiments of the present invention, rApps130require end-to-end network insight for its operation. rApps130issue high-level policies and send them to the entities in the lower hierarchical layer (e.g., near-RT RICs) for interpretation and implementation on radio units116.

On the other hand, xApps132reside on the near-RT RICs104and are distributed. Typically, the xApps132are those applications that need to operate at timescales of less than a second. Instead, due to their proximity to the network entities (CUs118, DUs120, etc.), near-Real Time RICs104are used to host the xApps132that identify and enforce delay-sensitive optimization policies that require insight in the domain state only. Accordingly, xApps132operate leveraging the near-real time control loop that is executed in under 1 s, whereas, for rApps130, this time can be above 1 s.

The near-RT RICs104are placed in the lower hierarchical layer compared to the non-RT RIC112. Each near-RT RIC114has an overview of only its own controlled domains. The near-RT RICs104host xApps132. xApps132may not require end-to-end network insight for operation but only insight into the domain state. xApps132may implement the policies issued by the rApps130or run independently from rApps130.

There are various types of xApps132. For example, a first type of xApps132can subscribe to rApps130and implement the policies that the rApps130issue over the interface A1. Second type of xApps132can execute independently from rApps130and govern the network behavior according to their own logic. xApps132execute in parallel with each other, and conflicts can occur. Such conflicts can cause network instability or performance degradation. Conflicts also cause a security risk in O-RAN100because attackers may use such a conflict as a vulnerability to attack the network.

O-RAN Alliance has specified the following conflict types between the xApps132. Direct conflict: Different xApps132request to modify the same parameter (e.g., first xApp132requests increased antenna downtilt, and second xApp132requests a decrease in the antenna downtilt). Indirect conflict: Different xApps132request to modify different parameters, but modifying the parameters can have opposing effects (e.g., first xApp132requests as antenna down tilt, and a second xApp132requests a power increase). Implicit conflict: Different xApps request to modify different parameters, which may not have opposing effects but may cause the overall performance of the network to degrade.

An example of an implicit conflict includes when a first xAPP132requests a change to load balancing threshold to push the traffic from its domain, while a second xApp132requests reducing the codec rate for accommodating traffic in its domain. Accordingly, the changes are not affecting similar KPIs in both domains. Instead, one domain is pushing the traffic while the other is degrading the customer experience by downgrading the codec rate, thus posing an implicit conflict. It is understood that the examples of direct, indirect, and implicit conflicts herein are for illustration and that there are several other scenarios in which such conflicts can occur. As such, the examples herein are not to be construed as limiting scenarios.

A technical challenge exists to detect and mitigate such conflicts in the O-RAN100. Typically, direct and (some) indirect conflicts can be detected by leveraging pre-action resolution, in which the near-RT RIC114checks the parameters that certain xApp132is attempting to modify before the update is implemented in the network. In some cases, post-action verification is performed, in which the near-RT RIC114monitors the state of the network after the update has been implemented and verifies if the state is as expected. Implicit conflicts are not always easy to detect. State-of-the-art telecommunications today does not have formal mechanisms for identifying all indirect and implicit conflicts. Even further, O-RAN Alliance currently does not define any interaction between two or more near-RT RICs104. Accordingly, a first near-RT RIC114, which has a first domain, is not able to detect a conflict that may be caused in or by a second near-RT RIC114, which has its separate second domain.

Therefore, a technical challenge exists that coordination and execution of any cross-domain activity in O-RAN100(e.g., resolution of inter-domain conflicts) requires the involvement of the non-RT RIC112because the near-RT RICs104do not directly communicate. The consequence is increased response time, which may not be acceptable as applications demand faster response time for both the application and scheduling layer. Another disadvantage of the inability to resolve cross-domain (or inter-domain) conflict and handle cross-domain coordination leads to increased signaling between the near-RT RICs104and the non-RT RIC112has to be performed, which may lead to congestion on the A1 interface. Such congestion can be especially experienced in the scenarios when control loop utilization tends to surge for one or more applications.

From the domain point of view, a cross-domain or an inter-domain conflict is one in which conflicting xApps132reside on two (or more) different near-RT RICs114, i.e., actions performed in one domain201have consequences in another domain201that conflict with policies specified for that domain201. Herein, such near-RT RICs114, where a first xApp132from a first near-RT RIC114can affect policies of a second near-RT RIC114, are referred to as “neighboring near-RT RICs.”

Cross-domain conflicts can be caused by an action such as Cell Coverage Optimization (CCO) in Domain A vs. CCO in Domain B. Cross-domain conflict can also be caused by a Mobility Load Balancing (MLB) vs. Mobility Robustness Optimization (MRO). Inter-mobility handover function (IMHO) vs. Interference mitigation function can also cause a cross-domain conflict.

Embodiments of the present invention address such technical challenges regarding inter-domain conflicts in O-RAN100by using a direct communication link between neighboring near-RT RICs104. Note that the direct communication in the case when the two near-RT RICs/xAPP/E2 Nodes come from different NEPs may require additional adaptation layer(s). Further, one or more embodiments of the present invention facilitate creating and maintaining limited intended digital twins representing border areas of own domain and neighboring domains. Further, embodiments of the present invention facilitate the prediction of the impact of activities from the own domain on the neighboring domain and the identification of optimal follow-up actions that prevent negative impact. One or more embodiments of the present invention further facilitate the delegation of decision-making responsibilities from the non-RT RIC112to the near-RT RICs104.

At present, inter-domain conflict management in O-RAN100is performed by the non-RT RIC112. Embodiments of the present invention facilitate a comparatively faster inter-domain conflict resolution and inter-domain operation coordination that operates in the lower hierarchical layer of the O-RAN architecture, namely in the near-RT RIC s104.

Accordingly, embodiments of the present invention improve O-RAN architectures, such as the O-RAN architecture100. Embodiments of the present invention, accordingly, are rooted in computing technology and facilitates improvement to computing technology, particularly communication networks using O-RAN architecture. Such improvements include detecting and mitigating inter-domain conflicts, such as conflicts between a first near-RT RIC114and a second near-RT RIC in the O-RAN architecture. Additional improvements provided by embodiments of the present invention include mitigating congestion on the A1 interface. Further, embodiments of the present invention provide a practical application in the field of computing technology, particularly O-RAN, by establishing a direct communication link between two or more near-RT RICs104to resolve inter-domain conflicts and perform other coordination.

FIG.2depicts a block diagram of the near-RT RIC114according to one or more embodiments of the present invention. The near-RT RIC114is depicted executing N xApps132, N being any integer. Several functions performed by the near-RT RIC114are depicted as blocks; however, it is understood that at least some of these blocks can be combined. Each of the depicted blocks can be a separate module or component, such as a hardware unit (e.g., FPGA, ASIC, etc.) or a software unit (e.g., computer program, application program interface, library, etc.), or a combination thereof.

The near-RT RIC114is associated with a domain201, which includes a set of DUs120that is in communication with the near-RT RIC114. Typically, a DU120only communicates with a single near-RT RIC114when using the O-RAN100(until it is switched to a different near-RT RIC114). The near-RT RIC114communicates with the DUs120in domain201via one or more CUs118. In other words, a “domain”201of a near-RT RIC114is a set of DUs120that are associated with that near-RT RIC114. Each near-RT RIC114has its own separate domain201. Herein, the terms domain and near-RT RIC can be used interchangeably.

The near-RT RIC114includes, among other components, a cross-domain policy generator202, an awareness module204, a border state tracker206, and a border digital twin and activity register208.

Further, the near-RT RIC114includes several interfaces to communicate with other components of the O-RAN100. For example, the interfaces include an O1 interface210, an A1 interface212, an E2 interface214, and an NX1 interface216. The O1 interface210and the A1 interface212facilitate the non-RT RIC112to communicate with the near-RT RIC114as per the O-RAN specification. Further, the E2 interface214facilitates communication between the near-RT RIC114and the E2 nodes (i.e., CU118, DU120) as per the O-RAN specifications. The NX1 interface216facilitates a direct communication link between two or more near-RT RICs114.

The direct communication via the NX1 interface, as facilitated by one or more embodiments of the present invention, reduces the need for involving non-RT RIC112to resolve inter-domain conflicts, as is described herein. By eliminating the involvement of the non-RT RIC112, the resolution of the inter-domain conflict and coordination is faster and further eliminates congestion on the A1 interface (of the non-RT RIC112). Accordingly, embodiments of the present invention facilitate improvements to the near-RT RIC114, the non-RT RIC112, and the overall O-RAN100.

The border state tracker206is responsible for creating and maintaining the border digital twin and activity register208. The border state tracker206tracks and logs the conditions that are relevant for the border digital twin, e.g., relevant user and control plane events and conditions. The border state tracker206further shares/receives the border digital twin details with/from the neighboring near-RT RIC114, i.e., neighboring domains.

Tracking and logging such data digitally in a dynamic manner requires a specific format (i.e., data structure) that provides information that can be used for the detection of conditions that demand attention and policy identification. Embodiments of the present invention provide a logging operation and format that address such technical challenges.

FIG.3depicts a border state data structure used by a non-RT RIC114to track records according to one or more embodiments of the present invention. The data structure300is shown in a tabular format; however, it is understood that the data can be stored using other data structures, such as an array, a graph, etc. Each near-RT RIC114stores at least two of the data structures300: first data structure300logs update activity/request sent by the near-RT RIC114to a neighboring near-RT RIC114(neighbor, second near RT-RIC); and second data structure300logs update activity/request received from the neighboring near-RT RIC114.

Each data structure300can include multiple records302. Each record302represents an update activity being performed or an update request being sent by an xApp132(of either the near-RT RIC114or the neighbor). The update activity/request can be to change one or more parameters of the near-RT RIC114and/or any other component of the O-RAN100.

The record302stores information associated with the activity/request. For example, a near-RT RIC ID uniquely identifies the near-RT RIC114from which the border affecting update originates. An xApp ID uniquely identifies the xApp132that triggered the update. A timestamp is used for logging the time at which the update occurred. A criticality measure is used for logging the operational criticality level that triggered the issued action. The criticality can be predetermined based on the type of update, the timestamp, the parameters being updated, and other such variables related to the state of the near-RT RIC114and/or the xApp132.

Further, record302includes impacted KPIs, which are used for logging the KPIs that are targeted to be affected by the action associated with the update. Impacted E2 nodes are used for logging the E2 nodes (118,120) that are affected by the update. The receiving/neighboring near-RT RIC114(i.e., second near-RT RIC) leverages this information to identify the parts of its own domain that can be affected by the update.

The record302also logs an action performed with respect to the neighboring near-RT RIC114to complete the update. The action received indicates the interaction with the neighboring domain's near-RT RIC114. The impacted neighboring domains identify the neighboring near-RT RICS114, of which domains are affected by the issued action.

Tuned parameters list the set of configuration parameters that are affected by the update. In one or more embodiments of the present invention, record302also logs the actual change that was enforced in the form of delta value (e.g., “−x” meaning that the value is reduced by x, “+y” meaning that the value is increased for y) or new parameter value (e.g., “x” meaning that the new value of the parameter is x). It is understood that any other format can be used to represent the change being made by the update.

In some embodiments of the present invention, the record302logs the high-level intent that triggered the change. The intent can be provided by the xApp132requesting the update.

Response from Neighbor is used for logging the response received from the neighboring near-RT RIC114to which the update request is sent, e.g., acknowledgment, temporary reject, permanent reject, etc.

The post-implementation impact may also be stored to log the impact that the issued action had on the network. It is represented using the operational criticality level in one or more embodiments of the present invention.

Further, in one or more embodiments of the present invention, a Ping-pong count is stored to indicate if an update is repetitive. The ping-pong count column is used to count the number of occurrences of the same update. It can then be leveraged to detect conflict on the domain border.

It is understood that the above-listed attributes that are logged as the border state can vary in one or more embodiments of the present invention. For example, in some examples, fewer, additional, or different attributes are stored to log information associated with an update activity/request. Further, it is understood that althoughFIG.3only shows three records302; any number of records can be stored in other examples.

Referring toFIG.2, the near-RT RIC114further includes the border digital twin and activity register208. The border digital twin that is stored by the near-RT RIC114includes information from its own domain and neighboring domain.

FIG.4depicts a visualization of border digital twins402stored by each near-RT RICs114in one or more embodiments of the present invention. Each near-RT RIC114stores a border digital twin402that represents a state of one or more neighboring near-RT RICs114that affect that near-RT RIC114or which are affected by that near-RT RIC114. The border digital twin402is based on information logged (FIG.3) and other information associated with the near-RT RIC114.

Each border digital twin402includes at least the following information maintained by the Border State tracker202. The border digital twin402at the first near-RT RIC114includes information from own (i.e., first near-RT RIC114) and neighboring domains (i.e., second near-RT RIC114, third near-RT RIC114, etc.). WhileFIG.4depicts only three near-RT RICs114, in other examples, a different number of near-RT RICs114can exist. Further,FIG.4depicts four domains201(three associated with the near-RT RICs114depicted, and one shown without a corresponding near-RT RIC); however, in other examples, a different number of domains201can exist.

The border digital twin402stored at a near-RT RIC114records the identities of E2 nodes (118,120) in their own domain border and E2 nodes (118,120) in the neighboring domain border. Further, the border digital twin402stores information about existing connectivity between E2 nodes (118,120) belonging to different domains201. Additionally, the border digital twin402includes a configuration snapshot of each E2 node (118,120) from that border digital twin402.

In one or more embodiments of the present invention, the border digital twin402also includes the profile of users covered by each E2 node from the digital twin. Here, a user profile represents consumer usage type like consumer using high throughput applications, consumers having high mobility at particular time, etc. A user profile can also indicate a consumer categorization like premium user, budget user, etc. Further, present traffic demand from the users covered by each E2 node (118,120) from the digital twin402is also stored. In some examples, a dependency between configuration parameters of E2 nodes (118,120) in the border digital twin402is also stored.

The border digital twin402further includes the activity register, which is the log of cross-domain impacting control plane activities, e.g., activities from the xApps132. An “activity” of an xApp132can include any operation executed by the xApp132, such as an adjustment of a parameter, receipt/transmission of data/command, etc.

InFIG.4, information corresponding to the different domains201stored in the border digital twin402is represented with different colors (gray shade). The information can be stored using a data structure such as an array, a graph, a table, a database, etc.

In one or more embodiments of the present invention, the near-RT RIC114continuously analyzes the collected information, i.e., border digital twin402, and identifies conditions that need attention. In one or more embodiments of the present invention, instructions from the awareness module (elaborated below) are used to analyze the border digital twin402. Analysis of the border digital twin can be rule-based or artificial intelligence/machine learning (AI/ML) based analysis.

If a condition that needs attention is detected, the near-RT RIC114can propose actions labeled as “Seek Operations Support” (seeFIG.3), in which the near-RT RIC114114can request, for example, migration of its own E2 nodes to neighboring near-RT RICs114for the sake of self-offloading. These actions are written to the Activity Registry and will be shared with the neighboring Near-Real Time RICs by the border state tracker206. Further, the near-RT RIC114can create actionable insight that is consumed by the cross-domain policy generator202(elaborated below) for further processing.

In one or more embodiments of the present invention, such analysis and consequent actions can be triggered after each change (insert, modify, or delete) in the border digital twin and activity register208by leveraging database triggers where a database management system is used to store the border digital twin and activity register208.

The awareness module204facilitates performing operations in response to one or more instructions/commands from the non-RT RIC112and/or other components of the near-RT RIC114. For example, the awareness module204responds to INST1: Border digital twin relevance, which is used for the identification of conditions and events on the user and control plane that must be added to the border digital twin and activity register. For control plane activities (e.g., from xApps132), the instruction involves the rules for the prediction of potential cross-domain impact. INST1 is leveraged by border activity tracker206.

Further, the awareness module204responds to INST2: Log-based identification of conditions that need attention, which is leveraged to update and maintain the Border Digital Twin and Activity Register.

The awareness module204further response to INST3: Condition prioritization and policy identification. For example, conditions/activities that relate to quality of service (QoS) optimization have higher priority than policies for energy saving. Similarly, policies that are triggered by critically impacted E2 nodes are prioritized over policies triggered by E2 nodes with an impact level of major or minor. This information is leveraged by the cross-domain policy generator202for operation coordination (elaborated herein) when responding to operations support requests or identifying policy resolution strategies.

Further, the awareness module204responds to INST4: Adaptations needed on the NX1 interface, which might be used for communication between two near-RT RICs114as RIC/xApp/E2 nodes might have been developed by two different network equipment providers (NEPs). The INST4 response may include parameter conversion, value mapping, etc., performed by the awareness module204.

FIG.5depicts a data flow diagram of the utilization of instructions from the non-RT RIC112according to one or more embodiments of the present invention. At block502, a user plane or a control plane event occurs (i.e., update request/activity via the xApp132). At block504, the near-RT RIC114determines whether the event is relevant to the border digital twin at the near-RT RIC114using INST1. If the event is relevant, an update to the border digital twin402is triggered at block506.

At block508, based on the update to the border digital twin402and using INST2, conditions of the near-RT RIC114(and any neighboring near-RT RICs114) are identified from the logged data structure300, which are to be updated. Further, at block510, a cross-domain condition prioritization and policy identification is performed using INST3.

It is understood that the above sequence of operations is one example and that the instructions listed can be used in several other ways. Further, the names of the instructions used herein can be changed without affecting the functionality provided in one or more embodiments of the present invention.

Referring toFIG.2, the cross-domain policy generator202identifies cross-domain policies when conditions that need attention are identified (e.g., inter-domain conflict detected, operations support requested, etc.). For that purpose, the cross-domain policy generator202leverages the instructions INST3 from the awareness module204. The cross-domain policy generator202automatically generates a policy for the near-RT RIC114. A “policy” is a set of conditions that have to be satisfied before the near-RT RIC114, or an xApp132of the near-RT RIC114can perform an operation, and the operation cannot be performed if the condition(s) are not satisfied. The conditions are based on one or more neighboring near-RT RICs114in one or more embodiments of the present invention. In one or more embodiments of the present invention, the near-RT RIC114, upon generating a policy in this manner, shares the policy with one or more neighboring near-RT RICs114.

For example, a policy may include local xApp guidance in which, for example, the local xApp can be turned off for a certain amount of time, or it can be prevented from updating certain parameters on certain local E2 nodes. In one or more embodiments of the present invention, the policy can be passed to the conflict mitigator for enforcement of the policy. Here, “local” represents in relation to a near-RT RIC114that generates the policy. For example, if a first near-RT RIC114generates the policy, a local E2 node118is in the domain201associated with the first near-RT RIC114.

Alternatively, or in addition, the generated policy can include whether to send ACK (confirm) or NACK (reject) as a response to particular types of requests from a neighboring near-RT RIC114, for example, operations support requests.

In one or more embodiments of the present invention, conflict resolution action is proposed to the neighboring domain201and sent over the direct link (NX1 interface216) to the neighboring near-RT RIC114that controls the neighboring domain201. The neighboring near-RT RIC has to respond to the proposed action indicating that the action has been applied or rejected.

Conflict resolution actions can include a variety of actions. For example, an action can include a remote xApp to be requested to be turned off for a certain amount of time, or it can be prevented from updating certain parameters on a certain remote E2 node. Here, “remote” represents the neighboring near-RT RIC114or domain201. Alternatively, or in addition, an action can include reconfiguration of the remote E2 node to alleviate the effects of the conflict. A variety of other such actions can be requested of the neighboring near-RT RIC114to resolve a cross-domain conflict.

Further, the policy can include informing the non-RT RIC112(that controls the near-RT RIC and neighboring near RT-RIC114) when a cross-domain conflict condition cannot be locally solved. For example, such a condition can arise when the near-RT RIC114has conflicting policies from two domains having the same priorities, and criticality or operations support requests cannot be accommodated.

In one or more embodiments of the present invention, the near-RT RIC114sends the policy generated to the cross-domain policy generator202in the neighboring near-RT RIC114, which verifies and applies the policy.

A technical challenge that arises is a scenario in which multiple near-RT RICs114identify and attempt to resolve the same cross-domain conflict, particularly if each proposes a different conflict resolution policy. The different policies themselves may include steps that can be conflicting, leading to even further disruptions in the deployed O-RAN100. To address such a technical challenge, in embodiments of the present invention, even if multiple near-RT RICs114identify the (same) conflict, only the near-RT RIC114from whose domain201the conflicting policy with higher priority originated proposes the actions for conflict resolution. In case the conflicting policies have the same priority, then the near-RT RIC114may consider existing criticality in domain201to take suitable actions. In one or more embodiments of the present invention, domain201with critical impact overrides domain201with minor impact.

In the case where more than one neighboring domain201seeks the same coordinated action, then the timestamp is considered for prioritization of neighboring domain201. Other domain(s)201are sent a request to wait for a predetermined duration to prevent them from continuously sending repeated requests for coordinated actions.

Alternatively, in addition, in case the conflicting policies have the same priority and criticality, which is why the conflict cannot be locally resolved on the near-RT RIC level, then each near-RT RIC114reports about it to the non-RT RIC112. The non-RT RIC102identifies that the multiple reports received respectively from the several near-RT RICs114all refer to the same conflict occurrence. Such identification is based on the record302received, which identifies the near-RT RICs114and xApps132requesting an action causing the conflict(s). The non-RT RIC102is then responsible for identifying and enforcing the cross-domain policy.

FIG.6depicts a flowchart of a method to detect and/or mitigate cross-domain conflicts in an O-RAN at lower-level control entities according to one or more embodiments of the present invention. As noted herein, O-RAN specification and present techniques for resolving a cross-domain conflict, which occurs at lower-level entities of the O-RAN100(i.e., near-RT RICs, E2 nodes, etc.) is to use a higher-level entity (i.e., the non-RT RIC112) to detect and resolve the cross-domain conflict. Such a conflict resolution at the higher-level entity is used because the higher-level entity (non-RT RIC112) can request and capture control and user plane deployment details and conditions at block602. Further, the higher-level entity receives the desired operation goals, for example, from one or more administrators, customers, etc., at block604.

However, one of the technical challenges with such techniques is that the control loop with higher-level entities (e.g., 1 second or higher) is an order of magnitude slower than the control loop of the lower-level entities (sub-millisecond range). Accordingly, conflict resolution is slow, causing disruption in the operation of the lower-level entities. Further, the existing techniques cause congestion because several lower-level entities have to communicate with the higher-level entity to resolve the conflict.

The technical challenges are addressed by method600shown. At block606, at each of the lower-level entities (e.g., near-RT RICs114), cross-domain state awareness is created, respectively. Further, at block608, pairs of lower-level entities are identified such that the entities in a pair mutually impact each other by their activities. For example, near-RT RIC A114and near-RT RIC B114are identified as mutually impacting each other. Further, at block608, the mutually impacting pair of lower-level entities are provided instructions (e.g., INST-X instructions described herein) for sharing respective states. A “state” of a lower-level entity includes the data structure300that specifies attributes of the lower-level entity, including one or more control applications132executing on that lower-level entity.

At block610, the higher-level entity delegates control to resolve cross-domain conflicts (that satisfy certain conditions) to the lower-level entities that are identified and provided with instructions. At block612, the delegated lower-level entities in the mutually impacting pairs share operation policies determined based on the shared states (data structure300) with each other. Accordingly, at block614, the lower-level entities are enabled to resolve cross-domain conflicts with direct communication among themselves without involving the higher-level entity. Thus, the O-RAN100, which has a hierarchically distributed control plane, is improved to resolve cross-domain conflicts at lower-levels of the control plane at the lower-level itself without affecting the operations of the higher-level entity.

FIG.7depicts another flowchart of a method to detect and/or mitigate cross-domain conflicts in an O-RAN at lower-level control entities according to one or more embodiments of the present invention. Method700is performed in a hierarchically distributed programmable network, such as the O-RAN100.

At block702, the higher-level entity (i.e., non-RT RIC112) collects information about control and user plane deployment details and conditions. The non-RT RIC112captures information about network-wide conditions in several manners. For example, information about the underlying control plane is received over the interface O2. FCAPS-related information about the deployed network functions can be captured over interface O1. (FCAPS is an acronym for fault, configuration, accounting, performance, and security and is a network management framework created by the International Standards Organization (ISO).) Further, information about the user plane conditions is received from all the connected near-RT RICs114over the A1 interface. Each near-RT RIC114has information about local domain conditions, e.g., about the user and control plane conditions received from the connected E2 nodes, and information about the local hardware on which it is deployed, e.g., CPU usage, available cores, etc.

At block704, the non-RT RIC112identifies domains201with mutual impact. The domains with mutual impact are determined using an artificial intelligence/machine learning (AI/ML) model(s) that identifies cross-domain conflict based on the control and user plane data captured over at least a predetermined duration (or a predetermined number of operations). In one or more embodiments of the present invention, conflict detection may identify patterns that indicate conflict occurrence based on the logged data. The AI/ML model(s) are pre-trained using a training dataset before being deployed on the non-RT RIC112in one or more embodiments of the present invention. The AI/ML model(s) can be continuously updated as the non-RT RIC112is used. In one or more embodiments of the present invention, the trained AI/ML model(s) can detect conflict-related patterns based on different conflict types, i.e., direct, indirect, and implicit. In one or more embodiments of the present invention, only the non-RT RIC112detects cross-domain or inter-domain conflicts. Each pair of domains201(and corresponding near-RT RICs114) that has had a cross-domain conflict(s) with each other are identified as the mutually impacting domains/entities.

At block706, the non-RT RIC112delegates control over cross-domain conflicts to a near-RT RIC114in an identified pair by creating a cross-domain state awareness module (204) in the near-RT RIC114. Creating awareness module204can include loading a computer program into the near-RT RIC114. Alternatively, or in addition, creating the awareness module204can include enabling the awareness module204that is in a dormant or inactive state in the near-RT RIC114. The creation of the awareness module204enables the near-RT RIC114to be able to perform several operations corresponding to the several instructions (INST-X) described herein. The awareness module204facilitates the creation and maintenance of the domain border state and activity register208as described herein using several operations. Each near-RT RIC114, thus updated, continuously creates, and maintains the domain border state and activity register208using the created awareness module204, at block706. Further, at block706, based on the border state and activity register208, each near-RT RIC114generates a cross-domain policy.

At block708, the first near-RT RIC114in an identified pair shares the cross-domain policy thus created with the second near-RT RIC114in the pair. The sharing is performed via direct communication on the NX1 interface216. Each near-RT RIC114in the pair compares the received policy from the other. The comparison can be based on metrics such as criticality, post-impact, timestamp, etc. Based on the comparison, each near-RT RIC114determines which one of the two near-RT RICs114in the pair is to be assigned a leader of that pair. Because the two near-RT RICs114are comparing the same two policies, albeit independently, both reach the same result/conclusion. Accordingly, one of the near-RT RICs114in the pair assumes the role of the leader of that pair. The leader near-RT RIC114uses the cross-domain policy that was created by itself.

At block710, in case of a cross-domain conflict being detected in the pair, the leader near-RT RIC114resolves the cross-domain conflict based on the policy that was generated by itself (i.e., leader near-RT RIC).

Accordingly, the hierarchically distributed programmable network can be improved to have tunable delegated control using method700. Embodiments of the present invention accordingly improve existing communication network architecture and provide a practical application to resolve cross-domain conflicts in such networks.

FIG.8depicts a sequence diagram to detect and/or mitigate cross-domain conflicts in an O-RAN at lower-level control entities according to one or more embodiments of the present invention. The sequence diagram illustrates the creation and use of the instructions (606,706) by the non-RT RIC112to delegate control to the lower-level entities (near-RT RICs114) to resolve a cross-domain conflict.

As described herein, the non-RT RIC112creates the awareness module204in the near-RT RIC A114(first near-RT RIC) that is identified to handle cross-domain conflicts with another near-RT RIC B114(second near-RT RIC) (802). For example, the non-RT RIC112initiates, in the near-RT RICs114, INST1 used for the creation of neighboring domains and border states. The near-RT RIC A114, using the awareness module204, accumulates the border state information, including E2 nodes, KPIs, xApps132, etc., of the neighboring near-RT RIC B114(804). The near-RT RIC A114also shares its own border state information with the near-RT RIC B114.

The border and state tracker206creates the border digital twin402and updates the border state and activity register208based on the control plane and user plane information captured in this manner (806).

The non-RT RIC112further triggers INST2 to analyze the border digital twin that is captured to identify potentially mutually impacting domains and cross-domain conflicts (808). The INST2 may trigger one or more scripts to be run at the near-RT RICs A, B114to analyze the respectively captured digital twins401(810). One or more of the conditions detected by the scripts are forwarded to the cross-domain policy generator202(812).

The non-RT RIC112triggers INST3 to analyze the generated cross-domain conflict policies to determine prioritization and consequent leader proclamation (814). The near-RT RICs A, B114perform a criticality analysis and priority analysis on the policies to compare them (816). As described herein, several other parameters from the border state data structure300can be used to break a tiebreaker between the policies. The generated policies are shared among the near-RT RICs A, B114using direct communication via the NX1 interface (818).

FIG.9depicts an operation flow for inter-domain conflict resolution by near-RT RICs according to one or more embodiments of the present invention. The operation flow ofFIG.9depicts the operations performed by the near-RT RICs A, B114to resolve the cross-domain conflict using the techniques described herein.

At block902, border state tracker206logs all local updates and conditions that are relevant for the border digital twin and activity register208, following instructions obtained from the non-RT RIC112(these are stored in the awareness module204). Both near-RT RICs114perform such updates.

At block904, the border state tracker206forwards the captured local conditions and activities that are relevant for the border digital twin and activity register208to the near-RT RICs114of the neighboring domains. Such communication occurs over the NX1 interface216.

At906, the border digital twin and activity register208continuously monitors its own data and identifies conditions that require attention by leveraging the instructions from the non-RT RIC112.

At908, when the border digital twin and activity register208identifies the condition that needs attention, it creates the actionable insight and passes it to the cross-domain policy generator202to decide on further steps. Consider the scenario in which the near-RT RIC B114identifies the condition, which is a cross-domain conflict in response to an update request from an xApp132(local or remote).

At910, the cross-domain policy generator202identifies and performs the necessary steps by leveraging the instructions from the non-RT RIC112that are stored in the awareness module202. The steps performed by the cross-domain policy generator202include, at910a, executing the policy locally. Further, at910b, the cross-domain policy generator202shares the policy with the remote cross-domain policy generator202. In the case that the cross-domain conflict cannot be locally resolved, at910c, the cross-domain policy generator202reports the condition that needs attention to the non-RT RIC112.

The non-RT RIC112and the near-RT RICs114can be computer servers in one or more embodiments of the present invention. In some cases, the computer server can use distributed computing. Alternatively, or in addition, the non-RT RIC112and the near-RT RICs114can be any other type of computing device, such as a desktop computer, a laptop computer, a portable computer, etc.

Although not explicitly illustrated herein, the non-RT RIC112can include several components as per the O-RAN specification or otherwise.

It should be noted that the near-RT RIC114includes all of the components as specified by the O-RAN specifications in addition to the one or more components described herein to facilitate the technical solutions herein.

In one or more embodiments of the present invention, operational intents received from the operator are essential for conflict mitigation as they reflect the operator's desires regarding network operation and therefore are used to identify the optimal xApp behavior for each network state. In general, the xApp actions at any time must be such that they maintain satisfactory KPIs or improve the degraded KPIs while keeping intent into consideration. The cross-domain conflict generator202is aware of the optimization goals of each xApp132and the parameters that each xApp132can affect. Only then the cross-domain conflict generator202can tune the xApp activity according to the intent requirements.

In one or more embodiments of the present invention, the cross-domain conflict generator202uses reinforcement learning to determine the policies.

Reinforcement learning is a subfield of machine learning and is also a general-purpose formalism for automated decision-making and AI. The goal of reinforcement learning is to take suitable action to maximize reward in a particular situation. Reinforcement learning (RL) is not strictly supervised as it does not rely only on a set of labeled training data but is not unsupervised learning because an agent is trained to maximize a reward. The agent needs to find the “right” actions to take in different situations to achieve its overall goal. There are three basic concepts in reinforcement learning: state, action, and reward. The algorithm (agent) evaluates a current situation (state), takes action, and receives feedback (reward) from the environment after each act. Positive feedback is a reward, and negative feedback is a punishment for making a mistake. Markov Property: requires that “the future is independent of the past given the present.” RL relies on the state transition probability, which indicates, given a present state, what is the probability the next state will occur. Further, in RL, all state transitions can be defined in terms of a State Transition Matrix P, where each row provides the transition probabilities from one state to all possible successor states. When an agent is transitioned from the current state to the next state, it is either rewarded positively or negatively based on the actions of the agent following a particular policy.

For example, the cross-domain conflict generator202can generate a policy: xApp1 may update param1 to val1 or val2 on E2 node CU/DU1, xApp2 must be blocked from changing param2 but can change param3 on the CU/DU1 and CU/DU2.

Cross-domain conflict generator202leverages the policies when responding to E2 guidance request that causes an update to one or more xApps132. For example, in the above policy example, if xApp2 attempts to update the param2 on the E2 node CU/DU1, the cross-domain conflict generator202responds with rejection. On the other hand, the cross-domain conflict generator202does not block xApp2 from making changes on the param3 on the same E2 node.

In one or more embodiments of the present invention, the cross-domain conflict generator202is able to record the instructions received in the individual policies and retrieve these when xApps132call E2 guidance requests and verify the requested xApp activity.

The technical solutions described herein improve the O-RAN100and provides a practical application to detect and mitigate cross-domain (inter-domain) conflicts at a lower-level, i.e., by the near-RT RICs. It is understood that one or more of the described operations can be performed in parallel and/or in sequence.

It should be noted that the non-RT RIC112and near-RT RIC114include several other components (such as interface termination modules, databases, shared data layers, messaging infrastructures, etc.) than depicted in the drawings herein. Only the relevant components are depicted and described herein. Also, in O-RAN, each network function104is deployed as a container. Here, “containers” are executable units of software in which application code is packaged, along with its libraries and dependencies, in common ways so that it can be run anywhere, whether it be on a desktop, traditional IT, or the cloud. It should be noted that containers, unlike virtual machines, do not need to include a guest OS in every instance and can, instead, simply leverage the features and resources of the host OS. Further, non-RT RIC112captures information about network-wide conditions in several manners. For example, information about the underlying cloud infrastructure is received over the interface O2. FCAPS-related information about the deployed network functions can be captured over interface O1. Further, information about the user plane conditions is received from all the connected near-RT RICs114over the A1 interface. Each near-RT RIC114has information about local domain conditions, e.g., about the user and control plane conditions received from the connected E2 nodes, and information about the local hardware on which it is deployed, e.g., CPU usage, available cores, etc.

Embodiments of the present invention facilitate detection, resolution, and mitigation of inter-domain conflicts in programmable networks with hierarchically organized operation planes. Embodiments of the present invention facilitate resolving such inter-domain conflicts at a lower-level of the hierarchical network. Log correlation and pattern detection are incorporated for collecting the stateful activity logs from neighbouring lower-level entities and aggregating these logs to detect the patterns that assist in creating policies to resolve cross-domain conflicts at the lower-level entities themselves without involving the higher-level entity. Here, lower-level entities include near-RT RICs, and higher-level entity includes non-RT RICs.

Embodiments of the present invention facilitate control applications communications for coordination & conflict management in a hierarchical programmable network, while higher-level entity in the hierarchy governs the policy. Embodiments of the present invention improve the existing O-RAN architecture by facilitating coordination and execution of cross-domain impacting activities without the involvement of the higher-level entity, i.e., non-RT RIC, and establishing a direct communication link between the lower-level entities, i.e., near-RT RICs impacted by the cross-domain conflict. Embodiments of the present invention facilitate reduced response time, thus enabling the use of applications that require faster response time for both the application and scheduling layer. Further, embodiments of the present invention mitigate signaling congestion between the near-RT RICs and the non-RT RIC on the A1 interface, especially when control loop utilization tends to surge for applications demanding reduced response times.

FIG.10depicts a computing environment in accordance with one or more embodiments of the present invention. Computing environment1100contains an example of an environment for the execution of at least some of the computer code involved in performing the inventive methods, such as optimal compression of machine learning model800. In addition to block800, computing environment1100includes, for example, computer1101, wide area network (WAN)1102, end user device (EUD)1103, remote server1104, public cloud1105, and private cloud1106. In this embodiment, computer1101includes processor set1110(including processing circuitry1120and cache1121), communication fabric1111, volatile memory1112, persistent storage1113(including operating system1122, as identified above), peripheral device set1114(including user interface (UI), device set1123, storage1124, and Internet of Things (IoT) sensor set1125), and network module1115. Remote server1104includes remote database1130. Public cloud1105includes gateway1140, cloud orchestration module1141, host physical machine set1142, virtual machine set1143, and container set1144.

COMPUTER1101may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smartwatch or other wearable computer, mainframe computer, quantum computer or any other form of computer or mobile device now known or to be developed in the future that is capable of running a program, accessing a network, or querying a database, such as remote database1130. As is well understood in the art of computer technology, and depending upon the technology, performance of a computer-implemented method may be distributed among multiple computers and/or between multiple locations. On the other hand, in this presentation of computing environment1100, detailed discussion is focused on a single computer, specifically computer1101, to keep the presentation as simple as possible. Computer1101may be located in a cloud, even though it is not shown in a cloud. On the other hand, computer1101is not required to be in a cloud except to any extent as may be affirmatively indicated.

PROCESSOR SET1110includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry1120may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips. Processing circuitry1120may implement multiple processor threads and/or multiple processor cores. Cache1121is memory that is located in the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores running on processor set1110. Cache memories are typically organized into multiple levels depending upon relative proximity to the processing circuitry. Alternatively, some, or all, of the cache for the processor set may be located “off chip.” In some computing environments, processor set1110may be designed for working with qubits and performing quantum computing.

Computer readable program instructions are typically loaded onto computer1101to cause a series of operational steps to be performed by processor set1110of computer1101and thereby effect a computer-implemented method, such that the instructions thus executed will instantiate the methods specified in flowcharts and/or narrative descriptions of computer-implemented methods included in this document (collectively referred to as “the inventive methods”). These computer readable program instructions are stored in various types of computer readable storage media, such as cache1121and the other storage media discussed below. The program instructions, and associated data, are accessed by processor set1110to control and direct performance of the inventive methods. In computing environment1100, at least some of the instructions for performing the inventive methods may be stored in block800in persistent storage1113.

VOLATILE MEMORY1112is any type of volatile memory now known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, the volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In computer1101, the volatile memory1112is located in a single package and is internal to computer1101, but, alternatively or additionally, the volatile memory may be distributed over multiple packages and/or located externally with respect to computer1101.

NETWORK MODULE1115is the collection of computer software, hardware, and firmware that allows computer1101to communicate with other computers through WAN1102. Network module1115may include hardware, such as modems or Wi-Fi signal transceivers, software for packetizing and/or de-packetizing data for communication network transmission, and/or web browser software for communicating data over the internet. In some embodiments, network control functions and network forwarding functions of network module1115are performed on the same physical hardware device. In other embodiments (for example, embodiments that utilize software-defined networking (SDN)), the control functions and the forwarding functions of network module1115are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer readable program instructions for performing the inventive methods can typically be downloaded to computer1101from an external computer or external storage device through a network adapter card or network interface included in network module1115.

END USER DEVICE (EUD)1103is any computer system that is used and controlled by an end user (for example, a customer of an enterprise that operates computer1101), and may take any of the forms discussed above in connection with computer1101. EUD1103typically receives helpful and useful data from the operations of computer1101. For example, in a hypothetical case where computer1101is designed to provide a recommendation to an end user, this recommendation would typically be communicated from network module1115of computer1101through WAN1102to EUD1103. In this way, EUD1103can display, or otherwise present, the recommendation to an end user. In some embodiments, EUD1103may be a client device, such as thin client, heavy client, mainframe computer, desktop computer and so on.

REMOTE SERVER1104is any computer system that serves at least some data and/or functionality to computer1101. Remote server1104may be controlled and used by the same entity that operates computer1101. Remote server1104represents the machine(s) that collect and store helpful and useful data for use by other computers, such as computer1101. For example, in a hypothetical case where computer1101is designed and programmed to provide a recommendation based on historical data, then this historical data may be provided to computer1101from remote database1130of remote server1104.