CN116325866A - System and method for realizing mobility load balance of self-organizing network - Google Patents

Abstract

The present invention provides an efficient and reliable system for implementing a first instruction set (interchangeably referred to as Mobility Load Balancing (MLB)) of SONs in an O-RAN architecture and a data acquisition interworking method thereof. The O-RAN architecture has at least two entities, called Near real-time wireless intelligent controllers (Near RT RICs) (124) and Non-real-time wireless intelligent controllers (Non-RT RICs) (122). The method may also provide a functional segmentation of the MLB and related functional flows between at least two entities. The method further ensures that the MLB performs locally, including possible splitting between the gNB (interchangeably referred to as E2 node in the O-RAN architecture), the Non-RT RIC, and the Near RT RIC. The method and system may also provide data collection to facilitate MLB function execution in both the Near RT RIC entity and the Non-RT RIC entity.

Description

System and method for realizing mobility load balance of self-organizing network

Technical Field

Embodiments of the present disclosure relate generally to telecommunications deployment. More particularly, the present disclosure relates to systems and methods for implementing mobility load balancing for self-organizing networks (self-organizing network, SON) in an open radio access network (Open Radio Access Network, O-RAN).

Background

The following description of the related art is intended to provide background information related to the field of the present disclosure. This section may include certain aspects of the related art that are relevant to the various features of the disclosure. However, it should be understood that this section is merely intended to enhance the reader's understanding of the present disclosure and is not an admission that it is prior art.

Load balancing distributes network or application traffic among multiple servers in a server farm in an orderly and efficient manner. Each load balancer is located between different types of cell groups, receives incoming requests and distributes them to any available server capable of satisfying those requests. Modern mobile communication networks comprise a combination of different cell types and different access technologies. Mobile users have also grown exponentially as cellular networks have evolved from generation 4 (4G), generation 5 (5G), to generation 6 (6G), and other radio access technologies such as wireless fidelity (Wireless Fidelity, wiFi). Deployment and load balancing of ultra high density heterogeneous networks (hetnets) is also increasing to meet the increasing demand for the number of users. Hetnets are typically built from multiple portfolios and multiple vendor based solutions.

Operators face multiple challenges in green field deployment or gray field deployment of HetNets. One of the challenges is the need for high quality installations, including continuous monitoring of the performance and health of the deployed network. Furthermore, dynamically adapting to changing environments and actively adjusting and optimizing is also a challenge for mobile operators.

These challenges require a lot of manual work and, due to regular/frequent field surveys, lead to long delays and thus to huge operating costs (Operational Expenses, OPEX). To overcome these drawbacks and greatly reduce OPEX, self-organizing networks (Self-Organizing Network, SON) are one solution. The SON may be a self-organizing network or a self-optimizing network. SON may be an automated technology that allows the network to set up and manage resources and configurations itself for optimal performance. The functions of SON can be divided into three categories. The first is self-configuration. Self-configuration facilitates seamless integration into the network through automatic configuration of key parameters. Self-configuration is most valuable during initial network deployment. Self-configuration includes a variety of capabilities such as Plug-and-Play (PnP) functionality, automatic neighbor relation (Automatic Neighbour Relation, ANR) functionality, and physical layer cell identity (Physical Layer Cell Identity, PCI) selection and conflict resolution functionality.

The second type is self-optimization. Self-optimization helps to enhance network performance through near real-time optimization of wireless and network configurations. Self-optimization is valuable throughout the life cycle of the network. Self-optimization includes various capabilities such as mobility load balancing (Mobility Load Balancing, MLB), mobile robustness optimization (Mobility Robustness Optimization, MRO), random access channel (Random Access Channel, RACH) optimization, energy Saving (ES), radio Link failure reporting, coverage and capacity optimization (Coverage and Capacity Optimization, CCO), data Link (DL) power control, remote tone antennas (Remote Electrical Tilt, RET), forward handover, frequent handover mitigation (Frequent Handover Mitigation, FHM), and interference mitigation (Inter-cell, intra-system radio access technology (Intra Radio Access Technology, intra-system-RAT), inter-system radio access technology (Inter Radio Access Technology, inter-RAT)).

The third class is self-healing. Self-repair allows neighboring cells to maintain network quality in the event of a cell/sector failure, providing resilience (reliability) in the face of unpredictable outage situations. Self-healing is valuable throughout the life cycle of a network. Self-repair includes various capabilities such as cell outage detection (dead/sick/dormant cells/sectors/beams), cell outage restoration, cell outage compensation, and cell outage compensation restoration.

The above SON functions are handled by SON algorithms alone or in groups. The SON algorithm performs functions such as monitoring the network by collecting management data, including management data analysis service (Management Data Analytics Services, MDAS) data, analyzing the management data to determine if there is a problem in the network to be solved, determining SON operations to solve the problem, performing SON operations, and evaluating whether the problem has been solved by analyzing the management data. Based on the location of the SON algorithm, SONs are classified into four different solutions that enable various SON use cases, the choice of solution depending on the needs of the SON use cases.

Although the minimization of drive tests (Minimization of Drive Test, MDT) function is reused as much as possible, its function can also be designed to operate independently of SON. The above SON functions may be handled by SON algorithms alone or in groups. The SON algorithm may perform functions such as monitoring the network by collecting management data (including MDAS data) and analyzing the management data to determine if there are problems in the network that need to be addressed. The SON algorithm may also determine SON operations to solve the problem and perform SON operations to solve the problem. Furthermore, SON algorithms can evaluate whether the problem has been solved by analyzing the management data.

Based on the location of the SON algorithm, SONs can be categorized into four different solutions that enable various SON use cases. The choice of solution may depend on the requirements of the SON use case. The Centralized SON (C-SON) may include the functions performed by the SON algorithm in the management system. Cross-Domain Centralized SON (CD C-SON) may include functionality that SON algorithms may perform in the Cross-Domain (CD) layer. Furthermore, a Domain-centered SON (D C-SON) may be a SON algorithm that may be performed in the Domain layer. Furthermore, the Distributed SON (D-SON) may be the SON algorithm in NFs.

