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

“NETWORK MANAGEMENT IN OPEN-RADIO ACCESS NETWORKS”

APPLICANT:

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 communication and networks, and more specifically relates to techniques for managing and coordinating neighbor relations and physical cell identifier optimization in an Open Radio Access Network (O-RAN).

BACKGROUND
[0002] Automatic neighbor relations (ANR) and physical cell identifier optimization (PCIO) are two fundamental aspects in a mobile wireless scenario. The ANR creates cell neighbor relations, which are enhanced by an ANR-E (Automatic neighbor relation-enhanced) using KPI/QoS (Key Performance Indicator/Quality of Service) information, and which is an input to the PCIO. Traditionally, this is a sequential/serial operation that means if the PCIO does not provide feedback to the ANR or the ANR-E, the same can be problematic sometime. The PCIO is fundamentally a graph coloring problem, which is NP (non-deterministic polynomial-time) hard (meaning that the complexity of solution grows exponentially with respect to number of cells). Consequently, it is sometimes hard to find optimal solutions, or may sometimes cause infeasibility (i.e., unable to find even a solution) or may need to lock neighbor tables, when PCI allocations are being optimized.
[0003] Therefore, it is necessary for the ANR or the ANR-E to know information (in addition to the KPI/QoS information) so that the cell neighbor relations can be tweaked to drive to acceptable PCI allocations. Furthermore, it is possible that poor KPI/QoS is a consequence of PCI conflicts, and the PCIO can obviate the need for the ANR or the ANR-E to make changes in the cell neighbor relations. Some of the prior art references are given below in the same context, where:
[0004] US20180270671A1 discloses a method implemented on a base station to determine one or more neighbour PCI values. The base station determines the PCI values based on a received UE-ANR report or a Neighbour Relation Table (NRT).
[0005] US20210325550A1 discloses a method for managing neighbor relations and coordinating physical cell identifier (PCIs) using a received geolocation information.
[0006] A non-patent literature entitled “Quasi-Quantum PCI optimization in 5G Networks” discloses coordination of cell identifiers and cell neighbor lists for mobility management or interference management. A quasi-quantum-based approach for resource management in wireless networks, and in particular explores the automated Physical Cell-Id (PCI) assignment SON optimization problem for mobility management in emerging cellular or WiFi or hybrid cellular+WiFi networks.
[0007] Yet another non-patent literature entitled “O-RAN based proactive ANR optimization” discloses a new approach for ANR optimization for the next generation networks using O-RAN defined open interfaces and architectural platform. This approach leverages O-RAN architecture that supports implementation of intelligent models and proposes a Machine Learning (ML) based proactive ANR optimization technique to improve gNodeB (gNB) handovers.
[0008] While the prior arts discuss various techniques for managing and coordinating neighbor relations and physical cell identifier optimization, they still have deficiencies like infeasibility of optimal PCI allocations due to which operators are forced to live with suboptimal allocations, call/session drops, poor RACH (random-access channel) success rates, insufficient throughput, lack of network operation robustness due to not proactively accounting for the possibility that a PCI conflict may be the cause for poor KPI/QoS, and the possibility that the PCIO may make it unnecessary to modify the neighbor relations. In light of the above-stated discussion, there is a need to overcome the above stated disadvantages.

OBJECT OF THE DISCLOSURE
[0009] A principal object of the present disclosure is to solve the aforesaid drawbacks and provide methods, systems, devices, entity, controller, or the like for managing and coordinating neighbor relations and physical cell identifier (PCI) optimization in an Open Radio Access Network (O-RAN). That is, the principal object of the present disclosure is to develop coordination between ANR-E (Automatic Neighbor Relation-Enhanced) rApp(s) and PCI rApp(s) to make network operation more robust by taking corrective actions in a proactive manner.
[0010] Another object of the present disclosure is to reduce call/session drops, increase handover success rates and provide better throughput especially at cell edges.

