System and method enabling interoperability in a self-organizing network

Abstract

The present disclosure provides a system and method that enable interoperability with a self-organizing network (SON) in a heterogeneous network (HetNET). The method includes transmitting a SON capability query to one or more entities within the HetNet, receiving SON capability information associated with the one or more entities within the HetNet in response to the SON capability query, and generating an initial SON configuration associated with the one or more entities based on the received SON capability information.

Description

Technical Field

[0001] Reservation of Rights Part of the present disclosure in this patent document includes materials that are subject to intellectual property rights, including but not limited to copyrights, designs, trademarks, integrated circuit (IC) layout designs, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its related companies (hereinafter referred to as the owner in this specification). The owner reserves all rights except that anyone can copy it as long as the patent document or the patent disclosure content is published in the patent application or record of the Patent and Trademark Office. All rights to such intellectual property are fully reserved by the owner.

[0002] Embodiments of the present disclosure generally relate to communication networks. In particular, the present disclosure relates to technologies for achieving interoperability in a self-organizing network (SON).

Background Art

[0003] The following description of related technologies is intended to provide background information related to the field of the present disclosure. This section may include specific aspects of the art related to various features of the present disclosure. However, this section should be understood to be used only to deepen the reader's understanding of the present disclosure and not as an approval of the prior art.

[0004] For example, with the evolution of cellular networks from the fourth generation (4G) to the fifth generation (5G) and further to the sixth generation (6G), and the evolution of other wireless access technologies such as Wireless Fidelity (Wi-Fi), the number of subscribers to network services has increased rapidly, and mobile network operators are forced to deploy very high-density heterogeneous networks (HetNets) to meet the requirements of subscribers. HetNets are usually constructed by multi-portfolio and multi-vendor-based solutions.

[0005] During the deployment of HetNet into new or existing fields, the main challenges faced by the communication operator(s) are the requirements for high-quality installations covering the following. 1. Continuous monitoring of the performance and health of the deployed network. 2. Dynamic adaptation to changing environments. 3. Pre-adjustment and optimization.

[0006] These challenges lead to huge operational expenses (OPEX). To overcome these drawbacks and dramatically reduce OPEX, network providers have devised self-organizing networks (SON).

[0007] SON is an automation technology that enables the network to automatically set itself up, self-manage resources and configurations, and achieve optimal performance.

[0008] SON performs its role based on the following categories. I. Self-configuration: Supports seamless integration into the network through the automatic configuration of major parameters. This is most valuable during the initial network deployment. It includes the following functions: 1. Plug-and-play function. 2. Automatic neighbor relation function. 3. Physical layer cell identity (PCI) selection and conflict resolution function. II. Self-optimization: Supports the improvement of network performance by optimizing the radio and network configurations in near real time. This is valuable throughout the life of the network. It includes the following functions: 1. Mobility load distribution. 2. Optimization of mobility robustness. 3. Optimization of the random access channel (RACH). 4. Energy saving. 5. Radio link failure report. 6. Coverage and Capacity Optimization (Downlink (DL) Power Control, Remote Electrical Tilt (RET)). 7. Forward Handover. 8. Reduction of Frequent Handovers. 9. Interference Reduction (Inter-cell, Intra-cell, Intra Radio Access Technology (RAT), Inter-RAT), etc. III. Self-Recovery: This enables adjacent cells to maintain the network quality even when a cell / sector fails, providing resilience (reliability) in the face of unexpected outages. This is valuable throughout the network's lifespan. It includes the following functions: 1. Detection of Cell Outages [Dead / Sick / Sleep Cells / Sectors / Beams].[[]END] 2. Recovery of Cell Outages. 3. Compensation for Cell Outages. 4. Compensation Recovery of Cell Outages.

[0009] The above SON functions are processed individually or in groups by SON algorithms. SON algorithms perform functions such as monitoring the network(s) by collecting management data including management data analytics service (MDAS) data, analyzing the management data to determine if there are problems to be solved within the network(s), determining SON actions to solve the issues, executing the SON actions, and evaluating whether the issues have been solved by analyzing the management data.

[0010] Furthermore, based on the location of the SON algorithm, SON can be broadly classified into four different solutions that can implement various SON use cases, and the solution is selected according to the needs of the SON use case. 1. Centralized SON (C-SON): This means that the SON algorithm is executed within the management system. 2. Cross-Domain Centralized SON (CD C-SON): Here, the SON algorithm is executed within the cross-domain layer. 3. Domain-Controlled SON (DC-SON): Here, the SON algorithm is executed within the domain layer. 4. Distributed SON (D-SON): Here, the SON algorithm is within the NF. 5. Hybrid SON (H-SON): Here, the SON algorithm is executed at two or more levels such as the NF layer, domain layer, or cross-domain layer. Since the SON algorithm is left to implementation, vendors may choose different approaches for SON solutions. Some vendors may adopt the C-SON approach, the D-SON approach, or an H-SON approach-based solution.

[0011] Mobile network operators cannot avoid using multi-vendor solutions when deploying HetNets. Figure 1A shows a typical 5G HetNet deployment scenario related to mobile network operators. Mobile network operators may use management entities such as network management systems (NMS) from different vendors, sets of element management systems (EMS) from different vendors, and radio access network (RAN) nodes such as sets of next-generation node Bs (gNBs) from different vendors. Among them, the gNB central unit (CU) may be from a first set of vendors, and the gNB distributed unit (DU) may be from a second set of vendors. Some of the problems that network operators may face in the above-exemplified deployed HetNet are as follows. i. The D-SONs of gNB-CU-1 (110-1) and gNB-CU-2 (110-2) communicate with each other via the open Xn interface, but since they are from different vendors, they may not be well coordinated. ii. The D-SON of gNB-CU-2 (110-2) and the hybrid SON of gNB-CU-n (110-N) communicate with each other via the open Xn interface, but since both are from different vendors, they may not be well coordinated. iii. C-SON can be implemented co-located with a management entity (such as an EMS / NMS) or as a stand-alone entity. However, integrating C-SON as a stand-alone entity with RAN nodes may require more effort. iv. The CDC-SON (106) within the NMS (104) may affect the performance of the DC-SON and D-SON functions operating in a multi-vendor environment. v. Partially integrating a third-party SON solution into a HetNet leads to a decrease in overall KPIs. vi. L3-RRM coordination across adjacent gNB-CUs (110-1, 110-2 …, 110-N) is lacking, regardless of whether it is the same vendor or a multi-vendor scenario, which may affect the overall KPI performance. vii. L3-RRM and L2-RRM coordination across multi-vendor gNB-CUs (110-1) and gNB-DUs (112-1) may affect dynamic resource sharing and allocation. viii. Implementing unique SON and RRM has a significant impact on overall performance because the operation of each algorithm is different and each has its own pros and cons.

[0012] In the scenarios described above, even if a vendor is ready to integrate with a third-party solution [SON and / or RRM], it may not be possible to deterministically quantify / confirm the output performance regarding whether there are incompatibilities between the solutions of any vendors and whether there are agreed-upon vendor-to-vendor conflicts.

[0013] One possible solution to address these problems and limitations is to make the interface between the RAN node that interacts with the SON solution as open an interface as possible. Figure 1B shows a possible solution proposed by the Open Radio Access Network (O-RAN) Alliance. Referring to Figure 1B, the O-RAN architecture may include logical blocks that include a Near-Real Time (RT) RAN Intelligent Controller (RIC) (118), an Open Radio Access Network Aggregation Unit Control Plane (O-CU-CP) (122), an Open Radio Access Network Aggregation Unit User Plane (O-CU-UP) (124), an Open Radio Access Network Distributed Unit (O-DU) (126), and an Open Radio Access Network Radio Unit O-RU function (128). The E2 interface connects the O-eNB (120) to the Near-RT RIC (118). Further, the O-eNB (120) can support the O-DU and O-RU functions via an open fronthaul interface (134) between them. On the management side, there is a Service Management and Orchestration (SMO) (114) framework that includes the Non-RT-RIC (116) function. On the other hand, the O-Cloud (132) may include a collection of physical infrastructure nodes that meet the O-RAN requirements for hosting related O-RAN functions (such as Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU), support software components (operating systems, virtual machine monitors, container runtimes, etc.) and appropriate management and orchestration functions, including a cloud computing platform. As shown in Figure 2B, the O-RU (128) terminates the open fronthaul M plane (134) interface to the O-DU (126) and the SMO (114).

