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 neighbor (neighbour) cell management 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 Neighbor 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 neighbor 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 neighbors 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 neighbors cell management in a wireless network (e.g., 5G wireless network, RAN or the like):
[0004] US20160165527A1 discloses neighbor relation information management that involves, for example: acquiring, reporting, exchanging, and updating neighbor relation information. The neighbor relation information is logged by an access terminal in a manner that does not affect access terminal paging or other mobility behavior.
[0005] A non-patent literature entitled “Simulating Long Term Evolution Self-Optimizing Based Networks’” discloses a simulator in which ANR, and Handover Optimization functions are implemented and evaluated using a real network scenario.
[0006] Another non-patent literature entitled “Self-optimization in long-term evolution (LTE): An Approach to Reduce Call Drops in Mobile Network” discloses a robust functionality of self-optimizing network, such as automatic neighbor list optimization, mobility load balancing optimization and handover optimization approach, that is used to improve voice call quality and make a self-automated mobile network that would be fruitful to reduce call drop rate.
[0007] But, none of the prior art references discloses techniques of timestamping when a neighbor cell associated with a target cell is removed by an rApp/xApp from a neighbor relation table (NRT) in the wireless network (e.g., RAN or the like) and temporary blocking of the neighbor cell based on a predefined network parameter to avoid immediate addition and removal of the same neighbor cell in the wireless network. 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 neighbor cell management in a wireless network (e.g., RAN or the like).
[0009] Another object of the present disclosure is to use a timestamping technique when a neighbor cell associated with a target cell is removed by an rApp or an xApp from a neighbor relation table (NRT) in the radio access network (RAN). The neighbor cell is temporarily blocked from being added back again based on a predefined network parameter to avoid immediate addition and removal of the same neighbor cell in the O-RAN.
[0010] Another object of the present disclosure is to provide that when the xApp receives an A1 NR policy from the rApp for a cell, the xApp marks at least one neighbor on a neighbor list as “removed” in an RIC NRT for the cell and records the current time as the timestamp for that neighbor. A neighbor marked as “removed” (removed by the rApp) in the RIC NRT will be treated as blocked and will not be added to the RIC NRT in an E2 node.
[0011] Another object of the present disclosure is to provide that when the xApp processes ANR reports from the E2 node, if certain time has elapsed since the timestamp for a neighbor of the cell which was marked as “removed”, the neighbor of the cell will be removed from the RIC NRT, which allows a Near-RT RIC to add this neighbor back to the NRT in RIC and the E2 nodes.

