DESC:FIELD OF INVENTION
[0001] The embodiments of the present disclosure generally relate to telecommunication deployment. More particularly, the present disclosure relates to systems and methods for enabling mobility load balancing of self-organising networks in an Open Radio Access Network (O-RAN).

BACKGROUND OF THE INVENTION
[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.
[0003] Load balancing is a methodical and efficient distribution of network or application traffic across multiple servers in a server farm. Each load balancer sits between different types of cell combinations and receives and distributes incoming requests to any available server capable of fulfilling them. A modern mobile communications network comprises a combination of different cell types and different access technologies. As cellular networks evolve from 4th generation (4G), 5th generation (5G), and then to 6th generation (6G) along with other radio access technologies such as Wireless Fidelity (WiFi), mobile subscriptions also increase exponentially. The deployment and load balancing of very high-density heterogeneous networks (HetNets) also increase to fulfill the demands of the increasing number of subscribers. The HetNets are generally built by Multi-Portfolio and Multi-Vendor-based solutions.
[0004] The operator faces multiple challenges during greenfield or brownfield deployments of HetNets. One of the challenges is the demand for high-quality installations that covers continuous monitoring of performance and health of the deployed networks. Further, dynamically adapting to changing environments and making proactive adjustments and optimization are also challenging for mobile operators.
[0005] These challenges demand very high manual work and an extensive delay occurs due to regular/frequent field visits that lead to very huge Operational Expenses (OPEX). To overcome these deficiencies and drastically reduce the OPEX, a Self-Organizing Network (SON) is the solution. The SON may be a Self-Organizing Network or a Self-Optimizing Network. The SON may be an automation technology that may enable the network to set itself up and self-manage resources and configuration to achieve optimal performance. The SON may function under three categories. The first category is self-configuration. Self-configuration may aid in seamlessly integrating into the network through an automatic configuration of key parameters. Self-configuration is the most valuable during initial network deployments. It includes several capabilities such as Plug-and-Play functionalities (PnP), Automatic Neighbour Relation function (ANR), and Physical Layer Cell Identity (PCI) selection and conflict resolution functions.
[0006] The second category is self-optimization. Self-optimization aids in enhanced network performance through near real-time optimization of radio and network configurations. Self-optimization is valuable throughout the lifetime of the network. Self-optimization includes various capabilities such as Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), Random Access Channel (RACH) Optimization, Energy Saving (ES), Radio Link Failure Reporting, Coverage and Capacity Optimization (CCO), Data Link (DL) Power control, Remote Electrical Tilt (RET), Forward Handover, Frequent Handover Mitigation (FHM]), and Interference Mitigation (Inter-Cell, Intra-Cell, Intra Radio Access Technology (Intra-RAT), Inter Radio Access Technology (Inter-RAT)).
[0007] The third category is self-healing. Self-healing allows adjacent cells to maintain network quality in case a cell/sector fails, providing resiliency (reliability) in the face of unforeseen outage conditions. Self-healing is valuable throughout the lifetime of the network. Self-healing includes various capabilities such as Cell Outage Detection (Dead/Sick/Sleeping cell/sector/beam), Cell Outage Recovery, Cell Outage Compensation, and Cell Outage Compensation Recovery.
[0008] The above SON functions are handled by SON algorithms either individually or in groups. SON algorithms perform the functionalities like Monitoring the network(s) by collecting management data including Management Data Analytics Services (MDAS) data, Analysis of the management data to determine if there are issues in the network(s) that need to be resolved, decision on the SON actions to resolve the issues, execution the SON actions and Evaluation of whether the issues have been solved by analysing the management data. Based on the location of the SON algorithm, SON is categorized into four different solutions that are possible for implementing various SON use cases, the solution is selected depending on the needs of the SON use cases.
[0009] Minimization of Drive Test (MDT) functionality may have been designed to operate independently from the SON, although its functionalities are reused wherever possible. The above SON functions may be handled by SON algorithms either individually or in groups. The SON algorithms may perform the functionalities like monitoring the network(s) by collecting management data including MDAS data and analysis of the management data to determine if there are issues in the network(s) that need to be resolved. The SON algorithms may also decide on the SON actions to resolve the issues and execute the SON actions for resolution. Further, the SON algorithms may evaluate whether the issues have been resolved by analyzing the management data.
[0010] Based on the location of the SON algorithm, the SON may be categorized into four different solutions that may be possible for implementing various SON use cases. The solution may be selected depending on the needs of the SON use cases. A Centralized SON (C-SON) may include the function that the SON algorithm executes in the management system. A Cross Domain-Centralized SON (CD C-SON) may include the function that the SON algorithms may execute in the Cross-Domain (CD) layer. Further, a Domain-Centralized SON (D C-SON) may be the SON algorithm that may execute in the Domain layer. Furthermore, a Distributed SON (D-SON) may be the SON algorithm in the NFs.
[0011] Thereafter, a Hybrid SON (H-SON) may be the SON algorithm that may be executed at two or more levels like the Network Function (NF) layer, Domain layer, or Cross Domain (CD) layer. Since the SON algorithms are according to implementation, different vendors may choose different approaches for their SON solutions. Some vendors may choose the C-SON approach, some may choose the D-SON approach and others may choose the H-SON approach-based solutions. The operators may inevitably use multivendor solutions while deploying HetNets.
[0012] In 3GPP specifications for the SON functions, a description of the functions is provided but the specification does not say how the same must be implemented. This leads to multi-vendor integration issues and discourages operators from implementing the SON in their networks. The O-RAN alliance is a consortium that aims to alleviate these multivendor interoperability issues, but the SON functionalities have not been addressed in the O-RAN architecture. Moreover, since the SON algorithms are left to implementation, different vendors may choose different approaches for their SON solutions. Some vendors may come up with Centralised SON (C-SON) approach, some with Distributed SON (D-SON) approach, and others with Heterogenous SON approach-based solutions. The operators inevitably use multivendor solutions while deploying HetNets.
[0013] FIG. 2A illustrates a typical 5G HetNet deployment scenario wherein management entities like Network Management System (NMS) from a different vendor, a set of Element Management Systems (EMSes) from a different set of vendors, Radio Access Network (RAN) nodes like Next Generation NodeB (gNB)-Control units (CU) from a different set of vendors, and gNB-distributed units (DU) from a different set of vendors. The operator may face issues in the deployed HetNet of FIG. 1. One of the issues is that D-SON of gNB-CU-1 (116) and gNB-CU-2 (124) may not coordinate well as both are from different vendors, though they communicate each other via an open Xn interface.
[0014] Another issue is that D-SON of gNB-CU-2 (124) and the Hybrid SON of gNB-CU-n (130) (D-SON + D C-SON) may not coordinate well as both are from different vendors, though they communicate with each other via the open Xn interface. A key issue is that C-SON can be realized as either collocated with management entities (such as EMS or NMS) or as a standalone entity. Integrating the C-SON as a standalone entity with RAN nodes is extremely difficult, as the interface is left to implementation. Moreover, CD C-SON in the NMS (106) may impact the performance of the D C-SON and D-SON functionalities, operating in the multi-vendor environment.
[0015] Another issue lies in integrating the 3rd party SON solutions partially in the HetNet which leads to degradation of the overall Key Performance Indicators (KPIs). Further, L3- Radio Resource Management (RRM) coordination across the neighbor gNB-CUs (116, 124, 130) may be lacking irrespective of the same or multivendor scenarios, which will have an impact on the overall KPI performance. L3-RRM and L2-RRM coordination across the multi-vendor gNB-CU (116, 124, 130) and gNB-DUs (118, 120, 122, 126, 128, 132) may have an impact on the dynamic resource sharing and allocation.
[0016] The SON and Radio Resource Management (RRM), being a proprietary implementation, have a significant impact on the overall performance while multiple vendors coordinate with one other across the Xn interface. Each algorithm behaves differently and has its own limitations. Even if the vendors are ready to integrate with the third-party solutions [SON and/or RRM], the vendors may not deterministically quantify/confirm the output performance, mainly due to the vendors’ solutions. Such a situation always ends with a clash among the agreed vendors.
[0017] One possible solution to resolve these issues or limitations is to make the interface between SON solutions and the interacting RAN nodes, an open interface as much as possible. The O-RAN alliance is a worldwide community of mobile network operators, vendors, and research and academic institutions operating in the Radio Access Network (RAN) industry. O-RAN ALLIANCE’s mission is to re-shape the RAN industry towards more intelligent, open, virtualized, and fully interoperable mobile networks. The new O-RAN standards will enable a more competitive and vibrant RAN supplier ecosystem with faster innovation to improve user experience. O-RAN-based mobile networks will at the same time improve the efficiency of RAN deployments as well as operations by the mobile operators.
[0018] FIG. 2 illustrates the logical Architecture defined by the O-RAN. Within the logical architecture of O-RAN, as shown in FIG. 2, the radio side includes Near-Real Time (RT) RAN Intelligent controller (224) (RIC), O-RAN Central Unit Control Plane (O-CU-CP) (228), O-RAN Central Unit-User Plane (O-CU-UP) (230), O-RAN Distributed Unit (O-DU) (232-1), and O-RAN Radio Unit (O-RU) (232-2) functions. The E2 interface connects Evolved Node B (O-eNB) to Near Real-Time RAN Intelligent Controller (Near-RT RIC). Although not shown in this figure, the O-eNB does support O-DU and O-RU functions with an Open Fronthaul interface between them. The management side includes Service and Management Orchestration (SMO) Framework containing a Non Real-Time RAN Intelligent Controller (Non-RT-RIC) function. The ORAN-Cloud (O-Cloud) (234), on the other hand, is a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions (such as Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU, etc.), the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.) and the appropriate management and orchestration functions. As shown in FIG. 2B, the O-RU terminates the Open Fronthaul M-Plane (236) interface towards the O-DU and SMO.
[0019] Thus, as can be seen, the traditional approaches have many limitations. As the mobile subscription is exponentially increasing, the data demand is becoming very high for each subscriber. Along with the explosion of the cellular heterogeneous network deployment, there is a huge demand for the deployment of Wi-Fi Access points (AP), to fulfill the huge data throughput requirements. As a result, the operator is densely deploying the Wi-Fi Access Points which may operate at 2.4GHz, 5GHz, and even at higher frequencies. Also, the operator is forced to use multivendor solutions to deploy in its network for the scenarios like carrier-grade Wi-Fi, enterprise Wi-Fi, Mi-Fi, Home Wi-Fi, etc. With a massive number of APs deployed, the interference is becoming a crucial issue to deal with. Future networks must deal with this interference management issue through SON/RRM functionalities for organization and optimization of APs. If the APs are densely deployed without coordination, they may exhibit poor channel/spectrum reuse. Moreover, significant contention among APs and clients might occur, resulting in low throughput and poor end-user experience.
[0020] Further, the prior art does not provide for any mechanisms to realize the Mobility Load Balancing function in an O-RAN Architecture nor discloses any functional split mechanism between different entities in an O-RAN architecture and the associated data/control flow mechanisms.
[0021] Therefore, there is a well-felt need to provide systems and methods that can overcome the shortcomings of the existing prior art.