[0014] With the explosive increase in the deployment of cellular HetNets, there may be a great demand for the deployment of Wi-Fi access points (APs) to meet the huge data throughput requirements. As a result, network communication operators may be forced to use multi-vendor solutions to deploy in the network according to scenarios such as carrier-grade Wi-Fi, enterprise Wi-Fi, Mi-Fi, home Wi-Fi, etc. Furthermore, in the above discussions related to FIGS. 1A and 1B, no clearly defined technology for implementation in HetNets based on O-RAN is provided to avoid competition arising from multi-vendor solutions.

[0015] Therefore, in this technical field, there is a need to provide an interoperability solution between multiple vendor functions that can overcome the drawbacks of existing prior arts.

SUMMARY OF THE INVENTION

PROBLEMS TO BE SOLVED BY THE INVENTION

[0016] Some of the objectives of the present disclosure satisfied by at least one embodiment of this specification are as listed herein below.

[0017] An objective of the present disclosure is to provide the realization of self-organizing network (SON) functions at several locations of a 4G / 5G heterogeneous network (HetNet) architecture.

[0018] Another objective of the present disclosure is to provide the functional execution split localization of SON functions in a service management and orchestration (SMO) framework.

[0019] Another objective of the present disclosure is to provide the functional execution split in an open radio access network (O-RAN) architecture management entity and / or a non-real-time RAN intelligent controller (non-RT RIC) entity, Near RT-RIC, E2 node.

[0020] Yet another object of the present disclosure is to provide a specific mechanism for data collection for addressing the said functions of SON in an O-RAN architecture.

[0021] Yet another object of the present disclosure is to provide discovery of mutual SON function implementation across a HetNet.

[0022] Yet another object of the present disclosure is to provide a mode of interoperating within a SON function.

[0023] Yet another object of the present disclosure is to provide a mode of interoperability across SON functions.

[0024] Yet another object of the present disclosure is to provide a communication system immediately on-site.

Means for Solving the Problems

[0025] This section is provided to introduce in a simplified form specific objects and aspects of the present disclosure, which will be further described in the following detailed description. This summary is not intended to identify key features or the scope of the claimed subject matter.

[0026] In one aspect, the present disclosure relates to a system enabling interoperability of a self-organizing network (SON) in a heterogeneous network (HetNet). The system includes one or more processors and a memory operably coupled to the one or more processors. The memory includes processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to send a SON capability query to one or more entities in the HetNet, receive SON capability information associated with the one or more entities in the HetNet in response to the SON capability query, and generate an initial SON configuration associated with the one or more entities based on the received SON capability information.

[0027] In some embodiments, the system is configured to instruct one or more entities in a HetNet to enable / disable the SON functions of the one or more entities based on the received SON capability information, and the one or more entities include open radio access network (O-RAN) entities.

[0028] In some embodiments, the system includes a non-real-time radio access network intelligent controller (non-RT RIC), a near-RT RIC, and an E2 node. In some embodiments, the SON capability information includes a SON support bitmap information element (IE). The system is configured to create a SON support matrix based on the SON support bitmap IEs received from one or more entities and generate an initial SON configuration based on the SON support matrix.

[0029] In one or more embodiments, the system is configured to collect analysis data associated with a HetNet, detect one or more events within the HetNet, and generate a dynamic SON configuration associated with one or more entities based on at least one of the collected data and the detected one or more events.

[0030] In some embodiments, the system operates a first element associated with the SON configuration of a first entity of the one or more entities, operates a second element associated with the SON configuration of a second entity of the one or more entities, detects a change in the operation associated with the first element of the first entity, and is configured to communicate the change in the operation associated with the first element of the first entity to the second element of the second entity. Further, the system is configured to receive a response from the second element of the second entity based on the change in the operation associated with the first element of the first entity and execute the change in the operation associated with the first element of the first entity based on the received response.

[0031] In another aspect, the present disclosure relates to a method for enabling interoperability of a self-organizing network (SON) in a heterogeneous network (HetNet). The method includes transmitting, by one or more processors, a SON capability query to one or more entities in the HetNet, receiving, by one or more processors, SON capability information associated with one or more entities in the HetNet in response to the SON capability query, and generating, by one or more processors, an initial SON configuration based on the received SON capability information.

[0032] In some embodiments, the method includes instructing, by one or more processors, one or more entities in the HetNet to enable / disable the SON function of the one or more entities based on the received SON capability information, where the one or more entities include open radio access network (O-RAN) entities. In one embodiment, the one or more entities include at least one of a non-real-time radio access network intelligent controller (non-RT RIC), a near-RT RIC, and an E2 node, and the SON capability information includes a SON support bitmap information element (IE).

[0033] In some embodiments, the method includes creating, by one or more processors, a SON support matrix based on a SON support bitmap IE from one or more entities, and generating, by one or more processors, an initial SON configuration based on the SON support matrix. Further, the method includes collecting, by one or more processors, analysis data related to the HetNet, detecting, by one or more processors, one or more events in the HetNet, and generating, by one or more processors, a dynamic SON configuration associated with one or more entities based on at least one of the collected data and the detected events.

[0034] In some embodiments, the method includes operating, by one or more processors, a first element associated with a SON configuration of a first entity of one or more entities; operating, by one or more processors, a second element associated with a SON configuration of a second entity of one or more entities; detecting, by one or more processors, a change in an operation associated with the first element of the first entity; communicating, by one or more processors, the change in the operation associated with the first element of the first entity to the second element of the second entity. Further, the method includes receiving, by one or more processors, a response from the second element of the second entity based on the change in the operation associated with the first element of the first entity; and executing, by one or more processors, the change in the operation associated with the first element of the first entity based on the received response.

[0035] In yet another aspect, the present disclosure relates to a user equipment (UE) operating in a heterogeneous network (HetNet). The UE includes one or more processors communicatively coupled to a system, the system including the one or more processors and a memory operably coupled to the one or more processors, the memory including processor-executable instructions that, when executed by the one or more processors, cause the one or more processors to transmit a self-organizing network (SON) capability query to one or more entities in the HetNet, receive SON capability information associated with the one or more entities in the HetNet in response to the SON capability query, and generate an initial SON configuration associated with the one or more entities based on the received SON capability information.

[0036] In yet another aspect, the present disclosure, when executed by a processor, causes the processor to send a self-organizing network (SON) capability query to one or more entities within a HetNet, receive SON capability information associated with the one or more entities within the HetNet in response to the SON capability query, and generate an initial SON configuration associated with the one or more entities based on the received SON capability information, and relates to a non-transitory computer-readable medium containing one or more instructions stored therein.

[0037] The accompanying drawings, which are incorporated herein and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems, and like reference numerals refer to the same parts throughout the different drawings. The components in the drawings are not necessarily drawn to scale, and instead, emphasis is placed on clearly illustrating the principles of the present disclosure. Some of the drawings may show components using block diagrams and may not represent the internal circuitry of each component. It will be understood by those skilled in the art that such a disclosure of the drawings may include a disclosure of electrical components, electronic components, or circuits commonly used to implement such components.

Brief Description of the Drawings

[0038]

Figure 1A

Figure 1B

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 5

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 6E

Figure 6F

Figure 7A

Figure 7B

Figure 7C

Figure 7D

Figure 8A

Figure 8B

Figure 8C

Figure 8D