SUMMARY
[0012] Accordingly, the present disclosure provides neighbor cell management methods and a radio access network intelligent controller (RIC) for a RAN. The method includes temporarily controlling (blocking or unblocking) at least one neighbor cell associated with a target cell based on at least one predefined network parameter, so as to avoid: an immediate addition of the at least one neighbor cell in the RAN after an removal of the same neighbor cell in the O-RAN (100), or vice versa. The at least one neighbor cell is controlled for a predefined duration, wherein the predefined duration is based on a serving condition parameter of the RAN. The temporarily controlling the at least one neighbor cell associated with the target cell comprises one of: removing the at least one neighbor cell from at least one neighbor relation table (NRT) of the RIC and an E2 node and adding the same neighbor cell to the at least one NRT of the RIC and the E2 node. The RIC is at least one of a Near-Real-Time RAN Intelligent Controller (Near-RT RIC) and a Non-Real-Time RAN Intelligent Controller (Non-RT RIC). Further, the RAN includes at least one xApp hosted on the Near-real-time RIC and at least one rApp hosted on the Non-RT RIC, where the at least one rApp running on the Non-RT RIC communicates with the at least one xApp running on the Near-RT RIC to provide policy-based guidance for configuration of at least one of a service, resource, and platform-related policy in the RAN. The Non-RT RIC operates within a Service and Management Orchestration (SMO) framework for handling non-real-time (non-RT) events, wherein the Near-RT RIC operates as a cloud-based process on a network edge, wherein the Near-RT RIC provides policy-based guidance feedback to the Non-RT RIC through the at least one xApp. The method further includes timestamping the at least one neighbor cell when the at least one neighbor cell is temporarily blocked and recording the timestamp in an NRT of the RIC (i.e., RIC NRT).
[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 open radio access network (RAN) (or O-RAN system).
[0016] FIG. 2 illustrates a hybrid ANR (Automatic Neighbor Relation) in the RAN to manage a plurality of neighbor cells of each target cell.
[0017] FIG. 3 illustrates an example RIC solution architecture.
[0018] FIG. 4 illustrates an example near-RT RIC architecture.
[0019] FIG. 5 illustrates an example non-RT RIC MVP (Minimum viable plan) architecture.
[0020] FIG. 6 is a flowchart illustrating a method, implemented by an xApp, for handling ping-ponging behavior using the hybrid automatic neighbor relation and an A1 policy.
[0021] FIG. 7A-FIG. 7F are flowcharts illustrating a method, implemented by an xApp, for handling ping-ponging behavior using the hybrid automatic neighbor relation, E2 and ANR report handling.
[0022] FIG. 8 is a flow chart illustrating a neighbor cell management method in the RAN.

DETAILED DESCRIPTION
[0023] 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.
[0024] 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.
[0025] 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.
[0026] The deficiencies in previous techniques (as discussed in background section) can be solved by the proposed neighbor cell management methods in a radio access network (RAN). The method can be used to avoid a ping-pong behaviour between NRTs (neighbor relation tables) at E2 nodes and a RAN intelligent controller (RIC).
[0027] The proposed method uses timestamping when a neighbor cell associated with a target cell is removed by an rApp or an xApp from a neighbor relation table (NRT) in a RAN. The neighbor cell is temporarily blocked based on a predefined network parameter to avoid immediate addition and removal of the neighbor cell after the removal of the same neighbor of the target cell. In other words, the proposed method uses timestamping to avoid ping-ponging behavior in an ANR (Automatic Neighbor Relation). The xApp records a timestamp for the neighbor cells to be removed and after a certain period, the neighbor cells are moved from the RIC NRT. The timestamp is a recorded current time when the neighbor cells are marked as “removed” in a NRT. By using the timestamping approach, the neighbor cells are temporarily blocked for immediate addition and removal in the RAN. The neighbor cell is a neighbor (or neighbour) to the target cell and neighbor relation provides information about the neighbor cell. Each target cell holds a table of detected neighbor cells which are used in connection with handovers, where the table is called neighbor relation table (NRT).
[0028] FIG. 1 illustrates an open radio access network (RAN) (or O-RAN system) (100) (interchangeably be called as O-RAN architecture (100)). Referring to FIG. 1, the O-RAN (100) is a part of telecommunications systems which connects individual devices to other parts of a network through radio connections. The O-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. The O-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.
[0029] 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).
[0030] 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 a bandwidth of a wireless communication network and at least one of a plurality of UEs (124a, 124b, 124c, 124d) (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.
[0031] 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 O-RAN (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 Near-RT-RIC (114) is connected to an O-CU (320) (shown in FIG. 3), the O-DU (120), and the O-RU (122) through the E2 interface.
[0032] 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) (combinedly called as an E2 node) with the E2 interface for data collection. The E2 node can connect only to one Near-RT-RIC, but one Near-RT-RIC can connect to multiple E2 nodes. Typically, protocols that go over the E2 interface are control plane protocols that control and optimize the elements of the E2 node and the resources they use.
[0033] Non-Real Time (Non-RT) control functionality greater than 1s) and Near-Real Time (Near-RT) control functions on a timescale of 1ms to 1second 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.
[0034] The O-RAN (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 (114) respectively.
[0035] Further, the O-CU (Open Central Unit) (320) is a logical node hosting RRC (Radio Resource Control), SDAP (Service Data Adaptation Protocol), and PDCP (Packet Data Convergence Protocol). The O-CU (320) 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.
[0036] 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.
[0037] The O-Cloud (112) is a collection of physical RAN nodes (that host various RICs, CUs, and DUs), software components (such as operating systems and runtime environments) and the SMO (102), 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.
[0038] 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).
[0039] 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 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.
[0040] 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.
[0041] 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).
[0042] Now referring to the various interfaces used in the O-RAN (100) as mentioned above.
[0043] 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.
[0044] 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 O-RAN (100) with the O1 or O2 interfaces.
[0045] 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).
[0046] 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).
[0047] 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.
[0048] 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).
[0049] 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.
[0050] 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.
[0051] 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.
[0052] FIG. 2 illustrates a hybrid Automatic Neighbor Relation (ANR) in the O-RAN system (100) to manage a plurality of neighbor cells (210b, 210c, 210d) of each target cell. The O-RAN (100) acts as a neighbor cell management system. The hybrid ANR is a SON (self-organizing network) feature associated with the automatic configuration of neighbor cell relations at a given base station (e.g., e-NodeB, gNodeB or the like). A Neighbor Relation Table (NRT) held at the base station will contain an entry for each neighboring cell. Each entry will contain all the information the base station needs to know about its neighbor. The ANR functionality is to relieve an operator/service provider from the burden of manually managing Neighbor Relations (NRs). The ANR function resides in the base station and manages the conceptual Neighbor Relation Table (NRT). A neighbor detection function is located within the ANR, where the neighbor detection function finds new neighbors and adds them to the NRT. The ANR also contains a neighbor removal function which removes outdated NRs.
[0053] The various elements and functions of the ORAN system/architecture (100) are already explained in FIG. 1. 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.
[0054] 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 ORAN (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.
[0055] The Near-RT-RIC (114) operates as a cloud-based process on a network edge of the O-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 neighbor cell on a neighbor list as removed in an RIC NRT and an E2 node for the cell. The neighbor list is an automatic discovery and setup of neighbor relations when the UE (124a-124d) moves from a serving eNB to a target eNB. The neighbor 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 neighbor cell, etc.
[0056] In other words, the rApp (204) is designed to run on the Non-RT-RIC (202) providing additional value-added services to assist creation of policies that the Non-RT-RIC (114) delivers down to the xApp(s) (206) in the Near-RT-RIC (114) through the A1 interface, wherein the at least one rApp (204) temporarily blocks the at least one neighbor cell associated with the target cell from being immediately added back again based on a predefined network parameter, so as to avoid an immediate addition of the at least one neighbor cell in the O-RAN after the removal of the same neighbor cell in the RAN wherein the at least one neighbor cell is associated with the predefined network parameter. The predefined network parameter can be, for example, but not limited to, number of users and their locations, current load, signalling, and processing delay for context collection, capacity demand, re-configuration delay, and removed neighbor cell, etc.
[0057] Further, the Near-RT-RIC (114) timestamps the at least one neighbor cell when the at least one neighbor cell is temporarily blocked. The information/provisions related to timestamp is explained in FIG. 6, and FIG. 7A-FIG. 7F. The Near-RT-RIC (114) records the timestamp in the RIC NRT, wherein the RIC NRT resides in the Near-RT-RIC (114) that stores information about the at least one target cell and at least one neighbor cell to the target cell, wherein the RIC NRT comprises a Neighbor Cell Identifier (NCI) identifying the at least one neighbor cell.
[0058] Further, the at least one blocked neighbor cell is removed from the RIC NRT upon determining that a threshold time has elapsed for the at least one blocked neighbor cell since the recorded timestamp. The threshold time is a certain time period after which the blocked neighbor is allowed to be added back to the RIC NRT and the E2 node to avoid ping-ponging behavior. The at least one blocked neighbor cell is added back to the RIC NRT and the E2 node, upon determining that the threshold time has elapsed since the recorded timestamp for the at least one blocked neighbor cell, wherein information corresponding to the addition of the at least one blocked neighbor cell is updated in the rApp (204) running in the Non-RT-RIC (202) from the xApp (206) through the A1 interface and the at least one blocked neighbor cell is unblocked after a predefined duration. The RIC NRT is optimized by removing poorly performing at least one neighbor cell from the RIC NRT. The poor conditions are due to coverage problems, irregular placement of cells, unsuitable handoff performance, amount, number, or proportion of calls/UEs handed out undesirably, distant cells added to the neighbor list of a source cell etc. The at least one neighbor cell is controlled (blocked or unblocked) for the predefined duration, wherein the predefined duration is based on a serving condition parameter of the O-RAN (100). The serving condition parameter can be, for example, but not limited to serving eNB measurement results (including Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), path loss, etc.), and neighboring eNBs measurement results (optional). The eNBs control their measurements through a notification of measurement objects, cell lists, report modes, measurement metrics, measurement parameters, etc.
[0059] The O-RAN (100) also includes performance management (PM) counters (not shown) for marking addition or removal of the at least one neighbor cell in the NRT at which information of cells and their neighbor is stored. The removal/addition of the at least one neighbor cell is determined based on at least one of handover success performance, number of handovers, a reference signal received power (RSRP), quality (RSRQ) thresholds, maximum numbers of UEs (124a-124d), minimum numbers of UEs (124a-124d), increasing numbers of UEs (124a-124d) and decreasing numbers of UEs (124a-124d).
[0060] In an example, each E2 node (O-DU (120) or O-CU (320)), preferably the O-CU (or CU) (320), may capture radio signal quality measurements from the plurality of user equipment’s (UEs) (124b-124d) associated with the target cell. The radio signal quality measurements may also be associated with each of the plurality of neighbor cells (210b, 210c, 210d) of the target cell. The target cell may be any of the plurality of neighbor cells (210b, 210c, 210d). For instance, if a cell (210b) acts as the target cell, then the neighbor cells will be 210c, 210d. Similarly, if a cell (210c) acts as the target cell, then the neighbor cells will be 210b, 210d and so on so forth. The CU (320) 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.
[0061] FIG. 3 illustrates an example RIC solution architecture (300). The RIC solution architecture (300) may include the O-CU (320), the O-RU (122), the O-DU (120), the Non-RT-RIC (202), the Near-RT-RIC (114), the rApp(s) (204) and the xApp(s) (206). The operations and functions of the O-CU (320), the O-RU (122), the O-DU (120), the Non-RT-RIC (202), the Near-RT-RIC (114), the rApp(s) (204) and the xApp(s) (206) are already explained in connection with FIG. 1 and FIG. 2. The RIC solution architecture (300) may also include a BSS (Business Support System) infrastructure (302), an OSS (Operation Support System) and NOC (Network Operations Center) infrastructure (304), a global orchestrator (306), a RAN domain orchestrator (308), a RAN O&M (Operation and management) platform (310), a virtual / container infrastructure (312), and a commercial off-the-shelf (COTS) infrastructure (314).
[0062] The COTS infrastructure (314) supports IEEE 1588v2 Precise Time Protocol (PTP), so as to improve the time synchronization accuracy of minimum level (around 65ns) for carrier aggregation in the ORAN system (100). The RAN domain orchestrator (308) automates an end-to-end service lifecycle from planning and design to activation, optimization and assurance across the entire multivendor Open vRAN domain. The RAN domain orchestrator (308) supports infrastructure management, site registration function, image inventory management, platform installation, location, and topology management. It supports the following three functions such as RAN NSSMF (Network Slice Subnet Management Function), NF (Network Function) orchestration and cloud infrastructure management and operation. The RAN NSSMF decides whether to reuse an existing RAN NSSI or create a new RAN NSSI based on slice profile, shareability and availability of a matching RAN NSSI.
[0063] In the RIC solution architecture (300), a vRAN domain orchestration solution brings together the orchestration, OSS and analytics functions needed to fully automate all aspects of the RAN domain from planning and design to activation, assurance and optimization. The vRAN domain orchestration solution collects the data from the BSS infrastructure (302), the OSS & NOC infrastructure (304), the global orchestrator (306), the RAN domain orchestrator (308), the virtual/container infrastructure (312) and the COTS infrastructure (314). The BSS infrastructure (302) provides ‘BSS as a service’, making Communication Service Providers (CSPs) focus on creating, launching new services, and improving customer experience. The RAN O&M platform (310) supports Near-RT-RIC management, CU management, DU management and RU management. The RIC solution architecture (300) also includes a process framework having a customization framework (316) and a cloud native continuous integration and continuous delivery (CICD) (318) supporting site deployment, installation and commissioning in the RIC solution architecture (300).
[0064] FIG. 4 illustrates an example Near-RT-RIC architecture (400). Referring to FIG. 4, the Near-RT-RIC architecture (400) may include a messaging infrastructure (408) that supports an xApp on-boarding function, an xApp subscription management function, a policy control function, a RAN fault and telemetry streaming function, a self-manageability function, a platform manageability integration function and an open-source integration for a stream reporting function.
[0065] The Near-RT-RIC architecture (400) may also include the xApp(s) (206), an SDK/API (Software Development Kit/Application Programming Interface) (402), an O1 terminator (404), an A1 terminator (406), an E2 terminator (410), an RNIB (Radio Network Information Base) and UEIB (User Equipment Information Base), and a framework (412) comprising and supporting ELK & Grafana, RMR Library, REDIS dBaaS, Docker & Helm and Kubernetes Infrastructure. The xApp(s) (206) can be, for example, but not limited to an MLB xAPP, a DSS xAPP, an eMBB xAPP, a community xApps, any third Party xApps or the like. The xApp(s) (206) enables rule-based AI (artificial intelligence), options to adopt ML (machine learning) based trained models. Further, the xApp(s) (206) provides own RAN services.
[0066] The A1 terminator (406) simulates the Near-RT-RIC (114) for integration/testing. By using the E2 terminator (410), the RIC hosts the xApp(s) (206) that use the E2 interface to collect near real-time information and provide value added services in the Near-RT-RIC architecture (400). The RNIB captures the near real-time state of the underlying network and feeds RAN data to train the AI/ML models, which are then fed to the Near-RT-RIC (114) to facilitate radio resource management for subscribers. The UEIB contains entries for the UEs (124) and their identity.
[0067] The framework (412) provides shared libraries and classes for common support in the Near-RT-RIC architecture (400) in the form of RMR library. The framework (412) also provides a scope for custom integration in the Near-RT-RIC architecture (400). The Near-RT-RIC architecture (400) is scalable and has low latency.
[0068] Generally, the ELK & Grafana supports the data querying and analysis in the Near-RT-RIC architecture (400). The REDIS dBaaS is a fully managed in-memory NoSQL database, easily deployed in integrated environment. The Docker & Helm is an application package manager which can be used to run on top of Kubernetes. The Kubernetes infrastructure is a combination of resources (including servers, physical or virtual machines, cloud platforms and more) that supports a Kubernetes environment.
[0069] FIG. 5 illustrates an example non-RT-RIC-MVP (Minimum viable plan) architecture (500). The non-RT-RIC-MVP architecture (500) may include an application framework (512) having the rApp(s) (204) such as, but not limited to, rApp1 (204a), rApp2 (204b), rApp3 (204c), the Non-RT-RIC (202), the near-RT-RIC (114), a data source (502), an ODL SBI (A1 adaptor) (504), data brokers (506), a subscription manager (508) and a routing manager (510). The operations and functions of the application framework, the Non-RT-RIC (202) and the Near-RT-RIC (114) are already explained in connection with FIG. 1 to FIG. 4. A policy framework (residing in the Non-RT-RIC (202)) may include a policy management service, a policy engine, and a policy catalog. The policy management service, the policy engine, and the policy catalog are used for handling the policy management function. The policy management function corresponds to configuration of service, resource and platform related policies. The policy definition, execution, enforcement capability are exposed through the rApp(s) (204). The policy catalog triggers the decision logic based on output of the rApp(s) (204). The data source (502), fetching information from the O-RAN (100), may include an enrich information DB (database), a software defined network-radio (SDN-R) and a DCAE (Data Collection, Analytics and Events). The SDN-R may be implemented as the data source for the policy framework. The DCAE may be utilized for VES (Virtual Network Function (VNF) Event Stream) collection, data brokerage, and data source for policy framework. The non-RT-RIC-MVP architecture (500) may be integrated with southbound systems and northbound systems through interfaces (e.g., A1 interfaces).
[0070] The data brokers (506) connect with requisite data via a data pipeline in the non-RT-RIC-MVP architecture (500). The subscription manager (508) manages subscription information in the non-RT-RIC-MVP architecture (500). The routing manager (510) is responsible for distributing routing policies among the other platform components and the xApp(s) (206) in the non-RT-RIC-MVP architecture (500).
[0071] FIG. 6 is a flowchart (600) illustrating a method, implemented by the xApp (202), for handling ping-ponging behavior using the hybrid automatic neighbor relations and the A1 policy. At step 602, the method includes receiving an A1 NR policy from the rApp (204) (i.e., ANR rApp). At step 604, the method includes detecting if each service (or servicing) cell i is in the A1 NR policy. If no more cell is in the A1 NR policy, at step 614, the method includes sending E2 NR control messages to the E2 node(s). At step 606, the method includes detecting if neighbor of cell i is available. If no more neighbor of cell i is available, at step 612, the method includes creating E2 NR control for the cell i and the result of the step 612 is fed to step 604, thus a loop is formed. At step 608, the method includes marking the neighbor j as “removed” in the RIC NRT. At step 610, the method includes adding a timestamp_ to the neighbor j when it is marked as “removed”. The timestamp_ is a recorded current time when the the neighbor j is marked as “removed”. After adding the timestamp_ to the neighbor j, the step/operation 606 continues again in the form of loop.
[0072] FIG. 7A-FIG. 7F are flowcharts (700) illustrating a method, implemented by the xApp (206), for handling ping-ponging behavior using the hybrid automatic neighbor relations, E2 and ANR report handling.
[0073] At step 702, the method includes determining that a periodic timer is expired. The periodic timer keeps track of a processing period for which ANR reports sent by the E2 nodes are processed by the xApp (206). At step 704, the method includes fetching the ANR reports sent by the E2 nodes since the last processing period. At step 706, the method includes determining availability of ANR report(s). If the method determines that there is no more ANR report then, the method proceeds to step 720, otherwise checks at step 722 for each neighbor (aka “nbr”) in the RIC NRT whether the nbr is marked as “removed” and certain time threshold has elapsed since the timestamp was added. If the nbr marked as “removed” and certain time threshold has elapsed since the timestamp was added then, at step 724, the method includes removing the nbr from the RIC NRT and proceeds to step 726. If not, the method proceeds to step 726. At step 726, the method aggregates outputs of step 722 and step 724.
[0074] Similarly, if the method determines that there is ANR report(s) available then, the method proceeds to 708. At step 708, the method includes determining whether neighbor j of the cell i has multiple RSRP measurements in a single event (e.g., A4 event or the like) measured by the UE (124) and determining that the event reporting interval is less than a threshold average. If the neighbor j of the cell i has multiple RSRP measurements in the single event measured by the UE (124) and the event reporting interval is less than the threshold average then, at step 710, the method computes the short-term average of the RSRP(s), which is forwarded to step 712. If the conditions mentioned at step 708 is not satisfied, then the method proceeds to step 712. At step 712, the method aggregates outputs of step 708 and step 710.
[0075] At step 714, the method includes determining whether the neighbor j of cell i is reported in multiple reports (regardless of the measured by the same UE (124) or not and regardless of its RSRP being a short-term average or not). If the neighbor j of cell i is reported in multiple reports, then, at step 716, the method includes taking the maximum RSPR for nbr of cell i and proceeds to step 718. If no, the method proceeds to step 718. At step 718, the outputs of step 714 and step 716 are aggregated.
[0076] At step 728, the method includes detecting the availability of the cell(s) for each reported service (servicing) cell i. If the method detects that no more cell is available then, at step 766, the method includes sending the E2 NR control messages to the E2 node(s). If the cell(s) is available, the method proceeds to step 730 to check the availability of nbr for each reported neighbor j of cell i. If the nbr(s) is not available, the method proceeds to step 764. At step 764, the method includes creating the E2 NR control for cell i. If the nbr is available, the method proceeds to step 732.
[0077] At step 732, the method includes detecting that the nbr j is in the RIC NRT. If the nbr j is in the RIC NRT then, at step 734, the method includes detecting that nbr j is marked as “removed”. If the nbr j is marked as “removed” then, at step 736, the method includes ignoring the report for nbr j. If the nbr j is marked as “not removed” then, at step 738, the method includes determining that nbr j has the highest RSRP. If the nbr j has the highest RSRP then, at step 740, the method includes updating RSRP for nbr j. At step 742, the method includes re-sorting the RIC NRT based on the RSRP and proceeds to step 744. If the nbr j does not have the highest RSRP, the method proceeds to step 744. At step 744, outputs of step 738 and step 742 are aggregated. Further, at step 746, the outputs of step 744 and step 736 are aggregated.
[0078] Similarly, if the nbr j is not in the RIC NRT, then the method proceeds to step 748. At step 748, the method includes determining whether the RIC NRT is full. If the RIC NRT is not full then, at step 750, the method includes inserting nbr j in the RIC NRT in sorted order of RSRP. If the RIC NRT is full then, at step 752, the method includes determining whether the RSRP of nbr j is greater than the lowest RSRP in the NRT. If the RSRP of nbr j is greater than the lowest RSRP in the NRT then, at step 756, the method includes removing the lowest RSRP neighbor. At step 758, the method includes inserting nbr J in the RIC NRT in the sorted order of RSRP. If the RSRP of nbr j is less than the lowest RSRP in the NRT then, at step 754, the method includes ignoring the report for nbr j. At step 760, the method aggregates outputs of step 754 and step 758. At step 762, the method aggregates outputs of steps 760 and step 750. At step 763, the method aggregates outputs of steps 746 and step 762.
[0079] FIG. 8 is a flow chart (800) illustrating the neighbor cell management method in the O-RAN (100). At step 802, the method includes temporarily controlling (blocking or unblocking) the at least one neighbor cell associated with the target cell based on the at least one predefined network parameter, so as to avoid one of the immediate addition of the at least one neighbor cell in the O-RAN (100) and the immediate removal of the at least one neighbor cell in the O-RAN (100) after the removal of the same neighbor cell in the O-RAN (100), or vice versa.
.
[0080] Advantageously, the method prevents the ping-pong behaviour/ oscillations between NRTs at the E2 nodes and the RIC.
[0081] The various actions, acts, blocks, steps, or the like in the flow charts (600-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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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).
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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 neighbor cell management method for an open radio access network (O-RAN) (100), wherein the neighbor cell management method comprises:
temporarily controlling, by a radio access network intelligent controller (RIC), at least one neighbor cell associated with a target cell based on at least one predefined network parameter, so as to avoid: an immediate addition of the at least one neighbor cell in the O-RAN (100) after an removal of the same neighbor cell in the O-RAN (100), wherein the RIC is at least one of a Near-Real-Time RAN Intelligent Controller (Near-RT-RIC) (114) and a Non-Real-Time RAN Intelligent Controller (Non-RT-RIC) (202).