OBJECTS OF THE PRESENT DISCLOSURE
[0022] Some of the objects of the present disclosure, which at least one embodiment herein satisfies, are as listed herein below.
[0023] An object of the present disclosure is to provide a system and methods for realizing the Mobility Load Balancing (MLB) functionality of SON in an O-RAN architecture.
[0024] An object of the present disclosure is to provide a system and method for enabling data collection and interworking methods thereof.
[0025] An object of the present disclosure is to provide a system and method for facilitating functional split for MLB and the related functional flows between the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the Non-Real Time Radio Intelligent Controller (Non-RT RIC).
[0026] An object of the present disclosure is to provide a system and method that cover the locality of execution of the MLP function including a possible split between the gNB (called the E2 node in the O-RAN Architecture), Non-RT RIC, and the Near RT RIC.
[0027] An object of the present disclosure is to provide a system and method that facilitate specific mechanisms of data collection to facilitate the MLB functional execution in the Near and Non-RT RIC entities.

SUMMARY
[0028] This section is provided to introduce certain objects and aspects of the present invention in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0029] In an aspect, the present disclosure provides a system for realizing Mobility Load Balancing (MLB) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN). The system comprises a Non-Real-Time Radio Access Network Intelligent Controller (non-RT RIC) that is configured to transmit a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC. The resource status request is transmitted to the one or more E2 nodes via an E2 interface. Further, the Non-RT RIC of the system receives load information of the cell from the one or more E2 nodes based on the transmitted resource status request.
[0030] Further, the Non-RT RIC of the system obtains reports from the one or more E2 nodes based on the collected load information. The reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipments (UEs) associated with the cell. The reports obtained from the one or more E2 nodes further comprise a measurement of the load information. The measurement of the load information is performed by one or more E2 nodes. Further, the Non-RT RIC of the system transmits the obtained reports to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC). The reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure.
[0031] Further, the Non-RT RIC of the system receives a Handover (HO) Trigger value from the Near-RT RIC based on the reports. The HO Trigger value is received from the Near-RT RIC via an E2 interface. Further, the Non-RT RIC of the system reduces a load of the cell based on the modified HO Trigger value. The load of the cell is restored by the Near-RT RIC when the load of the cell becomes less than an average load within a given time. The Near-RT RIC is configured to receive reports based on load information of the cell. Further, the Near-RT RIC offloads the cell based on the received reports to one or more neighbour cells.
[0032] Further, the Near-RT RIC obtains load information from the one or more neighbour cells. Further, the Near-RT RIC generates a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information. Further, the Near-RT RIC transmits the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell. The one or more neighbour cells have cell load less than an average load within a given time period.
[0033] In an aspect, the present disclosure provides a method for realizing Mobility Load Balancing (MLB) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN). The method includes transmitting a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC. The resource status request is transmitted to the one or more E2 nodes via an E2 interface. Further, the method includes receiving load information of the cell from the one or more E2 nodes based on the transmitted resource status request. Further, the method includes obtaining reports from the one or more E2 nodes based on the collected load information. The reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipment (UEs) associated with the cell.
[0034] The reports obtained from the one or more E2 nodes further comprise a measurement of the load information. The measurement of the load information is performed by one or more E2 nodes. Further, the method includes transmitting the obtained reports to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC). The reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure. Further, the method includes receiving a Handover (HO) Trigger value from the Near-RT RIC based on the reports. The HO Trigger value is received from the Near-RT RIC via an E2 interface. Further, the method includes reducing a load of the cell based on the modified HO Trigger value. The load of the cell is restored by the Near-RT RIC when the load of the cell becomes less than an average load within a given time.
[0035] The Near-RT RIC is configured to receive reports based on load information of the cell. Further, the Near-RT RIC offloads the cell based on the received reports to one or more neighbour cells. Further, the Near-RT RIC obtains load information from the one or more neighbour cells. Further, the Near-RT RIC generates a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information. Further, the Near-RT RIC transmits the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell. The one or more neighbour cells have a cell load less than an average load within a given time period.

