Description:TECHNICAL FIELD
[0001] The present disclosure relates to wireless communication and networks, and more specifically relates to methods and a controller (e.g., Near-Real Time RAN Intelligent Controller (Near-RT-RIC) and Non-Real Time RAN Intelligent Controller (Non-RT-RIC)) for managing a plurality of neighbour (neighbor) cells of a target cell in a radio access network (RAN).

BACKGROUND
[0002] Fifth generation (5G) wireless networks aim to achieve seamless mobile broadband services, machine to machine and ultra-reliable low latency communications. These goals require massive improvements in terms of capacity, reliability, latency reduction, and scalability. Besides software de?ned networks and network function virtualization, self-organizing network (SON) is another enabling technology which makes 5G wireless network feasible. A prominent component of the SON is Automatic Neighbour Relation (ANR), where the ANR has direct impact on reliability, scalability, and capacity of the 5G wireless networks. When the current state of standardization and implementation of an ANR functionality is considered, it is seen that a new approach is needed for the ANR to comply with 5G requirements. Thus, a comprehensive hybrid ANR (H-ANR) architecture, which leads to the management of neighbour cell relations utilizing an extensive set of universal performance criteria, con?guration metrics, and measurements, is used. The H-ANR functionality measures and ranks the neighbours for each cell based on measurements reported by User Equipments (UEs) and radio nodes (e.g., eNBs, gNBs or the like).
[0003] Further, some of the prior art references are given below for automated neighbours cell management in a wireless network (e.g., 5G wireless network, RAN or the like):
[0004] US20220053579A1 discloses a communication device for a communication system in which network slicing is supported. US20220053579A1 discloses a procedure that is performed between user equipment and base stations in a telecommunications system for supporting mobility in a context of network slicing. A source gNB configures the user equipment to perform appropriate neighbour cell measurements for neighbour gNBs. Further, the source gNB then decides on handover and selects a target gNB based on the measurement results and the tenant ID(s) and/or slice type(s) (per tenant ID) supported by the neighbour gNBs.
[0005] US20160165527A1 discloses neighbour relation information management that involves, for example: acquiring, reporting, and exchanging neighbour relation information. The invention is employed in automatic neighbour relation (ANR) operations whereby entities may autonomously (e.g., without human or network operator action) acquire, report, exchange, or update neighbour relation information. The exchange of neighbour relation information directly from one network entity to another provides more efficient ANR.
[0006] A 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. The approach would leverage 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.
[0007] But, none of the prior art references discloses techniques of batching of data for consumption of rApp(s) and xApp(s) at a desired time scale and use of infinite size neighbour relations tables (NRTs) to have a large pool of neighbours to choose from. In light of the above-stated discussion, there is a need to overcome the above stated disadvantages.

OBJECT OF THE DISCLOSURE
[0008] A principal object of the present disclosure is to solve the aforesaid drawbacks and provide methods and a controller for neighbour cell management in a wireless network (e.g., RAN or the like).
[0009] Another object of the present disclosure is to provide an automatic neighbour relation (ANR) function in the RAN (e.g., disaggregated 5G RAN or the like) that supports high interoperability in a disaggregated multi-vendor environment which follow O-RAN paradigms and that provides more flexibility in granularity of the processing to further provide more robust data in different scenarios (in an example, an E2 node may not support all the granularities, an xApp needs for the data).
[0010] Another object of the present disclosure is to utilize batch input and processing of data (e.g., handover measurement data for rApp and ANR reports for xApp) for consumption of rApp and xApp at a desired time scale thereby providing more efficient use of computing and networking resources.
[0011] Yet another object of the present disclosure is to utilize infinite size neighbour relation tables (NRTs) that allows to have a large pool of neighbours and customizable choices of neighbours.