Figure 8E

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0039] The above will become more apparent from the following more detailed description of the present disclosure.

[0040] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Some of the features described below may be used each alone, or in any combination with other features, optionally. Each individual feature may or may not address all of the above problems, and may only address some of the above problems. Some of the problems described above may not be fully addressed by any of the features described herein.

[0041] The following description is provided only by way of example and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of the exemplary embodiments provides an explanation to those skilled in the art for implementing the exemplary embodiments. It should be understood that various changes may be made in the functions and arrangements of the elements without departing from the spirit and scope of the present disclosure as described.

[0042] In the following description, specific details are provided to give a complete understanding of the various embodiments. However, it will be understood by those skilled in the art that the various embodiments may be practiced without these specific details. For example, components such as circuits, systems, networks, processes, etc. may be shown as components in block diagram form in order not to obscure the embodiments with unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0043] It should also be noted that individual embodiments may be described as a process shown in a flowchart, a flow diagram, a data flow diagram, a structural diagram, or a block diagram. In a flowchart, operations may be described as sequential processes, but many operations can be performed in parallel or simultaneously. Further, the order of operations may be rearranged. When the operations of a process are completed, the process ends, but there may be additional steps not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its end may correspond to the return of the function to the calling function or the main function.

[0044] As used herein, the terms "exemplary" and / or "illustrative" are used in the sense of "serving as an example, instance, or illustration." To avoid misunderstanding, the subject matter disclosed herein is not limited by such examples. Further, any aspect or design described herein as "exemplary" and / or "illustrative" should not be construed as necessarily being more preferred or advantageous than other aspects or designs, nor does it mean excluding equivalent exemplary structures and techniques known to those of ordinary skill in the art. Additionally, as long as the terms "includes," "has," "contains," and other similar terms are used in either the embodiments or the claims for describing the invention, such terms are intended to be inclusive in the same manner as the term "comprising" as an open transitional term without excluding any additional element or other element.

[0045] References throughout this specification to "one embodiment" or "an embodiment," or "an instance" or "one instance" mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Further, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0046] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The terms "comprise" and / or "comprising", as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0047] Certain terms and phrases are used throughout the present disclosure and have the following meanings in the context of the ongoing disclosure.

[0048] The term "HetNet" can refer to a heterogeneous network that includes one or more components of a 4G / 5G / 6G network.

[0049] The term "SON" can refer to a self-organizing network that is a radio access network (RAN) that can automatically plan, configure, manage, optimize, and repair itself.

[0050] The term "MRO" can refer to the optimization of mobility robustness that performs automatic optimization of parameters affecting active-mode and idle-mode handovers.

[0051] The term "MLB" can refer to mobility load balancing in which a cell suffering from congestion can transfer its load to other cells having spare resources.

[0052] The term "SMO" can refer to Service Management and Orchestration (SMO) that provides an automation platform for open RAN radio resources.

[0053] The term "Non-RT-RIC" can refer to a Non-Real-Time RAN Intelligent Controller. The non-RT RIC is part of the SMO framework, is deployed centrally in the service provider network, and enables non-real-time (> 1 second) control of RAN elements and their resources through a special application called an rApp.

[0054] The term "Near-RT RIC" can refer to a Near-Real-Time RAN Intelligent Controller that is responsible for intelligent edge control of RAN nodes and resources. The near-RT RIC typically controls RAN elements and their resources using optimization actions that take from 10 milliseconds to 1 second to complete.

[0055] Various embodiments throughout this disclosure are described in more detail with reference to FIGS. 2-10.

[0056] In one aspect, the present disclosure provides a robust and effective solution for implementing SON functions in O-RAN entities such as near-real-time RIC and non-real-time RIC.

[0057] FIG. 2 shows an exemplary network architecture (200) in which, or with which, embodiments of the present disclosure may be implemented.

[0058] As shown in FIG. 2, network (200) can include network devices (202) capable of implementing the functions of a network management system (NMS) or an element management system (EMS), and can be coupled to a plurality of nodes (206-1, 206-2,... 206-N), whereby the network device (202) can be configured to facilitate communication via a self-organizing network (SON) among the plurality of nodes (collectively referred to as nodes 206 and individually referred to as nodes 206). In some embodiments, the nodes (206) can include, but are not limited to, next-generation node B (gNB), evolved node B (eNodeB), gNB centralized unit (gNB-CU), and gNB distributed unit (gNB-DU), and provide communication services to one or more user equipment or computing devices or user devices (208-1, 208-2,... 208-N) (collectively referred to as user devices 208 and hereinafter individually referred to as user devices 208).

[0059] Referring to architecture (200), in some embodiments, a communication channel can be established by enabling SON interoperability between user devices (208) associated with different nodes (206), for example, communication can be established between a second user device (208-2) associated with a first node (206-1) and an nth user device (208-N) associated with an nth node (206-N).

[0060] In another embodiment, a communication channel can be established by enabling SON interoperability between user devices (208) associated with the same node, for example, communication can be established between a first user device (208-1) and a second user device (208-2) associated with a first node (206-1).

[0061] Referring to FIG. 2, the network device (202) can include a network controller, can be configured as an application server, can operate communicably, or can be integrated with the user device (208) via the network (210). In some embodiments, the controller (202) can be coupled to the server (204). The server (204) may be a centralized server for storing and processing data related to the user device (208).

[0062] In another exemplary embodiment, the user device (208) can include a wireless device. The wireless device may be a mobile device that can include, for example, mobile phones such as feature phones or smartphones and other devices. The user device (208) may not be limited to the above-described devices, and can include any type of device capable of providing wireless communication, such as mobile phones, tablet computers, personal digital assistants (PDAs), personal computers (PCs), laptop computers, media centers, workstations, and other devices.

[0063] Referring to FIG. 2, in one embodiment, the network (210) can be a next-generation network that can include at least one of a wireless network, a wired network, or a combination thereof. The network (210) can be implemented as one of different types of networks such as an intranet, a local area network (LAN), a wide area network (WAN), the Internet, etc. Further, the network (210) can be either a dedicated network or a shared network. A shared network can represent the association of different types of networks that can use various protocols such as, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP), Automatic Repeat reQuest (ARQ), etc. In one embodiment, the network (210) can be related to a next-generation network that can be facilitated, for example, via a terrestrial wide-area access network such as a Global System for Mobile Communications (GSM) network for mobile communication, a universal terrestrial radio network (UTRAN), an Enhanced Data rate for GSM Evolution (EDGE) radio access network (GERAN), an evolved universal terrestrial radio access network (E-UTRAN), a WIFI or other LAN access network, or a satellite or Wireless Microwave Access (WIMAX) network. In an exemplary embodiment, the communication network can enable a next-generation network based on a subscription related to the user / user device and / or via a Subscriber Identity Module (SIM) card. Various other types of communication networks or services can be possible.

[0064] By way of example and not limitation, network (210) can utilize different types of air interfaces, such as code division multiple access (CDMA), time division multiple access (TDMA), or frequency division multiple access (FDMA) air interfaces and other implementations. In an exemplary embodiment, a wired user device can be used alone or in combination with a wireless access network, including, for example, conventional telephone service (POTS), public switched telephone network (PSTN), asynchronous transfer mode (ATM), and other network technologies configured to transfer Internet protocol (IP) packets.

[0065] One of ordinary skill in the art will understand that the exemplary network architecture (200) can be modular and have the flexibility to accommodate any type of change.

[0066] FIG. 3 shows an exemplary block diagram representation (300) of a network node or controller (202) for enabling the interoperability of a self-organizing network (SON) according to one embodiment of the present disclosure.

[0067] Referring to FIG. 3, an exemplary architecture of controller (202) is shown. Controller (202) can facilitate the interoperability of a self-organizing network by a combination of hardware implementation and software implementation. In some embodiments, the controller can include SMO, non-RT RIC, and near-RT-RIC. Controller (202) can include one or more processors (302). One or more processors (302) can be coupled to a memory (304). Memory (304) can store instructions that, when executed by one or more processors (302), can cause controller (202) to perform the steps described herein.