Hereinafter, a Hybrid SON (H-SON) may be a SON algorithm that may be performed on two or more layers, such as a Network Function (NF) layer, a domain layer, or a cross-domain (CD) layer. Since SON algorithms are implementation dependent, different vendors may choose different schemes for their SON solutions. Some suppliers may choose a C-SON scheme, some suppliers may choose a D-SON scheme, and other suppliers may choose solutions based on an H-SON scheme. Operators may inevitably use multi-vendor solutions when deploying HetNets.

In the 3GPP specifications for SON functions, a description of the functions is provided, but the specifications do not specify how these functions have to be implemented. This leads to integration problems for multiple suppliers and prevents operators from implementing SON in their networks. The O-RAN alliance is an alliance aimed at alleviating these multi-vendor interoperability problems, but SON functions have not been addressed in the O-RAN architecture. In addition, since the SON algorithm is implementation dependent, different vendors may choose different schemes for their SON solutions. Some suppliers may offer centralized SON (C-SON) schemes, some suppliers offer distributed SON (D-SON) schemes, and others offer solutions based on heterogeneous SON schemes. Operators will inevitably use multi-vendor solutions when deploying HetNets.

Fig. 2A illustrates a typical 5G HetNet deployment scenario in which management entities such as network management systems (Network Management System, NMS) from different vendors, a set of element management systems (Element Management System, EMS) from different vendors, radio access network (Radio Access Network, RAN) nodes such as next generation NodeB (gNB) Control Units (CU) from different vendors, and gNB Distributed Units (DUs) from different vendors. Operators may face the problems in the HetNet deployed in fig. 1. One of the problems is that although the D-SON of the gNB-CU-1 (116) and the gNB-CU-2 (124) communicate with each other over an open Xn interface, they come from different suppliers and therefore they may not coordinate well.

Another problem is that although the D-SON of the gNB-CU-2 (124) and the hybrid SON of the gNB-CU-n (130) (D-son+ D C-SON) communicate with each other over an open Xn interface, they come from different suppliers and therefore they may not coordinate well. One key issue is that the C-SON can be implemented either with a management entity (such as an EMS or NMS) or as a stand-alone entity. Integrating the C-SON as a stand-alone entity with the RAN node is extremely difficult, as the interface is implementation dependent. Furthermore, CD C-SON in the NMS (106) may have an impact on the performance of D C-SON functions and D-SON functions operating in a multi-vendor environment.

Another problem is the integration of third party SON solutions into HetNet, which can lead to a drop in overall key performance indicators (Key Performance Indicator, KPIs). Furthermore, L3-radio resource management (Radio Resource Management, RRM) coordination between neighboring NB-CUs (116, 124, 130) may be lacking, whether in the same vendor or multi-vendor scenario, which will have an impact on overall KPI performance. L3-RRM and L2-RRM coordination between multiple vendors gNB-CUs (116, 124, 130) and gNB-DUs (118, 120, 122, 126, 128, 132) may have an impact on dynamic resource sharing and allocation.

SON and RRM are implemented as proprietary, which have a great impact on overall performance when multiple vendors coordinate with each other through an Xn interface. Each algorithm behaves differently and has its own limitations. Even if the vendor is ready to integrate with third party solutions (SON and/or RRM), the vendor may not be able to positively quantify/confirm output performance, mainly due to the vendor's solution. This situation always ends up with conflicts between agreed suppliers.

One possible solution to address these problems or limitations is to make the interface between the SON solution and the interacting RAN node as open as possible. The O-RAN alliance is a global community consisting of mobile network operators, suppliers, and research and academic institutions operating in the Radio Access Network (RAN) industry. The O-RAN alliance has the mission to remodel the RAN industry into a more intelligent, open, virtualized and fully interoperable mobile network. The new O-RAN standard will improve the user experience through faster innovations, thereby enabling a more competitive and viable RAN provider ecosystem. An O-RAN based mobile network will increase the efficiency of RAN deployment and at the same time improve the operation of the mobile operator.

Fig. 2 shows a logical architecture defined by an O-RAN. Within the logical architecture of the O-RAN, the Radio side includes Near Real-Time (RT) RAN intelligent controllers (RAN Intelligent Controller, RIC) (224), O-RAN Central Unit control Plane (O-RAN Central Unit Control Plane, O-CU-CP) (228), O-RAN Central Unit-User Plane (O-CU-UP) (230), O-RAN distributed units (O-RAN Distributed Unit, O-DU) (232-1) and O-RAN Radio Unit (O-RAN Radio Unit, O-RU) (232-2) functions, as shown in fig. 2. The E2 interface connects an evolved node B (O-eNB) to a Near real time RAN intelligent controller (Near-RT RIC). Although not shown in the figure, the O-eNB does support O-DU and O-RU functions with an open fronthaul interface between them. The management side includes a service and management orchestration (Service and Management Orchestration, SMO) framework that contains Non-real-time RAN intelligent controller (Non-RT RIC) functions. On the other hand, ORAN-Cloud (O-Cloud or O-Cloud) (234) is a Cloud computing platform that includes a set of physical infrastructure nodes (e.g., near-RT RIC, O-CU-CP, O-CU-UP, and O-DU, etc.), supporting software components (e.g., operating system, virtual machine monitor, container runtime, etc.), and appropriate management and orchestration functions that meet the O-RAN requirements to carry the relevant O-RAN functions. As shown in FIG. 2B, the O-RU terminates an Open front-end M-Plane (236) interface towards the O-DU and SMO.

Thus, it can be seen that the conventional method has many limitations. As mobile users grow exponentially, the demand for data by each user becomes very high. With the proliferation of cellular heterogeneous network deployment, there is a great need to deploy Wi-Fi Access Points (APs) to meet the great data throughput requirements. Thus, operators are densely deploying Wi-Fi APs that can operate at frequencies of 2.4GHz, 5GHz, and even higher. Furthermore, operators are forced to deploy carrier-grade Wi-Fi, enterprise Wi-Fi, mi-Fi, home Wi-Fi, etc. scenarios in their networks using multi-provider solutions. With the deployment of a large number of APs, interference is becoming a critical issue to deal with. Future networks must address this interference management problem by organizing and optimizing the SON/RRM functions of the AP. If APs are densely deployed without coordination, they may exhibit poor channel/spectrum reuse. Furthermore, serious competition between the AP and the client may occur, resulting in low throughput and poor end-user experience.

Furthermore, the prior art does not provide any mechanism to implement mobility load balancing functionality in an O-RAN architecture, nor does it disclose any mechanism of function segmentation between different entities in an O-RAN architecture and associated data/control flow mechanisms.