2. The neighbor cell management method as claimed in claim 1, wherein temporarily controlling the at least one neighbor cell associated with the target cell comprises one of: removing the at least one neighbor cell from at least one neighbor relation table (NRT) of the RIC and an E2 node and adding the at least one neighbor cell to the at least one NRT of the RIC and the E2 node, wherein the E2 node is one of an open distributed unit (O-DU) (120), an open centralized unit (O-CU) (320), and an O-RAN-compliant long-term evolution evolved NodeB (LTE eNB).

3. The neighbor cell management method as claimed in claim 1, wherein the method comprises:
timestamping, by the RIC, the at least one neighbor cell when the at least one neighbor cell is temporarily blocked; and
recording, by the RIC, the timestamp in an NRT of the RIC.

4. The neighbor cell management method as claimed in claim 1, wherein the method further comprises associating, by the RIC, the at least one neighbor cell with the at least one predefined network parameter.

5. The neighbor cell management method as claimed in claim 1, wherein the method comprises updating, by the RIC, a neighbor list of an NRT of the RIC while temporarily controlling the at least one neighbor cell associated with the target cell, wherein the neighbor list is an automatic discovery and setup of neighbor relations based on measurement from at least one User Equipment (UE) (124)

6. The neighbor cell management method as claimed in claim 1, wherein the at least one neighbor cell is controlled for a predefined duration, wherein the predefined duration is based on a serving condition parameter of the O-RAN (100).