SUMMARY
[0011] Accordingly, the present disclosure provides a network management method in an Open Radio Access Network (O-RAN). The network management method comprises creating cell neighbor relations for a plurality of operating cells using at least one of a key performance indicator (KPI) and quality of service (QoS) information, wherein the cell neighbor relations are created by an ANR-E (Automatic Neighbor Relation-Enhanced) module within an ANR-E rApp. The network management method further comprises assigning unique physical cell identifiers to each of the plurality of operating cells by a PCI (physical cell identifier) optimization module within a PCI rApp based on the created cell neighbor relations, wherein the ANR-E rApp and the PCI rApp are deployed in a Non-Real Time RAN Intelligent Controller (Non-RT-RIC). The network management method further comprises developing coordination between the ANR-E rApp and the PCI rApp that further comprising: modifying a neighbor relation table when PCI optimization through the PCI rApp is hitting infeasibility or taking undue time; tweaking the cell neighbor relations by the ANR-E module based on the modifications made to the neighbor relation table; and updating input to the PCI rApp based on the modifications, thereby driving optimal PCI allocations.
[0012] The neighbor relation table is modified by the ANR-E rApp upon determining that a poor QoS and KPI are a consequence of PCI conflicts, where the PCI rApp requests the ANR-E rApp to make modification in the cell neighbor relations. A policy governed trigger is sent to the ANR-E rApp to modify the cell neighbor relations when the PCI rApp is hitting infeasibility or taking undue time, which is greater than a predefined time while optimizing the PCIs. While modifying the neighbor relation table by the ANR-E rApp, the PCI rApp requests the ANR-E rApp to at least one of pause a flag and raise a flag, when a cell from the plurality of operating cells is undergoing PCI reassignment or any modifications in the cell neighbor relations as a consequence of the cell defers.
[0013] 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
[0014] 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:
[0015] FIG. 1 illustrates an overview of a general architecture of an O-RAN.
[0016] FIG. 2 illustrates the O-RAN hosting rApp(s) and xApp(s) in conjunction with FIG. 1.
[0017] FIG. 3 illustrates coordination mechanism between an ANR-E (Automatic Neighbor Relation-Enhanced) rApp and a PCI (Physical Cell Identifier) rApp in conjunction with FIG. 1.
[0018] FIG. 4 to FIG. 7 illustrate example PCI rApp – ANR-E rApp interactions.
[0019] FIG. 8 is a flow chart illustrating a network management method for the O-RAN.