It is therefore apparent that there is a need to provide systems and methods that overcome the shortcomings of the prior art.

Disclosure of Invention

Some objects met by at least one embodiment of the present disclosure are listed below.

It is an object of the present disclosure to provide a system and method for implementing Mobility Load Balancing (MLB) functions for SONs in an O-RAN architecture.

It is an object of the present disclosure to provide a system for enabling data collection and an interworking method thereof.

It is an object of the present disclosure to provide a system and method for facilitating functional segmentation of related functional flows between MLBs and Near real-time wireless intelligent controllers (Near-Real Time Radio Intelligent Controller, near-RT RIC) and Non-real-time wireless intelligent controllers (Non-Real Time Radio Intelligent Controller, non-RT RIC).

It is an object of the present disclosure to provide a system and method that covers locations performing MLP functions, including possible segmentation between the gNB (referred to as E2 node in the O-RAN architecture), non-RT RIC, and Near-RT RIC.

It is an object of the present disclosure to provide a system and method that facilitates a specific mechanism for data collection to facilitate the execution of MLB functions in Near-RT RIC and Non-RT RIC entities.

This section presents in simplified form certain objects and aspects of the invention, which will be further described in the detailed description below. This summary is not intended to identify key features or scope of the claimed subject matter.

In one aspect, the present disclosure provides a system for implementing Mobility Load Balancing (MLB) functionality of a self-organizing network (SON) of cells in an open radio access network (O-RAN). The system includes a Non-real-time radio access network intelligent controller (Non-RT RIC) configured to send 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 sent 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 sent resource status request.

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 include Radio Resource (RR) status, composite available capacity group (Composite Available Capacity Group, CACG), slice available capacity (Slice Available Capacity, sliAC), and the number of active User Equipments (UEs) associated with the cell. The reports obtained from the one or more E2 nodes also include measurements of the load information. The measurement of the load information is performed by the one or more E2 nodes. In addition, the Non-RT RIC of the system sends the obtained report to a Near real time radio access network intelligent controller (Near-RT RIC). The report is periodically transmitted to the Near-RT RIC via the F1AP resource status initiator.

Furthermore, the Non-RT RIC of the system receives a Handover (HO) trigger value from the Near-RT RIC based on the report. The HO trigger value is received from the Near-RT RIC via the E2 interface. Furthermore, the Non-RT RIC of the system reduces the load of the cell based on the modified HO trigger value. And recovering the load of the cell by the Near-RT RIC when the load of the cell is less than the average load in a given time. The Near-RT RIC is configured to receive a report based on load information of the cell. Furthermore, the Near-RT RIC transfers the cell to one or more neighboring cells based on the received report.

Furthermore, the Near-RT RIC obtains load information from the one or more neighboring cells. Furthermore, the Near-RT RIC generates HO trigger values for the one or more neighboring cells based on the obtained load information. Furthermore, the Near-RT RIC sends the generated HO trigger value to the O-CU-CP for reconfiguring one or more user equipments associated with the cell. The cell load of the one or more neighboring cells is less than the average load for a given period of time.

In one aspect, the present disclosure provides a method for implementing Mobility Load Balancing (MLB) functionality of a self-organizing network (SON) of cells in an open radio access network (O-RAN). The method includes sending a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of the E2 interface are in communication with a Non-RT RIC. The resource status request is sent 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 a report from the one or more E2 nodes based on the collected load information. The reports obtained from the one or more E2 nodes include Radio Resource (RR) status, combined Available Capacity Group (CACG), slice available capacity (SliAC), and the number of active User Equipments (UEs) associated with the cell.

The reports obtained from the one or more E2 nodes also include measurements of the load information. The measurement of the load information is performed by the one or more E2 nodes. Furthermore, the method comprises sending the obtained report to a Near real time radio access network intelligent controller (Near-RT RIC). The report is periodically transmitted to the Near-RT RIC via an F1AP resource status initiator. Furthermore, the method includes receiving a Handover (HO) trigger value from the Near-RT RIC based on the report. The HO trigger value is received from the Near-RT RIC via the E2 interface. Furthermore, the method includes reducing a load of the cell based on the modified HO trigger value. And recovering the load of the cell by the Near-RT RIC when the load of the cell is less than the average load in a given time.

The Near-RT RIC is configured to receive a report based on load information of the cell. Furthermore, the Near-RT RIC transfers the cell to one or more neighboring cells based on the received report. Furthermore, the Near-RT RIC obtains load information from the one or more neighboring cells. Furthermore, the Near-RT RIC generates HO trigger values for the one or more neighboring cells based on the obtained load information. Furthermore, the Near-RT RIC sends the generated HO trigger value to the O-CU-CP for reconfiguring one or more user equipments associated with the cell. The cell load of the one or more neighboring cells is less than the average load for a given period of time.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the disclosed methods and systems and, in which like reference numerals designate like parts in the different views. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some of the figures may use block diagrams to represent components and may not represent internal circuitry of each component. Those skilled in the art will appreciate that the invention of such figures includes inventions of electrical, electronic or circuitry commonly used to implement such components.

Fig. 1 shows an exemplary network architecture (100) in or with which the proposed system of the present disclosure may be implemented, according to an embodiment of the present disclosure.

Fig. 2A and 2B illustrate an exemplary representation (200 and 220) of an existing HetNet deployment and components associated therewith, according to an embodiment of the disclosure.

Fig. 3 illustrates an exemplary block diagram representation (300) of a system architecture according to an embodiment of the present disclosure.

Fig. 4 shows an exemplary MLB xApp [ UC-1] representation (400) highlighting a tentative sequential flow (tentative sequence flow) for collecting load information for a serving cell from an associated E2 node, according to an embodiment of the present disclosure.

Fig. 5 illustrates an exemplary MLB xApp [ UC-1] representation (500) highlighting a flow for processing load information of a serving cell received from an associated E2 node, according to an embodiment of the present disclosure.

FIG. 6 illustrates an exemplary MLB xApp [ UC-1] representation (600) of a tentative sequential flow for restoration to a normal state after an MLB transition, according to an embodiment of the disclosure.

Fig. 7 is an illustrative embodiment (700) of an alternative deployment scenario for an MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure.