[0068] In an exemplary embodiment, when multiple pre-defined criteria can be considered, the processor(s) (302) can prioritize the pre-defined criteria to enable an efficient configuration and organization of the associated network. Various other embodiments are possible. The pre-defined criteria may include SON capability bitmap information element (IE).

[0069] Referring to FIG. 3, the processor(s) (302) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operating instructions. Among other functions, the processor (302) may be configured to fetch and execute computer-readable instructions stored in the memory (304) of the controller (202). The memory (304) may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium that can be fetched and executed to create or share data packets via a network service. The memory (304) may include any non-transitory storage device, such as volatile memory such as random access memory (RAM), or erasable programmable read-only memory (EPROM), flash memory, etc.

[0070] In one embodiment, the controller (202) can include interface(s) (306). The interface(s) (306) can include various interfaces, such as, for example, an interface for a data input / output device called an I / O device, an interface for a storage device. The interface(s) (306) can facilitate the communication of the controller (202). The interface(s) (306) can also provide a communication path to one or more components of the controller (202). Examples of such components include, but are not limited to, processing engine(s) or module(s) (308) and database (310).

[0071] Referring to FIG. 3, the processing engine(s) or module(s) (308) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing engine(s) or module(s) (308). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine(s) or module(s) (308) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware of the processing engine or module(s) (308) may include processing resources (e.g., one or more processors) and may execute such instructions. In an example of the present invention, the machine-readable storage medium can store instructions that, when executed by the processing resources, implement the processing engine(s) or module(s) (308). In such an example, the controller (202) can include a machine-readable storage medium that stores instructions and processing resources for executing the instructions, or the machine-readable storage medium can be separate but accessible to the controller (202) and the processing resources. In other examples, the processing engine(s) or module(s) (308) may be implemented by an electronic circuit.

[0072] Furthermore, the processing engine or module(s) (308) of the controller 202 can include one or more components, as shown in FIG. 3, which can include a query engine (312), an organization engine (314), and other engines / modules or components (316). In one embodiment, the query engine (312) can enable the master node to query the capabilities of other nodes. For example, the capabilities being queried may include the SON capabilities of the queried node. As an example, one or more nodes may include capabilities, and other nodes may include limitations.

[0073] Referring to FIG. 3, in some embodiments, the orchestration engine (314) may instruct to retain or invalidate SON functions at specific nodes based on their capacity and connectivity, thereby enabling the interoperability and orchestration of various networks. Various other functions of the components may be possible. In one embodiment, the database (210) may include data stored or generated as a result of functions implemented by any of the components of the processing engine(s) (308) of the controller (202).

[0074] Those skilled in the art will appreciate that the exemplary block diagram (300) may be modular and may have the flexibility to adapt to any kind of changes in the controller (202). FIG. 3 shows exemplary components of the block diagram (300), but in other embodiments, the block diagram (300) may include fewer units, different units, units in different arrangements, or additional functional units than shown in FIG. 3. Additionally, or alternatively, one or more units of the controller (202) may perform the functions described as being performed by one or more other units of the controller (202).

[0075] FIG. 4A shows an exemplary message flow (400-A) of a discovery and handshake mechanism that uses a service management and orchestration (SMO) entity as a master according to one embodiment of the present disclosure. In FIG. 4A, different messages related to SON capability queries and responses are shown.

[0076] According to some embodiments, each of the O-RAN functions connected to the SMO (410) via O1 can handle different SON use cases and can have different SON capabilities. These O-RAN function modules, namely the Non-RT RIC (420) and the Near-RT RIC (430), need to expose their SON capabilities to the SMO (410) via the O1 interface. The SMO (410) functions as a master to coordinate SON capabilities among the non-RT RIC (420), the Near-RT RIC (430), and the E2 node (440). The SMO shall query their SON capabilities when the Non-RT RIC (420), the Near-RT RIC (430), and the E2 node (440) are connected to the SMO (410) via the O1 interface. This is a discovery function executed by the SMO (410) to understand the SON capabilities. Based on the SON capability data from the Non-RT RIC (420), the Near-RT RIC (430), and the E2 node (440), the SMO (410) determines the O-RAN functions and the SON capabilities that the O-RAN functions need to address. If all O-RAN functions, namely the Non-RT RIC (420), the Near-RT RIC (430), and the E2 node (440), can handle a specific SON function, the SMO (410) determines, based on the operator configuration, whether the competing SON capabilities need to be handled by any of the Non-RT RIC (420), the Near-RT RIC (430), or the E2 node (440). The SMO (410) communicates to the Non-RT RIC (420), the Near-RT RIC (430), and the E2 node (440) via the O1 interface the decision to retain the SON capabilities. The Non-RT RIC, the Near-RT RIC, and the E2 node, based on the commands from the SMO, retain or invalidate specific SON capabilities and coordinate with other O-RAN functions to achieve smooth interoperability of SON use cases across the hierarchy.

[0077] Referring to FIG. 4A, first, at step 402, the Non-RT-RIC (420), near-RT-RIC (430), and E2 node (440) become operational. When the nodes (420, 430, 440) become operational, the SMO (410) sends a first SON capability query (404-a) to the non-RT RIC (420), a second SON capability query (404-b) to the near-RT RIC (430), and a third SON capability query (404-c) to the E2 node (440). Upon receiving the SON capability query, the non-RT-RIC (420), near-RT RIC (430), and E2 node (440) each respond by disclosing their SON capabilities (406-a, 406-b, 406-c). When the SMO (410) receives the SON capability information, at step 408, it can determine whether to disable or retain the SON functions in the non-RT RIC (420), near-RT RIC (430), and E2 node (440). The SMO (410) sends commands (412-a, 412-b, 412-c) to the non-RT RIC (420), near-RT RIC (430), and E2 node (440) respectively to retain or disable the SON functions. Accordingly, at step 414, the SMO (410), non-RT RIC (420), near-RT RIC (430), and E2 node (440) coordinate with each other for SON function execution. All the above messaging is performed via the O1 interface.

[0078] In some embodiments, based on the communication service provider configuration, either the Near-RT RIC (430) or the Non-RT RIC (420) can function as a master. The Non-RT or Near-RT RIC configured as a master executes queries on other entities and exposes their SON capabilities via the O1 interface. When the master O-RAN function is aware of the SON capabilities of other O-RAN functions to which it is connected, the master node determines, based on the configuration, the placement of SON functions in each O-RAN function. The master node communicates the decision regarding the placement of SON functions to other O-RAN functions via the O1 interface. Based on commands from the master node, other O-RAN functions connected to the master node retain or invalidate SON capabilities and coordinate with other O-RAN functions for SON functions. FIGS. 4B and 4C show scenarios of near-RT-RIC (430) and non-RT RIC (420) as master nodes, which are described in detail below.

[0079] FIG. 4B shows an exemplary message flow (400-B) of a discovery and handshake mechanism using a non-real-time radio access network intelligent controller (non-RT RIC) as a master, according to an embodiment of the present disclosure. In FIG. 4B, different messages related to queries and responses of SON capabilities with the near RT-RIC (430) as a master are shown.