BRIEF DESCRIPTION OF DRAWINGS
[0036] The accompanying drawings, which are incorporated herein, and constitute a part of this invention, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that invention of such drawings includes the invention of electrical components, electronic components or circuitry commonly used to implement such components.
[0037] FIG. 1 illustrates an exemplary network architecture (100) in which or with which the proposed system of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure.
[0038] FIGs. 2A and 2B illustrate exemplary representations (200 and 220) of existing HetNet deployment and the components associated with it, in accordance with an embodiment of the present disclosure.
[0039] FIG. 3 illustrates an exemplary block diagram representation (300) of system architecture, in accordance with an embodiment of the present disclosure.
[0040] FIG. 4 illustrates an exemplary MLB xApp [UC-1] representation (400) highlighting a tentative sequence flow for collecting load information for the serving cell from the associated E2 nodes in accordance with an embodiment of the present disclosure.
[0041] FIG. 5 illustrates an exemplary MLB xApp [UC-1] representation (500) highlighting flow for processing on load information for the serving cell received from the associated E2 nodes. in accordance with an embodiment of the present disclosure.
[0042] FIG. 6 illustrates an exemplary MLB xApp [UC-1] representation (600) of a tentative sequence flow for restoring to normal condition, post the MLB offload in accordance with an embodiment of the present disclosure.
[0043] FIG. 7 is an illustrated embodiment (700) of an alternative deployment scenario for MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure.
[0044] FIG. 8 illustrates an exemplary MLB xApp [UC-2] representation (800) of a tentative sequence flow for configuring load information collection across Xn interface in accordance with an embodiment of the present disclosure.
[0045] FIG. 9 illustrates an exemplary MLB xApp [UC-2] representation (900) of a tentative sequence flow for collecting and post processing of received load information across Xn interface in accordance with an embodiment of the present disclosure.
[0046] FIG. 10 is an illustrated embodiment of a Functional block diagram (1000) for MLB support at Non-RT RIC in accordance with an embodiment of the present disclosure.
[0047] FIG. 11 illustrates an exemplary representation (1100) of a sequence flow of data across different O-RAN entities for MLB support in accordance with an embodiment of the present disclosure.
[0048] FIG. 12 is an illustrated embodiment (1200) of a Functional Architecture for MLB support across SMO and E2 Node only in accordance with an embodiment of the present disclosure.
[0049] FIG. 13 is an illustrated embodiment (1300) of a Functional Architecture for MLB support across SMO and E2 Node only, excluding Non-RT RIC in accordance with an embodiment of the present disclosure.
[0050] FIG. 14 illustrates an exemplary computer system (1400) in which or with which embodiments of the present invention can be utilized, in accordance with embodiments of the present disclosure.
[0051] The foregoing shall be more apparent from the following more detailed description of the invention.

