Claims:CLAIMS
We Claim:

1. A method of managing a plurality of neighbour cells (354b, 354c, 354d) of each target cell (354a) in a radio access network (300), the method comprising:
capturing and reporting, by a central unit (CU) (512) associated with each target cell (354a), a radio signal quality associated with each of the plurality of neighbour cells (354b, 354c, 354d) of a target cell based on signal strength measurements reported by a plurality of user equipments (UEs) (324a1, 324a2, 324a3) to the target cell and a handover performance between the target cell and each of the plurality of neighbour cells (354b, 354c, 354d);
ranking and labelling the plurality of neighbour cells (354b, 354c, 354d) based on the radio signal quality associated with each of the plurality of neighbour cells; and
taking and managing an action based on the ranking and labelling, wherein the action is associated with the plurality of neighbour cells (354b, 354c, 354d).

2. The method as claimed in claim 1, wherein the managing action comprises adding a cell to the plurality of neighbour cells when the cell is identified as a good neighbour, wherein the good neighbour is determined based on at least one of a radio signal quality information, a radio signal quality threshold and priority of each of the plurality of neighbour cells.

3. The method as claimed in claim 1, wherein the managing action comprises rearranging priorities of each of the plurality of neighbour cells (354b, 354c, 354d) based on the ranking.

4. The method as claimed in claim 1, wherein ranking the plurality of neighbour cells (354b, 354c, 354d) comprising assigning a rank to each of the plurality of neighbour cells based on calculation of the radio signal quality for each of the plurality of neighbour cells.

5. The method as claimed in claim 1, wherein the managing action comprises removing a cell for handover consideration from the plurality of neighbour cells when the cell is identified as a bad neighbour, wherein the bad neighbour is so labelled based on at least one of a handover performance information derived from attempted handovers, a handover failure information, a handover successful information, an attempted handovers threshold, a handover success ratio, and a handover success ratio threshold.

6. The method as claimed in claim 1, wherein the handover performance is defined by one or more of a number of attempted handovers between each of the plurality of neighbour cells and the target cell and a number of successful handovers between each of the plurality of neighbour cells and the target cell.

7. A system (300) for managing a plurality of neighbour cells (354b, 354c, 354d) of each target cell, the system (300) configured to:
capture radio signal quality measurements from a plurality of user equipments (UEs) (324a1, 324a2, 324a3) associated with a target cell, wherein the radio signal quality measurements are captured by a central unit (CU) (512) associated with the target cell, wherein the radio signal quality measurements are associated with each of the plurality of neighbour cells (354b, 354c, 354d);
report the radio signal quality measurements for all subscribed target cells to at least one xApp (406) in connection with a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC) (314) by the CU (512), wherein the CU (512) is in connection with the Near-RT RIC (314) over an E2 interface;
rank the plurality of neighbour cells by the at least one xApp (406) based on the radio signal quality measurements associated with each of the plurality of neighbour cells;
capture a handover performance from each target cell, wherein the handover performance is captured by the central unit (CU) (512) associated with the target cell, wherein the handover performance is associated with each of the plurality of neighbour cells (354b, 354c, 354d) of the target cell;
report the handover performance of all subscribed cells to at least one rApp (404) in connection with a Non-Real-Time Radio Access Network Intelligent Controller (Non-RT RIC) (402) within a Service Management and Orchestrator (SMO) (302) by the CU (512), wherein the CU (512) is in connection with the SMO (302) over an O1 interface;
create a policy and send the policy by the at least one rApp (404) to the at least one xApp (406) in connection with the Near-RT RIC (314) over an A1 interface; and
take and manage an action based on the ranking and the policy by the at least one xApp (406) in connection with the Near-RT RIC (314), wherein the manage action is associated with the plurality of neighbour cells (354b, 354c, 354d).

8. The system (300) as claimed in claim 7, wherein the manage action comprises adding a cell to the plurality of neighbour cells when the cell is identified as a good neighbour, wherein the good neighbour is determined based on at least one of a radio signal quality information, a radio signal quality threshold, priority of each of the plurality of neighbour cells.

9. The system (300) as claimed in claim 7, wherein the manage action comprises rearranging priorities of each of the plurality of neighbour cells (354b, 354c, 354d) based on the ranking.

10. The system (300) as claimed in claim 7, wherein rank the plurality of neighbour cells (354b, 354c, 354d) comprising assigning a rank to each of the plurality of neighbour cells based on calculation of the radio signal quality for each of the plurality of neighbour cells.

11. The system (300) as claimed in claim 7, wherein the manage action comprises removing a cell from the plurality of neighbour cells when the cell is identified as a bad neighbour, wherein the bad neighbour is so labelled based on at least one of a handover performance information derived from attempted handovers, a handover failure information, a handover successful information, an attempted handovers threshold, a handover success ratio, and a handover success ratio threshold.

12. The system (300) as claimed in claim 7, wherein the handover performance is defined by one or more of a number of attempted handovers between each of the plurality of neighbour cells and the target cell and a number of successful handovers between each of the plurality of neighbour cells and the target cell.
, Description:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2003

COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION

“METHOD AND SYSTEM OF MANAGING PLURALITY OF NEIGHBOUR CELLS OF A TARGET CELL”

APPLICANT(S):

Name : Sterlite Technologies Limited

Nationality : Indian

Address : 3rd Floor, Plot No. 3, IFFCO Tower,
Sector – 29, Gurugram, Haryana
122002


The following specification particularly describes the invention and the manner in which it is to be performed:
TECHNICAL FIELD
[0001] The present disclosure relates to wireless communications networks, and more specifically, relates to a method and a system for managing a plurality of neighbour cells of a target cell in an O-RAN (Open-Radio Access Network).