7. The neighbor cell management method as claimed in claim 1, wherein the method comprises unblocking, by the RIC, the at least one blocked neighbor cell after a predefined duration.

8. The neighbor cell management method as claimed in claim 1, wherein the open RAN (100) comprises at least one xApp (206) hosted on the Near-real-time-RIC (114) and at least one rApp (204) hosted on the Non-Real-Time-RIC (202).

9. The neighbor cell management method as claimed in claim 8, wherein the at least one rApp (204) running on the Non-RT-RIC (202) communicates with the at least one xApp (206) running on the Near-RT-RIC (114) to provide policy-based guidance for the configuration of at least one of service, resource, and platform-related policy in the O-RAN (100).

10. The neighbor cell management method as claimed in claim 8, wherein a policy is received by the at least one xApp (206), wherein the xApp (206) receives the policy from the rApp (204).

11. The neighbor cell management method as claimed in claim 8, wherein the Non-RT-RIC (202) operates within a Service and Management Orchestration (SMO) framework (102) for handling non-real-time (non-RT) events, wherein the Near-RT-RIC (114) operates as a cloud-based process on a network edge, wherein the Near-RT-RIC (114) provides policy-based guidance feedback to the Non-RT-RIC (202) through the at least one xApp (206).

12. The neighbor cell management method as claimed in claim 1, wherein the Near-RT-RIC (114) and the Non-RT-RIC (202) host cloud-native, microservice-based applications, wherein the cloud-native, microservice-based applications comprise at least one xApp (206) and at least one rApp (204).