DETAILED DESCRIPTION
[0020] 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 details so as not to unnecessarily obscure aspects of the invention.
[0021] 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.
[0022] 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.
[0023] The deficiencies in previous techniques (as discussed in background section) can be solved by the proposed disclosure that provides techniques for managing and coordinating neighbor relations and physical cell identifier optimization in an Open Radio Access Network (O-RAN). That is, the present disclosure provides coordination mechanism between ANR-E (Automatic Neighbor Relation-Enhanced) rApp(s) and PCI (Physical Cell Identifier) rApp(s) to make network operation more robust by taking corrective actions in a proactive manner, where the ANR-E rApp(s) and the PCI rApp(s) are joint unlike the prior arts. Unlike conventional techniques, the present disclosure helps in reducing call/session drops, increasing handover success rates and achieving better throughput especially at cell edges by implementing coordination mechanism disclosed herein.
[0024] The coordination mechanism disclosed herein provides a policy assisted coordination between the ANR-E rApp(s) and the PCI rApp(s) and drives PCI optimization (PCIO) to optimal solutions efficiently unlike prior arts. The coordination mechanism has ability to suspend ANR in an/a xApp/CU (Central Unit or O-CU) and lock neighbor tables in the CU, through policies driven via A1 interfaces (O-RAN specification), while PCI optimization is in progress. Advantageously, the coordination mechanism avoids conflicts between the neighbor relations and optimal PCI allocations. In a nutshell, the present disclosure provides a solution that iterates between two functions (i.e., between the ANR-E rApp(s) and the PCI rApp(s)) and reach an optimal solution.
[0025] Now referring to the figures, where FIG. 1 illustrates a general overview architecture of an Open-Radio Access Network (O-RAN) (100). The O-RAN (100) is a part of a telecommunications system which connects individual devices to other parts of a network through radio connections. The O-RAN (100) provides a connection of user equipment (UE) such as mobile phone or computer with a core network of the telecommunication systems. The O-RAN (100) is an essential part of access layer in the telecommunication systems which utilizes base stations (such as eNodeB, gNodeB) for establishing radio connections. The O-RAN (100) is an evolved version of prior radio access networks, makes the prior radio access networks more open and smarter than previous generations. The O-RAN (100) provides real-time analytics that drive embedded machine learning systems and artificial intelligence back-end modules to empower network intelligence. Further, the O-RAN (100) includes virtualized network elements with open and standardized interfaces. The open interfaces are essential to enable smaller vendors and operators to quickly introduce their own services or enables 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 (100) 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.
[0026] The O-RAN (100) may comprise a Service Management and Orchestrator (SMO) (can also be termed as “Service Management and Orchestration Framework”) (102), a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) (104) (act as a master controller) residing in the SMO (102), a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (106), an Open Evolved NodeB (O-eNB) (108), an Open Central Unit Control Plane (O-CU-CP) (110), an Open Central Unit User Plane (O-CU-UP) (112), an Open Distributed Unit (O-DU) (114), an Open Radio Unit (O-RU) (116), and an Open Cloud (O-Cloud) (118).
[0027] The SMO (102) is configured to provide SMO functions/services such as data collection and provisioning services of the O-RAN (100). The data collection of the SMO (102) may include, for example, data related to configuration of a wireless communication network and at least one of a plurality of user equipments (not shown in figures). That is, the SMO (102) oversees all the orchestration aspects, management and automation of O-RAN elements and resource and supports O1, A1 and O2 interfaces.
[0028] As the O-RAN (100) continues to evolve towards more open architecture, opportunities for innovation in the O-RAN space have proliferated. One of the central components within the O-RAN (100) is a RAN Intelligent Controller (RIC), which provides an open hosting platform and is responsible for controlling and optimising the RAN functions. The RIC incorporates AI/ML into its decision-making functionalities and comes in two forms: the Non-RT-RIC (104) and the Near-RT-RIC (106), which can be adapted to specific latency or control loop requirements.
[0029] The Non-RT-RIC (104) is a logical function that enables non-real-time control and optimization of the O-RAN elements and resources, AI/ML workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT-RIC (106). The Non-RT-RIC (104) (which is also an A1 interface terminator (A1 term)) is a part of the SMO Framework (102) and communicates to the Near-RT-RIC (106) using the A1 interface. The Near-RT-RIC (106) 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 E2 interface.
[0030] Non-Real Time (Non-RT) control functionality (>1s) and Near-Real Time (Near-RT) control functions (<1s, particularly 10 milliseconds to one second) are decoupled in the RIC. 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.
[0031] The O-eNB (108) is hardware aspect of a fourth generation RAN that communicates with at least one of the plurality of user equipments via wireless communication networks such as a mobile phone network. The O-eNB (108) is a base station and may also be referred to as e.g., evolved Node B (“eNB”), “eNodeB”, “NodeB”, “B node”, gNB, or BTS (Base Transceiver Station), depending on the technology and terminology used. The O-eNB (108) is a logical node that handles transmission and reception of signals associated with a plurality of cells (not shown in figures). The O-eNB (108) supports O1 and E2-en interfaces to communicate with the SMO (102) and the Near-RT-RIC (106) respectively.
[0032] Further, the O-CU (Open Central Unit or CU) (130) is a logical node hosting RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol) and PDCP (Packet Data Convergence Protocol). The O-CU (130) is a disaggregated O-CU and includes two sub-components: O-CU-CP (110) and O-CU-UP (112). The O-CU-CP (110) is a logical node hosting the RRC and the control plane part of the PDCP. The O-CU-CP (110) supports O1, E2-cp, F1-c, E1, X2-c, Xn-c and NG-c interfaces for interaction with other components/entities.
[0033] Similarly, the O-CU-UP (112) is a logical node hosting the user plane part of the PDCP and the SDAP and uses O1, E1, E2-up, F1-u, X2-u, NG-u and Xn-u interfaces.
[0034] The O-DU (114) is a logical node hosting RLC/MAC (Medium access control)/High-PHY layers based on a lower layer functional split and supports O1, E2-du, F1-c, F1-u, OFH CUS–Plane and OFH M-Plane interfaces.
[0035] The O-RU (116) 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 (116) utilizes OFH CUS–Plane and OFH M-Plane interfaces.
[0036] The O-Cloud (118) is a collection of physical RAN nodes (that host various RICs, CUs, and DUs) and software components (such as operating systems and runtime environments) where the SMO (102) manages and orchestrates the O-Cloud (118) from within via the O2 interface. The O-Cloud (118) refers to a collection of O-Cloud resource pools at one or more location and the software to manage nodes and deployments hosted on them. The O-Cloud (118) will include functionality to support both deployment-plane and management services.
[0037] Now referring to the various interfaces used in the O-RAN (100) as mentioned above.
[0038] The O1 interface is element operations and management interface between management entities in the SMO (102) 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 (106), the O-CU (the O-CU-CP (110) and the O-CU-UP (112)), the O-DU (114), the O-RU (116) and the O-eNB (108). The management and orchestration functions are received by the aforesaid O-RAN managed elements via the O1 interface. The SMO (102) in turn receives data from the O-RAN managed elements via the O1 interface for AI model training.
[0039] The O2 interface is a cloud management interface, where the SMO (102) communicates with the O-Cloud (118) it resides in. Typically, operators that are connected to the O-Cloud (118) can then operate and maintain the O-RAN (100) with the O1 or O2 interfaces.
[0040] The A1 interface enables communication between the Non-RT-RIC (104) and the Near-RT-RIC (106) and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT-RIC (106).
[0041] The E1 interface connects the two disaggregated O-CUs i.e., the O-CU-CP (110) and the O-CU-UP (112) and transfers configuration data (to ensure interoperability) and capacity information between the O-CU-CP (110) and the O-CU-UP (112). The capacity information is sent from the O-CU-UP (112) to the O-CU-CP (110) and includes the status of the O-CU-UP (112).
[0042] The Near-RT-RIC (106) connects to the O-CU-CP (110), the O-CU-UP (112), the O-DU (114) and the O-eNB (108) (combinedly called as an E2 node) with the E2 interface (i.e., E2-cp, E2-up, E2-du and E2-en respectively) 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.
[0043] The F1-c and F1-u interfaces (combinedly an F1 interface) connect the O-CU-CP (110) and the O-CU-UP (112) to the O-DU (114) to exchange data about frequency resource sharing and network statuses. One O-CU can communicate with multiple O-DUs via F1 interfaces.
[0044] 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 (114) and the O-RU (116). 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 (116) to the SMO (102). The O-DU (114) uses the OFH M-Plane to manage the O-RU (116), while the SMO (102) can provide FCAPS (fault, configuration, accounting, performance, security) services to the O-RU (116).
[0045] 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 send information between compatible deployments, such as a 4G network’s eNBs or between an eNB and a 5G network’s en-gNB.
[0046] 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.
[0047] The NG-c (control plane interface) and the NG-u (user plane interface) connect the O-CU-CP (110) and the O-CU-UP (112) respectively to a 5G core. The control plane information is transmitted to a 5G access and mobility management function (AMF) that receives connection and session information from the user equipment and the user plane information is relayed to a 5G user plane function (UPF), which handles tunnelling, routing and forwarding, for example.
[0048] FIG. 2 illustrates the O-RAN (100) hosting rApp(s) (122) and xApp(s) (124) in conjunction with FIG. 1. In addition to the explanation provided above in conjunction with FIG. 1, the SMO (102) includes a generic SMO block (102a) and a RAN operation and management (O&M) block (102b). The generic SMO block (102a) performs orchestration and service management activities and is an O2 interface terminator (O2 term). The RAN O&M block (102b) supports network commissioning, deployment of the network nodes, O&M and monitoring of the network nodes in the O-RAN (100). Further, the RAN O&M block (102b) handles the network performance evaluation and traffic analysis in the O-RAN (100) and is an O1 interface terminator (O1 term). The Generic SMO block (102a), RAN O&M block (102b) and Non-RT-RIC (104) all communicate using SMO Service Interfaces.
[0049] The O-RAN (100) further includes the rApp(s) (122) and the xApp(s) (124) that are network automation tools. The rApp(s) (122) and the xApp(s) (124) maximize the radio access network’s operational efficiency. The rApp(s) (122) and the xApp(s) (124) provide essential control and management features and functionality. The rApp(s) (122) is a specialized microservice hosted in the Non-RT-RIC (104) which communicates with the Non-RT-RIC Framework (105) through an R1 interface. The rApp(s) (122) is designed to run/execute on the Non-RT-RIC (104) to realize different RAN automation and management use cases, with control loops on a time scale of one second and longer. The xApp(s) (124) is hosted in the Near-RT-RIC (106) and optimizes radio spectrum efficiency. The Non-RT-RIC’s applications called the rApp(s) (122) communicates with the Near-RT-RIC’s counterpart applications, called the xApp(s) (124), to provide policy-based guidance. The Near-RT-RIC (106) provides policy guidance back to the Non-RT-RIC through the xApp(s) (124). The rApp(s) (122) and the xApp(s) (124) are initialized to consume network data about new cell test KPIs (key performance indicators) and provide policy-based guidance to each other for provisioning of resources for the new cell and integrating the new cell into the O-RAN (100).
[0050] Additional functionality and features of the O-RAN (100) and its components are explained below in conjunction with FIG. 3, where FIG. 3 illustrates coordination mechanism between an ANR-E (Automatic Neighbor Relation-Enhanced) rApp (122a) and a PCI (Physical Cell Identifier) rApp (122b).
[0051] The ANR-E rApp (122a) and the PCI rApp (122b) are the types of the rApp(s) (122) hosted/registered/deployed in the Non-RT-RIC (104). That is, ANR-E services and PCI optimization services are registered as the ANR-E rApp (122a) and the PCI rApp (122b) respectively within the Non-RT-RIC (104).
[0052] The ANR-E rApp (122a) has an ANR-E (or ANR) module (120) to provide the ANR-E services that creates cell neighbor relations using at least one of a key performance indicator (KPI) and quality of service (QoS) information for a plurality of operating cells (306a, 306b, 306c and so on so forth), where a cell neighbor relation (or neighbor relation) is information that a neighbor cell is a neighbor to a target cell and each target cell holds a table of detected neighbor cells which are used in connection with handovers, this table is called neighbor relation table (NRT). Similarly, the KPI describes end-to-end packet transmission latency through the radio access network (RAN), utilization, and performance, etc. and the QoS information includes speed, bandwidth, reliability, and availability etc. of the network (100). The ANR-E rApp (122a) further generates enhanced cell neighbor relations by using the ANR-E module (120), where the ANR-E module (120) determines the cell neighbor relations based on an observed handover to a target cell (could be either of 306a, 306b, 306c) from a serving cell and accordingly enhances the cell neighbor relations based on at least one of the KPI and the QoS information.
[0053] The PCI rApp (122b) comprises a PCI optimization module (126) to provide the PCI optimization services that assigns unique physical cell identifiers to each of the plurality of operating cells (306a, 306b, 306c and so on so forth) based on the created cell neighbor relations, wherein the plurality of operating cells (306a, 306b, 306c and so on so forth) is a set of cells coming under a zone in which performance information of each cell can continuously be measurable by the ANR-E module (120). The zone is a contiguous region and defines a group of cells which is deployed at different locations within the zone. Every cell requires a physical cell identifier (PCI) which is used to indicate the physical layer identity of a cell. The PCI is used for cell identity during a cell selection procedure and PCI values need to be unique among a cell and two levels of neighboring cells, and there are other criteria to reduce network performance issues. The PCI rApp (122b) facilitates PCI optimization to ensure to a great extent that neighboring cells should have different primary sequences allocated. The PCI rApp (122b) refines and assigns the PCI. The refining/cleaning of the PCIs is probably the most effective steps to improve RF performance. Good PCI assignment reduces call drops by enabling the UE to clearly distinguish one cell from another. Due to aforesaid functions of the PCI rApp (122b), the PCI rApp (122b) may also be called as PCI optimization rApp.
[0054] The Non-RT-RIC (104) develops coordination between the ANR-E rApp (122a) and the PCI rApp (122b) and a policy controlled/governed loop is formed between the ANR-E rApp (122a) and the PCI rApp (122b), where the ANR-E rApp (122a) sends a policy governed trigger to the PCI rApp (122b) and vice-versa. The policy governed triggers include information that a cell is undergoing PCI reassignment, and any modifications in the cell neighbor relations involving that cell should be deferred. Such coordination is developed by modifying a neighbor relation table when the PCI optimization through the PCI rApp (122b) is hitting infeasibility or taking undue time; by tweaking the cell neighbor relations by the ANR-E module (120) based on the modifications made to the neighbor relation table; and by updating input to the PCI rApp (122b) based on the modifications, thereby driving optimal PCI allocations.
[0055] In other words, when the PCI optimization through the PCI rApp (122b) is hitting infeasibility or taking undue time, the neighbor relation table is modified by the ANR-E rApp (122a) because of poor QoS and/or KPI being a consequence of PCI conflict and the PCI rApp (122b) requests the ANR-E rApp (122a) the need to make changes/modifications in the cell neighbor relations. While modifying the neighbor relation table by the ANR-E rApp (122a), the PCI rApp (122b) may request the ANR-E rApp (122a) to pause a flag /raise a flag (at least one of pause a flag and raise a flag), when a cell is undergoing PCI reassignment or any modifications in the cell neighbor relations as a consequence of the cell shall defer. During pause the flag /raise the flag operation, the PCI rApp (122b) suspends or disregards any input received regarding the cell neighbor relations by the ANR-E rApp (122a) when the PCI allocations are being optimized or in process. The feedback received regarding the cell neighbor relations at the ANR-E rApp (122a) through the neighbor relation table exists in the xApp(s) (124) and/or the CU (130).
[0056] During the coordination process, the policy governed trigger is sent/initiated from the ANR-E rApp (122a) to the PCI rApp (122b), where the PCI rApp (122b) uses additional measurements such as signal-to-noise ratio (SNR), Channel Quality Indication (CQI) and Block Error Rate (BLER), etc. to investigate possibility that poor QoS/KPI reports received by the ANR-E rApp (122a) persists and can assign a “possible neighbor” label to some cell neighbor relations. The relation between two cells is termed as the ‘possible neighbor’ when the reuse distance between the two cells is small. The relation between the two cells can also be termed as likely neighbor or inferred neighbor. In general, the SNR is used by a UE to measure the strength of a desired signal relative to background noise. For example, if the UE’s radio receives a signal at -75 dBm, and the background noise is -90 dBm, then the effective SNR is 15 dB. Similarly, the CQI is used by the UE to indicate the channel quality to the eNB. The CQI reported value is between 0 and 15 and this indicates the level of modulation and coding the UE could operate. Similarly, the BLER is used to determine the in-sync or out-of-sync indication at the time the radio link monitoring (RLM) is done. The BLER is measured after channel decoding and de-interleaving has been done after performing the cyclic redundancy check (CRC) for all transport blocks.
[0057] The PCI rApp (122b) receives the poor QoS/KPI reports from the ANR-E rApp (122a) that inform that a neighbor cell (306b and 306c are neighbor cells when 306a is a serving cell, and so on so forth) is unable to complete handovers satisfactorily, and possibly there is PCI conflict. In any telecom technology (second generation (2G), third generation (3G), fourth generation (4G) or fifth generation (5G)), mobility (handover) decision whether a UE (e.g., 304) will handover or not is taken by a base station (302) based on measurement reports from the UE (304). There are multiple measurement items (RSRP (Reference Signal Received Power), RSRQ (Reference Signal Received Quality), (SINR) Signal to Interference and Noise Ratio (which is an excellent indicator of network health and measures signal quality that is the strength of the wanted signal compared to the unwanted interference and noise)) and multiple ways (periodic, event triggered) to measure the signal quality of the serving cell (306a) and neighbor cells (306b, 306c). The measurement data is reported by the UE (304) to the rApp (122) or the xApp (124) in the O-RAN (100) and based on that the handover is performed. Similarly, during a network change or network reconfiguration, the physical cell identifier of the cells is changed or updated. Further, in a scenario when two neighboring cells/eNBs are having the same PCI are detected, it is termed as PCI conflict or PCI confusion.
[0058] Similarly, the policy governed trigger is sent/initiated from the PCI rApp (122b) to the ANR-E rApp (122a) to inform that a cell is undergoing PCI reassignment, and any modifications in the cell neighbor relations involving that cell should be deferred as disclosed above. If the PCI optimization (i.e., the PCI rApp (122b)) is hitting infeasibility or taking undue time (which is greater than a predefined time (e.g., 30 minutes) while optimizing the PCI(s)), the policy governed trigger to be sent to the ANR-E rApp (122a) to modify the cell neighbor relations. This should be done in a closed loop manner (“policy controlled/governed loop”) until an acceptable solution is reached where a PCI allocation solution is achieved which meets all the PCI conflict criteria.
[0059] Advantageously, the above-explained actions like modification of the neighbor relation table, assignment of “possible neighbor” label to some of the cell neighbor relations, locking/suspending the feedback received regarding the cell neighbor relations are some corrective actions that develop the coordination and make the network operation more robust in a proactive manner.
[0060] FIG. 4 to FIG. 7 illustrate example PCI rApp – ANR-E rApp interactions.
[0061] A first example interaction process (400), as shown in FIG. 4, depicts DSON (Distributed Self-Organizing Network) ANR failure, in which the process somehow missed the fact that the UE (shown as a rectangular box) can see interference from another cell marked PCI=1 (shown at the top) during handover from the cell marked PCI=3 to the cell marked PCI=1. The PCI rApp (122b) does not have any information about PCI confusion because there is no Relation between the two cells marked PCI=1. Herein, the interference may be sporadic and happen only at some times.
[0062] A mitigation process (500), as shown in FIG. 5, depicts an ANR-E solution, where the link marked “x” is not used for the handover.
[0063] A third example solution process (600), as shown in FIG. 6, depicts a PCI/ANR-E solution, where after getting poor handover KPI information, the following actions take place:
• Identify that the cell marked PCI “1 to 6” has small reuse distance from the cell marked PCI=1 even though there is no PCI confusion.
• Reassign the cell PCI from PCI=1 to PCI=6.
• If there is improvement in the cell-attach performance, mark the cells (labels PCI=1 and PCI 1 to 6) cells as “likely neighbor” or “inferred neighbor”, where two cells with the same PCI ID are considered as likely neighbor or inferred neighbor.
[0064] A fourth solution interaction process (700), as shown in FIG. 7, depicts a true solution, where ANR xApp (or xApp) should discover that the two cells marked with PCI=1 are PCI=6 are neighbors and mark it accordingly as shown.
[0065] FIG. 8 is a flow chart illustrating a network management method for/in the O-RAN. The operations (802 to 806) are handled by the Non-RT-RIC (104). For the sake of brevity, the operations and functions of the Non-RT-RIC (104) are not repeated while describing FIG. 8.
[0066] At Step 802, the method includes creating the cell neighbor relations using at least one of the key performance indicators (KPIs) and the quality of service (QoS) information for the plurality of operating cells (306a, 306b, 306c and so on so forth), wherein the cell neighbor relations are created by the ANR-E (or ANR) module (120) within the ANR-E rApp (122a).
[0067] At Step 804, the method includes assigning the unique physical cell identifiers to each of the plurality of operating cells (306a, 306b, 306c and so on so forth) by the PCI optimization module (126) within the PCI rApp (122b) based on the created cell neighbor relations. The ANR-E rApp (122a) and the PCI rApp (122b) are deployed in the Non-RT-RIC (104).
[0068] At Step 806, the method includes developing coordination between the ANR-E rApp (122a) and the PCI rApp (122b).
[0069] Such coordination is developed by modifying the neighbor relation table when the PCI optimization through the PCI rApp (122b) is hitting infeasibility or taking undue time; by tweaking the cell neighbor relations by the ANR-E module (120) based on the modifications made to the neighbor relation table; and by updating input to the PCI rApp (122b) based on the modifications, thereby driving optimal PCI allocations.
[0070] The various actions, acts, blocks, steps, or the like in the flow chart (800) 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 invention.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] The results of the disclosed methods may be stored in any type of computer data repository, 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).
[0075] 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.
[0076] 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.
[0077] 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.
[0078] Conditional language used herein, such as, among others, "can," "may," "might," "may," “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.
[0079] 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.
[0080] 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
, Claims:CLAIMS