SUMMARY
[0012] Accordingly, the present disclosure provides methods and a RAN for managing a plurality of neighbour cells of a target cell in the RAN. The target cell accommodates the plurality of neighbour cells. The method includes batch processing of an input data at an xApp hosted on a Near-RT-RIC and an rApp hosted on a Non-RT-RIC. The Near-RT-RIC is connected to an E2 node through an E2 interface. The Non-RT-RIC is connected to the Near-RT-RIC through an A1 interface. The input data comprises a handover (HO) measurement data associated with the target cell and an automatic neighbour relation (ANR) report associated with the target cell. The input data is associated with a predefined period for the target cell. Further, the method includes periodically updating neighbour relations table (NRT) at the E2 node based on the batch processing of the input data, where the E2 node includes at least one of an open distributed unit (O-DU), an open centralized unit (O-CU), and an O-RAN-compliant LTE eNB (long-term evolution evolved NodeB). The periodically updating of the neighbour relations table (NRT) at the E2 node is performed by executing a neighbour update technique for the target cell at the E2 node.
[0013] Further, the method includes combining, by the E2 node, the processed input data from the xApp and the rApp periodically. Further, the method comprises deactivating a neighbour cell from the plurality of neighbour cells when a number of handovers attempts for the neighbour cell in the processed input data associated with a time period is greater than a predefined threshold along with the handover success ratio being less than a predefined threshold. Further, the method includes maintaining an infinite size neighbour relation table (NRT) for the target cell by the xApp. Further, the method includes updating the NRT for the target cell with priority neighbour cells in the infinite size NRT, wherein the priority neighbour cells having a Reference Signal Received Power (RSRP) is greater than a predefined RSRP threshold, wherein the priority neighbour cells are not deactivated neighbour cells. Further, the method includes sending measurement control information received from the rApp and the xApp to the E2 node to configure measurement reporting for at least one neighbour cell of a serving target cell, wherein the measurement control information comprises a neighbour cell relation list including a cell identifier of the serving target cell reported periodically from the processed input data of the xApp and the rApp.
[0014] 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
[0015] 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:
[0016] FIG. 1 illustrates a radio access network (RAN) (or O-RAN system).
[0017] FIG. 2 illustrates a hybrid ANR (Automatic Neighbour Relation) in the RAN to manage a plurality of neighbour cells of each target cell.
[0018] FIG. 3A-FIG. 3B are flowcharts illustrating a method, implemented by an rApp, for batch input and processing using the hybrid automatic neighbour relation and an A1 policy.
[0019] FIG. 4A-FIG. 4F are flowcharts illustrating a method, implemented by an xApp, for batch input and processing using the hybrid automatic neighbour relation, E2 and ANR report handling.
[0020] FIG. 5 is a flow chart illustrating a neighbour cell management method in the RAN.