13. An open radio access network (O-RAN) (100), comprises:
a Non-Real-Time RAN Intelligent Controller (Non-RT-RIC) (202) residing in the SMO (102), wherein the Non-RT-RIC (202) provides at least one of a policy-based guidance, a model management, and enrichment information to a Near-Real-Time RAN Intelligent Controller (Near-RT-RIC) (114),
wherein the Non-RT-RIC (202) controls Radio Resource Management (RRM) decisions in the E2 nodes, wherein the Non-RT-RIC (202) provides a policy to the Near-RT-RIC (114) to mark at least one neighbor cell on a neighbor list as removed in an RIC NRT and an E2 node for a cell, wherein the E2 node comprises at least one of an open distributed unit (O-DU) (120), an open centralized unit (O-CU) (320), and an ORAN-compliant LTE eNB (long-term evolution evolved NodeB), wherein the E2 node allows an RIC to control procedures and functionalities of the E2 node, wherein the O-DU (120) is responsible for real-time scheduling functions and connects each component with at least one other component in the O-RAN (100), wherein the O-CU (320) is responsible for non-real-time function in the O-RAN (100),
wherein the Near-RT-RIC (114) timestamps the at least one neighbor cell when the at least one neighbor cell is temporarily blocked, and
wherein the Near-RT-RIC (114) records the timestamp in the RIC NRT, wherein the RIC NRT resides in the Near-RT-RIC (114) that stores information about the at least one target cell and the at least one cell that is neighbor to the target cell, wherein the RIC NRT comprises a Neighbor Cell Identifier (NCI) identifying the at least one neighbor cell.