[0080] Referring to FIG. 4B, when the system becomes operational in step 416, a communication service provider, e.g., a mobile network communication service provider, can configure the near-RT RIC (430) as the master node in step 418. Then, the near-RT RIC (430) can execute SON capability queries with the non-RT RIC (420) and the E2 node (440) via the A1 and E2 interfaces respectively. According to some embodiments, the near-RT RIC (430) can send a SON capability query (422-a) to the non-RT RIC (420) via the A1 interface. Further, the near-RT RIC (430) can send a SON capability query (422-b) to the E2 node (440) via the E2 interface. The non-RT RIC (420) can send its SON capability (424-a) to the near-RT RIC (430) via the A1 interface. Similarly, the E2 node (440) can send its SON capability (424-b) to the near-RT RIC (430) via the E2 interface. The near-RT RIC (430) determines in step 426 whether to disable or retain the SON functions in the non-RT RIC (420) and the E2 node (440), and accordingly sends a command (428-a) to the non-RT RIC (420) to disable or retain the SON function, and sends another command (428-b) to the E2 node. Further, in step 432, all the nodes (410, 420, 430, 440) coordinate with each other for the SON function. In one embodiment, all the communications between the near-RT RIC (430) and the non-RT RIC (420) are performed via the A1 interface. Similarly, all the communications between the near-RT RIC (430) and the E2 node (440) are performed via the E2 interface.

[0081] FIG. 4C shows an exemplary message flow (400-C) for a discovery and handshake mechanism using the non-RT RIC as the master according to an embodiment of the present disclosure.

[0082] Referring to Figure 4C, when the system becomes operational at step 434, the communication operator can configure the non-RT RIC (420) as the master node at step 436. Next, the non-RT RIC (420) can execute SON capability queries with the near-RT RIC (430) and the E2 node (440). According to some embodiments, the near-RT RIC may be a repeater for communication between the non-RT RIC (420) and the E2 node (440). Referring to Figure 4C, the non-RT RIC (420) can send a SON capability query (438-a) for both the near-RT RIC (430) and the E2 node (440) to the near-RT RIC (430) via the A1 interface. The near-RT RIC (430) relays the SON capability query (438-b) to the E2 node (440) via the E2 interface. Further, the near-RT RIC (430) can send its SON capability (442-a) to the non-RT RIC (420) via the A1 interface. Similarly, the E2 node (440) can send its SON capability (442-b) to the near-RT RIC (430) via the E2 interface, which is further relayed to the non-RT RIC (420) via the A1 interface for the SON capability of E2. At step 444, the non-RT RIC (420) determines whether to disable or retain the SON functions in the near-RT RIC (430) and the E2 node (440), and accordingly sends a command (446-a) addressing both the near-RT RIC (430) and E2 (440) via the A1 interface. The near-RT RIC (430) relays the command (446-b) to the E2 node (440) via the E2 interface. The commands (446-a, 446-b) can include whether to disable or retain the SON functions. Further, at step 448, all the nodes (410, 420, 430, 440) adjust with each other for the SON function.

[0083] Through the SON capability discovery and handshake mechanism described above, duplication and conflict of SON functions in interconnected O-RAN functions are avoided. This may improve interoperability in an environment with O-RAN functions from different vendors with unknown SON capabilities.

[0084] In some embodiments, SON-related measurements, configuration parameters, and other related data are collected by O-RAN functions to perform SON-based decisions. In some cases, an O-RAN function that executes a SON function may need SON-related data from other O-RAN functions that are not connected at the same layer. For example, Cell A and Cell B may be located in the same place. However, the Near-RT RIC to which the E2 node is connected may be in another cell. Therefore, SON functions such as MLB and MRO may need input from adjacent E2 nodes that are not connected to the same Near-RT or Non-RT RIC. In such scenarios, based on the received input, the O-RAN function can decide to perform a handover to an adjacent O-RAN function or release a user equipment (UE). To facilitate the collection of SON-related data or execute an action based on the result of SON, the Near-RT RIC or Non-RT RIC publishes SON-related data or receives a command as a result of the SON function. An application program interface (API) to an external interface for obtaining SON-related data or executing SON-related actions may facilitate this scenario.

[0085] FIG. 5 shows a table (500) representing various deployment options for enabling the interoperability of SON functions across separate nodes. In one embodiment, a system for localizing specific SON functions and algorithms can be realized by implementing any of the deployment scenarios described in FIG. 5. Referring to FIG. 5, there are about 16 deployment scenarios. In some embodiments, the SON function can be deployed to any one of the SMO, non-RT RIC, near-RT RIC, or E2 node, as described in deployment scenarios 1, 2, 4, and 11, respectively. In some embodiments, the SON function can be deployed to two O-RAN modules, for example, SMO and non-RT RIC, SMO and near-RT RIC, non-RT and near-RT RIC, SMO and E2 node, non-RT RIC and E2 node, and near-RT RIC and E2 node, as shown in deployment scenarios 3, 5, 6, 8, 9, and 12. In some other embodiments, the SON function can be deployed to three O-RAN modules, for example, SMO, non-RT RIC, and near-RT RIC, SMO, non-RT RIC and E2 node, SMO, near-RT RIC and E2 node, non-RT RIC, near-RT RIC, and E2 node, as shown in deployment scenarios 7, 10, 13, and 14. In some embodiments, the SON function can be deployed to all four O-RAN modules, for example, SMO, near-RT RIC, non-RT RIC, and E2 node, as shown in deployment scenario 15. In some embodiments, as shown in deployment scenario 16, SON may not be implemented in any O-RAN module.

[0086] Figure 6A shows a first deployment scenario (600-A) in which the SON algorithm is supported in the management entity of the SMO according to an embodiment of the present disclosure. In Figure 6A, the implementation of the SON function in the element management system (EMS) (620) in the SMO (410) is shown. According to some embodiments, the SMO (410) includes one or more management entities (640), for example, a network management system (NMS) (610) and an EMS (620). In an exemplary embodiment, the SON algorithm is supported by the EMS (620) of the SMO (410).

[0087] Figure 6B shows a second deployment scenario (600-B) in which the SON algorithm is supported in the EMS and the network management system (NMS) according to an embodiment of the present disclosure. In Figure 6B, the implementation of the SON function in the NMS (610) and the EMS (620) in the management entity (640) of the SMO (410) is shown.

[0088] Figure 6C shows a third deployment scenario (600-C) in which different SON algorithms are supported in a multi-vendor EMS according to an embodiment of the present disclosure. In Figure 6C, the implementation of the SON function in the EMS (620) associated with the first vendor and the EMS (630) associated with the second vendor in the SMO (410) is shown. In some embodiments, each EMS vendor (620, 630) can support different SON functions, and the performance of the E2 node (440) is directly associated with the vendor-specific SON function. In an exemplary embodiment, when the second EMS vendor (630) does not explicitly support the SON function, the associated E2 node (440) can obtain the SON function from a non-ORAN entity or through an internal mechanism associated with the management entity (640) to share the SON function across the entire EMS (620, 630) regardless of the availability of SON support.

[0089] Referring to FIGS. 6A, 6B, and 6C, the E2 node (440) and the near-RT RIC (430) may not support the SON algorithm and may be indicated in the SON capabilities to the SMO (410) via the "SON support bitmap IE" via the O1 interface. The "SON support bitmap IE" is shown in FIG. 6D, which will be described in detail below.

[0090] FIG. 6D shows a SON support bitmap information element (IE) (600-D) according to an embodiment of the present disclosure. FIG. 6D shows different SON algorithms supported by specific SON modules in the bitmap arrangement. The various fields of the bitmap IE include SON, physical layer cell identity (PCI), automatic neighbor relation (ANR), MLB, MRO, coverage and capacity optimization (CCO), energy saving (ES), inter-cluster interference mitigation (ICMI), computing component (COM), and seven unused bits.

[0091] Referring to FIG. 6D, in some embodiments, the SON support bitmap IE (600-D) may indicate that when bit 0 is set to "0", the SON algorithm is not supported and the remaining bitmap is irrelevant. However, when bit 0 is set to "1", it can indicate that the SON algorithm is supported, and the remaining bits in the bitmap indicate the support of specific SON algorithms. For example, when bit 1 is set to "1", it indicates the support of the PCI selection and conflict resolution algorithms. Similarly, when bit 2 is set to "1", it indicates the support of the ANR algorithm. Bit 3 indicates MLB support, bit 4 indicates MRO support, bit 5 indicates CCO support, bit 6 indicates ES support, bit 7 indicates ICIM support, bit 8 indicates COM support, and the remaining bits may be reserved for future inclusion of support for other SON functions.