We Claim:
1. A network management method in an Open Radio Access Network (O-RAN) (100), the network management method comprising:
creating cell neighbor relations for a plurality of operating cells (306a, 306b, 306c) using at least one of a key performance indicator (KPI) and quality of service (QoS) information, wherein the cell neighbor relations are created by an ANR-E (Automatic Neighbor Relation-Enhanced) module (120) within an ANR-E rApp (122a);
assigning unique physical cell identifiers to each of the plurality of operating cells (306a, 306b, 306c) by a PCI (physical cell identifier) optimization module (126) within a PCI rApp (122b) based on the created cell neighbor relations, wherein the ANR-E rApp (122a) and the PCI rApp (122b) are deployed in a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) (104); and
developing coordination between the ANR-E rApp (122a) and the PCI rApp (122b).

2. The network management method as claimed in claim 1, wherein the plurality of operating cells (306a, 306b, 306c) is a set of cells coming under a zone in which performance information of each cell is continuously measurable by the ANR-E module (120).

3. The network management method as claimed in claim 1, wherein an rApp (122) is designed to execute on the Non-RT-RIC (104) to realize different RAN automation and management use cases, with control loops on a time scale of more than one second.

4. The network management method as claimed in claim 1 further comprising:
registering ANR-E services and PCI optimization services as the ANR-E rApp (122a) and the PCI rApp (122b) respectively within the Non-RT-RIC (104).