14. The O-RAN (100) as claimed in claim 13, wherein the O-RAN (100) comprises at least one rApp (202) designed to run on the Non-RT-RIC (202) providing additional value-added services to assist a creation of policies that the Non-RT RIC (114) delivers down to at least one xApp (206) in the Near-RT RIC (114) through an A1 interface, wherein the at least one xApp (206) temporarily blocks the at least one neighbor cell associated with a target cell based on a predefined network parameter, so as to avoid an immediate addition of the at least one neighbor cell in the O-RAN (100) after a removal of the same neighbor cell in the O-RAN (100).

15. The O-RAN (100) as claimed in claim 13, wherein the Non-RT-RIC (202) is connected to the Near-RT-RIC (114) through an A1 interface, wherein the Near-RT-RIC (114) is connected to the O-CU (320), the O-DU (120), and an O-RU (Open – Radio Unit) (122) through an E2 interface.

16. The O-RAN (100) as claimed in claim 13, wherein at least one blocked neighbor cell is removed from a neighbor list of the RIC NRT upon determining that the recorded timestamp for the at least one blocked neighbor cell has elapsed.

17. The O-RAN (100) as claimed in claim 16, wherein the at least one blocked neighbor cell is allowed to be added back to the RIC NRT and the E2 node, upon determining that a threshold time has elapsed since the recorded timestamp for the at least one blocked neighbor cell, wherein the addition of the at least one neighbor cell is done and information corresponding to the addition of the at least one neighbor cell is updated by both near-RT RIC xApp and E2 nodes

18. The O-RAN (100) as claimed in claim 13, wherein optimization of the RIC NRT comprises removal of poorly performing at least one neighbor cell from at least one neighbor relation table (NRT).

19. The O-RAN (100) as claimed in claim 13, wherein the O-RAN (100) comprises performance management (PM) counters for marking addition of the at least one neighbor cell or removal of the at least one neighbor cell.

20. The O-RAN (100) as claimed in claim 13, wherein removal of the at least one neighbor cell is determined based on at least one of the handover success performance, number of handovers, reference signal received power (RSRP), reference signal received quality (RSRQ) thresholds, maximum numbers of UEs (124), minimum numbers of UEs (124), increasing numbers of UEs (124) and decreasing numbers of UEs (124).