DETAILED DESCRIPTION
[0021] 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.
[0022] 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.
[0023] 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.
[0024] The deficiencies in previous techniques (as discussed in background section) can be solved by proposed neighbour cell management methods in a radio access network (RAN). The proposed method discloses at least one rApp and at least one xApp for periodic processing of input data such as handover (HO) measurement data and automatic neighbour relation (ANR) reports in a batch fashion by periodically dividing time into periods. At the end of each period, the at least one xApp or the at least one rApp processes the input data that is fetched in that period and periodically updates the neighbour relation (or relations) table (NRT) at an E2 node based on the processing. The input data is processed to identify a bad neighbour which is further removed from an RIC NRT.
[0025] FIG. 1 illustrates a radio access network (RAN) (or O-RAN system or disaggregated 5G RAN) (100) (interchangeably be called as RAN architecture (100)). Referring to FIG. 1, the RAN (100) is a part of telecommunications systems which connects individual devices to other parts of a network through radio connections. The RAN (100) provides a connection of user equipments (UEs) (124a-124c) such as mobile phones, internet of things (IoT) or computers with a core network of the telecommunication systems over a fiber or a wireless backhaul connection. That link goes to the core network, which manages subscriber information, location and more. The RAN (100) is an essential part of an access layer in the telecommunication systems which utilizes base stations (such as e-NodeB, gNodeB or the like) for establishing radio connections. The O-RAN (Open-Radio Access Network) (100) 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 (100) provides real-time analytics that drives 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 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 (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) (202) residing in the SMO (102), an Open Cloud (O-Cloud) (112), a Near-Real Time RAN Intelligent Controller (Near-RT-RIC) (114), an Open Central Unit Control Plane (O-CU-CP) (116), an Open Central Unit User Plane (O-CU-UP) (118), an Open Distributed Unit (O-DU) (120), and an Open Radio Unit (O-RU) (122).
[0027] The SMO (102) is configured to provide SMO functions/services such as data collection and provisioning services of the ORAN (100). The data collection of the SMO (102) may include, for example, data related to a bandwidth of a wireless communication network and at least one of a plurality of UEs (124a, 124b, 124c, 124d) (combinedly “124”) (shown in FIG. 1 and FIG. 2). That is, the SMO (102) oversees all the orchestration aspects, management and automation of ORAN elements and resources and supports O1, A1 and O2 interfaces. The SMO (102) provides fine-grained policy guidance such as getting a user equipment to change frequency, and other data enrichments to RAN functions over the A1 interface.
[0028] The SMO (102) may include an A1 REST (Representational State Transfer) client (106) that may handle the A1 policy management services (e.g. add/remove adapters, security certs or the like) in the SMO framework (102) and handle one or more policies using an A1 policy agent (104).
[0029] The Non-RT-RIC (202) is a logical function that enables non-real-time control and optimization of the ORAN elements and resources, artificial intelligence/machine learning (AI/ML) workflow including model training and updates, and policy-based guidance of applications/features in the Near-RT-RIC (114). The Non-RT-RIC (202) controls Radio Resource Management (RRM) decisions in the ORAN (100). The Non-RT-RIC (202) is a part of the SMO framework (102) and communicates/connected to the Near-RT-RIC (114) using an A1 interface. The Near-RT-RIC (114) is a logical function that enables near-real-time control and optimization of the ORAN elements and resources via fine-grained data collection and actions over an E2 interface. The E2 interface is an open interface between two endpoints, i.e., the Near-RT-RIC (114) and E2 nodes, i.e., DUs, CUs, and O-RAN-compliant LTE eNBs. The E2 interface allows the Near-RT-RIC (114) to control procedures and functionalities of the E2 nodes. Moreover, the E2 interface enables the collection of metrics from the RAN (100) to the Near-RT-RIC (114), either periodically or after pre-defined trigger events. The Near-RT-RIC (114) is connected to an O-CU, the O-DU (120), and the O-RU (122) through the E2 interface.
[0030] In other words, the Near-RT-RIC (114) connects to the O-CU-CP (116), the O-CU-UP (118), and the O-DU (120) (each can also be 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.
[0031] 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.
[0032] The ORAN (100) includes an O-eNB (not shown) that is hardware aspect of a fourth generation RAN that communicates with at least one of the plurality of UEs (124a-124d) via wireless communication networks such as a mobile phone network. The O-eNB 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 is a logical node that handles transmission and reception of signals associated with a plurality of cells (not shown in figures). The O-eNB supports O1 and E2-en interfaces to communicate with the SMO (102) and the Near-RT-RIC (106) respectively.
[0033] Further, the 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 (116) and O-CU-UP (118). The O-CU-CP (116) is a logical node hosting the RRC and the control plane part of the PDCP. The O-CU-CP (116) supports O1, E2, F1-c, E1, X2-c, Xn-c and NG-c interfaces for interaction with other components/entities. Similarly, the O-CU-UP (118) 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.
[0034] The O-RU (122) 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 (122) utilizes OFH CUS–Plane and OFH M-Plane interfaces. Also, the O-RU (122) converts radio signals, sent to and from an antenna, to digital signals that are transmitted over a fronthaul to the O-DU (120).
[0035] The O-Cloud (112) 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 (112) from within via an O2 interface. The O-Cloud (112) 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 (112) will include functionality to support both deployment-plane and management services.
[0036] The O-DU (120) 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. The O-DU (120) is responsible for real-time scheduling functions, wherein the O-DU (120) connects each component with at least one other component in the ORAN (100).
[0037] In a management plane (M-Plane), the O-DU (120) and the SMO (102) are used to manage the O-RU (122) (or O-RUs), wherein the O-DU (120) and the SMO (102) use NETCONF (Network Configuration Protocol) to manage the O-RU (122). Alternatively, the O-DU (120) and other NMSs (Network Management Systems) may manage the O-RU (122) via a NETCONF client. In such a case, the SMO (102) (or the NMS) corresponds to the NETCONF client (or O1 NETCONF Client (FCAPS)) (108) while the O-RU (122) corresponds to a NETCONF server, and the O-DU (120) 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. Further, the SMO (102) can include a High Volume (HV)-VES/File Collector (110) used for real-time event streaming needed for performance counter (PM) in the SMO (102).
[0038] 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.
[0039] The ORAN (100) also comprises a 5G core network (126) that may include a user plane function (UPF) (128), access and mobility management function (AMF) (130), a Network Slicing Selection Function (NSSF) (132), a Network Exposure Function (NEF) (134), a Network Function Repository Function (NRF) (136), a Policy Control Function (PCF) (138), a Unified Data Management (UDM) (140), a Session Management Function (SMF) (142), an Application Function (AF) (144), a Service Communication Proxy (SCP) (146) and an Authentication Server Function (AUSF) (148). The NSSF (132), the NEF (134), the NRF (136), the PCF (138), the UDM (140), the SMF (142), the AF (144), the SCP (146) and the AUSF (148) may communicate with a data network (150) using various interfaces (e.g., N4, N5, N7, N8, N10, N11, N12, N13, N14, N15, N16, N17, N22, N24, N27, N31 or the like).
[0040] Now referring to the various interfaces used in the ORAN (100) as mentioned above.
[0041] The O1 interface is element operations and management interface between management entities in the SMO (102) and ORAN managed elements, for operation and management, by which FCAPS (fault, configuration, accounting, performance, security) management, Software management, File management shall be achieved. The ORAN managed elements include the Near-RT-RIC (114), the O-CU (the O-CU-CP (116) and the O-CU-UP (118)), the O-DU (120), and the O-RU (122). The management and orchestration functions are received by the aforesaid ORAN managed elements via the O1 interface. The SMO (102), in turn, receives data from the ORAN managed elements via the O1 interface for AI model training.
[0042] The O2 interface is a cloud management interface, where the SMO (102) communicates with the O-Cloud (112) it resides in. Typically, operators that are connected to the O-Cloud (112) can operate and maintain the ORAN (100) with the O1 or O2 interfaces. The O2 interface is used to support cloud infrastructure management and deployment operations with O-Cloud infrastructure that hosts the Open RAN functions in the RAN (100). The O2 interface supports orchestration of O-Cloud infrastructure resource management (e.g., inventory, monitoring, provisioning, software management and lifecycle management) and deployment of the Open RAN network functions, and provides logical services for managing the lifecycle of deployments that use cloud resources.
[0043] The A1 interface enables the communication between the Non-RT-RIC (202) and the Near-RT-RIC (114) and supports policy management, machine learning and enrichment information transfer to assist and train AI and machine learning in the Near-RT-RIC (114). The A1 interface is used for policy (or policy-based) guidance.
[0044] The E1 interface connects the two disaggregated O-CUs i.e., the O-CU-CP (116) and the O-CU-UP (118) and transfers configuration data (to ensure interoperability) and capacity information between the O-CU-CP (116) and the O-CU-UP (118). The capacity information is sent from the O-CU-UP (118) to the O-CU-CP (116) and includes the status of the O-CU-UP (118).
[0045] The F1-c and F1-u interfaces (combinedly an F1 interface) connect the O-CU-CP (116) and the O-CU-UP (118) to the O-DU (120) to exchange data about frequency resource sharing and network statuses. One O-CU can communicate with multiple O-DUs via F1 interfaces.
[0046] 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 (120) and the O-RU (122). 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 (122) to the SMO (102). The O-DU (120) uses the OFH M-Plane to manage the O-RU (122), while the SMO (102) can provide FCAPS (fault, configuration, accounting, performance, security) services to the O-RU (122).
[0047] 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.
[0048] 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.
[0049] The NG-c (control plane interface) and the NG-u (user plane interface) connect the O-CU-CP (116) and the O-CU-UP (118) respectively to the 5G core network (126). The control plane information is transmitted to the 5G access and mobility management function (AMF) (130) that receives connection and session information from the user equipment and the user plane information is relayed to the 5G user plane function (UPF) (128), which handles tunnelling, routing and forwarding, for example.
[0050] FIG. 2 illustrates a hybrid Automatic Neighbour Relation (ANR) in the O-RAN system (or RAN) (100) to manage a plurality of neighbour cells (210b, 210c, 210d) of each target cell (210a). The RAN (100) acts as a neighbour cell management system and various elements and functions of the ORAN system/architecture (or RAN) (100) are already explained in FIG. 1. Referring to FIG. 2, the hybrid ANR is a SON (self-organizing network) feature associated with the automatic configuration of neighbour cell relations at a given base station (e.g., e-NodeB, gNodeB or the like). A Neighbour Relation Table (NRT) is created and managed by the ANR xApp in the Near-RT RIC and is also held at the base station. The NRT will contain an entry for each neighbouring cell. Each entry will contain all the information the base station needs to know about its neighbour. The ANR functionality is to relieve an operator/service provider from the burden of manually managing Neighbour Relations (NRs). The ANR function resides in the base station and manages the conceptual Neighbour Relation Table (NRT). A neighbour detection function is part of ANR, where the neighbour detection function finds new neighbours and adds them to the NRT. The ANR system also contains a neighbour removal function which removes outdated NRs. The NRT for each cell maintained in the Near-RT-RIC (114) has the following fields for each neighbour criteria and other metrics:
a) Neighbour number/index,
b) Neighbour Cell TCI (target cell identifier),
c) isRemoveAllowed,
d) isHOAllowed,
e) Reference Signal Received Power (RSRP),
f) Timestamp added (when this neighbour was added),
g) Removed_by_rApp (1 or 0, set to 1 by xApp when the neighbour is removed by rApp) and
h) Timestamp removed (when this neighbour is marked as removed by rApp).
[0051] The Non-RT-RIC (202) may comprise (or host) a Non-RT-RIC application (cloud-native, microservice-based application) such as an rApp (204) connected/integrated via an R1 interface. The rApp (204) is a modular microservice and an independent software plug-in to the Non-RT-RIC (202) deployed to provide functional extensibility to the ORAN (100) by third parties. That is, the Non-RT-RIC (202) may provide different functionalities by using programmable modules, such as the rApp(s) (204), from different operators and vendors. There may be one or more rApps (204) in the Non-RT-RIC (202). Generally, the services delivered by the Non-RT-RIC (202) are composed of the rApp(s) (204). With the Non-RT-RIC (202), the rApp(s) (204) may be designed to provide granular service assurance and may improve the quality-of-experience wherever needed. The rApp(s) (204) improves neighbour relations using QoS/KPI (Quality of Service / Key Performance Indicator) measurements. In general, a neighbour relation is an information that a neighbour cell is a neighbour to a target cell.
[0052] The Near-RT-RIC (114) may host the at least one xApp (206) that use E2 interface to collect near real-time information and provide value added services. The xApp(s) (206) is a cloud-native, microservice-based application and an independent software plug-in to the Near-RT-RIC (114) to provide functional extensibility to the RAN (100) by the third parties. The Near-RT-RIC (114) can be provided with different functionalities by using programmable modules such as xApp(s) (206), from different operators and vendors. The xApp(s) (206) creates neighbour relation tables using UE measurements.
[0053] The Near-RT-RIC (114) operates as a cloud-based process on a network edge of the RAN (100). The Near-RT-RIC (114) provides policy-based guidance back to the Non-RT-RIC (202) through the xApp(s) (206). The Non-RT-RIC (202) provides at least one of a policy-based guidance, a model management, and enrichment information to the Near-RT-RIC (114), where the Non-RT-RIC (202) provides a policy to the Near-RT-RIC (114) to mark at least one neighbour cell on a neighbour list as removed in an RIC NRT and the E2 node for the cell. The neighbour list is an automatic discovery and setup of neighbour relations when the UE (124a-124d) moves from a serving eNB to a target eNB. The neighbour list comprises a number of users and their locations, current load, cell loading information, in terms of throughput and/or number of connections, signalling, and processing delay for context collection, capacity demand, re-configuration delay, and removed neighbour cell, etc.
[0054] Further, the Near-RT-RIC (114) is connected to the E2 node (e.g., the O-DU (120), the O-CU, and an O-RAN-compliant LTE eNB (long-term evolution evolved NodeB) or the like) through the E2 interface and the Non-RT-RIC (202) is connected to the Near-RT-RIC (114) through the A1 interface. The xApp (206) hosted on the Near-RT-RIC (114) and the rApp (204) hosted on the Non-RT-RIC (202) perform batch processing of an input data (e.g., handover (HO) measurement data, automatic neighbour relation (ANR) report or the like). Information related to the batch processing is explained below in conjunction with FIG. 3 and FIG. 4. The E2 node sends the ANR report(s) to the ANR-xApp (i.e., xApp) (206), which includes RSRP measurement for the neighbour cells of the target cell. In any telecom technology (2G, 3G, 4G or 5G), mobility (handover) decision (e.g., whether the UE (124) will be handover or not) is taken by base station based on measurement reports from the UE (124). There are multiple measurement items (e.g., RSRP, Reference Signal Received Quality (RSRQ), Signal to Interference & Noise Ratio (SINR) or the like) and multiple ways (periodic, event triggered) to measure the signal quality of a serving cell and neighbour cells. The measurement data reported by the UE (124) to the rApp (204) or the xApp (206) in the radio access network is called handover measurement data. The rApp (204) or the xApp (206) fetch the data periodically and process the same in a batch fashion. After the end of every time period, the input data (e.g., handover measurement data and ANR reports) are fetched for that particular period and then processed to update the neighbours. The input data is associated with a predefined period for the target cell.
[0055] Based on (or after) the batch processing of the input data, the E2 node periodically updates the neighbour relations table (NRT) by executing a neighbour update technique for the target cell at the E2 node. By using the neighbour update technique, the NRT (or RIC NRT) is updated with top neighbour cells of the target cell having RSRP greater than a predefined RSRP threshold and that are not deactivated cells. The NRT includes information corresponding to a unique cell identity of at least one neighbour cell from the plurality of neighbour cells. Each target cell holds a table of detected neighbour cells which are used in connection with handovers, this table is called as neighbour relation table (NRT).
[0056] The E2 node combines the processed input data received from the xApp (206) and the rApp (204) periodically. The E2 node deactivates the neighbour cell (e.g., a bad neighbour cell or the like) from the plurality of neighbour cells based on input from the xApp or rApp. This is typically when a number of handovers attempts for the neighbour cell in the processed input data associated with a time period is greater than a certain threshold along with the handover success ratio being lower than a certain threshold. For example, the criteria could be having handover-success less than 30% with at least 10 handover attempts in 15 minutes. In other words, the neighbour cell is declared as the bad neighbour cell when handover attempt by the UE (124) is greater than a handover attempted threshold and a ratio of handover successful with handover attempted is less than a minimum handover-success ratio.
[0057] The xApp (206) maintains a predefined RSRP threshold for neighbour cells measurements. After receiving the UE-measured RSRP measurements for each target neighbour cell, the xApp (206) compares the RSRP measurement associated with at least one neighbour cell from the plurality of neighbour cells with the predefined RSRP threshold. Further, the xApp (206) includes the neighbour cell in the infinite size NRT if the RSRP is above the predefined RSRP threshold. Based on the determination, the xApp (206) maintains the infinite size NRT for each cell. Further, the xApp (206) updates the NRT with priority neighbour cells in the infinite size NRT. In general, the infinite size NRTs are used to send entire NRTs and delta updates (e.g., incremental updates) to E2 nodes (such as O-DU, O-CU or the like) in a single go to update neighbours in a more robust way and address scenarios with dense cells, where each cell can have a large number of neighbours. The xApp (206) (e.g., ANR-xApp) maintains the infinite size NRTs sorted by latest RSRPs reported for the neighbours in descending order but updates the E2 node with only the top neighbours. The ANR-xApp maintains a predefined RSRP threshold for neighbour cells measurement and upon receiving the RSRP signal of the neighbour cells, it is compared to the threshold. The priority neighbour cells are the cells for whom RSRP is greater than the threshold, assuming that the priority neighbour cells are not deactivated neighbour cells (explained later).
[0058] The xApp (206) and the rApp (204) send measurement control information to the E2 node to configure measurement reporting by UEs for measurements related to at least one neighbour cell of a serving target cell. The measurement control information includes a neighbour cell relation list including a cell identifier of the serving target cell reported from the processed input data of the xApp (206) and the rApp (204) periodically. The processed input data is received from the rApp (204) and the xApp (206) within an evaluation period that is related to an interval of a predefined period for the serving target cell.
[0059] That is, each E2 node reports its NRT and aggregated ANR reports from its UE(s) (124a, 124b, 124c, 124d) for each cell (210a, 210b, 210c, 210d) to the Near-RT-RIC (114) on a subscription basis. The Near-RT-RIC (114)/ANR-xApp (206) keeps its version of NRT for each cell in its Radio-Network Information Base (R-NIB). The ANR-xApp (or xApp) (206) 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 (e.g, 16 intraFreqNeighCells) and other parameters.
[0060] In an example, for a particular cell, top Max_E2node_NRT_Size neighbours in the NRT in the Near-RT-RIC (114) and 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 (206) and the E2 node, e.g., if short-term average RSRP is used or not, different thresholds used by the xApp (206) and the E2 node, impact from the neighbour update decision of the rApp (204) and possible vendor specific mechanism for NRT update in the E2 node.
[0061] The ANR-xApp (206) may modify its NRTs and send the modification, in the form of an E2 NR control message (or control message), to the relevant E2 node(s). The control message may contain a list of neighbours to be added and/or removed. The control message 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 message from the Near-RT-RIC (114) 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 (206) may also modify the NRTs in the Near-RT-RIC (114) based on an A1 policy, after which the ANR-xApp (206) sends the modification to the relevant E2 node(s) via the E2 NR control message. By keeping more potential neighbours in the RIC NRTs than in the E2 node(s) NRTs helps avoiding the ping-ponging behavior while updating NRTs.
[0062] Further, the xApp (206) has options of sending entire top m neighbours in the RIC NRTs or delta’s to E2 nodes’ NRTs. In the first option, for each cell, the ANR-xApp (206) finds the top n neighbours in the RIC NRT whose RSRP is greater than the predefined RSRP threshold and who are not marked as “removed” by the rApp (204), then updates the E2 node with top m of the top n neighbours, where m = Min(n, Max_E2node_NRT_Size) (Max_E2node_NRT_Size can be, e.g., intraFreqNeighCells(16) in 3GPP standard). Alternatively, the xApp (206) sends the entire top m neighbours in a more robust way for updating NRT in the E2 node since the impact due to the loss of the NR control message can be reduced by a following control message and sending NRTs from E2 nodes to the RIC can be avoided.
[0063] Further, each E2 node (O-DU (120) or O-CU), preferably the O-CU (or CU), may capture radio signal quality measurements from the plurality of user equipments (UEs) (124b-124d) associated with the target cell. The radio signal quality measurements may also be associated with each of the plurality of neighbour cells (210b, 210c, 210d) of the target cell. The target cell may be any of the plurality of neighbour cells (210b, 210c, 210d). For instance, if a cell (210b) acts as the target cell, then the neighbour cells will be 210c, 210d. Similarly, if a cell (210c) acts as the target cell, then the neighbour cells will be 210b, 210d and so on so forth. The CU may report the radio signal quality measurements for all subscribed target cells to at least one xApp (206) that is in connection with the Near-RT-RIC (114), wherein the CU is in connection with the Near-RT-RIC (114) over the E2 interface. Based on the radio signal quality, addition and removal of the cell is determined.
[0064] FIG. 3A-FIG. 3B are example flowcharts (300) illustrating a method for batch input and processing using the hybrid automatic neighbour relation and an A1 policy.
[0065] At step 302, the method includes determining that a periodic timer is expired. At step 304, the method includes fetching the handover (HO) measurement data since the last processing period. At step 306, the method includes combining/pre-processing the data for each neighbour (aka “nbr”) of each serving (or service or servicing) cell. At step 308, the method includes detecting if serving cell i is available in the ANR report(s). If no more serving cell is available then, at step 324, the method includes sending the A1 NR policies to the corresponding ANR xApps (206). At step 310, the method includes detecting nbr (neighbour j) for each serving cell i. If no nbr is left, then at step 318, the method includes determining any removed (or bad) neighbour j for the serving cell i. If a removed (or bad) neighbour j exists for the serving cell then, at step 320, the method includes creating the A1 NR policy (list of “removed” neighbour) for the serving cell i that is transmitted to step 322. If the removed (or bad) neighbour j does not exist for the serving cell i, then the method jumps to step 322. At step 322, outputs of step 318 and step 320 are aggregated and sent back to step 308.
[0066] At 312, the method includes for each neighbour j determining whether HO_attempted (j) is greater than HO_attempted_threshold and HO_successful (j) / HO_attempted (j) is less than 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 step 314, the method includes marking the neighbour j as “removed” which is further forwarded to step 316. If the above condition is not satisfied, then the method jumps to step 316. At step 316, outputs of step 312 and step 314 are aggregated and sent back to step 310.
[0067] FIG. 4A-FIG. 4F are flowcharts (400) illustrating a method, implemented by the xApp (206), for batch input and processing using the hybrid automatic neighbour relations, E2 and ANR report handling.
[0068] At step 402, the method includes determining that the periodic timer is expired. At step 404, the method includes fetching the ANR reports sent by the E2 nodes since the last processing period. At step 406, the method includes determining availability of the ANR report(s). If the method determines that there is no more ANR report then, the method proceeds to step 420 and initiates a loop for each neighbour (aka “nbr”) in the RIC NRT and checks at step 422 for each nbr in the 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 step 424, the method includes removing the nbr from the RIC NRT and proceeds to step 426. If not, the method proceeds to step 426. At step 426, the method aggregates outputs of step 422 and step 424.
[0069] Similarly, if the method determines that there is ANR report(s) available then, the method proceeds to 408. At step 408, the method checks if several measurements in a sufficiently short interval need to be averages. The method includes determining whether neighbour j of the serving cell i has multiple RSRP measurements in a single event (e.g., A4 event or the like) measured by the UE (124) which span a time-interval less than a certain time-interval averaging threshold. If the neighbour j of the serving cell i has multiple RSRP measurements in the single event measured by the UE (124) and the event reporting interval is less than time-interval averaging threshold then, at step 410, the method computes short term average of the RSRP(s), which is forwarded to step 412. If the conditions mentioned at step 408 are not satisfied, then the method proceeds to step 412. At step 412, the method aggregates outputs of step 408 and step 410.
[0070] At step 414, the method includes determining whether the neighbour j of the serving cell i is reported in multiple reports (regardless of measured by same UE (124) or not and regardless of its RSRP being a short-term average or not). If the neighbour j of the serving cell i is reported in multiple reports (regardless of measured by same UE (124) or not and regardless of its RSRP being a short-term average or not) then, at step 416, the method includes taking the maximum RSRP for neighbour j of the serving cell i and proceeds to step 418. If no, the method proceeds to step 418. At step 418, outputs of step 414 and step 416 are aggregated.
[0071] At step 428, the method includes detecting availability of the cell(s) in the ANR report for each reported serving cell i. If the method detects that no more cell is available then, at step 466, the method includes sending the E2 NR control message(s) to the E2 node(s). If a serving cell is available, the method proceeds to step 430 to check availability of nbr (neighbour j) for each reported serving cell i. If the nbr(s) is not available, the method proceeds to step 464. At step 464, the method includes creating the E2 NR control message(s) for the serving cell i. If the nbr(s) is available, the method proceeds to step 432.
[0072] At step 432, the method includes detecting for each reported neighbour j of the serving cell i that the neighbour j is in the RIC NRT. If the neighbour j is in the RIC NRT, then at step 434, the method includes detecting that neighbour j is marked as “removed”. If the neighbour j is marked as “removed” then, at step 436, the method includes ignoring the report for the neighbour j. If the neighbour j is marked as “not removed” then, at step 438, the method includes determining that neighbour j has highest RSRP. If the neighbour j has highest RSRP then, at step 440, the method includes updating RSRP for neighbour j. At step 442, the method includes re-sorting the RIC NRT based on the RSRP and proceeds to step 444. If the neighbour j does not have the highest RSRP, the method proceeds to step 444. At step 444, outputs of step 438 and step 442 are aggregated. Further, at step 446, outputs of step 444 and step 436 are aggregated.
[0073] Similarly, if the neighbour j is not in the RIC NRT, then the method proceeds to step 448. At step 448, the method includes determining whether the RIC NRT is full. If the RIC NRT is not full then, at step 450, the method includes inserting neighbour j in the RIC NRT in a sorted order of RSRP. If the RIC NRT is full then, at step 452, the method includes determining whether the RSRP of neighbour j is greater than lowest RSRP in the NRT. If the RSRP of neighbour j is greater than the lowest RSRP in the NRT then, at step 456, the method includes removing the lowest RSRP neighbour. At step 458, the method includes inserting neighbour j in the RIC NRT in the sorted order of RSRP. If the RSRP of neighbour j is less than the lowest RSRP in the NRT then, at step 454, the method includes ignoring the report for neighbour j. At step 460, the method aggregates outputs of step 454 and step 458. At step 462, the method aggregates outputs of step 460 and step 450. At step 463, the method aggregates outputs of step 446 and step 462.
[0074] FIG. 5 is a flow chart (500) illustrating a neighbour cell management method in the RAN (100). At step 502, the method includes batch processing of the input data at the xApp (206) hosted on the Near-RT-RIC (114) and the rApp (204) hosted on the Non-RT-RIC (202). The input data is associated with the predefined period for the target cell. At step 504, the method includes periodically updating the neighbour relations table (NRT) at the E2 node based on the batch processing of the input data.
[0075] The proposed method provides an automatic neighbour relation (ANR) function in the O-RAN (e.g., disaggregated 5G RAN or the like) that supports high interoperability in a disaggregated multi-vendor environment which follow O-RAN paradigms. Advantageously, the batch input and processing of data (e.g., handover measurement data for rApp and ANR reports for xApp) for consumption of the rApp and the xApp at a desired time scale provides more efficient use of computing and networking resources. The use of infinite size NRTs allows to have a large pool of neighbours and customizable choices of neighbours (e.g., for network slicing). The proposed disclosure provides more flexibility in granularity of the processing, thereby providing more robust data in different scenarios (in an example, in general, the E2 nodes may not support all the granularities, the xApp needs for the data).
[0076] The various actions, acts, blocks, steps, or the like in the flow charts (300-500) 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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).
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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 method for managing a plurality of neighbour cells of a target cell in a radio access network (100), wherein the target cell accommodates the plurality of neighbour cells, the method comprising:
batch processing of an input data at an xApp (206) hosted on a Near-Real-Time RAN Intelligent Controller (Near-RT-RIC) (114) and an rApp (204) hosted on a Non-Real-Time RAN Intelligent Controller (Non-RT-RIC) (202), wherein the input data is associated with a predefined period for the target cell; and
periodically updating neighbour relations table (NRT) at an E2 node based on the batch processing of the input data, wherein the E2 node comprises at least one of an open distributed unit (O-DU) (120), an open centralized unit (O-CU), and an O-RAN-compliant LTE eNB (long-term evolution evolved NodeB).