BACKGROUND
[0002] In general, neighbor relations are critical for an operation of cellular wireless networks. The quality of the neighbor relations directly affects handoff success, throughput and overall performance of the cellular wireless networks. Manually provisioning and managing neighbor cells is a challenging task and it becomes more difficult as new mobile technologies are being rolled out. In the same context, Automatic Neighbor Relations (ANR) are a SON (Self-Organizing Network) function, and an ANR is introduced to eliminate the need to manually manage neighbor relations (NRs) in the cellular wireless networks. Further, the ANR is used to automatically populate a neighbor relation table (NRT). With fifth generation (5G) and disaggregation of radio access network (RAN), the problem becomes complex, and the ANR solution needs to be modified to exploit the flexibility an Open Radio Access Network (O-RAN) architecture provides. This can enhance the ability of the ANR solution to optimize the handoff (handover) success, the throughput and overall performance of the cellular wireless networks.
[0003] FIG. 1 is an example conventional illustration (100) in which a Long-Term Evolution Physical Cell Identifier (LTE PCI) planning for poorly performing neighbors (or noisy neighbors) is described. As shown in FIG. 1, the ANR function resides in an eNB (eNodeB or Evolved Node B) and manages a conceptual Neighbor Relation Table (NRT), where a neighbor detection function determines new neighbors and adds them to the NRT which is located within the ANR. The ANR also contains a neighbor removal function which removes poorly performing neighbors from the NRT. The neighbor detection function and the neighbor removal function are implementation specific. Further, for each cell that the eNB has, the eNB keeps an NRT. For each NR, the NRT contains the target cell identifier (TCI), where the TCI identifies a target cell. In an example, for an Evolved UMTS Terrestrial Radio Access Network (E-UTRAN), the TCI corresponds to the E-UTRAN Cell Global Identifier (ECGI) and Physical Cell Identifier (PCI) of the target cell. The ANR function relies on cells broadcasting their identity on global level, the ECGI allows an Operations & Maintenance (O&M) system (102) to manage the NRT. The O&M system can add and delete NRs. The O&M system (102) can also change attributes of the NRT. The O&M system (102) is informed about changes in the NRT.
[0004] With respect to Intra-RAT/frequency ANR, the gNB or eNB serving cell with the ANR function, instructs each UE to perform measurements on neighbor cells, as a part of the normal call procedure. The gNB/eNB may use different policies for instructing the UE to do measurements, and when to report them to the gNB/eNB. When the UE discovers new cell’s ECGI (E-UTRAN Cell Global Identifier) or NR Cell Global Identifier (NCGI), the UE reports the detected ECGI/NCGI (aka “CGI”) to the serving cell gNB/eNB. In addition, the UE reports tracking area codes and all Public Land Mobile Network identifiers (PLMN IDs) that have been detected. The gNB or eNB adds this neighbor relation to the NRT.
[0005] With respect to Inter-RAT/Inter-frequency ANR, the gNB or eNB serving cell with the ANR function can instruct the UE to perform measurements and detect cells on other RATs/frequencies during connected mode. The gNB or eNB may use different policies for instructing the UE to do measurements, and when to report them to the gNB or eNB.
[0006] Further, the UE reports the PCI of the detected cells in the target RATs/frequencies. When the gNB or eNB receives the UE reports containing PCIs of cell(s), the gNB or eNB may instruct the UE to read the CGI (cell global identifier) and an RAC (routing area code) of the detected neighbor cell in case of GERAN (GSM EDGE Radio Access Network) detected cells and the CGI, a location area code (LAC) and, the Routing Area Code (RAC) in case of UTRAN detected cells. For the inter-frequency case, the eNB/gNB may instruct the UE to read the ECGI/NCGI, TAC and all available PLMN ID(s) of the inter-frequency detected cell. The eNB/gNB updates its inter-RAT/inter-frequency neighbor relation table after receiving relevant information from the UE.
[0007] FIG. 2a is an example illustration (200a) in which neighbor relations are detected in a distributed approach, according to prior art. Referring to FIG. 2a, a base station (BS) (202a) adds/deletes its neighbors automatically monitoring signaling messages over interfaces Uu and X2. Thus, in a distributed ANR (D-ANR), neighbor detection process is typically fast, as it is deployed close to the radio network. However, the process influences fewer cells per-algorithm because a D-ANR module works per BS basis.
[0008] FIG. 2b is an example illustration (200b) in which neighbor relations are detected in a centralized approach, according to prior art. Referring to FIG. 2b, a centralized ANR (C-ANR) determines multiple cells operating under different BSs together. Thus, the C-ANR can jointly optimize NRTs of multiple BSs. The C-ANR adds the NRs to cells based on centralized configuration data and key performance indicators (KPIs). The ECGI is acquired from centralized database, instead of UE measurements. However, the C-ANR may detect potential neighbors slower when compared to the D-ANR since it does not have real-time intra/inter RAT and intra/inter frequency NRT update functionalities that the D-ANR possesses.
[0009] FIG. 2c is an example illustration (200c) in which neighbor relations are detected in a hybrid approach, according to prior art. Referring to FIG. 2c, a hybrid-ANR (H-ANR) optimum comprise between the D-ANR and the C-ANR. But the operations of the H-ANR is complex. The current scope is not sufficient to comply with 5G requirements, especially with dynamic HetNet optimization which strives for very low latency under high scalability. Some of the prior art references are given below:
[0010] US10827549B2 relates generally to facilitating automatic neighbor relationships. For example, this disclosure relates to facilitating automatic neighbor relationships to support radio access networks for a 5G (virtualized or not), or other next generation network, air interface. In the disclosure, network virtualization and SDN can provide improved programmability, time to market, etc. 5G RAN can be decomposed and some of the RAN functions, such as the non-real time functions (more precisely the L3 and part of L2 functions for both control plane and user plane) can be centralized and virtualized (e.g., vCU), and the real time RAN functions can be distributed to or close to the cell sites (e.g., donor unit (DU)/radio unit (RU)). This disclosure provides an enabler of 5G RAN, the 5G automatic neighbor relationship (ANR), to optimize the mobility management to select the best anchor cell (either LTE or 5G NB) while supporting various deployments and 5G virtualization.
[0011] US9294963B2 teaches a method that comprises, at the source eNB, maintaining a Neighbor Relation Table (NRT) identifying the connectivity of the source eNB to cells of its neighbor eNBs, this information including for each eNB cell an indication that the eNB cell is an open, closed or hybrid eNB cell and, for each closed and hybrid eNB cell, a Closed Subscriber Group, CSG, identity. The method further comprises determining that a handover of the UE is required and using the information stored in the NRT to identify closed and optionally hybrid eNBs cells to which the subscriber has access, selecting a target eNB cell from the available open eNBs cells and the identified closed and optionally hybrid eNBs cells, and performing handover of the subscriber from the source to the target eNB cell including establishing an X2 interface between the source and the target eNBs where no such interface exists a priori.
[0012] According to current 3GPP Long Term Evolution (LTE) specifications, the eNB can obtain knowledge about its connectivity to its neighbors by means of a Neighbor Relation Table (NRT) which it maintains. The NRT in the eNB can be configured either manually or via Operation and Maintenance (O&M) processes, or automatically via the Automatic Neighbor Relation (ANR) function which resides in the eNB.
[0013] Another non-patent literature entitled “Hybrid Automatic Neighbor Relations for 5G Wireless Networks” discloses a comprehensive hybrid ANR (H-ANR) architecture considering the requirements of 5G systems which will keep LTE-A at the core of wireless cellular network. The introduced architecture is also applicable to current networks and includes NR ranking, blacklisting and whitelisting functionalities which utilize an extensive set of universal performance criteria, configuration metrics, and measurements. These functionalities are applicable to inter-vendor/heterogeneous network (HetNet) scenarios. Furthermore, D-ANR attributes of BSs are managed to optimize automatic intra-frequency neighbor detection process. eX2 blacklisting and whitelisting policy based on cell to cell or transmission/reception points (TRP) to TRP relations [16] between two BSs are also envisioned and introduced for 5G systems. Optimization of NRT which includes removal of poorly performing neighbors is conducted by ranking NRs with a universal ranking equation. New NRs are introduced utilizing historical performance of NRs and number of available vacancies.
[0014] While the prior arts cover various solutions for managing neighbour cells, however these solutions are not effective, since existing methods and system has drawbacks, e.g., Highly dynamic HetNet (heterogeneous network) environment demands very low latency and high quality neighbor relations with high scalability. The existing solutions do not support high interoperability in a disaggregated multi-vendor environment and do not support policy-based features to reduce operational complexity. In light of the above-stated discussion, there is a need to overcome the above stated disadvantages.

OBJECT OF THE DISCLOSURE
[0015] A principal object of the present disclosure is to provide a method and a system for managing a plurality of neighbour cells of each target cell of a radio access network.
[0016] Another object of the present disclosure is to support very low latency and high quality neighbor relations with high scalability in a highly dynamic HetNet (heterogeneous network) environment.
[0017] Another object of the present disclosure is to support high interoperability in a disaggregated multi-vendor environment.
[0018] Another object of the present disclosure is to assist policy-based features to reduce operational complexity in the disaggregated multi-vendor environment. The policy-based features may be, for example, but not limited to automated relation blacklisting and whitelisting, automated X2/Xn blacklisting and whitelisting, automated X2 and Xn connection management and automated relation tracking.
[0019] Another object of the present disclosure is to implement ANR (Automatic Neighbour Relation) function in an O-RAN architecture.
[0020] Another object of the present disclosure is to avoid a ping-pong behavior between NRTs at E2 nodes and an RIC (Radio Intelligent Controller) in the O-RAN architecture.
[0021] Another object of the present disclosure is to leverage centralized visibility at the RIC in updating/optimizing NRTs at different cells.
[0022] Yet another object of the present disclosure is to provide a hybrid automatic neighbour relation function in the O-RAN architecture to manage the neighbour relations functionality through measuring and ranking the neighbours for each cell by UEs and gNBs (Next Generation NodeB). Further, each E2 node reports its NRT and aggregated radio signal quality measurements of neighbor cells for each subscribed cell to a Near-RT RIC over an E2 interface based on subscriptions. The E2 node is configured to report handover performance management (PM) data for each cell to an SMO/Non-RT RIC over an O1 interface. The E2 node receives UE measurement reports (e.g., NR-CGI, PCI, RSRP measurements) for each neighbour cell while events trigger at the UE. Thus results in enhancing the user experience.