5. The network management method as claimed in claim 1, wherein the network management method comprises generating enhanced cell neighbor relations by the ANR-E module (120) by:
determining the cell neighbor relations based on an observed handover to a target cell from a serving cell; and
enhancing the cell neighbor relations based on determination of the cell neighbor relations.

6. The network management method as claimed in claim 1, wherein developing coordination further comprising:
modifying a neighbor relation table when PCI optimization through the PCI rApp (122b) is hitting infeasibility or taking undue time;
tweaking the cell neighbor relations by the ANR-E module (120) based on the modifications made to the neighbor relation table; and
updating input to the PCI rApp (122b) based on the modifications, so as to drive optimal PCI allocations.

7. The network management method as claimed in claim 6, wherein the cell neighbor relations in the neighbor relation table is modified by the ANR-E rApp (122a) upon determining that a poor QoS and KPI are a consequence of PCI conflicts, wherein the PCI rApp (122b) requests the ANR-E rApp (122a) to make modification in the cell neighbor relations.

8. The network management method as claimed in claim 6, wherein the network management method comprises:
sending a policy governed trigger to the ANR-E rApp (122a) to modify the cell neighbor relations when the PCI rApp (122b) is hitting infeasibility or taking undue time, which is greater than a predefined time while optimizing the PCIs.