[0092] FIG. 6E shows a SON support matrix (600-E) associated with deployment scenarios (600-A to 600-C) according to an embodiment of the present disclosure. In FIG. 6E, SON capabilities associated with different SON modules as the SON support matrix (600-E) are shown, for example, a management entity (640) of the SMO (410), a non-RT RIC (420), a near-RT RIC (430), and an E2 node (440). The SON capabilities can be communicated using a SON support bitmap IE.

[0093] FIG. 6F shows an exemplary sequence flow (600-F) of SON support according to the first, second, and third deployment scenarios (600-A to 600-C) according to an embodiment of the present disclosure. FIG. 6F shows a message sequence between different SON modules.

[0094] In some embodiments, upon successful establishment of the O1 link, the Near-RT RIC (430) and the E2 node (440) can indicate their SON support capabilities via the message O1: Capability Update Indication, which can include details of the SON support bitmap. Also, each time the SON function is enabled / disabled by the management entity (640) of the near-RT RIC (430) and / or the E2 node (420), they use this message to update their SON support functions. Further, upon receiving the capability information from the near-RT RIC (430) and the E2 node (440), the management entity (640) updates its Near-RT RIC database and / or E2 node database according to the source of the received message. The management entity (640) can use this information to create or prepare the final SON support matrix. The SON support matrix can include a determination of which SON algorithms are used to provide appropriate SON support.

[0095] Referring to FIG. 6F, at step 604, an O1 link can be established between the management entity (ME) (640) of the SMO (410), the near-RT RIC (430), and the E2 node (440). When the link is established and SON is enabled or disabled, at step 606, in the near-RT RIC (430), the near-RT-RIC (430) can send a capability update indication (608) including the SON support bitmap associated with the near-RT-RIC (430). The ME (640) updates its near-RT RIC database at step 612 to include the latest capability information shared by the near-RT RIC (430). Further, when SON is enabled or disabled, at step 614, in the E2 node (420), the E2 node (420) can send a capability update indication (616) including the SON support bitmap associated with the E2 node (440). The ME (640) updates its E2 node database at step 618 to include the latest function information shared by the E2 node (440). Based on the received capability information, the ME (640) determines the final support matrix at step 622. The ME (640) notifies the near-RT RIC (430) of the final SON support matrix at step 624 and receives an acknowledgement response from the near-RT RIC (430) at step 626. Further, the ME (640) notifies the E2 node (440) of the final SON support matrix at step 628 and receives an acknowledgement response from the E2 node (440) at step 632. When the SON matrix communication is complete, the ME (640) prepares the initial SON configuration at step 634 and can communicate it to the near-RT RIC (430) and the E2 node (440) at steps 636 and 638 respectively. Further, the ME (640) can prepare a dynamic SON configuration based on the analysis data and events at step 642. The ME (640) can communicate the dynamic SON configuration to the near-RT RIC (430) and the E2 node (440) at steps 644 and 646 respectively.In some embodiments, the message communication between the ME (640), the near-RT RIC (430), and the E2 node (440) may be performed via an O1 interface link.

[0096] FIG. 7A shows an exemplary diagram depicting a fourth deployment scenario (700-A) supported in a non-RT RIC where the SON algorithm uses an O1 interface, according to an embodiment of the present disclosure. In FIG. 7A, an implementation of the SON algorithm (710) as an rApp in the non-RT RIC (420) is shown. The SON algorithm (710) can communicate with the ME (720) using an internal interface defined as part of the SMO (410). The ME (720) can further communicate with the near-RT RIC (430) and the E2 node (440) via the O1 interface. In some embodiments, the ME (720) can function as a master, receive SON support functions from the non-RT RIC (420), the near-RT RIC (430), and the E2 node (440), derive a SON support matrix, and transmit SON configuration information to the non-RT RIC (420), the near-RT RIC (430), and the E2 node (440).

[0097] FIG. 7B shows an exemplary diagram representing a fifth deployment scenario (700-B) supported in a non-RT RIC where the SON algorithm uses A1 and E2 interfaces according to an embodiment of the present disclosure. In FIG. 7B, a SON algorithm implemented in a non-RT RIC (420) as an rApp communicating with a near-RT RIC via an A1 interface (704) is shown. In some embodiments, the non-RT RIC (420) can communicate with an E2 node (440) via a near-RT RIC (430). For example, the non-RT RIC (420) implemented as an rApp can communicate with the near-RT RIC (430) via the A1 interface (704), and the near-RT RIC (430) can further relay SON data to the E2 node (440) via the E2 interface (706).

[0098] FIG. 7C shows a SON support matrix (700-C) associated with deployment scenarios (700-A to 700-B) according to an embodiment of the present disclosure. In FIG. 7C, a SON support matrix with a non-RT RIC (420) implementing SON functions is shown. Only the bits (0 to 15) corresponding to the non-RT RIC (420) of the ME (640) are set, indicating that the SON function is implemented only in the non-RT RIC (420).

[0099] Figure 7D shows an exemplary sequence flow (700-D) of SON support according to a fourth and fifth deployment scenario (700-A to 700-B) according to an embodiment of the present disclosure. In Figure 7D, SON support messaging (700-D) associated with the SON implementation described above with reference to Figures 7A and 7B is shown. Referring to Figure 7D, at step 708, the establishment of the A1 link is successfully completed between the non-RT RIC (420) and the near-RT RIC (430) of the SMO (410). Further, in the near-RT RIC (430), at step 712, the SON algorithm can be enabled or disabled. When the SON algorithm is enabled / disabled, the near-RT RIC (430) can indicate its SON support capabilities at step 714 via the message A1: Capability Update Indication, which includes details of the SON support bitmap of the near-RT-RIC. The non-RT RIC (420) updates its near-RT RIC database at step 716. Similarly, an E2 link can be established between the near-RT RIC (430) and the E2 node (440) at step 718. Further, at step 722, the SON algorithm can be enabled / disabled at the E2 node (440). When the SON algorithm is enabled / disabled, the E2 node (440) can indicate its SON support capabilities to the near-RT RIC (430) at step 724 via the message E2: Capability Update Indication, which includes details of the SON support bitmap of the E2 node. The near-RT RIC (430) can relay the message to the non-RT RIC (420) via the message A1: Capability Update Indication at step 726. Upon receiving the relayed message, the non-RT RIC (420) can update its E2 node database at step 726. Also, whenever the SON function is enabled / disabled by the ME (720) at the near-RT RIC (430) and / or the E2 node (440), their SON support capabilities can be updated using the above messages.

[0100] Referring to FIG. 7D, the non-RT RIC (420) entity can, at step 732, prepare a final SON support matrix based on at least the messages received at steps 714 and 726. The non-RT RIC (420) can then, at step 734, communicate the final SON support matrix to the near-RT RIC (430). The near-RT RIC (430) transfers, at step 736, the final SON support matrix from the non-RT RIC (420) to the E2 node (440). The E2 node (440) can, at step 738, send an acknowledgement response message to the near-RT RIC (430). The near-RT RIC (430) relays, at step 742, the acknowledgement response message to the non-RT RIC (420). Upon receiving the acknowledgement response message, the non-RT RIC (420) prepares, at step 744, an initial SON configuration. The non-RT RIC (420) communicates, at step 746, the initial SON configuration to the near-RT RIC (430), which communication includes the initial SON configuration associated with the near-RT RIC (430) and the initial SON configuration associated with the E2 node (440). The near-RT RIC (430) further relays, at step 748, the initial SON configuration associated with the E2 node (440) to the E2 node.