SUMMARY
[0023] Accordingly, the present disclosure provides a method and a system of managing a plurality of neighbour cells of each target cell. The method includes capturing and reporting (by a central unit (CU) associated with each target cell) a radio signal quality associated with each of the plurality of neighbour cells of a target cell based on signal strength measurements reported by a plurality of user equipments (UEs) to the target cell and a handover performance between the target cell and each of the plurality of neighbour cells. The handover performance may be defined by one or more of a number of attempted handovers between each of the plurality of neighbour cells and the target cell and a number of successful handovers between each of the plurality of neighbour cells and the target cell. Further, the method includes ranking and labelling the plurality of neighbour cells based on the radio signal quality associated with each of the plurality of neighbour cells, wherein ranking the plurality of neighbour cells may comprise assigning a rank to each of the plurality of neighbour cells based on calculation of the radio signal quality for each of the plurality of neighbour cells. Further, the method includes taking and managing an action based on the ranking and labelling, wherein the action is associated with the plurality of neighbour cells. The managing action may comprise adding a cell to the plurality of neighbour cells when the cell is identified as a good neighbour, wherein the good neighbour is determined based on at least one of a radio signal quality information, a radio signal quality threshold, priority of each of the plurality of neighbour cells. Alternatively, the managing action may comprise rearranging priorities of each of the plurality of neighbour cells based on the ranking. Alternatively, the managing action may comprise removing a cell from the plurality of neighbour cells when the cell is identified as a bad neighbour, wherein the bad neighbour is so labelled based on at least one of a handover performance information derived from attempted handovers, a handover failure information, a handover successful information, an attempted handovers threshold, a handover success ratio, a handover success ratio threshold, or the like.
[0024] The system comprises a central unit (CU). The CU captures radio signal quality measurements from a plurality of user equipments (UEs) associated with a target cell, wherein the radio signal quality measurements are captured by the central unit (CU) associated with the target cell and wherein the radio signal quality measurements are associated with each of the plurality of neighbour cells. The radio signal quality measurements for all subscribed target cells are reported by the CU to at least one xApp in connection with a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC), wherein the CU is in connection with the Near-RT RIC over an E2 interface. The at least one xApp ranks the plurality of neighbour cells based on the radio signal quality measurements associated with each of the plurality of neighbour cells.
[0025] The CU also captures a handover performance from each target cell, wherein the handover performance is captured by the CU associated with the target cell and wherein the handover performance is associated with each of the plurality of neighbour cells of the target cell. The handover performance of all subscribed cells is further reported to at least one rApp in connection with a Non-Real-Time Radio Access Network Intelligent Controller (Non-RT RIC) within a Service Management and Orchestrator (SMO) by the CU, wherein the CU is in connection with the SMO over an O1 interface. Based on the reporting, a policy is created and sent by the at least one rApp to the at least one xApp in connection with the Near-RT RIC over an A1 interface. Lastly, the at least one xApp in connection with the Near-RT RIC takes and manages an action based on the ranking and the policy, wherein the manage action is associated with the plurality of neighbour cells.
[0026] These and other aspects herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the invention herein without departing from the spirit thereof.

BRIEF DESCRIPTION OF FIGURES
[0027] The invention is illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the drawings. The invention herein will be better understood from the following description with reference to the drawings, in which:
[0028] FIG. 1 is an example illustration in which an LTE PCI planning for poorly performing neighbours (or noisy neighbors) is described, according to the prior art.
[0029] FIG. 2a is an example illustration in which neighbour relations are detected in a distributed approach, according to the prior art.
[0030] FIG. 2b is an example illustration in which the neighbour relations are detected in a centralized approach, according to the prior art.
[0031] FIG. 2c is an example illustration in which the neighbour relations are detected in a hybrid approach, according to the prior art.
[0032] FIG. 3 illustrates an O-RAN architecture, according to the present disclosure.
[0033] FIG. 4 illustrates a hybrid ANR in the O-RAN architecture, according to the present disclosure.
[0034] FIG. 5 illustrates an RIC solution architecture, according to the present disclosure.
[0035] FIG. 6 illustrates a near-RT RIC architecture, according to the present disclosure.
[0036] FIG. 7 illustrates a non-RT-RIC-MVP architecture, according to the present disclosure.
[0037] FIG. 8 is a sequence diagram illustrating hybrid automatic neighbour relations in a disaggregate 5G RAN, according to the present disclosure.
[0038] FIG. 9 is an example flowchart illustrating a method, implemented by an rApp, for handling the hybrid automatic neighbour relations, according to the present disclosure.
[0039] FIG. 10 is an example flowchart illustrating a method, implemented by an xApp, for handling the hybrid automatic neighbour relations and A1 policy handling, according to the present disclosure.
[0040] FIG. 11 is an example flowchart illustrating a method, implemented by the xApp, for handling the hybrid automatic neighbour relations, E2 and ANR report handling, according to the present disclosure.
[0041] FIG. 12 is an example flowchart illustrating a method for creating an E2 NR control, according to the present disclosure.
[0042] FIG. 13 is an example flowchart illustrating a method, implemented by the xApp, for handling an E2 node NRT, according to the present disclosure.
[0043] FIG. 14 is an example flowchart illustrating a method for managing a table of a plurality of neighbour cells of a target cell, according to the present disclosure.