9. The network management method as claimed in claim 6, wherein while modifying the neighbor relation table by the ANR-E rApp (122a), the PCI rApp (122b) requests the ANR-E rApp (122a) to at least one of pause a flag and raise a flag, when a cell from the plurality of operating cells (306a, 306b, 306c) is undergoing PCI reassignment in the cell neighbor relations.

10. The network management method as claimed in claim 9, wherein the PCI rApp (122b) suspends or disregards information received regarding the cell neighbor relations by the ANR-E rApp (122a) when the PCI allocations are being optimized or in process, wherein the feedback received regarding the cell neighbor relations at the ANR-E rApp (122a) through the neighbor relation table exists in at least one of an xApp (124) and a central unit (CU) (130), wherein the xApp (124) resides in a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (106) that is connected with the Non-RT-RIC (104) through an A1 interface.

11. An Open Radio Access Network (O-RAN) (100) comprising:
an ANR-E (Automatic Neighbor Relation-Enhanced) module (120) within an ANR-E rApp (122a) for creating cell neighbor relations for a plurality of operating cells (306a, 306b, 306c) using at least one of a key performance indicator (KPI) and quality of service (QoS) information; and
a PCI (physical cell identifier) optimization module (126) within a PCI rApp (122b) for assigning unique physical cell identifiers to each of the plurality of operating cells (306a, 306b, 306c) based on the created cell neighbor relations, wherein the ANR-E rApp (122a) and the PCI rApp (122b) are deployed in a Non-Real Time RAN Intelligent Controller (Non-RT-RIC) (104) and a coordination is developed between the ANR-E rApp (122a) and the PCI rApp (122b).