2. The method as claimed in claim 1, wherein the batch processing of the input data comprises:
batch processing of a handover (HO) measurement data associated with the target cell by the rApp (204) hosted on the Non-RT-RIC (202); and
batch processing of an automatic neighbour relation (ANR) report associated with the target cell by the xApp (206) hosted on the Near-RT-RIC (114).

3. The method as claimed in claim 1, wherein the method comprises combining, by the E2 node, the processed input data from the xApp (206) and the rApp (204) periodically.

4. The method as claimed in claim 1, wherein periodically updating the neighbour relations table (NRT) at the E2 node comprises executing a neighbour update technique for the target cell at the E2 node.

5. The method as claimed in claim 1, wherein the method comprises deactivating a neighbour cell from the plurality of neighbour cells when a number of handovers attempts for the neighbour cell in the processed input data associated with the predefined period is greater than a predefined threshold and the handover success ratio is lower than a predefined threshold.

6. The method as claimed in claim 1, wherein the method comprises:
maintaining an infinite size neighbour relation table (NRT) for the target cell by the xApp (206); and
updating the NRT for the target cell with priority neighbour cells in the infinite size NRT, wherein the priority neighbour cells having a Reference Signal Received Power (RSRP) is greater than a predefined RSRP threshold, wherein the priority neighbour cells are not deactivated neighbour cells.