[0101] Referring to FIG. 7D, based on the analysis data pattern and also based on some recent events, the non-RT RIC (420) can, at step 752, generate a dynamic SON configuration. The non-RT RIC (420) can then communicate the dynamic SON configuration in a similar manner as in the above steps of communicating the initial SON configuration. The non-RT RIC (420) sends, at step 754, a message A1: Configuration Command [with near-RT RIC: dynamic SON configuration, and E2 node: dynamic SON configuration] to the near-RT RIC, and relays, at step 756, further E2 node: dynamic SON configuration, to the E2 node (440) via an E2 configuration command message.

[0102] Figure 8A shows an exemplary diagram depicting a sixth deployment scenario (800-A) supported by both a management entity and a non-RT RIC in which the SON algorithm uses the O1 interface, according to an embodiment of the present disclosure. In Figure 8A, a SON algorithm supported by both the ME (810) and the non-RT RIC (420) is shown. In some embodiments, the non-RT RIC (420) is associated with a first vendor and can support one version of the SON algorithm, the ME (810) is associated with a second vendor and can support another version of the SON algorithm, and both the first vendor and the second vendor may or may not support the full list of SON capabilities.

[0103] Figures 8B to 8D show a SON support matrix associated with a deployment scenario (800-A) according to an embodiment of the present disclosure. In Figure 8B, the SON capabilities associated with the ME (810), non-RT RIC (420), near-RT RIC (430), and E2 node (440) are shown. Referring to Figure 8B, the ME (810) and non-RT RIC (420) support SON algorithms. In some embodiments, the ME (810) supports ICIM, MRO, MLB, ANR, and PCI functions, and the non-RT RIC (420) supports COM, ICIM, ES, CCO, MRO, MLB, ANR, PCI, and SON functions. In an exemplary embodiment, the master ME (810) may have the option to select the best SON function between the set of SON functions supported by the ME (810) and the non-RT RIC (420). Thus, the ME (810) can first select all of the best SON functions implemented by the non-RT RIC (420), as shown in the SON support matrix of Figure 8C. The ME (810) can further communicate the selected SON support matrix to other entities, such as the non-RT RIC (420), near-RT RIC (430), and E2 node (440), by one or more of the methods described above. However, the ME (810) can start collecting statistics related to the applied SON functions over a certain period under different conditions and can decide to modify the SON support matrix. In some embodiments, the ME (810) can select SON functions from multiple entities to improve the overall performance of the HetNet. For example, Figure 8D shows a new SON support matrix determined by the ME (810). Referring to Figure 8D, in the new SON support matrix (800-D), the ME (810) selects SON algorithms from both the ME (810) and the non-RT RIC (420).Therefore, SON algorithms such as PCI, ANR, MLB, MRO, and ICIM are selected from the ME(810), and SON algorithms such as CCO, ES, and COM are selected from the non-RT RIC(420). Furthermore, since the set of selected algorithms is from different vendors and may be executed at different locations, for example, it may be in different regions or not, some adjustment may be required between them. In some embodiments, the ES from the non-RT RIC(420) may need to be adjusted with the MLB algorithm from the ME(810) to make the final decision on whether to transition to the energy-saving mode. Generally, the MLB algorithm recognizes the cell load pattern, and based on the analysis data, the MLB algorithm can plan to offload a part of the cell data. In an exemplary embodiment, considering the cases of cells C1, C2, C3... Cn, MLB can sense the cell overload of C1 and C2 and plan to offload a part of the cell data associated with C1 and C2 to the adjacent cell C3. However, if the ES is planning the energy-saving mode of cell C3, C3 will enter the sleep mode, and if the MLB executes the offload of C3, cell C3 may become active again. This may cause a ping-pong effect in C3. Therefore, to avoid such problems, the ES needs to be adjusted with the MLB. In other words, when one or more SON functions are used across different modules, it is necessary to adjust those functions to avoid problems.

[0104] Figure 8E shows an exemplary sequence flow (800-E) of SON support according to a sixth deployment scenario (800-A) according to an embodiment of the present disclosure. In Figure 8E, the coordination between different SON algorithms implemented on different entities is shown. Referring to Figure 8, at step 804, the ES algorithm can be executed on the non-RT RIC (420), and the MLB algorithm can be executed on the ME (810). Further, at step 806, the non-RT RIC (420) can detect a series of events that require a particular cell to transition to an energy-saving state. Upon detecting the series of events, the ES of the non-RT RIC (420) determines at step 808 to send the particular cell to the sleep mode, but the ES confirms with the MLB algorithm before sending a message to the ME (810) to send the particular cell to the sleep mode. The ES of the non-RT RIC (420) can initiate a SON algorithm feedback request including at least one of a cell identity (cell ID), an ES algorithm (ES algo), event information, and a pending algorithm decision (pending algo decision) at the MLB of the ME (810) at step 812. The MLB of the ME (810) can analyze the load situation of the received cell ID based on both past states and future trends at step 814 and can prepare a proposal response to be sent to the ES of the non-RT RIC (420) at step 816. The MLB of the ME (810) can send a SON algorithm feedback response including at least one of a cell ID, an MLB algorithm, a proposal report, an applicable duration, etc. at step 818. The ES of the non-RT RIC (420) can analyze the received report and can determine whether to continue or abort the initiated action based on the received report at step 820. The ES of the non-RT RIC (420) can execute its decision at step 822. Further, the ES of the non-RT RIC (420) can instruct the MLB of the ME (810) to execute it at step 824, and this instruction includes an ES algorithm decision execution status.Communication between different SONs implemented in different entities may enable appropriate operation.

[0105] FIG. 9 shows an exemplary representation (900) of possible interference in a HetNet due to the interaction between multiple SON functions according to an embodiment of the present disclosure. In FIG. 9, the possible conflicts that may occur within the HetNet due to optimization by the SON implementation are shown. In some embodiments, when two or more SON functions aim to optimize the same output parameter, one or more conflicts may occur, and examples thereof are as follows: · Conflict of resources between MRO and MLB. · Conflict between CCO and inter-cell interference coordination (ICIC). · Conflict between cell outage compensation (COC) and ICIC.

[0106] Referring to FIG. 9, MRO may be associated with eNodeB (eNB1) (920), and MLB may be associated with eNB2 (930). A handover conflict may occur between MRO and MLB. In some embodiments, the COC associated with the operation and maintenance node (O&M) (910) may attempt to increase the transmission power to solve the function stop problem, while the ICIC associated with eNB2 (930) may attempt to reduce the transmission power to reduce interference. This may cause a conflict. Similarly, the CCO associated with the operation and maintenance node (O&M) (910) may attempt to adjust the antenna parameters to improve coverage, while the ICIC may attempt to reduce the transmission power and cause a conflict. Therefore, by applying the adjustment techniques as described above with reference to FIG. 8D, such conflicts may be avoided in the SON implementation.

[0107] Those skilled in the art will understand that these are merely examples and in no way limit the scope of the present disclosure.

[0108] FIG. 10 shows an exemplary computer system (1000) that can utilize embodiments of the present disclosure or can be used to utilize embodiments of the present disclosure. As shown in FIG. 10, computer system (1000) can include an external storage device (1010), a bus (1020), a main memory (1030), a read-only memory (1040), a mass storage device (1050), communication ports (plural possible) (1060), and a processor (1070). Those skilled in the art will understand that computer system (1000) can include two or more processors and communication ports. Processor (1070) can include various modules related to embodiments of the present disclosure. Communication ports (plural possible) (1060) can be any of an RS-232 port used for modem-based dial-up connections, a 10 / 100 Ethernet port, a 1 gigabit port or a 10 gigabit port using copper wire or fiber, a serial port, a parallel port, or any other existing port or next-generation port. Communication ports (plural possible) (1060) can be selected according to a network such as a local area network (LAN), a wide area network (WAN), or any network to which computer system (1000) is connected. Main memory (1030) can be a random access memory (RAM) or any other dynamic storage device generally known in the art. Read-only memory (1040) can be any static storage device(s) including, but not limited to, a programmable read-only memory (PROM) chip for storing static information such as startup or basic input / output system (BIOS) instructions for processor (1070). Mass storage device (1050) can be any current or future mass storage solution that can be used to store information and / or instructions.