12. The O-RAN (100) as claimed in claim 11, wherein the plurality of operating cells (306a, 306b, 306c) is a set of cells coming under a zone in which performance information of each cell is continuously measurable by the ANR-E module (120).

13. The O-RAN (100) as claimed in claim 11, wherein an rApp (122) is designed to execute on the Non-RT-RIC (104) to realize different RAN automation and management use cases, with control loops on a time scale of more than one second.

14. The O-RAN (100) as claimed in claim 11, wherein ANR-E services and PCI optimization services are registered as the ANR-E rApp (122a) and the PCI rApp (122b) respectively within the Non-RT-RIC (104).

15. The O-RAN (100) as claimed in claim 11, wherein the ANR-E module (120) generates enhanced cell neighbor relations by:
determining the cell neighbor relations based on an observed handover to a target cell from a serving cell; and
enhancing the cell neighbor relations based on determination of the cell neighbor relations.

16. The O-RAN (100) as claimed in claim 11, wherein the coordination is developed by:
modifying a neighbor relation table when PCI optimization through the PCI rApp (122b) is hitting infeasibility or taking undue time;
tweaking the cell neighbor relations by the ANR-E module (120) based on the modifications made to the neighbor relation table; and
updating input to the PCI rApp (122b) based on the modifications, so as to drive optimal PCI allocations.