FIG. 8 illustrates an exemplary MLB xApp [ UC-2] representation (800) of a tentative sequential flow for configuring load information collection over an Xn interface according to an embodiment of the disclosure.

FIG. 9 illustrates an exemplary MLB xApp [ UC-2] representation (900) of a tentative sequential flow for collection and post-processing of received load information over an Xn interface according to embodiments of the disclosure.

FIG. 10 is an illustrative embodiment of a functional block diagram (1000) of MLB support at a Non-RT RIC in accordance with an embodiment of the present disclosure.

Fig. 11 illustrates an exemplary representation (1100) of sequential flow of data across different O-RAN entities for MLB support in accordance with an embodiment of the present disclosure.

Fig. 12 is an illustrative embodiment (1200) of a functional architecture supported only by SMO and MLB of E2 nodes in accordance with an embodiment of the present disclosure.

Fig. 13 is an illustrative embodiment (1300) of a functional architecture supported by only SMO and E2 nodes, an MLB that does not include a Non-RT RIC, in accordance with an embodiment of the disclosure.

FIG. 14 illustrates an exemplary computer system (1400) in which embodiments of the present invention may be used or with in accordance with embodiments of the present disclosure.

The above will be more apparent from the following detailed description of the invention.

Detailed Description

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It may be evident, however, that the embodiments of the disclosure may be practiced without these specific details. Some of the features described below may be used with each other independently or in any combination of the other features. A single feature may not address all of the problems discussed above, or may only address some of the problems discussed above. Some of the problems discussed above may not be fully solved by any of the features described herein.

The following description merely provides exemplary embodiments 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 being 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.

Specific details are set forth in the following description in order to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown in block diagram form in order to avoid obscuring the embodiments with 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.

Further, it is noted that the 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. Furthermore, the order of the operations may be rearranged. When the operation of a process is completed, the process is terminated, but there may be additional steps not included in the figure. A procedure may correspond to a method, a function, a procedure, a subprogram, a slave program, etc. When a procedure corresponds to a function, its termination may correspond to returning the function to the calling function or the main function.

The words "exemplary" and/or "schematically" are 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. Moreover, any aspect or design described herein as "exemplary" and/or "illustrative" 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.

Reference throughout this specification to "one embodiment," "one 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 (in one embodiment)" or "in an embodiment (in an dimension)" 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.

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.

The present invention provides a system for implementing a first instruction set (interchangeably referred to as Mobility Load Balancing (MLB) function) of a self-organizing network (SON) in an open radio access network (O-RAN) architecture and a data acquisition interworking method thereof. The O-RAN architecture has at least two entities, called Near real-time wireless intelligent controllers (Near-RT RICs or Near real-time RICs) and Non-real-time wireless intelligent controllers (Non-RT RICs or Non-real-time RICs). The method may also provide for functional segmentation of the MLB and related functional flows between at least two entities. The method may further ensure that the location of the MLB is performed, including possible splitting between gNB (interchangeably referred to as E2 node in O-RAN architecture), non-RT RIC and Near-RT RIC. The method and system may also provide data collection to facilitate MLB function execution in both Near-RT RIC entities and Non-RT RIC entities.