7. The method as claimed in claim 6, wherein maintaining the infinite size NRT for the target cell comprises:
maintaining the predefined RSRP threshold for neighbour cells measurements;
receiving a RSRP signal;
comparing the RSRP signal associated with at least one neighbour cell from the plurality of neighbour cells with the predefined RSRP threshold; and
determining that a measurement for the at least one neighbour cell is performed based on the comparison; and
maintaining the infinite size NRT for the target cell based on the determination.

8. The method as claimed in claim 1, wherein information associated with the NRT comprises a unique cell identity of at least one neighbour cell from the plurality of neighbour cells.

9. The method as claimed in claim 1, wherein the method comprises sending measurement control information received from the rApp (204) and the xApp (206) to the E2 node to configure measurement reporting for at least one neighbour cell of a serving target cell.

10. The method as claimed in claim 9, wherein the measurement control information comprises a neighbour cell relation list including a cell identifier of the serving target cell reported from the processed input data of the xApp (206) and the rApp (204) periodically.

11. The method as claimed in claim 9, wherein the input data is received from the rApp (204) and the xApp (206) within an evaluation period that is related to an interval of the predefined period for the serving target cell.

12. The method as claimed in claim 1, wherein the Near-RT-RIC (114) is connected to the E2 node through an E2 interface, wherein the Non-RT-RIC (202) is connected to the Near-RT-RIC (114) through an A1 interface.

13. A radio access network (RAN) (100) comprising:
a Near-Real-Time RAN Intelligent Controller (Near-RT-RIC) (114) connected to an E2 node through an E2 interface;
a Non-Real-Time RAN Intelligent Controller (Non-RT-RIC) (202) connected to the Near-RT-RIC (114) through an A1 interface, wherein the RAN (100) is configured for:
batch processing of an input data at an xApp (206) hosted on the Near-RT-RIC (114) and an rApp (204) hosted on the Non-RT-RIC (202), wherein the input data is associated with a predefined period for the target cell; and
periodically updating neighbour relations table (NRT) at the E2 node based on the batch processing of the input data, wherein the E2 node comprises at least one of an open distributed unit (O-DU) (120), an open centralized unit (O-CU), and an O-RAN-compliant LTE eNB (long-term evolution evolved NodeB).