17. The O-RAN (100) as claimed in claim 16, wherein the neighbor relation table is modified by the ANR-E rApp (122a) upon determining that a poor QoS and KPI are a consequence of PCI conflicts, wherein the PCI rApp (122b) requests the ANR-E rApp (122a) to make modification in the cell neighbor relations.

18. The O-RAN (100) as claimed in claim 16, wherein a policy governed trigger is sent to the ANR-E rApp (122a) to modify the cell neighbor relations when the PCI rApp (122b) is hitting infeasibility or taking undue time, which is greater than a predefined time while optimizing the PCIs.

19. The O-RAN (100) as claimed in claim 16, wherein while modifying the neighbor relation table by the ANR-E rApp (122a), the PCI rApp (122b) requests the ANR-E rApp (122a) to at least one of pause a flag and raise a flag, when a cell from the plurality of operating cells (306a, 306b, 306c) is undergoing PCI reassignment in the cell neighbor relations.

20. The O-RAN (100) as claimed in claim 19, wherein the PCI rApp (122b) suspends or locks a feedback received regarding the cell neighbor relations by the ANR-E rApp (122a) when the PCI allocations are being optimized or in process, wherein the feedback received regarding the cell neighbor relations at the ANR-E rApp (122a) through the neighbor relation table exists in at least one of an xApp (124) and a central unit (CU) (130), wherein the xApp (124) resides in a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (106) that is connected with the Non-RT-RIC (104) through an A1 interface.

Dated this 03rd Day of October, 2022
Signature:
Name: Arun Kishore Narasani
Patent Agent: IN/PA 1049