[0109] The bus (1020) communicatively couples the processor (1070) to other memories, storage, and communication blocks. The bus (1020) may be, for example, a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus for connecting expansion cards, drives, and other subsystems, a Small Computer System Interface (SCSI), a Universal Serial Bus (USB), etc., as well as other buses such as a front side bus (FSB) that connects the processor (1070) to the computer system (1000).

[0110] Optionally, a communications carrier and management interface, such as a display, keyboard, and cursor control device, may also be coupled to the bus (1020) to support direct interaction of the communications carrier with the computer system (1000). Other communications carriers and management interfaces may be provided via network connections connected via communication port(s) (1060). The foregoing exemplary computer system (1000) is in no way intended to limit the scope of the present disclosure.

[0111] Although considerable emphasis has been placed herein on preferred embodiments, it will be understood that many embodiments can be made and that many changes can be made to the preferred embodiments without departing from the principles of the present disclosure. These and other changes to the preferred embodiments of the present disclosure will be apparent to those skilled in the art from the disclosure herein, and it should be clearly understood that the foregoing description is merely illustrative of the present disclosure and is not to be construed as limiting.

[0112] Advantages of the Present Disclosure The present disclosure provides interoperability techniques between SON functions implemented by one or more vendors.

[0113] The present disclosure provides a master-slave architecture for discovery and handshake between different entities that enables a better implementation of SON procedures.

[0114] The present disclosure provides an advanced communication system.

Claims

1. A system (202) that enables interoperability of a self-organizing network (SON) in a heterogeneous network (HetNet) (100), comprising: one or more processors (302); a memory (304) operably coupled to the one or more processors (302), which, when executed, causes the one or more processors (302) to: send SON capability queries (404-a, 404-b, 404-c) to one or more entities within the HetNet (100); in response to the SON capability queries (404-a, 404-b, 404-c), receive SON capability information (406-a, 406, b, 406-c) associated with the one or more entities within the HetNet (100); generate an initial SON configuration associated with the one or more entities based on the received SON capability information; the memory (304) including processor-executable instructions; and the system (202).

2. The memory (304), which, when executed, causes the one or more processors (302) to: instruct one or more entities within the HetNet (100) to enable the SON function of the one or more entities based on the received SON capability information, wherein the system (202) according to claim 1 includes processor-executable instructions.

3. The memory (304), which, when executed, causes the one or more processors (302) to: instruct one or more entities within the HetNet (100) to disable the SON function of the one or more entities based on the received SON capability information, wherein the system (202) according to claim 1 includes processor-executable instructions.

4. The system (202) according to claim 1, wherein the one or more entities include an open radio access network (O-RAN) entity.

5. The system (202) according to claim 4, wherein the one or more entities include at least one of a non-real-time radio access network intelligent controller (non-RT RIC) (420), a near-RT RIC (430), and an E2 node (440).

6. The system (202) according to claim 1, wherein the SON capability information includes a SON support bitmap information element (IE).

7. The memory (304) causes the one or more processors (302) at execution time to create a SON support matrix based on the SON support bitmap IE received from the one or more entities, generate the initial SON configuration based on the SON support matrix, The system (202) according to claim 6, comprising processor-executable instructions. **Claim 8** The memory (304) causes the one or more processors (302) at execution time to collect analysis data associated with the HetNet (100), detect one or more events within the HetNet (100), generate a dynamic SON configuration associated with the one or more entities based on at least one of the collected data and the one or more detected events, The system (202) according to claim 7, comprising processor-executable instructions. **Claim 9** The memory (304) causes the one or more processors (302) at execution time to operate a first element associated with the SON configuration of a first entity among the one or more entities, operate a second element associated with the SON configuration of a second entity among the one or more entities, detect a change in an operation associated with the first element of the first entity, communicate the change in the operation associated with the first element of the first entity to the second element of the second entity, The system (202) according to claim 7, comprising processor-executable instructions. **Claim 10** The memory (304) causes the one or more processors (302) at execution time to receive a response from the second element of the second entity based on the change in the operation associated with the first element of the first entity, execute the change in the operation associated with the first element of the first entity based on the received response, The system (202) according to claim 9, comprising processor-executable instructions. **Claim 11** A method for enabling interoperability of a self-organizing network (SON) in a heterogeneous network (HetNet) (100), One or more processors (302) transmit SON capability queries (404-a, 404-b, 404-c) to one or more entities within the HetNet (100); One or more processors (302) receive SON capability information (406-a, 406-b, 406-c) associated with the one or more entities within the HetNet (100) in response to the SON capability queries (404-a, 404-b, 404-c); One or more processors (302) generate an initial SON configuration based on the received SON capability information; A method comprising the above steps.

12. One or more processors (302) instruct one or more entities within the HetNet (100) to enable the SON function of the one or more entities based on the received SON capability information; The method according to claim 11, further comprising the above step.

13. One or more processors (302) instruct one or more entities within the HetNet (100) to disable the SON function of the one or more entities based on the received SON capability information; The method according to claim 11, further comprising the above step.

14. The method according to claim 11, wherein the one or more entities include an Open Radio Access Network (O-RAN) entity.

15. The method according to claim 14, wherein the one or more entities include at least one of a non-real-time radio access network intelligent controller (non-RT RIC) (420), a near-RT RIC (430), and an E2 node (440).

16. The method according to claim 11, wherein the SON capability information includes a SON support bitmap information element (IE).

17. One or more processors (302) create a SON support matrix based on the SON support bitmap IEs from the one or more entities; One or more processors (302) generate an initial SON configuration based on the SON support matrix; The method according to claim 16, further comprising the above steps.

18. collecting, by the one or more processors (302), analysis data associated with the HetNet (100); detecting, by the one or more processors (302), one or more events within the HetNet (100); generating, by the one or more processors (302), a dynamic SON configuration associated with the one or more entities based on at least one of the collected data and the detected events; The method according to claim 17, comprising the above.

19. operating, by the one or more processors (302), a first element associated with the SON configuration of a first entity among the one or more entities; operating, by the one or more processors (302), a second element associated with the SON configuration of a second entity among the one or more entities; detecting, by the one or more processors (302), a change in an operation associated with the first element of the first entity; communicating, by the one or more processors (302), the change in the operation associated with the first element of the first entity to the second element of the second entity; The method according to claim 17, comprising the above.

20. receiving, by the one or more processors (302), a response from the second element of the second entity based on the change in the operation associated with the first element of the first entity; executing, by the one or more processors (302), the change in the operation associated with the first element of the first entity based on the received response; The method according to claim 19, comprising the above.

21. A user equipment (UE) operating in a heterogeneous network (HetNet), comprising: one or more processors communicatively coupled to a system (202), the system (202) including one or more processors (302) and a memory (304) operatively coupled to the one or more processors (302), the memory, when executed by the one or more processors (302), causing the one or more processors (302) to Cause one or more entities within the HetNet (100) to receive a self-organizing network (SON) capability query (404-a, 404-b, 404-c). Cause SON capability information (406-a, 406-b, 406-c) associated with the one or more entities within the HetNet (100) to be received in response to the SON capability query (404-a, 404-b, 404-c). Cause an initial SON configuration associated with the one or more entities to be generated based on the received SON capability information. Including processor-executable instructions The user equipment (UE). [

22. ] A non-transitory computer-readable medium having stored thereon one or more instructions that, when executed by a processor, cause the processor to Cause one or more entities within the HetNet (100) to receive a self-organizing network (SON) capability query (404-a, 404-b, 404-c). Cause SON capability information (406-a, 406-b, 406-c) associated with the one or more entities within the HetNet (100) to be received in response to the SON capability query (404-a, 404-b, 404-c). Cause an initial SON configuration associated with the one or more entities to be generated based on the received SON capability information. Including the one or more instructions The non-transitory computer-readable medium.

Images