DETAILED DESCRIPTION OF INVENTION
[0052] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0053] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0054] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0055] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0056] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0057] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0058] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
[0059] The present invention provides a system for realizing a first set of instructions (interchangeably referred to as Mobility Load Balancing (MLB) functionality) of SON in an O-RAN architecture and the data collection interworking methods thereof. The O-RAN architecture has at least two entities called the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the Non-Real Time Radio Intelligent Controller (Non-RT RIC). The method may further provide for a functional split for the MLB and related functional flows between at least two entities. The method may further ensure locality of execution of the MLB including a possible split between a gNB (interchangeably referred to as the E2 node in the O-RAN Architecture), the Non-RT RIC, and the Near-RT RIC. The methods and system may further provide for data collection to facilitate the MLB functional execution in the Near and Non-RT RIC entities.
[0060] Referring to FIG. 1 that illustrates an exemplary network architecture for a self-organizing network (100) (also referred to as network architecture (100)) in which or with which a Service Management and Orchestration (SMO) system (110) or simply referred to as the system (110) of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure. As illustrated, the exemplary network architecture (100) may be equipped with Non-Real Time Radio Intelligent Controller (Non-RT RIC) (122) associated with the SMO system (110), and Near-Real Time Radio Intelligent Controller (Near-RT RIC) (124) communicatively coupled to the SMO system (110) for the SON.
[0061] The SMO system (110) may be communicatively coupled to a plurality of first computing devices (102-1, 102-2, 102-3…102-N) (interchangeably referred to as user equipment (102-1, 102-2, 102-3…102-N) and (individually referred to as the user equipment (UE) (124) and collectively referred to as the UE (102)) through a second computing devices (104-1, 104-2,…104-N) (interchangeably referred to as the base station (104-1, 104-2,…104-N) and individually referred to as the base station (104) and collectively as base stations (104)) and the SMO system (110) may be further operatively coupled to the base stations (104) via an Open radio access network Radio Unit (O-RU) (114). The SMO (110) may be further communicatively coupled to the one or more third computing devices (106) (interchangeably referred to as gNB distributed units (DU) or gNB DU 106), and one or more fourth computing devices (116) (interchangeably referred to as gNB control units (CU) or gNB CU 116). The one or more fourth computing devices (116) may be communicatively coupled to a plurality of fifth computing devices (118) (interchangeably referred to as first nodes (118) hereinafter).
[0062] In an exemplary embodiment, the first, second, third, fourth, and fifth computing devices may pertain to a plurality of neighbor cells or a serving cell.
[0063] In an exemplary embodiment, the Serving cell and the plurality of Neighbor cells may be spread across a plurality of CUs (116) and a plurality of DUs (106). A first interface (also referred to as the Xn interface hereinafter) may be used for data collection for the MLB.
[0064] The SMO (110) may be configured to execute a first set of instructions (interchangeably referred to as the mobility load balancing or MLB hereinafter). The MLB, when executed, may manage data acquisition from the plurality of the first, second, third, fourth, and fifth computing devices associated with the Near-RT RIC (124). In an embodiment, the MLB implementation in the Near-RT RIC (124) may architecturally cover the data collection mechanisms when the plurality of neighbor cells is across the same Near-RT RIC (124).
[0065] In yet another embodiment, the serving cell and the neighbor cells may be under different Near-RT RIC, wherein each cell is associated with a different near RT RIC and may be spread across different CUs (116) and different O-DUs (106). The Xn interface may not be used here for collecting the data.
[0066] In an embodiment, the SMO system (110) and the Near-RT RIC (124) may be a System on Chip (SoC) system but not limited to the like. In another embodiment, an onsite data capture, storage, matching, processing, decision-making, and actuation logic may be coded using Micro-Services Architecture (MSA) but not limited to it. A plurality of microservices may be containerized and may be event-based to support portability.
[0067] In an embodiment, the network architecture (100) may be modular and flexible to accommodate any kind of changes in the SMO system (110), and the Near-RT RIC (124). The SMO system (110) and the Near-RT RIC (124) configuration details can be modified on the fly.
[0068] In an embodiment, the SMO system (110) may be remotely monitored and the data, application, and physical security of the SMO system (110) may be fully ensured. In an embodiment, the data may get collected meticulously and deposited in a cloud-based data lake to be processed to extract actionable insights. Therefore, the aspect of predictive maintenance can be accomplished.
[0069] In yet another embodiment, the MLB may be split between the Near-RT RIC and the Non-RT RIC and the SMO may play a key role for MLB SON feature support.
[0070] In yet another embodiment, the MLB may be split between the SMO and the gNB node (not shown in FIG. 1 and interchangeably referred to as the E2 node hereinafter), across an open second interface (interchangeably referred to as the O1 interface hereinafter).
[0071] In an exemplary embodiment, a communication network (108) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. A network may include, by way of example but not limitation, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, some combination thereof.
[0072] In another exemplary embodiment, the centralized server (112) may be included in architecture (100). The centralized server (112) may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.
[0073] In an embodiment, the one or more first computing devices (124), the one or more mobile devices (not shown in FIG. 1) may communicate with the SMO system (108) via set of executable instructions residing on any operating system, including but not limited to, Android TM, iOS TM, Kai OS TM and the like. In an embodiment, one or more first computing devices (124) and the one or more mobile devices may include, but not limited to, any electrical, electronic, electro-mechanical or an equipment or a combination of one or more of the above devices such as mobile phone, smartphone, Virtual Reality (VR) devices, Augmented Reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as touch pad, touch enabled screen, electronic pen, receiving devices for receiving any audio or visual signal in any range of frequencies and transmitting devices that can transmit any audio or visual signal in any range of frequencies. It may be appreciated that the to one or more first computing devices (124), and the one or more mobile devices may not be restricted to the mentioned devices and various other devices may be used. A smart computing device may be one of the appropriate systems for storing data and other private/sensitive information.
[0074] FIG. 3 illustrates an exemplary block diagram representation (300) of a system architecture, in accordance with an embodiment of the present disclosure. As illustrated, in an aspect, (also referred to as USECASE-1 or OPTION 1), the serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-q1) are under the same Near-RT RIC (302). The serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-q1) may be spread across different O-CU-CPs (308-1, 308-2, 308-n) and different O-DUs (314-1, 314-2,…314-n) and the Xn interface may not be used for load information collection for MLB support. For example, let Cell-1 (301-1) be the serving cell, which is loaded above an upper Threshold [Th-U]. The subset of the plurality of neighbor cells may be assumed to have a cell load below a Lower Threshold [Th-L], which are the candidate cells to offload.
[0075] FIG. 4 illustrates an exemplary MLB xApp [UC-1] representation (400) highlighting a tentative sequence flow for collecting load information for the serving cell from the associated E2 nodes in accordance with an embodiment of the present disclosure. As illustrated, the tentative sequence flow for a cell context creation at the Near-RT RIC (406) where Cell-1 may be successfully commissioned (408). The cell may collect the load information from the associated E2 nodes by triggering the Resource Status Request (414) to the E2 nodes via E2 interface. The E2 nodes may perform measurements (422) and may report the measured load information (424) to the Near-RT RIC (406) based on the configured periodicity via the E2 interface.
[0076] In an embodiment, when a cell is deployed and commissioned (408), the cell may establish an E2 link (410) with the Near-RT RIC [RIC] (406). The RIC (406) may create a cell context for the cell (412). Next, the RIC (406) may transmit a RIC Subscription Request (414) to the O-CU-CP-1 (404) to start the measurements for this cell (418) and start reporting periodically. Next, the O-CU-CP-1 (404) may configure the measurements (422) in the O-DU-1 (402) for the cell via an F1AP Resource Status Initiation procedure (424). Further, the O-DU-1 (402) may start the measurements (422) for the cell and start reporting (424) to the O-CU-CP, at set periodicity on Radio Resource status (RR), Composite Available Capacity Group (CACG), Slice Available Capacity (SliAC), Number of Active UEs, etc. Further, the O-CU-CP-1 (404) may forward the resource status updates (426 and 428) along with the Number of RRC connections (430 and 434) to the Near-RT RIC (406). Next, the Near-RT RIC (406) may check all the resource status updates (426 and 428) and store the resource status updates (426 and 428) against the cell. This procedure sequence may be followed for every cell that may get commissioned under the Near-RT RIC (406).
[0077] FIG. 5 illustrates an exemplary MLB xApp [UC-1] representation (500) highlighting flow for processing on load information for the serving cell received from the associated E2 nodes in accordance with an embodiment of the present disclosure. As illustrated, the tentative sequence flow for the processing of the received cell load information is shown that needs necessary steps further if the load situation demands, to offload UEs towards the chosen neighbor cells.
[0078] In an embodiment, when an RIC Indication (510) may be received at the Near-RT RIC (508), and if the Cell load is > Th-U for some time duration ‘T1’, the cell may decide to offload some of its load towards the plurality of neighbor cells (512). Next, the Near-RT RIC (508) may collect the list of the plurality of neighbors cells of the loaded cell, from the local ANR xApp (514). From the list of the plurality of neighbor cells, both the serving cell and the plurality of neighbor cells may appear to belong to the same Near-RT RIC (508) (516). Further, the Near-RT RIC (508) may collect the load information for this list of the plurality of neighbor cells from the relevant cell contexts within the MLB xApp (518). Further, the Near-RT RIC (508) may analyze the load information and identify a subset of cells whose cell load is < Th-L for some time duration ‘T’ (520). The cells whose cell load is < Th-L for some time duration ‘T’ may become candidate cells for offload.
[0079] Further, the Near-RT RIC (508), based on possible AI/ML algorithms, may dynamically choose the appropriate value for the HO Trigger parameter for the subset cells (522). Here, the MLB xApp may coordinate with the MRO xApp to decide on the appropriate HO Trigger parameters. The Near-RT RIC (508) may request the O-CU-CP-1 (506) via a RIC Subscription Request (524) to start using the modified HO Trigger value via the E2 interface. The O-CU-CP-1 (506) may reconfigure (528) the UEs (502) of the cells with new measurement configurations. Consequently, the UEs (502) within the loaded cell may send early measurement reports to trigger HO towards the plurality of neighbor cells. Hence, the HO may get triggered towards the plurality of neighbor cells, which may reduce the load of the serving cell (530).
[0080] FIG. 6 illustrates an exemplary MLB xApp [UC-1] representation (600) of a tentative sequence flow for restoring to normal condition, post the MLB offload in accordance with an embodiment of the present disclosure. The tentative sequence flow for restoring to normal operating condition of the cell, post the successful MLB offload is described herewith. As and when the Handovers are happening towards the neighbor cells, the load on the cell may start getting reduced. When the serving cell load is < Average load for some time duration ‘T’, the Near-RT RIC (608) may decide to revert (610) the changes made for the HO Trigger parameter for those cells.
[0081] The Near-RT RIC (608), based on AI/ML, may dynamically choose (612) an appropriate value for the HO Trigger parameter for the neighboring cells and the serving cell. Here, the MLB xApp may coordinate with the MRO xApp, if needed, to decide on the appropriate HO Trigger parameters. The Near-RT RIC (608) may request the O-CU-CP-1 (606) via a RIC Subscription Request (614) to start using the modified HO Trigger value via the E2 interface. The O-CU-CP-1 (606) may reconfigure (618) the UEs (602) of these cells with new Measurement Configurations and the operation starts moving towards normal.
[0082] FIG. 7 is an illustrated embodiment of an alternative deployment scenario representation (700) for MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure. As illustrated, the deployment scenario highlights an alternative embodiment (also Usecase 2 (UC-2) or Option 2). As illustrated, the serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-q1) may be under different Near-RT RIC entities (302-1 and 302-2). The serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-q1) may be spread across different O-CU-CPs (308-1 and 308-n) and different O-DUs (314-1) as shown in FIG. 7. The Xn interface may be used here for collecting the load information for the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-q1) which are under different Near-RT RIC entities (302-1 and 302-2) needed for the MLB support. Cell-1 is the serving cell, which is loaded above an upper Threshold [Th-U]. The plurality of neighbor cells of Cell-1, as per ANR table, may be identified by the shaded box. The subset of the plurality of neighbor cells may be assumed to have cell load below a lower Threshold [Th-L], which may be the candidate cells to offload.
[0083] FIG. 8 illustrates an exemplary MLB xApp [UC-2] representation (800) of a tentative sequence flow for configuring load information collection across Xn interface in accordance with an embodiment of the present disclosure. The tentative sequence flow shows the collection of the load information from the associated E2 nodes, that may be spread across multiple Near-RT RICs, by triggering the Resource Status Request to the E2 nodes via the E2 interface. In an exemplary embodiment, the E2 nodes may use the Xn interface to request and fetch the load information. The E2 nodes may perform measurements and report the measured load information to the requested E2 nodes via the Xn interface based on the configured periodicity in the way described herewith. The Near-RT RIC (808) may collect (810) the load information for the plurality of neighbor cells that belong to the same RIC within the MLB xApp locally. For the plurality of neighbor cells, which belongs to a different Near-RT RIC, the Near-RT RIC (808) may request the O-CU-CP-1 (806) to collect (814) the load information. The O-CU-CP-1 (806) may then request O-CU-CP-n (836), which belongs to another RIC, to provide (816) the load information for the list of cells via XnAP Resource Status Initiation procedure (818). The O-CU-CP-n (836) may start collecting the load information for all those cells from the O-DUs (804) via an F1AP Resource Status Initiation procedure (826).
[0084] FIG. 9 illustrates an exemplary MLB xApp [UC-2] representation (900) of a tentative sequence flow for collecting and post-processing of received load information across the Xn interface in accordance with an embodiment of the present disclosure. The tentative sequence for collecting the load information by the O-CU-CP-n (910) from their respective O-DUs (904) and forwarding the Resource status shows reports according to the set periodicity to the requested O-CU-CP-1 (906), which in turn forwards them to the Near-RT RIC (908). The Near-RT RIC (908) may process the received load information along with the load information collected locally and take the necessary action on similar lines as explained in Usecase-1 embodiment described herewith. When the O-CU-CP-n (910) may start receiving the load information from the O-DUs (904) via an F1AP Resource Status Reporting procedure (922), the O-CU-CP-n (910) may forward the F1AP: Resource Status Update report (922) to the O-CU-CP-1 (906) via an XnAP Resource Status Reporting procedure (924).
[0085] When the load condition of the serving cell may meet the criteria for offload, as mentioned in the Usecase-1 scenario, the Near-RT RIC (908) based on AI/ML, may dynamically choose the appropriate value for the HO Trigger parameter for each of the plurality of neighbor cells. The Near-RT RIC (908) may request the O-CU-CP-1 (906) to start using the modified HO Trigger value for the plurality of neighbor cells. The O-CU-CP-1 (906) may reconfigure (928) the UEs (902) of the cells which belong to the Near-RT RIC (908) with new measurement configurations.
[0086] For the cells, which belong to a different Near-RT RIC, the O-CP-CU-1 (906) may forward Modified HO Trigger value to the O-CU-CP-n (910) via an XnAP Mobility Settings Change procedure (930). The O-CU-CP-n (910) may reconfigure (928) all the UEs (902) of the cells which belong to the Near-RT RIC (908) with new measurement configurations. The remaining procedure remains the same as explained for Use case-1 in an earlier embodiment.
[0087] FIG. 10 is an illustrated embodiment (1000) of a Functional block diagram for MLB support at Non-RT RIC in accordance with an embodiment of the present disclosure. As illustrated, the E2 Node (1022) may perform the measurements and capture PM data, and store it locally. Based on the PM data reporting configurations (T), the E2 node (1022) may report the PM data, Events/Alarms, logs, etc., to the SMO (1002) via the O1 interface.
[0088] In a way of example and not as a limitation, the reporting configurations can be for example T [5min, 10min, 15min, 20min, 25min, 30min, 45min, 60min, 90min, etc.,].
[0089] In an exemplary embodiment, the EMS (1012) within the SMO (1002) may forward the data to MDAS (1006) and NMS (1004) internally. The MDAS (1006) may store the data and execute big data analytics considering the overall data accumulated so far in its storage. Further, the MDAS (1006) may generate the relevant load patterns for each concerned cell. The accumulation of data may be envisioned as days or months or years of data. As the data accumulation duration may be high, the accuracy and the closeness to the reality of the generated pattern may also be very high. The generated patterns like load pattern, time duration pattern, etc. may be shared with the Non-RT RIC (1008).
[0090] The Non-RT RIC [rApp] (1008) may analyze the patterns and try to derive whether a specific peak cell load pattern and a specific lower cell load pattern may be periodic or aperiodic, a duration of such patterns, and a probable occurrence of such patterns in future. The Non-RT RIC [rApp] (1008) may also analyze the similar pattern for the plurality of neighbor cells as well. From this analysis, the Non-RT RIC (1008) may predict the next immediate occurrence of the peak load of the cell and its duration, and for that duration, the Non-RT RIC (1008) may also examine the behavior of all the neighbor cells. Further, the Non-RT RIC (1008) may shortlist the subset of the sure-shot neighbor cells that can be candidate neighbor cells for offload. The predicted load condition, the predicted time duration of occurrence, the tentative list of neighbor cells for offload, etc. may be shared with the Near-RT RIC (1014) across a third interface (also referred to as the A1 interface hereinafter).
[0091] FIG. 11 illustrates an exemplary representation (1100) of a sequence flow of data across different O-RAN entities for MLB support in accordance with an embodiment of the present disclosure. As illustrated, in an aspect, the Non-RT RIC (1106) may use the predicted data to guide the Near-RT RIC (1108) accordingly. For example, when the predicted load is low for a set time duration, the Non-RT RIC (1106) can guide the Near-RT RIC (1108) to reduce a use of Carrier aggregation, reduce a use of Dual connectivity, reduce Bandwidth of operation, reduce MIMO configurations to the minimum possible, switch to lower Modulation classes, enable to attract more incoming Handovers, etc., applicable for the set time duration. Similarly, when the predicted load is very high for certain time duration, the Non-RT RIC (1106) can guide the Near-RT RIC (1108) to get prepared for enabling the above said features to maximum usage possible appropriately. In particular, the Non-RT RIC (1106) may provide guidance in the form of policies, while the Near-RT RIC (1108) may assess the current situation based on the received guidance and its own Real-time analytics and takes the decision accordingly.
[0092] FIG. 12 is an illustrated embodiment representation (1200) of a Functional Architecture for MLB support across the SMO (1002) and the E2 Node (1022) only in accordance with an embodiment of the present disclosure. As illustrated, in an aspect, the MLB functionality is split between the SMO (1002) and the E2 Node (1022), across the Open O1 interface (1018). In an exemplary embodiment, the MLB Controller (1204) at the management entity [For example EMS context (1012)] and the MLB agent (1202) at the E2 Node (1022).
[0093] The functionality of MLB rApp (1010) at Non-RT RIC is same as explained in the earlier embodiments, except that the MLB rApp (1010) may provide the derived MLB policies to the MLB controller (1204) locally. The MLB Controller (1204) at the Management entity (1012) can do the data analytics on the received PM data from the E2 node (1022) directly and take the appropriate decisions of the load balancing. The MLB Controller (1204) can also utilize the load/time patterns generated by the MDAS (1006) on the accumulated PM data, to take the MLB decisions. The MLB Agent (1202) may execute the MLB decisions/Commands received from the MLB Controller (1204) across the open O1 interface (1018).
[0094] The MLB Agent (1202) can access the near-RT PM data locally within E2 Node (1022), perform the real-time analytics on it and can take the decisions on load balancing locally. The MLB decisions may be aligned with the decisions/commands received from the MLB Controller (1204). The MLB Agent (1202) may be specific to the E2 node (1022) and implementation specific. However, adhering to the MLB guidelines received across the open O1 interface (1018), may still make the MLB function vendor-agnostic.
[0095] FIG. 13 is an illustrated representation (1300) of a Functional Architecture for MLB support across the SMO (1002) and the E2 Node (1022) only, excluding the Non-RT RIC in accordance with an embodiment of the present disclosure. As illustrated, in an aspect, the Non-RT RIC does not have any role to play w.r.t the MLB feature and the MLB controller (1204) itself takes care of all the functionalities explained for MLB rApp within Non-RT RIC under earlier embodiments. Rest of the functionalities are similar as explained above.
[0096] FIG. 14 illustrates an exemplary computer system (1400) in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present disclosure. As shown in FIG. 14, the computer system (1400) can include an external storage device (1410), a bus (1420), a main memory (1430), a read only memory (1440), a mass storage device (1450), a communication port (1460), and a processor (1470). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. Examples of the processor (1470) include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on chip processors, or other future processors.
[0097] The processor (1470) may include various modules associated with embodiments of the present invention. The communication port (1460) can be any of a RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit, or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port (1460) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects. The memory (1430) can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (1440) can be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or BIOS instructions for the processor (1470).
[0098] The mass storage (1450) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 782 family) or Hitachi (e.g., the Hitachi Deskstar 13K800), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors.
[0099] The bus (1420) communicatively couples the processor(s) (1470) with the other memory, storage, and communication blocks. The bus (1420) can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB, or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects processor (1470) to software system.
[00100] Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to bus (1420) to support direct operator interaction with a computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port (1460). The external storage device (1410) can be any kind of external hard drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM). The components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[00101] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the invention and not as limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00102] The present disclosure provides systems and methods for mobility load balancing of a cell in a telecommunication network using an Open Radio Access Network (O-RAN).
[00103] The present disclosure provides systems and methods for realizing the Mobility Load Balancing (MLB) functionality of a Self-Organizing Network (SON) in an O-RAN architecture.
[00104] The present disclosure provides systems and methods for a functional split between different entities in an O-RAN architecture and the associated data/control flow mechanisms.
[00105] The present disclosure provides systems and methods of two mechanisms for the realization of the MLB function in the O-RAN architecture such as MLB implementation in the Near RT RIC, Non-RT RIC entities, and MLB implementation in the management entity, and the Near RT RIC.
[00106] The present disclosure provides systems and methods to collect data for facilitating the MLB functional execution in the Near and the Non-RT RIC entities.
[00107] The present disclosure provides systems and methods to offload a cell to the neighbouring cells in a telecommunication network, thereby improving network efficiency, in an O-RAN architecture.