Referring to fig. 1, fig. 1 illustrates an exemplary network architecture (also referred to as network architecture (100)) of an ad hoc network (100) in which or with which the Service Management and Orchestration (SMO) system (110) (or simply system (110)) of the present disclosure may be implemented, according to an embodiment of the present disclosure. As shown, the exemplary network architecture (100) may be equipped with a Non-real-time wireless intelligent controller (Non-RT RIC) (122) associated with the SMO system (110), and a Near-real-time wireless intelligent controller (Near-RT RIC) (124) communicatively coupled to the SMO system (110) for SON.

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), interchangeably referred to as User Equipment (UE) (124) and collectively referred to as a plurality of UEs (102)) via a second computing device (104-1, 104-2, … -N) (interchangeably referred to as a base station (104-1, 104-2, … -N), and collectively referred to as a plurality of base stations (104)), and the SMO system (110) may be further operably coupled to the base station (104) via an open radio access network radio unit (Open radio access network Radio Unit, O-RU) (114). The SMO (110) may also be communicatively coupled to one or more third computing devices (106) (interchangeably referred to as a gNB Distributed Unit (DU) or gNB DU 106), and one or more fourth computing devices (116) (interchangeably referred to as a gNB Control Unit (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) (hereinafter interchangeably referred to as first nodes (118)).

In an example embodiment, the first computing device, the second computing device, the third computing device, the fourth computing device, and the fifth computing device may belong to a plurality of neighboring cells or serving cells.

In an example embodiment, the serving cell and the plurality of neighboring cells may be distributed across a plurality of CUs (116) and a plurality of DUs (106). The first interface (hereinafter also referred to as Xn interface) may be used for data collection of the MLB.

SMO (110) may be configured to execute a first set of instructions (interchangeably referred to hereinafter as mobility load balancing or MLB). When executed, the MLB may manage data collected from a plurality of first, second, third, fourth, and fifth computing devices associated with the Near-RT RIC (124). In one embodiment, when multiple neighbor cells span the same Near-RT RIC (124), the MLB implementation in the Near-RT RIC (124) may architecturally override the data collection mechanism.

In yet another embodiment, the serving cell and the plurality of neighboring cells may be at different Near-RT RIC, where each cell is associated with a different Near-RT RIC, and may be distributed over different CUs (116) and different O-DUs (106). The Xn interface cannot be used here to collect data.

In one embodiment, the SMO System (110) and Near-RT RIC (124) may be a System on Chip (SoC), but are not limited to similar systems. In another embodiment, the field data capture, storage, matching, processing, decision making, and actuation logic may be encoded using a Micro-service architecture (Micro-Services Architecture, MSA), but is not limited thereto. Multiple micro-services may be containerized and may be event-based to support portability.

In one embodiment, the network architecture (100) may be modular and flexible to accommodate any kind of variation in SMO systems (110) and Near-RT RIC (124). The configuration details of the SMO system (110) and the Near-RT RIC (124) may be dynamically modified.

In one embodiment, the SMO system (110) may be remotely monitored and data, application, and physical security of the SMO system (110) may be fully ensured. In one embodiment, the data may be carefully collected and deposited in a cloud-based data lake (data lake) for processing to extract valuable predictability. Thus, predictive maintenance may be achieved.

In yet another embodiment, the MLB may split between Near-RT RIC and Non-RT RIC, and the SMO may play a key role in MLB SON feature support.

In yet another embodiment, the MLB may split between SMO and gNB nodes (not shown in fig. 1, and interchangeably referred to as E2 nodes, hereinafter) through an open second interface (interchangeably referred to as O1 interface, hereinafter).

In one exemplary embodiment, as a non-limiting example, the communication network (108) may include at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, exchange, process, a combination thereof, or the like, one or more messages, data packets, signals, waves, voltages or current levels, or some combination thereof, or the like. As non-limiting examples, the network may include one or more of the following: wireless networks, wireline networks, the internet, intranets, public networks, private networks, packet-switched networks, circuit-switched networks, ad hoc networks, infrastructure networks, public Switched Telephone Networks (PSTN), wireline networks, cellular networks, satellite networks, fiber optic networks, and some combinations thereof.

In another exemplary embodiment, a centralized server (112) may be included in the architecture (100). As non-limiting examples, the centralized server (112) may include one or more of the following: a standalone server, a blade server, a server rack, a server bank, a server farm, hardware supporting a cloud service or part of a system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines executing server-side functions described herein, at least part of any of the foregoing, or some combination thereof.

In one embodiment, the one or more first computing devices (124), one or more mobile devices (not shown in fig. 1), may communicate with the SMO system (108) via a 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 one embodiment, the one or more first computing devices (124) and the one or more mobile devices may include, but are not limited to, any electrical device, electronic device, electromechanical device, or combination of one or more of the above devices, such as a mobile phone, a smart phone, a Virtual Reality (VR) device, an augmented Reality (Augmented Reality, AR) device, a laptop computer, a general purpose computer, a desktop computer, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device, where the computing device may include one or more built-in or externally coupled accessories, including but not limited to, a visual aid device, such as a camera, an audio aid device, a microphone, a keyboard, an input device for receiving input from a user, such as a touch pad, a touch screen, an electronic pen, a receiving device for receiving any audio or video signal in any frequency range, and a transmitting device that may transmit any audio or video signal in any frequency range. It is to be appreciated that the one or more first computing devices (124) and the one or more mobile devices may not be limited to the devices mentioned, and that various other devices may be used. The smart computing device may be one of the suitable systems for storing data and other private/sensitive information.

Fig. 3 illustrates an exemplary block diagram representation (300) of a system architecture according to an embodiment of the present disclosure. As shown, in one aspect (also referred to as use case-1 (UC-1) or option 1), the serving cell (304-1) and the plurality of neighboring cells (304-m, 304-m2, 304-p2, 304-q 1) are at the same Near-RT RIC (302). The serving cell (304-1) and the plurality of neighboring cells (304-m, 304-m2, 304-p2, 304-q 1) may be distributed over 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 (MLB support). For example, let cell-1 (301-1) be a serving cell, whose load exceeds the threshold upper limit [ Th-U ]. It may be assumed that the cell load of a subset of the plurality of neighboring cells, which are candidate cells for transfer, is below the lower threshold limit Th-L.

Fig. 4 illustrates an exemplary MLB xApp [ UC-1] representation (400) highlighting a tentative sequential flow for collecting load information for a serving cell from an associated E2 node, according to an embodiment of the present disclosure. Cell-1 may be successfully delegated (408) in a tentative sequential flow of the context of creating the cell at the Near-RT RIC (406) as shown. The cell may collect load information from the associated E2 node by triggering a resource status request (414) to the E2 node via the E2 interface. The E2 node may perform measurements (422) and may report measured load information (424) to the Near-RT RIC (406) via the E2 interface based on the configured periodicity.

In one embodiment, when a cell is deployed and commissioned (408), the cell may establish an E2 link (410) with a Near-RT RIC [ RIC ] (406). The RIC (406) may create a cell context (412) for the cell. Next, the RIC (406) may send a RIC subscription request (414) to the O-CU-CP-1 (404) to begin measurements (418) of the cell and to begin reporting periodically. Next, O-CU-CP-1 (404) may configure measurements (422) in O-DU-1 (402) for the cell via F1AP resource status initiation procedure (424). In addition, the O-DU-1 (402) may start to measure the cell (422) and report (424) Radio Resource (RR) status, composite Available Capacity Group (CACG), slice available capacity (SlIAC), number of active UEs (Act UEs) to the O-CU-CP at set periods, etc. In addition, O-CU-CP-1 (404) may forward resource status updates (426 and 428) to Near-RT RIC (406) along with the number of RRC connections (430 and 434). Next, the Near-RT RIC (406) may check all resource status updates (426 and 428) and store the resource status updates (426 and 428) of the cell. The order of the procedure may be followed for each cell that may be delegated by the Near-RT RIC (406).

Fig. 5 illustrates an exemplary MLB xApp [ UC-1] representation (500) highlighting a flow for processing load information for a serving cell received from an associated E2 node, according to an embodiment of the present disclosure. As shown, a tentative sequential flow for processing the received cell load information is shown, which may require further steps necessary to transfer the UE to the selected neighboring cell if the load situation requires it.

In one embodiment, when a RIC indication (510) may be received at a Near-RT RIC (508), and if the cell load (cell load) is greater than Th-U for a period of time 'T1', the cell may decide to transfer some of its load to multiple neighboring cells (512). Next, the Near-RT RIC (508) may collect a list of a plurality of neighbor cells for the high load cell from the local ANR xApp (514). From the list of the plurality of neighbor cells, the serving cell and the plurality of neighbor cells may belong to the same Near-RT RIC (508) (516). Further, the Near-RT RIC (508) may collect load information (518) from relevant cell contexts within the MLB xApp for the plurality of neighbor cell lists. In addition, the Near-RT RIC (508) may analyze the load information and identify a subset of cells (520) that have a cell load less than Th-L for a period of time 'T'. A cell with a cell load less than Th-L during the period 'T' may become a candidate cell for load transfer.

Furthermore, based on possible AI/ML algorithms, the Near-RT RIC (508) may dynamically select appropriate HO trigger parameter values (522) for the subset of cells. Here, the MLB xApp may cooperate with the MRO xApp to determine the appropriate HO trigger parameters. Near-RT RIC (508) may request, via RIC subscription request (524), O-CU-CP-1 (506) to begin using the modified HO trigger value via the E2 interface. The O-CU-CP-1 (506) may reconfigure (528) the cell's UE (502) with the new measurement configuration. Thus, the UE (502) within the high load cell may send an early measurement report to trigger a Handover (HO) to multiple neighboring cells. Thus, HO to multiple neighbor cells may be triggered, which may reduce the load of the serving cell (530).

FIG. 6 illustrates an exemplary MLB xApp [ UC-1] representation (600) of a tentative sequential flow for restoration to a normal state after an MLB transition, according to an embodiment of the disclosure. Temporary sequence flows are described herein that revert to a normal operating state after a cell successfully completes an MLB transition. When switching to a neighboring cell, the load on the own cell may start to decrease. When the load of the serving cell is less than the average load for a certain duration 'T', the Near-RT RIC (608) may determine to resume (610) the changes made to the HO trigger parameters of these neighboring cells.

Based on AI/ML, the Near-RT RIC (608) may dynamically select (612) appropriate HO trigger parameter values for neighboring cells and serving cells. If desired, the MLB xApp may cooperate with the MRO xApp to determine appropriate HO trigger parameters. Near-RT RIC (608) may request, via RIC subscription request (614), O-CU-CP-1 (606) to begin 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 the new measurement configuration and the operation begins to return to normal.

Fig. 7 is an illustrative embodiment of an alternative deployment scenario representation (700) of an MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure. As shown, the deployment scenario highlights an alternative embodiment (also referred to as use case 2 (UC-2) or option 2). As shown, the serving cell (304-1) and the plurality of neighboring cells (304-m, 304-m2, 304-p2, 304-q 1) may be in different Near-RT RIC entities (302-1 and 302-2). As shown in FIG. 7, the serving cell (304-1) and the plurality of neighboring cells (304-m, 304-m2, 304-p2, 304-q 1) may be distributed across different O-CU-CPs (308-1 and 308-n) and different O-DUs (314-1). The Xn interface can be used here to collect load information of multiple neighboring cells (304-m, 304-m2, 304-p2, 304-q 1) located at different Near-RT RIC entities (302-1 and 302-2) required for MLB support. Cell-1 is a serving cell whose load exceeds an upper threshold limit Th-U. According to the ANR table, a plurality of neighboring cells of cell-1 may be identified by a shaded box. It may be assumed that the cell load of a subset of the plurality of neighboring cells, which are candidate cells for transfer, is below the lower threshold limit Th-L.

FIG. 8 illustrates an exemplary MLB xApp [ UC-2] representation (800) of a tentative sequential flow for configuring load information collection over an Xn interface according to an embodiment of the disclosure. The tentative sequential flow illustrates the collection of load information from multiple associated E2 nodes, which may be distributed across multiple Near-RT RIC, by triggering a resource status request to the E2 node via the E2 interface. In one exemplary embodiment, the E2 node may use the Xn interface to request and obtain load information. In the manner described herein, the E2 node may perform measurements and report the measured load information to the requested E2 node via the Xn interface based on the configured periodicity. The Near-RT RIC (808) may locally collect (810) load information for a plurality of neighboring cells belonging to the same RIC within the MLB xApp. For multiple neighboring cells belonging to different Near-RT RIC, the Near-RT RIC (808) may request the O-CU-CP-1 (806) to collect (814) its load information. O-CU-CP-1 (806) may then request that O-CU-CP-n (836) belonging to another RIC provide (816) load information for cells in the cell list via the XnAP resource status initiator (818). The O-CU-CP-n (836) may begin to collect load information for all of these cells from the O-DUs (804) via the F1AP resource status initiator (826).

FIG. 9 illustrates an exemplary MLB xApp [ UC-2] representation (900) of a tentative sequential flow for collection and post-processing of received load information over an Xn interface according to embodiments of the disclosure. The tentative sequential flow is used by O-CU-CP-n (910) to collect load information from their respective O-DUs (904) and forward the resource status display report to the requested O-CU-CP-1 (906) according to the set period, and then the O-CU-CP-1 (906) forwards the resource status display report to the Near-RT RIC (908). The Near-RT RIC (908) may process the received load information as well as locally collected load information and take necessary actions on similar lines, as explained in the UC-1 embodiment described herein. When O-CU-CP-n (910) may begin receiving load information from O-DUs (904) via F1AP resource status reporting procedure (922), O-CU-CP-n (910) may send F1AP via XnAP resource status reporting procedure (924): the resource status update report (922) is forwarded to O-CU-CP-1 (906).

When the load condition of the serving cell may meet the transfer criterion, as mentioned in the UC-1 scenario, the Near-RT RIC (908) may dynamically select an appropriate value of the HO trigger parameter for each of the plurality of neighboring cells based on AI/ML. The Near-RT RIC (908) may request the O-CU-CP-1 (906) to begin using the modified HO trigger values for multiple neighbor cells. The O-CU-CP-1 (906) may reconfigure (928) UEs (902) belonging to the cell of the Near-RT RIC (908) with the new measurement configuration.

For cells belonging to different Near-RT RIC, the O-CP-CU-1 (906) may forward the modified HO trigger value to the O-CU-CP-n (910) via the XnAP mobility settings change procedure (930). The O-CU-CP-n (910) may reconfigure (928) all UEs (902) belonging to the cell of the Near-RT RIC (908) with the new measurement configuration. The rest of the procedure is the same as explained for UC-1 in the previous example.

FIG. 10 is an illustrative embodiment (1000) of a functional block diagram of MLB support at a Non-RT RIC in accordance with an embodiment of the disclosure. As shown, the E2 node (1022) may perform measurements and capture PM data and store it locally. Based on the PM data reporting configuration (T), the E2 node (1022) may report PM data, events/alarms, logs, etc. to the SMO (1002) via the O1 interface.

By way of non-limiting example, the reporting configuration may be, for example, 5min, 10min, 15min, 20min, 25min, 30min, 45min, 60min, 90min, etc.

In one exemplary embodiment, the EMS (1012) within the SMO (1002) may internally forward data to the MDAS (1006) and the NMS (1004). The MDAS (1006) may store data and perform big data analysis in consideration of the overall data accumulated in its memory so far. In addition, the MDAS (1006) may generate an associated load pattern for each associated cell. Accumulation of data can be envisaged as days, months or years of data. Since the data accumulation duration may be long, the accuracy and proximity to reality of the generated pattern may also be very high. The generated patterns, such as load patterns, duration patterns, etc., may be shared with Non-RT RIC (1008).

Non-RT RIC [ rApp ] (1008) may analyze these patterns and attempt to derive whether a particular maximum cell load pattern and a particular lower cell load pattern are periodic or aperiodic, the duration of such pattern, and the circumstances in which such pattern may occur in the future. Non-RT RIC [ rApp ] (1008) may also analyze similar patterns of multiple neighboring cells. Based on this analysis, the Non-RT RIC (1008) can predict the maximum cell load that will occur immediately next and its duration, and for this duration the Non-RT RIC (1008) can also check the behavior of all neighboring cells. In addition, the Non-RT RIC (1008) may list a subset of reliable neighbor cells of candidate neighbor cells available for transfer. The predicted load condition, the predicted duration of occurrence of high load, the tentative list of neighbor cells for handover, etc. may be shared with the Near-RT RIC (1014) through a third interface (hereinafter also referred to as A1 interface).

Fig. 11 illustrates an exemplary representation (1100) of sequential flow of data across different O-RAN entities for MLB support in accordance with an embodiment of the present disclosure. As shown, in one aspect, non-RT RIC (1106) may use the prediction data to direct Near-RT RIC (1108) accordingly. For example, when the predicted load is lower for a set duration, the Non-RT RIC (1106) may direct the Near-RT RIC (1108) to reduce the use of carrier aggregation, reduce the use of dual connectivity, reduce operating bandwidth, reduce MIMO configuration as much as possible, switch to a lower modulation class, be able to attract more incoming switches, etc., for the set duration. Similarly, when the predicted load is very high for a certain duration, the Non-RT RIC (1106) may instruct the Near-RT RIC (1108) to be ready to use the above features as much as possible. Specifically, non-RT RIC (1106) may provide guidance in the form of policies, while Near-RT RIC (1108) may evaluate the current situation based on the received guidance and its own real-time analysis and make decisions accordingly.

Fig. 12 is a pictorial embodiment representation (1200) of a functional architecture supported by MLBs only across SMO (1002) and E2 nodes (1022), in accordance with an embodiment of the present disclosure. As shown, in one aspect, the MLB function performs a split between SMO (1002) and E2 node (1022) over an open O1 interface (1018). In one exemplary embodiment, the MLB controller (1204) is located at a management entity (e.g., EMS context (1012)), and the MLB agent (1202) is located at the E2 node (1022).

The function of the MLB rApp (1010) at the Non-RT RIC is the same as explained in the previous embodiment, except that the MLB rApp (1010) can provide the derived MLB strategy locally to the MLB controller (1204). The MLB controller (1204) at the management entity (1012) may directly perform data analysis on the PM data received from the E2 node (1022) and make appropriate load balancing decisions. The MLB controller (1204) may also make MLB decisions using load/time patterns generated by the MDAS (1006) on the accumulated PM data. The MLB agent (1202) may execute MLB decisions/commands received from the MLB controller (1204) over an open O1 interface (1018).

The MLB agent (1202) may access Near-RT PM data locally within the E2 node (1022), perform real-time analysis thereof, and may make load balancing decisions locally. The MLB decisions may be consistent with decisions/commands received from the MLB controller (1204). The MLB agent (1202) may be specific to the E2 node (1022) and specific to a particular implementation. However, compliance with the MLB criteria received over the open O1 interface (1018) may still make the MLB functionality vendor independent.

Fig. 13 is a diagram (1300) of a functional architecture supported by an MLB that does not include a Non-RT RIC, spanning only SMO (1002) and E2 nodes (1022), according to an embodiment of the disclosure. As shown, in one aspect, the Non-RT RIC does not play any role for the MLB feature, and the MLB controller (1204) itself is responsible for all functions explained in the previous embodiments for the MLB rApp within the Non-RT RIC. The remaining functions are similar to those explained above.

FIG. 14 illustrates an exemplary computer system (1400) in which embodiments of the present invention may be used or with in accordance with embodiments of the present disclosure. As shown in FIG. 14, the computer system (1400) may include an external storage device (1410), a bus (1420), a main memory (1430), a memory,Read only memory (1440), mass storage device (1450), communication ports (1460), and processor (1470). Those skilled in the art will appreciate that a computer system may include more than one processor and multiple communication ports. Examples of processors (1470) include, but are not limited to

or Itanium 2 processor, or +.>

Or Athlon->

Processor(s)>

Series processor, fortisco ^TM A system-on-chip processor, or other future processor.

The processor (1470) may include various modules associated with embodiments of the present invention. The communication port (1460) may be any of an RS-232 port, 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 for modem-based dial-up connections. The communication port (1460) may be selected according to the network, such as a local area network (Local Area Network, LAN), wide area network (Wide Area Network, WAN), or any network to which the computer system is connected. The memory (1430) may be random access memory (Random Access Memory, RAM), or any other dynamic storage device known in the art. The read-only memory (1440) may be any static storage device such as, but not limited to, a programmable read-only memory (Programmable Read Only Memory, PROM) chip for storing static information (e.g., boot-up or BIOS instructions for the processor (1470)).

The mass memory (1450) may be any current or future mass memory solution that may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, parallel advanced technology attachment (Parallel Advanced Technology Attachment, PATA) or serial advanced technology attachment (Serial Advanced Technology Attachment, SATA) hard disk drives or solid state drives (internal or external, e.g., having universal serial bus (Universal Serial Bus, USB) and/or Firewire interfaces), such as those available from the greek (e.g., the greek barreda 782 family) or the hitachi (e.g., the hitachi Deskstar 13K 800), one or more optical disks, redundant array of independent disks (Redundant Array of Independent Disk, RAID) storage, such as disk arrays (e.g., SATA arrays) available from various vendors.

Bus (1420) communicatively couples processor (1470) with other memory, storage, and communication blocks. The bus (1420) may be, for example, a peripheral component interconnect (Peripheral Component Interconnect, PCI)/PCI expansion (PCI-X) bus, a small computer system interface (mall Computer System Interface, SCSI), USB, etc., for connecting expansion cards, drives and other subsystems, and other buses (e.g., a Front Side Bus (FSB) connecting the processor (1470) to the software system).

Optionally, operation and management interfaces (e.g., display, keyboard, and cursor control devices) may also be coupled to the bus (1420) to support direct operation and interaction with the computer system. Other operation and management interfaces may be provided through network connections via communication ports (1460). The external storage device (1410) may be any kind of external hard disk drive, floppy disk drive,

A drive, a Compact Disc-Read Only Memory (CD-ROM), a Compact Disc-Re-Writable (CD-RW), a digital video Disc Read Only Memory (Digital Video Disk-Read Only Memory, DVD-ROM). The above components are only used to illustrate various possibilities. The above-described exemplary computer system should not limit the scope of the present disclosure in any way.

Although the preferred embodiments are fairly important herein, it is understood that many embodiments may be produced from the preferred embodiments and that many changes may be made in the preferred embodiments without departing from the principles of the present invention. The above-described and other variations in the preferred embodiments of the present invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be clearly understood that the foregoing description is made only by way of illustration of the invention and not by way of limitation.

Advantageous effects

The present disclosure provides systems and methods for mobility load balancing of cells in a telecommunications network using an open radio access network (O-RAN).

The present disclosure provides systems and methods for implementing Mobility Load Balancing (MLB) functions for self-organizing networks (SON) in an O-RAN architecture.

The present disclosure provides systems and methods for functional segmentation between different entities in an O-RAN architecture and associated data flow/control flow mechanisms.

The present disclosure provides systems and methods for implementing two mechanisms for MLB functionality in O-RAN architectures, such as MLB implementations in Near-RT RIC, non-RT RIC entities, and MLB implementations in management entities and Near-RT RICs.

The present disclosure provides systems and methods for collecting data to facilitate MLB function execution in Near-RT RIC entities and Non-RT RIC entities.

The present disclosure provides systems and methods for transferring cells to neighboring cells in a telecommunications network in an O-RAN architecture to improve network efficiency.

Rights reservation

A portion of the disclosure of this patent document contains material protected by intellectual property rights, such as, but not limited to, copyrights, designs, brands, IC layout designs, and/or trade dress protection, which pertains to Jio Platforms Limited (JPL) or its affiliated company (hereinafter referred to as the owner). The owner is not interested in any 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. The owner fully reserves all rights to such intellectual property rights. The present disclosure may relate to the O-RAN specifications given in 3gpp TR 21.905[1 ].

Claims (20)

1. A system (110) for implementing Mobility Load Balancing (MLB) functionality of a self-organizing network (SON) of cells 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; and

a memory coupled to the processor, wherein the memory includes processor-executable instructions that, when executed, cause the processor to:

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;

receiving load information of the cell from the one or more E2 nodes based on the transmitted resource status request;

obtaining reports from the one or more E2 nodes based on the collected load information;

transmitting the obtained report to a Near real time radio access network intelligent controller (Near-RT RIC) (124);

receiving a Handover (HO) trigger value from the Near-RT RIC based on the report; and

the load of the cell is reduced based on the modified HO trigger value.

2. The system of claim 1, wherein the resource status request is sent to the one or more E2 nodes via an E2 interface.

3. The system of claim 1, wherein the reports obtained from the one or more E2 nodes include Radio Resource (RR) status, combined Available Capacity Group (CACG), slice available capacity (SliAC), and a number of active User Equipments (UEs) associated with the cell.

4. The system of claim 1, wherein the report obtained from the one or more E2 nodes further comprises a measurement of the load information.

5. The system of claim 4, wherein the measurement of the load information is performed by the one or more E2 nodes.

6. The system of claim 1, wherein the report is periodically transmitted to the Near-RT RIC via an F1AP resource status initiation procedure.

7. The system of claim 1, wherein the HO trigger value is received from the Near-RT RIC via the E2 interface.

8. The system of claim 1, wherein the load of the cell is restored by the Near-RT RIC when the load of the cell is less than an average load for a given time.

9. The system of claim 1, wherein the Near-RT RIC is configured to:

receiving a report based on load information of the cell;

Transferring the cell to one or more neighboring cells based on the received report;

obtaining load information from the one or more neighboring cells;

generating HO trigger values for the one or more neighboring cells based on the obtained load information; and

the generated HO trigger value is sent to the O-CU-CP for reconfiguring one or more user devices associated with the cell.

10. The system of claim 9, wherein a cell load of the one or more neighboring cells is less than an average load over a given period of time.

11. A method for implementing Mobility Load Balancing (MLB) functions of a self-organizing network (SON) of cells in an open radio access network (O-RAN), the method comprising:

the processor sending a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of the E2 interface communicate with a Non-real time radio access network intelligent controller (Non-RT RIC) (122);

the processor receiving load information of the cell from the one or more E2 nodes based on the sent resource status request;

the processor obtaining a report from the one or more E2 nodes based on the collected load information;

The processor sends the obtained report to a Near real time radio access network intelligent controller (Near-RT RIC) (124);

the processor receiving a Handover (HO) trigger value from the Near-RT RIC based on the report; and

the processor reduces the load of the cell based on the modified HO trigger value.

12. The method of claim 11, wherein the resource status request is sent to the one or more E2 nodes via an E2 interface.

13. The method of claim 11, wherein the reports obtained from the one or more E2 nodes include Radio Resource (RR) status, combined Available Capacity Group (CACG), slice available capacity (SliAC), and a number of active User Equipments (UEs) associated with the cell.

14. The method of claim 11, wherein the report obtained from the one or more E2 nodes further comprises a measurement of the load information.

15. The method of claim 14, wherein the measuring of the load information is performed by the one or more E2 nodes.

16. The method of claim 11, wherein the report is periodically transmitted to the Near-RT RIC via an F1AP resource status initiation procedure.

17. The method of claim 11, wherein the HO trigger value is received from the Near-RT RIC via the E2 interface.

18. The method of claim 11, wherein the load of the cell is restored by the Near-RT RIC when the load of the cell is less than an average load for a given time.

19. The method of claim 11, wherein the Near-RT RIC is configured to:

receiving a report based on load information of the cell;

transferring the cell to one or more neighboring cells based on the received report;

obtaining load information from the one or more neighboring cells;

generating HO trigger values for the one or more neighboring cells based on the obtained load information; and

the generated HO trigger value is sent to the O-CU-CP for reconfiguring one or more user devices associated with the cell.

20. The method of claim 19, wherein a cell load of the one or more neighboring cells is less than an average load over a given period of time.

Images