DETAILED DESCRIPTION
[0044] In the following detailed description of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be obvious to a person skilled in the art that the invention may be practiced with or without these specific details. In other instances, well known methods, procedures and components have not been described in detail so as not to unnecessarily obscure aspects of the invention.
[0045] Furthermore, it will be clear that the invention is not limited to these alternatives only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without parting from the scope of the invention.
[0046] The accompanying drawings are used to help easily understand various technical features and it should be understood that the alternatives presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.
[0047] Standard networking terms and abbreviations:
[0048] NETCONF: NETCONF is a protocol defined by the IETF to “install, manipulate, and delete the configuration of network devices”. NETCONF operations are realized on top of a Remote Procedure Call (RPC) layer using an XML encoding and provide a basic set of operations to edit and query configuration on a network device.
[0049] Server (residing in networking devices like) (O-RU/O-DU): The Server can be a Switch, Router, Commercially Off-the-shelf Servers, Open Distributed Units, Open Radio Units, etc.
[0050] Client (EMS/SMO/O-DU): The Client here can be a user over Element Management System (EMS), Service Management and Orchestration (SMO), Open Distributed Unit (O-DU), Open Radio Unit (O-RU) Controller or any other NETCONF client accessing the NETCONF server.
[0051] gNB: New Radio (NR) Base stations which have the capability to interface with 5G Core named as NG-CN over NG-C/U (NG2/NG3) interface as well as 4G Core known as Evolved Packet Core (EPC) over S1-C/U interface.
[0052] LTE eNB: An LTE eNB is evolved eNodeB that can support connectivity to EPC as well as NG-CN.
[0053] Non-standalone NR: It is a 5G Network deployment configuration, where a gNB needs an LTE eNodeB as an anchor for control plane connectivity to 4G EPC or LTE eNB as an anchor for control plane connectivity to NG-CN.
[0054] Standalone NR: It is a 5G Network deployment configuration where gNB does not need any assistance for connectivity to the core network, it can connect on its own to NG-CN over NG2 and NG3 interfaces.
[0055] Non-standalone E-UTRA: It is a 5G Network deployment configuration where the LTE eNB requires a gNB as an anchor for control plane connectivity to NG-CN.
[0056] Standalone E-UTRA: It is a typical 4G network deployment where a 4G LTE eNB connects to EPC.
[0057] Xn Interface: It is a logical interface that interconnects the New RAN nodes i.e., it interconnects gNB to gNB and LTE eNB to gNB and vice versa.
[0058] Reference signal received power (RSRP): RSRP may be defined as the linear average over the power contributions (in [W]) of the resource elements that carry cell-specific reference signals within the considered measurement frequency bandwidth. RSRP may be the power of the LTE Reference Signals spread over the full bandwidth and narrowband.
[0059] The drawbacks mentioned earlier (in the background section) are overcome by the proposed disclosure that provides a hybrid automatic neighbour relation function in an O-RAN architecture to manage the neighbour relations functionality through measuring and ranking neighbours for each cell by UEs (User Equipments) and gNBs. Each E2 node (CU) reports its NRT and aggregated radio signal quality measurements of neighbour cells for each subscribed cell to a Near-RT RIC over an E2 interface based on subscriptions. The E2 node is configured to report handover performance measurement (PM) data for each cell to an SMO/Non-RT RIC over an O1 interface. The E2 node receives UE measurement reports (e.g., NR-CGI, PCI, RSRP measurements) for each neighbour cell while events trigger at the UE. Thus results in enhancing the user experience. The proposed disclosure also provides a highly dynamic HetNet (heterogeneous network) environment that demands very low latency and high quality neighbour relations with high scalability. The proposed disclosure supports a high interoperability in a disaggregated multi-vendor environment and supports policy-based features to reduce operational complexity.
[0060] Referring now to the drawings, and more particularly to FIGS. 3 through 14.
[0061] FIG. 3 illustrates an O-RAN system (or O-RAN) (300) (interchangeably be called as RAN (300)) according to the present disclosure. Referring to the FIG. 3, a radio access network (RAN) is a part of a telecommunications system which connects individual devices to other parts of a network through radio connections. The RAN provides a connection of user equipment (UE) such as mobile phones or computers with a core network of telecommunication systems. The RAN is an essential part of the access layer in the telecommunication systems which utilizes base stations (such as e node B, g node B) for establishing radio connections. The O-RAN (Open-Radio Access Network) (300) is an evolved version of prior radio access networks, making the prior radio access networks more open and smarter than previous generations. The O-RAN (300) provides real-time analytics that drives embedded machine learning systems and artificial intelligence back-end modules to empower network intelligence. Further, the O-RAN (300) includes virtualized network elements with open and standardized interfaces. The open interfaces are essential to enable smaller vendors and operators to quickly introduce their services or enable operators to customize the network to suit their own unique needs. Open interfaces also enable multivendor deployments, enabling a more competitive and vibrant supplier ecosystem. Similarly, open-source software and hardware reference designs enable faster, more democratic, and permission-less innovation. Further, the O-RAN (300) introduces a self-driving network by utilizing new learning-based technologies to automate operational network functions. These learning-based technologies make the O-RAN intelligent. Embedded intelligence, applied at both component and network levels, enables dynamic local radio resource allocation and optimizes network-wide efficiency. In combination with O-RAN’s open interfaces, AI-optimized closed-loop automation is a new era for network operations.
[0062] The O-RAN (300) may comprise a Service Management and Orchestrator (SMO) (can also be termed as “Service Management and Orchestration Framework”) (302), a Non-Real Time RAN Intelligent Controller (Non-RT RIC) (402) residing in the SMO (302), a Near-Real Time RAN Intelligent Controller (Near-RT RIC) (314), an Open Central Unit Control Plane (O-CU-CP) (316), an Open Central Unit User Plane (O-CU-UP) (318), an Open Distributed Unit (O-DU) (320), an Open Radio Unit (O-RU) (322) and an Open Cloud (O-Cloud) (312).
[0063] The SMO (302) is configured to provide SMO functions/services such as data collection and provisioning services of the ORAN (300). The data collection of the SMO (302) may include, for example, data related to a bandwidth of a wireless communication network and at least one of a plurality of user equipments (324a1, 324a2, 324a3, 324b, 324c, 324d) (“the plurality of user equipments may combinedly be represented as reference numeral 324”) (shown in FIG. 3 and FIG. 4). That is, the SMO (302) oversees all the orchestration aspects, management and automation of ORAN elements and resources and supports O1, A1 and O2 interfaces. The SMO (302) may include an A1 REST (Representational State Transfer) client (306) that may handle the A1 policy management services (e.g. add/remove adapters, security certs or the like) in the SMO framework (302) and handle one or more policies using an A1 policy agent (304).
[0064] The Non-RT RIC (402) is a logical function that enables non-real-time control and optimization of the ORAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT RIC (314). It is a part of the SMO framework (302) and communicates to the Near-RT RIC (314) using the A1 interface. The Near-RT RIC (314) is a logical function that enables near-real-time control and optimization of the O-RAN elements and resources via fine-grained data collection and actions over an E2 interface.
[0065] Non-Real Time (Non-RT) control functionality (> 1s) and Near-Real Time (Near-RT) control functions (< 1s) are decoupled in an RIC (RAN Intelligent Controller). The Non-RT functions include service and policy management, RAN analytics and model-training for some of the near-RT RIC functionality, and non-RT RIC optimization.
[0066] Further, an O-CU (Open Central Unit) is a logical node hosting RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), and PDCP (Packet Data Convergence Protocol). The O-CU is a disaggregated O-CU and includes two sub-components: O-CU-CP (316) and O-CU-UP (318). The O-CU-CP (316) is a logical node hosting the RRC and the control plane part of the PDCP. The O-CU-CP (316) supports O1, E2, F1-c, E1, X2-c, Xn-c and NG-c interfaces for interaction with other components/entities.
[0067] Similarly, the O-CU-UP (318) is a logical node hosting the user plane part of the PDCP and the SDAP and uses O1, E1, E2, F1-u, X2-u, NG-u and Xn-u interfaces. The O-DU (320) is a logical node hosting RLC/MAC (Medium access control)/High-PHY layers based on a lower layer functional split and supports O1, E2, F1-c, F1-u, OFH CUS–Plane and OFH M-Plane interfaces.
[0068] Further, the O-RU (322) is a logical node hosting Low-PHY layer and RF (Radio Frequency) processing based on a lower layer functional split. This is similar to 3GPP’s “TRP (Transmission And Reception Point)” or “RRH (Remote Radio Head)” but more specific in including the Low-PHY layer (FFT/iFFT, PRACH (Physical Random Access Channel) extraction). The O-RU (322) utilizes OFH CUS–Plane and OFH M-Plane interfaces.
[0069] The O-Cloud (312) is a collection of physical RAN nodes (that host various RICs, CUs, and DUs), software components (such as operating systems and runtime environments) and the SMO (302), where the SMO (302) manages and orchestrates the O-Cloud (312) from within via O2 interface.
[0070] Now referring to the various interfaces used in the ORAN (300) as mentioned above.
[0071] The O1 interface is element operations and management interface between management entities in the SMO (302) and O-RAN managed elements, for operation and management, by which FCAPS (fault, configuration, accounting, performance, security) management, Software management, File management shall be achieved. The O-RAN managed elements include the Near-RT RIC (314), the O-CU (the O-CU-CP (316) and the O-CU-UP (318)), the O-DU (320), and the O-RU (322). The management and orchestration functions are received by the aforesaid O-RAN managed elements via the O1 interface. The SMO (302), in turn, receives data from the O-RAN managed elements via the O1 interface for AI model training.
[0072] The O2 interface is a cloud management interface, where the SMO (302) communicates with the O-Cloud (312) it resides in. Typically, operators that are connected to the O-Cloud (312) can then operate and maintain the O-RAN (300) with the O1 or O2 interfaces.
[0073] The A1 interface enables the communication between the Non-RT RIC (402) and the Near-RT RIC (314) and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT RIC (314).
[0074] The E1 interface connects the two disaggregated O-CUs i.e., the O-CU-CP (316) and the O-CU-UP (318) and transfers configuration data (to ensure interoperability) and capacity information between the O-CU-CP (316) and the O-CU-UP (318). The capacity information is sent from the O-CU-UP (318) to the O-CU-CP (316) and includes the status of the O-CU-UP (318).
[0075] The Near-RT RIC (314) connects to the O-CU-CP (316), the O-CU-UP (318), and the O-DU (320) (combinedly called as an E2 node) with the E2 interface for data collection. The E2 node can connect only to one Near-RT RIC, but one Near-RT RIC can connect to multiple E2 nodes. Typically, protocols that go over the E2 interface are control plane protocols that control and optimize the elements of the E2 node and the resources they use.
[0076] The F1-c and F1-u interfaces (combinedly an F1 interface) connect the O-CU-CP (316) and the O-CU-UP (318) to the O-DU (320) to exchange data about frequency resource sharing and network statuses. One O-CU can communicate with multiple O-DUs via F1 interfaces.
[0077] Open fronthaul interfaces i.e., the OFH CUS-Plane (Open Fronthaul Control, User, Synchronization Plane) and the OFH M-Plane (Open Fronthaul Management Plane) connect the O-DU (320) and the O-RU (322). The OFH CUS-Plane is multi-functional, where the control and user features transfer control signals and user data respectively and the synchronization feature synchronizes activities between multiple RAN devices. The OFH M-Plane optionally connects the O-RU (322) to the SMO (302). The O-DU (320) uses the OFH M-Plane to manage the O-RU (322), while the SMO (322) can provide FCAPS (fault, configuration, accounting, performance, security) services to the O-RU (322).
[0078] An X2 interface is broken into the X2-c interface and the X2-u interface. The former is for the control plane and the latter is for the user plane that sends information between compatible deployments, such as a 4G network’s eNBs or between an eNB and a 5G network’s en-gNB.
[0079] Similarly, an Xn interface is also broken into the Xn-c interface and the Xn-u interface to transfer control and user plane information respectively between next generation NodeBs (gNBs) or between ng-eNBs or between the two different deployments.
[0080] The NG-c (control plane interface) and the NG-u (user plane interface) connect the O-CU-CP (316) and the O-CU-UP (318) respectively to a 5G core network (326). The control plane information is transmitted to a 5G access and mobility management function (AMF) (330) that receives connection and session information from the user equipment and the user plane information is relayed to a 5G user plane function (UPF) (328), which handles tunnelling, routing and forwarding, for example.
[0081] In the management plane (M-Plane), the O-DU (320) and the SMO (302) are used to manage the O-RU (322) (or O-RUs), wherein the O-DU (320) and the SMO (302) use NETCONF (Network Configuration Protocol) to manage the O-RU (322). Alternatively, the O-DU (320) and other NMSs (Network Management Systems) may manage the O-RU (322) via a NETCONF client. In such a case, the SMO (302) (or the NMS) corresponds to the NETCONF client (or O1 NETCONF Client (FCAPS)) (308) while the O-RU (322) corresponds to a NETCONF server and the O-DU (320) can act as both the NETCONF client and the NETCONF server depending on models such as a hierarchical model and a hybrid model known to a person skilled in the art.
[0082] In general, NETCONF is a network management protocol defined by the Internet Engineering Task Force to manage, install, manipulate, and delete the configuration of network devices. NETCONF operations are realized on top of a Remote Procedure Call (RPC) layer using an XML (Extensible Markup Language) encoding and provide a basic set of operations to edit and query configuration on a network device. NETCONF runs primarily over Secure Shell (SSH) transport. The protocol messages are exchanged on top of a secure transport protocol. Further, NETCONF reports management information that is useful to NNMi (Network Node Manager). In terms of SDN (Software Defined Networks), NETCONF is usually referenced as a southbound API (Application Programming Interface) from an SDN controller to network agents like switches and routers due to its potential for supporting multi-vendor environments.
[0083] The 5G core network (326) may include a Network Slicing Selection Function (NSSF) (332), a Network Exposure Function (NEF) (334), a Network Function Repository Function (NRF) (336), a Policy Control Function (PCF) (338), a Unified data management (UDM) (340), a Session Management Function (SMF) (342), an Application Function (AF) (344), a Service Communication Proxy (SCP) (346) and an Authentication Server Function (AUSF) (348). The NSSF (332), the NEF (334), the NRF (336), the PCF (338), the UDM (340), the SMF (342), the AF (344), the SCP (346) and the AUSF (348) may communicate with a data network (350) using various interfaces (e.g., N4, N5, N7, N8, N10, N11, N12, N13, N14, N15, N16, N17, N22, N24, N27, N31 or the like).
[0084] FIG. 4 illustrates a hybrid ANR in the O-RAN architecture (or RAN or system) (300) to manage a plurality of neighbour cells (354b, 354c, 354d) of each target cell, according to the present disclosure. The various elements and functions of the O-RAN system/architecture (or RAN or system) (300) are already explained in FIG. 3.
[0085] The Non-RT RIC (402) may comprise a Non-RT RIC Application such as rApp (404) connected/integrated via an R1 interface. The rApp is a modular microservice and an independent software plug-in to the Non-RT RIC (402) deployed to provide functional extensibility to the ORAN by third parties. That is, the Non-RT RIC may provide different functionalities by using programmable modules as rApp(s), from different operators and vendors. There may be one or more rApps (404) in the Non-RT RIC (402). Generally, the services delivered by the Non-RT RIC are composed of the rApp(s). With the Non-RT RIC, the rApp(s) may be designed to provide granular service assurance and may improve the quality-of-experience wherever needed.
[0086] The Near-RT RIC (314) may host one or more xApps (406) that use E2 interface to collect near real-time information and provide value added services. An xApp is an independent software plug-in to the Near-RT RIC (314) to provide functional extensibility to the RAN by third parties. The Near-RT RIC can be provided different functionalities by using programmable modules as xAPPs, from different operators and vendors.
[0087] Referring to FIG. 4, each E2 node (could be DU or CU (512)), preferably the CU (512), may capture radio signal quality measurements from the plurality of user equipments (UEs) (324a1, 324a2, 324a3) associated with a target cell. The radio signal quality measurements may also be associated with each of the plurality of neighbour cells (354b, 354c, 354d) of the target cell. The target cell may be any of the plurality of neighbour cells (354b, 354c, 354d). For instance, if a cell (354b) acts as the target cell, then the neighbour cells will be 354c, 354d. Similarly, if a cell (354c) acts as the target cell, then the neighbour cells will be 354b, 354d and so on so forth. The CU (512) may report the radio signal quality measurements for all subscribed target cells to at least one xApp (406) that is in connection with the Near-RT RIC (314), wherein the CU (512) is in connection with the Near-RT RIC (314) over the E2 interface. The plurality of neighbour cells (354b, 354c, 354d) may be ranked and labelled by the at least one xApp (406) based on the radio signal quality measurements associated with each of the plurality of neighbour cells, wherein the ranking of the plurality of neighbour cells (354b, 354c, 354d) may be done by assigning a rank to each of the plurality of neighbour cells (354b, 354c, 354d) based on calculation of the radio signal quality for each of the plurality of neighbour cells (354b, 354c, 354d). The labelling may be done using machine learning or any other suitable automated process. For example purposes, only three neighbour cells have been shown, however there may be more or less than three neighbour cells.
[0088] Further, the CU (512) may capture a handover performance from each target cell, wherein the handover performance may be associated with the target cell and with each of the plurality of neighbour cells (354b, 354c, 354d) of the target cell. The handover performance may be defined by one or more of a number of attempted handovers between each of the plurality of neighbour cells and the target cell and a number of successful handovers between each of the plurality of neighbour cells and the target cell. The CU (512) may report the handover performance of all subscribed cells to at least one rApp (404) in connection with the Non-RT RIC (402) within the SMO (302), wherein the CU (512) is in connection with the SMO (302) over the O1 interface. The at least one rApp (404) may create a policy and send the policy to the at least one xApp (406) in connection with the Near-RT RIC (314) over the A1 interface. The policy may also be referred to as an A1 NR policy or A1 policy. Subsequently, based on the ranking and the policy, the at least one xApp (406) in connection with the Near-RT RIC (314) may take and manage an action, wherein the manage action may be associated with the plurality of neighbour cells (354b, 354c, 354d). The manage action may comprise adding a cell to the plurality of neighbour cells when the cell is identified as a good neighbour, wherein the good neighbour is determined based on at least one of a radio signal quality information, a radio signal quality threshold, and priority of each of the plurality of neighbour cells. Alternatively, the manage action may comprise rearranging priorities of each of the plurality of neighbour cells (354b, 354c, 354d) based on the ranking. Alternatively, the manage action may comprise removing a cell from the plurality of neighbour cells when the cell is identified as a bad neighbour, wherein the bad neighbour is so labelled based on at least one of a handover performance information derived from attempted handovers, a handover failure information, a handover successful information, an attempted handovers threshold, a handover success ratio, and a handover success ratio threshold. The above details are further explained below using some parameters and use cases.
[0089] That is, each E2 node (could be DU or CU) reports its NRT and aggregated ANR reports from its UE(s) (324a1, 324a2, 324a3, 324b, 324c, 324d) for each cell (354a, 354b, 354c, 354d) to the Near-RT RIC (314) on a subscription basis. The Near-RT RIC (314)/ANR-xApp (406) keeps its version of NRT for each cell in its Radio-Network Information Base (R-NIB). The ANR-xApp (interchangeably “xApp”) (406) may maintain an “infinite-size” (e.g., n*Max_E2node_NRT_Size, n = 2, 3, …) NRT sorted by latest RSRPs reported for the neighbours in descending order but update the E2 node with only top m neighbours determined by Max_E2node_NRT_Size (=16 intraFreqNeighCells by 3GPP standard) and other parameters.
[0090] In an example, for a particular cell, top Max_E2node_NRT_Size neighbours in the NRT in the Near-RT RIC (314) and NRT in the E2 node may be different, but they tend to converge somehow over the time. The temporal discrepancy in NRTs may include different RSRP metrics used in the xApp (406) and the E2 node, e.g., if short-term average RSRP is used or not, different thresholds used by the xApp (406) and the E2 node, impact from the neighbour update decision of the rApp (404) and possible vendor specific mechanism for NRT update in the E2 node.
[0091] Further, the ANR-xApp (406) may modify its NRTs and send the modification to the relevant E2 node(s) via an E2 NR control. A control message may contain a list of neighbours to be added and/or removed. It may also contain a subset of the Near-RT RIC NRT, which lists the top m neighbours, depending on the level of support from the E2 node. The NR control from the near-RT RIC acts as one type of input for the E2 node to update its NRT, which need to be supported by the E2 node. The ANR-xApp (406) may also modify the NRTs in the near-RT RIC via an A1 policy, after which the ANR-xApp (406) sends the modification to the relevant E2 node(s) via the E2 NR control.
[0092] Further, it is well understood that removing a neighbour also includes the notion that the neighbour relation is retained and marked so that it is not considered for handovers.
[0093] Similarly, the non-RT RIC (402) does not keep its own version of NRTs since this may lead to explosion of NRT related data in the non-RT RIC due to the fact that the non-RT RIC usually acts as a central controller for multiple near-RT RICs or the whole network and keeping NRTs in the non-RT RIC may also increase the complexity of the algorithm for coordination of NRTs at three different entities. Further, the NRT for each cell I in the near-RT RIC has the following fields for each neighbour j:
a) Neighbor number/index j,
b) Neighbor NR-CGI,
c) Neighbor PCI,
d) RSRP_anr (j),
e) Timestamp_added, when this neighbor was added,
f) Removed_by_rApp (1 or 0, set when xApp receives neighbor deletion from rApp for this neighbor), and
g) Timestamp_removed, when Removed_by_rApp was set to 1
[0094] Each UE (324a1, 324a2, 324a3, 324b, 324c, 324d) is configured by its serving gNB (or serving cell, for example 354a, 354b, 354c, 354d). In order to report PCI, NR-CGI, RSRP measurements or reporting parameters (reporting threshold, reporting interval, number of reports, whose values are TBD) of each neighbor cell (354b, 354c, 354d) may be triggered by a pre-defined event, which may be an A4 event or other event, e.g., A3 event or other TBD event. If the reporting interval is in 100s ms, then a short-term average of RSRP measurements can be used to evaluate a neighbor (or neighbour).
[0095] The E2 interface is established between the near-RT RIC (314) and each E2 node (e.g., gNB/CU/DU) using an E2 SETUP procedure. The ANR-xApp (406) in the near-RT RIC (314) subscribes to the NRT and ANR report from each E2 node over the E2 interface. The ANR report for cell i contains a 3-tuple (e.g., NR-CGI, PCI and RSRP(s)) for each neighbor cell (354b, 354c, 354d) that the UEs (324a1, 324a2, 324a3), who are camped on to cell i, has visibility to. After the defined event triggers at the UE (324a1, 324a2, 324a3), the E2 node receives the UE reports (e.g., NR-CGI, PCI, RSRP measurements) for each neighbor cell (354b, 354c, 354d). If the reporting interval is reasonably small (e.g., in 100s ms), the E2 node may perform an optional short-term average of the RSRP measurements reported by the UE (324) for the neighbor cell(s) (354b, 354c, 354d) the UE (324) sees. The E2 node sends an ANR report for the serving cell (354a) to the near-RT RIC (314), where the RSRP(s) may be a short-term averaged RSRP value or a raw RSRP measurement value or a list of raw RSRP measurement values.
[0096] The ANR-xApp (406) receives the ANR report from E2 node. For each neighbor cell j in the ANR report, the ANR-xApp (406) performs an optional short-term average of the RSRP measurements to get a single RSRP value if the report contains a list of RSRP measurements for that neighbor cell and the reporting interval is reasonably small (e.g., in 100s ms), or gets the first or the only RSRP value otherwise. The resulted RSRP is named as RSRP_anr(j).
[0097] The ANR-xApp (406) puts neighbor cell j in the NRT of the serving cell (354a) specified in the E2 ANR report if RSRP_anr(j) > NRT_ADD_Threshold and j is not already in the NRT of the serving cell (354a) and the table size is less than maximum size.
[0098] Further, the ANR-xApp (406) sends an NR control message to the E2 node of the serving cell (354a) over the E2 interface, listing all the neighbors that need to be updated by the E2 node for the serving cell, if there is any neighbor change. Optionally, the ANR-xApp (406) may send top m neighbors in its NRT.
[0099] If the E2 node receives the NR control message from the Near-RT RIC (314), the E2 node may try to update the neighbor(s) in its NRT based on the NR Control message. Each E2 node may be configured to report a PM data for each cell i to the SMO (302) over the O1 interface. The PM data may be, for example, but not limited to, number of attempted HOs to each neighbor j over a last T seconds, HO_attempted (j), Number of successful HOs to each neighbor j over the last T seconds: HO_successful (j), and T >> RSRP reporting interval.
[00100] Further, the ANRE-rApp (interchangeably “rApp”) (404) in the non-RT RIC (402) subscribes to the PM data at the SMO (302). When the SMO (302) receives the PM data, the SMO (302) sends the PM data to the Non-RT RIC (402), which forwards the data to the ANRE-rApp (404). The ANRE-rApp (404) receives the PM data, i.e., a list of (HO_attempted (j), HO_successful (j)) pairs for cell i. For each neighbor j, the ANRE-rApp (404) marks j as a removed (bad) neighbor of cell i if HO_attempted (j) > HO_attempted_threshold and HO_successful (j) / HO_attempted (j) < HO_min_S_ratio.
[00101] Alternatively, the ANRE-rApp (404) sends an A1 neighbor relation (NR) policy to the ANR-xApp (406), listing all the bad neighbors that need to be removed by the ANR-xApp (406), if there is any bad neighbor for cell i. When the ANR-xApp (406) receives the A1 NR policy from the ANRE-rApp (404) for cell i, the ANR-xApp (406) marks the neighbor(s) on the bad neighbor list as “removed” in RIC NRT for cell i. Further, the ANR-xApp (406) sends the NR control message over the E2 interface to the E2 node of the serving cell i, listing all the neighbors that need to be updated (removed or added) by the E2 node for cell i.
[00102] We also allow for the architectural alternatives where ANR xApp is not present and ANRE- rApp interfaced directly with E2 nodes, or even if ANR xApp is present and still ANRE- App interfaced directly with E2 nodes.
[00103] The E2 node tries to update its NRT for cell i based on the E2 NR control message. Instead of sending a list of neighbors that the E2 node should add or remove, the xApp (406) may send its entire NRT or the top M neighbors to the E2 node. This is a more robust way for updating NRT in the E2 node since the impact due to the loss of a control message may be reduced by a following control message, but this approach also requires more process by the E2 node.
[00104] If RSRP for an existing neighbor is higher than the one in NRT for the same neighbor (due to report from a UE), the O-RAN system (or system) reflects that in NRT, i.e., update the RSRP in the NRT.
[00105] If the UE reports a neighbor with RSRP higher than the lowest RSRP in the NRT and the NRT table is at the full capacity, the system replaces the lowest RSRP neighbor with the new one.
[00106] The system maintains an “infinite-size” (e.g., 2*Max_E2node_NRT_Size) NRT in the xApp (406) sorted by latest RSRP reported for a given neighbor, but the system updates the E2 node with only the top Max_E2node_NRT_Size neighbors.
[00107] The xApp (406) removes a neighbor due to input from the rApp (404), but then the xApp (406) adds back that neighbor. The xApp (406) keeps a timestamp for a “removed” (marked as removed in the “infinite-size” NRT) neighbor for when it was “removed”, and consider adding the same neighbor back only after certain elapsed time. Further, the rApp (404) may observe HO failures for a neighbor that is not in the current NRT at the xApp (406) (due to the momentary mismatch between the NRTs at the E2 node and at the xApp).
[00108] Further, when the xApp (406) processes the ANR reports from the E2 nodes, if certain time has elapsed since the timestamp for a neighbor of a cell, the neighbor of the cell will be removed from the RIC NRT, which allows the near-RT RIC to add this neighbor back again to the RIC NRT and the E2 node NRT if the requirement to do so is met. Hence, the ping-pong behavior can be avoided.
[00109] The rApp (404) and the xApp (406) process, respectively, their input data (e.g., HO measurement data for rApp (404) and the ANR reports for the xApp (406)) in a batch fashion periodically by dividing time into time periods. At end of each period, triggered by a timer, the rApp (404) or the xApp (406) process all the data received in that period and run its neighbor update techniques. This results in more efficient use of computing and networking resources and more flexible in granularity of the processing and thus provide more robust data in different scenarios, where for example the E2 node(s) (804) may not support all the granularities the xApp needs for the data.
[00110] Based on the proposed solution, when ANR-xApp (406) receives the A1 NR policy from the ANRE-rApp (404) for cell i, the ANR-xApp (406) marks the neighbor(s) on the “removed” neighbor list as “removed” in RIC NRT for cell i and records the current time as the timestamp for that neighbor. A neighbor marked as “removed” (removed by the rApp (404)) in the RIC NRT will be treated as blocked and will not be added to the NRT in the E2 node (804).
[00111] The rApp(s) (404) improves neighbor relations using QoS/KPI (Quality of Service / Key Performance Indicator) measurements. The xApp(s) (406) creates neighbor relation tables using the UE measurements. The RIC enables a cost effective and efficient approach for implementing the hybrid ANR for the O-RAN system (300) using the neighbor relations and neighbor relation tables.
[00112] FIG. 5 illustrates an example RIC solution architecture (500), according to the present disclosure. The operations and functions of the CU (or O-CU) (512), the RU (or O-RU) (322), the DU (or O-DU) (320), the non-RT RIC (402), the near-RT RIC (314), the rApp(s) (404) and the xApp(s) (406) are already explained in connection with FIG. 3 and FIG. 4. The RIC solution architecture may include a BSS (Business Support System) infrastructure (502), an OSS (Operation Support System) & NOC (Network Operations Center) infrastructure (504), a global orchestrator (506), a RAN domain orchestrator (508), a virtual / container infrastructure (516), a commercial off-the-shelf (COTS) infrastructure (514) and a RAN O&M (Operation and management) platform (510). The COTS infrastructure supports support IEEE 1588v2 Precise Time Protocol (PTP), so as to improve the time synchronization accuracy of minimum level (around 65ns) for carrier aggregation in the O-RAN system (300). The RAN domain orchestration (508) automates an end-to-end service lifecycle from planning and design to activation, optimization and assurance across the entire multivendor Open vRAN domain.
[00113] In the RIC solution architecture, the vRAN domain orchestration solution brings together the orchestration, OSS and analytics functions needed to fully automate all aspects of the RAN domain from planning and design to activation, assurance and optimization. The vRAN domain orchestration solution collects the data from the BSS infrastructure (502), the OSS & NOC infrastructure (504), the global orchestrator (506), the RAN domain orchestrator (508), the virtual/container infrastructure (516) and the COTS infrastructure (514). The BSS infrastructure (502) provides ‘BSS as a service’, making Communication Service Providers (CSPs) focus on creating, launching new services, and improving customer experience. The RAN O&M platform (510) supports near-RT RIC management, CU management, DU management and RU management.
[00114] FIG. 6 illustrates a near-RT RIC architecture (600), according to the present disclosure. Referring to FIG. 6, the near-RT RIC architecture (600) may include a messaging infrastructure (608) and support an xApp on-boarding function, an xApp subscription management function, a policy control function, a RAN fault & telemetry streaming function, a self-manageability function, a platform manageability integration function and an open source integration for a stream reporting function.
[00115] The near-RT RIC architecture (600) also includes an E2 terminator (610), an RNIB & UEIB, the xApp(s) (406), an SDK/API (Software Development Kit/Application Programming Interface) (602), an O1 terminator (604), an A1 terminator (606), ELK & Grafana, RMR Library, REDIS dBaaS, Docker & Helm and Kubernetes Infrastructure. Generally, a Kubernetes infrastructure is a combination of resources (including servers, physical or virtual machines, cloud platforms and more) that supports a Kubernetes environment. The Docker & Helm is an application package manager which can be used to run on top of Kubernetes. REDIS dBaaS is a fully managed in-memory NoSQL database, easily deployed in our integrated environment. The ELK & Grafana supports the data querying and analysis.
[00116] FIG. 7 illustrates an example non-RT-RIC-MVP (Minimum viable plan) architecture (700), according to the present disclosure. The non-RT-RIC-MVP architecture (700) may include an application framework having the rApp(s) (404) such as, but not limited to, rApp1 (404a), rApp2 (404b), rApp3 (404c), the non-RT RIC (402), the near-RT RIC (314), a data source (702) and an ODL SB1 adaptor (704). The operations and functions of the application framework, the Non-RT RIC (402) and the Near-RT RIC (314) are already explained in connection with FIG. 3 to FIG. 4. A policy framework (residing in the non-RT RIC (402)) may include a policy management service, a policy engine, and a policy catalog. The policy management service, the policy engine, and the policy catalog are used for handling the policy management function. The policy management function corresponds to configuration of service, resource and platform related policies. The policy definition, execution, enforcement capability are exposed through the rApp(s) (404). The data source (702), fetching information from the RAN (300), may include an enrich information DB, a software defined network-radio (SDN-R) and a DCAE (Data Collection, Analytics and Events). The SDN-R may be implemented as the data source for the policy framework. The DCAE may be utilized for VES (Virtual Network Function (VNF) Event Stream) collection, data brokerage, and data source for policy framework. The non-RT RIC-MVP architecture (700) may be integrated with southbound systems through A1 interfaces.
[00117] FIG. 8 is a sequence diagram illustrating a hybrid automatic neighbor relations in the disaggregate 5G RAN/O-RAN, according to the present disclosure.
[00118] At step 1, the E2 nodes (804) send the configuration for the PCI, the NR-CGI, the RSRP report, the trigger event and the reporting parameter to the UE (324). The reporting parameter may be, for example, but not limited to, a reporting threshold, a reporting amount, and a reporting interval. At step 2, the E2 nodes (804) send the E2 setup request to the near-RT RIC (314). At step 3, the ANR xApp (406) sends the subscription for the ANR report and NRT. At step 4, the near-RT RIC (314) sends the subscription of the ANR report (e.g., NR-CG, PCI, RSRP or the like) and NRT to the E2 nodes (804).
[00119] At step 5, the ANRE- rApp (404) sends the subscription of the HO data to the non-RT RIC (402). At step 6, the non-RT RIC (402) sends the HO data collection information to an orchestrator (802). At step 7, the orchestrator (802) sends a request to create the measurement job (i.e., number of attempts HOs and successful HOs over last T seconds) to the E2 node(s) (804). At step 8, the orchestrator (802) subscribes to the E2 node (804) for an E2 node measurement data notification. At step 9, the orchestrator (802) sends the measurement data collection creation results to the non-RT RIC (402). At step 10, the non-RT RIC (402) sends the subscription results to the ANRE- rApp (404).
[00120] The event (e.g., A4 event, the A3 event or the like) is triggered at UE (324). At step 11, the UE (324) sends the NR-CGI, PCI, and RSRP measurements for the neighbor cell to the E2 node (804). The E2 node (804) updates the NRT. The E2 node (804) may perform the short-terms average on RSRPs optionally.
[00121] At step 12, the E2 node (804) sends the report corresponding to the NRT to the near-RT RIC (314). At step 13, the E2 node (804) sends the report (e.g., NR-CGI, PCI, and RSRP for each neighbor cell of a serving cell) to the near-RT RIC (314). At step 14, the near-RT RIC (314) sends the ANR report and E2 Node NRT to the ANR xApp (406). Optionally, the ANR xApp (406) may perform the short-terms average on RSRPs and run the ANR techniques to update the neighbor table.
[00122] At step 15, the ANR xApp (406) sends the neighbor relation control to the near-RT RIC (314). At step 16, the near-RT RIC (314) sends the NR control (nbrs added or removed or entire nbrs list) to the E2 node(s) (804). The E2 node(s) (804) updates the NRT. At step 17, the E2 node(s) (804) sends, via the E2 interface, the report (NRT) to the near-RT RIC (314). At step 18, the near-RT RIC (314) sends the E2nodeNRT to the ANR xApp (406). At step 19, the E2 node(s) (804) sends the data collection (e.g., HO attempts successful Hos or the like) to a collector ([HV-] VES/File Collector (FCAPS)) (310).
[00123] At step 20, the collector (310) sends a request for retrieval of HO (handover) data to the non-RT RIC (402). At step 21, the non-RT RIC (402) sends the retrieval of HO data to the ANRE- rApp (404). The collector (310) executes the ANR techniques. At step 22, the collector (310) sends the neighbor relation policy to the non-RT RIC (402). At step 23, the non-RT RIC (402) sends the NR policy (e.g., nbrs to be removed) to the near-RT RIC (314) via A1 interface. At step 24, the near-RT RIC (314) sends the NR policy (nbrs to be removed) to the ANR xApp (406). After receiving the NR policy, the ANR xApp (406) updates the neighbor table. At step 25, the ANR xApp (406) sends the NR control information to the Near-RT RIC (314).
[00124] At step 26, the Near-RT RIC (314) transmits the NR control (nbrs added or removed or entire nbrs list) to the E2 node(s) (804). Accordingly, the E2 node(s) (804) updates the NRT. At step 27, the E2 node(s) (804) sends the report (NRT) to the Near-RT RIC (314) via the E2 interface. At step 28, the Near-RT RIC (314) sends the E2nodeNRT to the ANR xApp (406).
[00125] FIG. 9 is an example flowchart (900) illustrating a method, implemented by the rApp (404), for handling the hybrid automatic neighbor relations, according to the present disclosure.
[00126] At 902, the method includes determining that a periodic timer is expired. At 904, the method includes fetching the HO measurement data since last processing period. At 906, the method includes combining/pre-processing the data for each neighbor of each service cell. At 908, the method includes detecting if service (or servicing) cell i is available in the report. If no more cell is available then, at 924, the method includes sending the A1 NR policies to the corresponding ANR xApps (406). At 910, the method includes detecting NBR for each neighbor j of i. If no nbr is left, at 918, the method includes determining any removed (or bad) neighbor j for the cell. If a removed (or bad) neighbor j exists for the cell then, at 920, the method includes creating the NR policy for the cell that is transmitted to 922. If the removed (or bad) neighbor j does not exist for the cell, then the method jumps to 922. At 922, outputs of 918 and 922 are aggregated and sent back to 908.
[00127] At 912, the method includes determining whether HO_attempted (j) > HO_attempted_threshold and HO_successful (j) / HO_attempted (j) < HO_min_S_ratio. If the above condition is true (i.e., HO_attempted (j) > HO_attempted_threshold and HO_successful (j) / HO_attempted (j) < HO_min_S_ratio) then, at 914, the method includes marking the neighbor cell j as “removed” which is further forwarded at 916. If the above condition is false, then the method jumps to 916. At 916, outputs of 912 and 914 are aggregated and sent back to 910.
[00128] FIG. 10 is a flowchart (1000) illustrating a method, implemented by the xApp (406), for handling the hybrid automatic neighbor relations and A1 policy handling, according to the present disclosure. At 1002, the method includes receiving the A1 NR policy from the ANR xAPP (406). At 1004, the method includes detecting if each service (or servicing) cell i is in the policy. If no more cell is in the policy, at 1014, the method includes sending the E2 NR control messages to the E2 node(s) (804). At 1006, the method includes detecting if neighbor of cell i is available for each neighbor j of cell i. If no more neighbor of cell is available, at 1012, the method includes creating the E2 NR control for cell i. At 1008, the method includes marking the neighbor j as “removed” in the RIC NRT. At 1010, the method includes adding a timestamp_removed in the neighbor j.
[00129] FIG. 11 is a flowchart (1100) illustrating a method, implemented by the xApp (406), for handling the hybrid automatic neighbor relations, E2 and ANR report handling, according to the present disclosure.
[00130] At 1102, the method includes determining that the periodic timer is expired. At 1104, the method includes fetching the HO measurement data since the last processing period. At 1106, the method includes determining availability of ANR report(s). If the method determines that there is no more ANR report then, the method proceeds to 1120 and checks at 1122 for each nbr in RIC NRT whether the Nbr marked as “removed” and certain time threshold has elapsed since timestamp_removed. If the Nbr marked as “removed” and certain time threshold has elapsed since timestamp_removed then, at 1124, the method includes removing the nbr from the RIC NRT and proceeded to 1126. If not, the method proceeds to 1126. At 1126, the method aggregates outputs of 1122 and 1124.
[00131] Similarly, if the method determines that there is ANR report(s) available then, the method proceeds to 1108. At 1108, the method includes determining whether neighbor j of the cell i has multiple RSRP measurements in a single event (e.g., A4 event or the like) measured by the UE (324) and determine that the event reporting interval lowest RSRP in the NRT. If the RSRP of nbrj is greater than the lowest RSRP in the NRT then, at 1156, the method includes removing the loweat RSRP neighbor. At 1158, the method includes inserting nbr J in the RIC NRT in the sorted order of RSRP. If the RSRP of nbrj is less than the lowest RSRP in the NRT then, at 1154, the method includes ignoring the report for nbr j. At 1160, the method aggregates outputs of 1154 and 1158 and at 1162, the method aggregates outputs of 1160 and 1150.
[00136] FIG. 12 is a flowchart (1200) illustrating a method for creating the E2 NR control, according to the present disclosure.
[00137] At 1202, the method includes obtaining the sorted valid RIC NRT for cell i (i.e., nbrs in RIC NRT for the cell i with RSRP >RSRP threshold and not marked as “removed”). At 1204, the method includes determining that e2c_nbr_list_size=min(max_E2node_NRT_size and valid_ric_nrt_size). At 1206, the method includes obtaining the E2 control nbr list (first e2c_nbr_list_size nbrs in the valid RIC NRT). At 1208, the method includes determining whether the E2 control list is changed since last report. If the E2 control list is changed since the last report then, at 1210, the method includes creating E2 control for cell i (list of nbrs to be added/removed or entire E2 control nbr list) and jumps to 1212. If the E2 control list is not changed since the last report then the method jumps to 1212. At 1212, the method aggregates outputs of 1208 and 1210.
[00138] FIG. 13 is a flowchart (1300) illustrating a method, implemented by the xApp (406), for handling the E2 node NRT, according to the present disclosure. At 1302, the method includes receiving the E2 node NRT for the cell i. At 1304, the method includes determining a delta information (i.e., differences) between the RIC NRT and E2 node NRT. At 1306, the method includes treating the delta information as acknowledgement to the E2 NR control.
[00139] FIG. 14 is a flowchart (1400) illustrating a method for managing (a table) of the plurality of neighbour cells (354b, 354c, 354d) of each target cell in the RAN (300). It may be noted that in order to explain the flowchart (1400), references will be made to the elements described in FIG. 3 to FIG. 13. As stated earlier, the target cell may be any of the plurality of neighbour cells (354b, 354c, 354d). For instance, if the cell (354b) acts as the target cell, then the neighbour cells will be 354c, 354d. Similarly, if the cell (354c) acts as the target cell, then the neighbour cells will be 354b, 354d and so on so forth.
[00140] At step (1402), the method includes capturing and reporting, by the central unit (CU) (512) associated with each target cell, the radio signal quality associated with each of the plurality of neighbour cells (354b, 354c, 354d) of the target cell based on signal strength measurements reported by the plurality of user equipments (UEs) (324a1, 324a2, 324a3) to the target cell and the handover performance between the target cell and each of the plurality of neighbour cells (354b, 354c, 354d). The handover performance may be defined by one or more of the number of attempted handovers between each of the plurality of neighbour cells and the target cell and the number of successful handovers between each of the plurality of neighbour cells and the target cell.
[00141] At step (1404), the method includes ranking and labelling the plurality of neighbour cells (354b, 354c, 354d) based on the radio signal quality associated with each of the plurality of neighbour cells, wherein ranking the plurality of neighbour cells (354b, 354c, 354d) may comprise assigning a rank to each of the plurality of neighbour cells based on calculation of the radio signal quality for each of the plurality of neighbour cells.
[00142] Further, at step (1406), the method includes taking and managing an action based on the ranking and labelling, wherein the action is associated with the plurality of neighbour cells (354b, 354c, 354d). The managing action may comprise adding a cell to the plurality of neighbour cells when the cell is identified as a good neighbour, wherein the good neighbour is determined based on at least one of the radio signal quality information, the radio signal quality threshold, priority of each of the plurality of neighbour cells. Alternatively, the managing action may comprise rearranging priorities of each of the plurality of neighbour cells (354b, 354c, 354d) based on the ranking. Alternatively, the managing action may comprise removing a cell from the plurality of neighbour cells when the cell is identified as a bad neighbour, wherein the bad neighbour is so labelled based on at least one of the handover performance information derived from attempted handovers, the handover failure information, the handover successful information, the attempted handovers threshold, the handover success ratio, the handover success ratio threshold, or the like.
[00143] Advantageously, the method may be used to implement the ANR function in the O-RAN architecture for supporting high interoperability in a disaggregated multi-vendor environment which follow O-RAN paradigms. The method may be used to implement policy-based features to reduce operational complexity. The method may also be used to manage the NRT constraint so that maximum neighbour accommodates in the O-RAN architecture.
[00144] The various actions, acts, blocks, steps, or the like in the flow chart and sequence diagrams may be performed in the order presented, in a different order or simultaneously. Further, in some implementations, some of the actions, acts, blocks, steps, or the like may be omitted, added, modified, skipped, or the like without departing from the scope of the present disclosure.
[00145] The embodiments disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.
[00146] It will be apparent to those skilled in the art that other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention. While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above-described embodiment, method, and examples, but by all embodiments and methods within the scope of the invention. It is intended that the specification and examples be considered as exemplary, with the true scope of the invention being indicated by the claims.
[00147] The methods and processes described herein may have fewer or additional steps or states and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied in, and fully or partially automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in specialized computer hardware.
[00148] The results of the disclosed methods may be stored in any type of computer data repositories, such as relational databases and flat file systems that use volatile and/or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM and/or solid-state RAM).
[00149] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
[00150] Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general-purpose processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
[00151] The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.
[00152] Conditional language used herein, such as, among others, “can”, “may”, “might”, “e.g.” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain alternatives include, while other alternatives do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more alternatives or that one or more alternatives necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular alternative. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
[00153] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain alternatives require at least one of X, at least one of Y, or at least one of Z to each be present.
[00154] While the detailed description has shown, described, and pointed out novel features as applied to various alternatives, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the scope of the disclosure. As can be recognized, certain alternatives described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.