RESERVATION OF RIGHTS
A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, IC layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. The present disclosure may pertain to O-RAN specifications as given in 3GPP TR 21.905 [1].

,CLAIMS:1. A system (110) for realizing Mobility Load Balancing (MLB) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN), the system comprising:
a Non-Real-Time Radio Access Network Intelligent Controller (Non-RT RIC) (122), wherein the Non-RT RIC comprises:
a processor;
a memory coupled to the processor, wherein the memory comprises processor-executable instructions, which on execution, causes the processor to:
transmit a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC;
receive load information of the cell from the one or more E2 nodes based on the transmitted resource status request;
obtain reports from the one or more E2 nodes based on the collected load information;
transmit the obtained reports to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC) (124);
receive a Handover (HO) Trigger value from the Near-RT RIC based on the reports; and
reduce a load of the cell based on the modified HO Trigger value.
2. The system as claimed in claim 1, wherein the resource status request is transmitted to the one or more E2 nodes via an E2 interface.
3. The system as claimed in claim 1, wherein the reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipment (UEs) associated with the cell.
4. The system as claimed in claim 1, wherein the reports obtained from the one or more E2 nodes further comprise a measurement of the load information.
5. The system as claimed in claim 4, wherein the measurement of the load information is performed by one or more E2 nodes.
6. The system as claimed in claim 1, wherein the reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure.
7. The system as claimed in claim 1, wherein the HO Trigger value is received from the Near-RT RIC via an E2 interface.
8. The system as claimed in claim 1, wherein the load of the cell is restored by the Near-RT RIC when the load of the cell becomes less than an average load within a given time.
9. The system as claimed in claim 1, wherein the Near-RT RIC is configured to:
receive reports based on load information of the cell;
offload the cell based on the received reports to one or more neighbour cells;
obtain load information from the one or more neighbour cells;
generate a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information; and
transmit the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell.
10. The system as claimed in claim 9, wherein the one or more neighbour cells have a cell load less than an average load within a given time period.
11. A method for realizing Mobility Load Balancing (MLB) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN), the method comprising:
transmitting, by a processor, a resource status request to one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC (122);
receiving, by the processor, load information of the cell from the one or more E2 nodes based on the transmitted resource status request;
obtaining, by the processor, reports from the one or more E2 nodes based on the collected load information;
conveying, by the processor, the obtained reports to a Non-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC) (124);
receiving, by the processor, a Handover (HO) Trigger value from the Near-RT RIC based on the reports; and
reducing, by the processor, a load of the cell based on the modified HO Trigger value.
12. The method as claimed in claim 11, wherein the resource status request is transmitted to the one or more E2 nodes via an E2 interface.
13. The method as claimed in claim 11, wherein the reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipment (UEs) associated with the cell.
14. The method as claimed in claim 11, wherein the reports obtained from the one or more E2 nodes further comprise a measurement of the load information.
15. The method as claimed in claim 14, wherein the measurement of the load information is performed by one or more E2 nodes.
16. The method as claimed in claim 11, wherein the reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure.
17. The method as claimed in claim 11, wherein the HO Trigger value is received from the Near-RT RIC via an E2 interface.
18. The method as claimed in claim 11, wherein the load of the cell is restored by the Near-RT RIC when the load of the cell becomes less than an average load within a given time.
19. The method as claimed in claim 11, wherein the Near-RT RIC is configured to:
receive reports based on load information of the cell;
offload the cell based on the received reports to one or more neighbour cells;
obtain load information from the one or more neighbour cells;
generate a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information; and
transmit the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell.
20. The method as claimed in claim 19, wherein the one or more neighbour cells have a cell load less than an average load within a given time.