CN116325868A - System and method for optimizing mobile robustness of a telecommunications network - Google Patents

Abstract

The present disclosure relates generally to wireless telecommunications networks, and more particularly to systems and methods for optimizing mobile robustness of a telecommunications network using an open radio access network (O-RAN). The system and method implement a Mobile Robustness Optimization (MRO) function and data collection interworking method for self-organizing networks (SONs) in an O-RAN architecture. The O-RAN architecture has two distinct entities: near real-time radio intelligent controllers (near RT RIC (210)) and non-real-time radio intelligent controllers (non-RT RIC (214A)) for functional segmentation and related functional flow of the MROs between these two entities. The system gathers data to advance MRO function execution in near RT RIC and non RT RIC entities.

Description

System and method for optimizing mobile robustness of a telecommunications network

Technical Field

Embodiments of the present disclosure relate generally to wireless telecommunications networks. More particularly, the present disclosure relates to systems and methods for optimizing mobile robustness of a telecommunications network using an 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 art relating to various features of the present 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.

In general, mobile users may also grow exponentially as cellular networks evolve from fourth generation (4G), fifth generation (5G), to sixth generation (6G) along with other radio access technologies such as wireless fidelity (Wi-Fi). Thus, mobile operators may be forced to deploy very high density heterogeneous networks (hetnets) to meet the needs of users. Hetnets can generally be built from multiple portfolios and multiple vendor based solutions. One of the major challenges operators face during greenfield or brown field deployment of hetnets may be the need for high quality installations. Another challenge is to continuously monitor the performance and health of the deployed network. Dynamic adaptation to changing environments is also a problem, as are active tuning and optimization.

The above challenges may require significant manual effort and time delay due to regular/frequent field access, and may result in additional operating costs. To overcome these drawbacks and greatly reduce the operating costs (OPEX), self-organizing networks (SON) may be used. The SON may be a self-organizing network or may also be a self-optimizing network. SON may be an automated technology that allows the network to set itself up and self-manage resources and configurations for optimal performance. SON can function in three categories. The first category is self-configuration. Self-configuration may facilitate 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 functions such as plug and play (PnP), automatic Neighbor Relation (ANR), and physical layer cell identity (PCI) selection and conflict resolution functions.

The second type is self-optimization. Self-optimization helps to enhance network performance through near real-time optimization of radio and network configuration. Self-optimization is valuable throughout the life cycle of the network. Self-optimization includes various functions such as Mobility Load Balancing (MLB), mobile Robustness Optimization (MRO), random Access (RACH) optimization, energy Saving (ES), radio link failure reporting, coverage and Capacity Optimization (CCO), (DL power control, RET), forward handover, frequent Handover Mitigation (FHM), and interference mitigation (inter-cell, intra-Radio Access Technology (RAT), 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. The self-repair includes various functions such as cell outage detection (dead/bad/dormant/sector/beam), cell outage restoration, cell outage compensation, and cell outage compensation restoration.

The Minimization of Drive Tests (MDT) function may be designed to operate independently of the SON, although its function is reused as much as possible. The SON functions described above may be handled by SON algorithms individually or in groups. The SON algorithm may perform functions such as monitoring a network by collecting management data including Management Data Analysis Service (MDAS) data and analyzing the management data to determine whether there is a problem in the network that needs to be solved. The SON algorithm may also decide SON actions to solve the problem and perform the SON actions that solve the problem. Furthermore, SON algorithms can evaluate whether a problem has been solved by analyzing management data.

Based on the location of the SON algorithm, SONs can be categorized into four different solutions, which may be used to implement various SON use cases. The solution may be selected according to the needs of the SON use case. The centralized SON (C-SON) may include the functions performed by the SON algorithm in the management system. A cross-domain centralized SON (CD C-SON) may include functionality that SON algorithms may perform in a cross-domain (CD) layer. Furthermore, the domain-centralized SON (D-C-SON) may be a SON algorithm that can be performed in the domain layer. Furthermore, the distributed SON (D-SON) may be a SON algorithm in a Network Function (NF).

Thereafter, the hybrid SON (H-SON) may be a SON algorithm that can be performed at two or more levels, such as NF layer, domain layer, or cross-domain (CD) layer. Since SON algorithms are implementation-based, different vendors may choose different methods for their SON solutions. Some suppliers may choose the C-SON method, some suppliers may choose the D-SON method, and other suppliers may choose solutions based on the H-SON method. Operators may inevitably use multi-vendor solutions when deploying hetnets.

Fig. 1 shows an exemplary block diagram representation (100) of a 5G HetNet deployment scenario. In a 5G HetNet deployment scenario, an operator may use management entities such as a Network Management System (NMS) from different vendors and a set of Element Management Systems (EMS) from different vendor sets. The operator may also use management entities such as Radio Access Network (RAN) nodes, e.g. next generation NodeB centralized units (gNB-CUs) from different vendor sets and next generation NodeB distributed units (gNB-DUs) from different vendor sets. Operators may face problems in hetnets deployed in fig. 1. One of the problems is that the D-SON of the gNB-CU-1 (116) and the gNB-CU-2 (124) may not coordinate well because both are from different suppliers, although both communicate with each other through an open Xn interface (I/F).

Another problem is that the D-SON of the gNB-CU-2 (124) and the hybrid SON of the gNB-CU-n (130) (D-son+dc-SON) may not coordinate well, as both come from different suppliers, although both communicate with each other through an open Xn interface. One key issue is that the C-SON can either be collocated with a management entity (e.g., EMS/NMS) or implemented as a stand-alone entity. Integrating the C-SON as a stand-alone entity with the RAN node is extremely difficult because of the need to implement an interface as well. Furthermore, the CD C-SON in the NMS (106) may affect the performance of operating D C-SON and D-SON functions in a multi-vendor environment.

Another problem is the integration of third party SON solutions into HetNet, which can lead to a drop in the overall Key Performance Indicators (KPIs). Furthermore, layer 3 radio resource management (L3-RRM) coordination between neighboring NB-CUs (116, 124, 130) is lacking, whether in the same vendor scenario or in multiple vendor scenarios, which will have an impact on overall KPI performance. L3-RRM and layer 2-RRM (L2-RRM) coordination across 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.

When multiple suppliers coordinate with each other through an Xn interface, SON and RRM as a proprietary implementation have a significant impact on overall performance. 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 may be to make the interface between the SON solution and the interworking Radio Access Network (RAN) node as open as possible. The open radio access network (O-RAN) alliance may be a global community of mobile network operators, suppliers, and research and academic institutions operating in the RAN industry.

The O-RAN alliance is likely to be a mission to change the RAN industry to a more intelligent, open, virtualized, and fully interoperable mobile network. New O-RAN standards may enable a more competitive and viable RAN provider ecosystem through faster innovations to improve the user experience. An O-RAN based mobile network will improve both the efficiency of RAN deployment and the operation of the mobile operator. However, conventional systems and methods may not provide a mechanism to implement mobile robustness optimization functions in an O-RAN architecture.

Thus, there is a need for mobile robustness optimization functionality in an O-RAN architecture, as well as a mechanism for functional partitioning between different entities in the O-RAN architecture and associated data/control flow mechanisms. Accordingly, there is a need in the art to provide systems and methods that overcome the shortcomings of the existing prior art.

Object of the present application

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

It is an object of the present disclosure to provide an efficient and reliable system and method for optimizing mobile robustness of a telecommunication network using an open radio access network (O-RAN).

It is an object of the present disclosure to provide a system and method for implementing Mobile Robustness Optimization (MRO) functions of a self-organizing network (SON) in an O-RAN architecture.

It is an object of the present disclosure to provide systems and methods for functional partitioning between different entities in an O-RAN architecture and associated data/control flow mechanisms.

It is an object of the present disclosure to provide a system and method for performing a partitioned MRO aspect of position.

It is an object of the present disclosure to provide systems and methods that provide support for detecting and helping to correct connection failures caused by Intra-radio access technology (Intra-RAT) mobility, as well as support for unnecessary inter-system handovers to other Radio Access Technologies (RATs).

It is an object of the present disclosure to provide systems and methods that address scenarios such as early handover, late handover, handover to a wrong cell, ping-pong handover, fast handover, very fast handover, etc.

It is an object of the present disclosure to provide systems and methods that address issues such as early handover, too late handover, handover to a wrong cell, ping-pong handover, fast handover, very fast handover, etc., by optimizing Handover (HO) parameters such as cell individual offset, hysteresis, trigger time, Q offset, etc.

It is an object of the present disclosure to provide a system and method for collecting data facilitating MRO function execution in near Real time radio access network intelligent controller (near RT RIC) entities and non-RT RIC entities.

It is an object of the present disclosure to provide a system and method for optimizing HO parameters for mobility scenarios for both idle and connected modes.

It is an object of the present disclosure to provide a system and method for implementing two mechanisms of MRO functionality in an O-RAN architecture, such as MRO implementation in a near RT RIC entity, a non-RT RIC entity, and MRO implementation in a management entity and a near RT RIC.

Disclosure of Invention

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 a Mobile Robustness Optimization (MRO) function 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 receive one or more data patterns of a cell from a Management Data Analysis Service (MDAS). The MDAS is configured to keep track of and monitor Phase Modulation (PM) data, events, and error logs received as fault, configuration, specification, performance, safety (FCAPS) data associated with the cells deployed in a geographic location. The MDAS is configured to perform big data analysis on FCAPS data to generate one or more data patterns.

Further, the non-RT RIC of the system selects a data pattern for the cell based on the received one or more data patterns. The management entity provides initial values of handover parameters during a deployment phase to the cell via an O1 interface. During a Plug-n-Connect (Plug-n-Connect) phase or a Plug-n-Play (Plug-Play) phase of the cell deployment, the management entity provides initial values of the handover parameters during the deployment phase to the cell via an O1 interface. The selected data pattern corresponds to a geographic location of one or more cells. The cell is preconfigured with initial values of the handover parameters in idle mode and connected mode. The one or more handover optimization policies are communicated by the non-RT RIC to the near-RT RIC via an A1 interface (512). The handover parameters for the cell include a cell individual offset value, a hysteresis value, a trigger time, and a Q offset value.

The near RT RIC is configured to collect near RT measurement data, phase Modulation (PM) data, and other data from an E2 node. The near RT RIC is further configured to share the collected data with RT data analysis functions. The near RT RIC is further configured to receive a data analysis from the RT data analysis function based on the collected data. The near RT RIC is further configured to use the one or more handover optimization policies received from the non-RT RIC based on the received data analysis. The near RT RIC is further configured to derive an optimized value for the handover parameter based on the one or more handover optimization policies. Further, the near RT RIC is configured to send the optimized handover parameters to the near RT RIC.

Further, the non-RT RIC of the system generates one or more handover optimization policies for the cell based on the selected data pattern. Further, the non-RT RIC of the system communicates the one or more handover optimization policies of the cell to a near real-time radio access network intelligent controller (near RT RIC) associated with the system. Further, the non-RT RIC of the system receives an optimized value of a handover parameter of the cell from the near RT RIC, wherein the near RT RIC generates an optimized value of the handover parameter based on the one or more handover optimization policies.

In one aspect, the present disclosure provides a method for implementing a Mobile Robustness Optimization (MRO) function of a self-organizing network (SON) of cells in an open radio access network (O-RAN). The method includes receiving one or more data patterns of a cell from a Management Data Analysis Service (MDAS). The MDAS is configured to keep track of and monitor Phase Modulation (PM) data, events, and error logs received as fault, configuration, specification, performance, safety (FCAPS) data associated with the cells deployed in a geographic location. The MDAS is configured to perform big data analysis on FCAPS data to generate one or more data patterns.

Further, the method includes selecting a data pattern for the cell based on the received one or more data patterns. The management entity provides initial values of handover parameters during a deployment phase to the cell via an O1 interface. During a Plug-n-Connect (Plug-n-Connect) phase or a Plug-n-Play (Plug-Play) phase of the cell deployment, the management entity provides initial values of the handover parameters during the deployment phase to the cell via an O1 interface. The selected data pattern corresponds to a geographic location of one or more cells. The cell is preconfigured with initial values of the handover parameters in idle mode and connected mode. The one or more handover optimization policies are communicated by the non-RT RIC to the near-RT RIC via an A1 interface (512). The handover parameters for the cell include a cell individual offset value, a hysteresis value, a trigger time, and a Q offset value.

The near RT RIC is configured to collect near RT measurement data, phase Modulation (PM) data, and other data from an E2 node. The near RT RIC is further configured to share the collected data with RT data analysis functions. The near RT RIC is further configured to receive a data analysis from the RT data analysis function based on the collected data. The near RT RIC is further configured to use the one or more handover optimization policies received from the non-RT RIC based on the received data analysis. The near RT RIC is further configured to derive an optimized value for the handover parameter based on the one or more handover optimization policies. Further, the near RT RIC is configured to send the optimized handover parameters to the near RT RIC.

Further, the method includes generating one or more handover optimization policies for the cell based on the selected data pattern. Further, the method includes transmitting the one or more handover optimization policies of the cell to a near real-time radio access network intelligent controller (near RT RIC) associated with the system. Further, the method includes receiving an optimized value of a handover parameter of the cell from the near RT RIC, wherein the near RT RIC generates the optimized value of the handover parameter based on the one or more handover optimization policies.

Drawings

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

Fig. 1 shows an exemplary block diagram representation (100) of a fifth generation 5G heterogeneous network (HetNet) deployment scenario.

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

Fig. 3 shows an exemplary representation (300) of a proposed Service Management and Orchestration (SMO) system for optimizing mobile robustness of a telecommunications network using an open radio access network (O-RAN) according to an embodiment of the present disclosure.

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

Fig. 5A shows an exemplary block diagram representation (500 a) of Mobile Robustness Optimization (MRO) in a near real-time radio intelligent controller (near RT RIC), non-real-time radio intelligent controller (non-RT RIC) entity of an O-RAN according to an embodiment of the disclosure.

Fig. 5B shows an exemplary block diagram representation (500B) of Mobile Robustness Optimization (MRO) in a management entity of an O-RAN and a near RT RIC entity, according to an embodiment of the disclosure.

Fig. 6A illustrates a sequence diagram representation (600 a) of detecting a premature handover during handover execution according to an embodiment of the present disclosure.

Fig. 6B shows a sequence diagram representation (600B) of detecting a premature handover immediately after successful handover execution according to an embodiment of the present disclosure.

Fig. 6C illustrates a sequence diagram representation (600C) of detecting a premature handover immediately after successful handover execution, in which User Equipment (UE) context is deleted in conjunction with an access and mobility management function (AMF), according to an embodiment of the present disclosure.

Fig. 6D illustrates a sequence diagram representation (600D) of detecting an too late handover during handover execution according to an embodiment of the present disclosure.

Fig. 6E illustrates a sequence diagram representation (600E) of detecting an too late handover prior to handover execution according to an embodiment of the present disclosure.

Fig. 6F illustrates a sequence diagram representation (600F) of detecting a handover to a wrong cell after successful handover execution with a wrong target cell according to embodiments of the present disclosure.

Fig. 6G illustrates a sequence diagram representation (600G) of detecting a handover to an erroneous cell after preparation for a successful handover with an erroneous target cell in accordance with an embodiment of the present disclosure.

FIG. 7 illustrates an exemplary computer system (700) in or with which embodiments of the present disclosure may be implemented, in accordance with embodiments of the present disclosure.

The above will be more apparent from the following more 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 disclosed embodiments may be practiced without these specific details. Several of the features described below may be used independently of one another or in combination with any combination of the other features. A single feature may not address any 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.

In the following description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those 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 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.

Further, it is noted that the individual embodiments may be 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. Further, the order of the operations may be rearranged. When the operation of one process is completed, the process is terminated, but the process may have additional steps not included in the figure. A process may correspond to a method, a function, a program, a subroutine, etc. When a process corresponds to a function, the termination of the process may correspond to the return of the function to the calling function or the main function.

The terms "exemplary" and/or "illustrative" 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 these 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" or "an embodiment" or "one example" or "an example" 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.

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 disclosure provides systems and methods for optimizing mobile robustness of a telecommunications network using an open radio access network (O-RAN). The present disclosure provides systems and methods for implementing Mobile Robustness Optimization (MRO) functions of self-organizing networks (SONs) in an O-RAN architecture. The present disclosure provides systems and methods for functional partitioning between different entities in an O-RAN architecture and associated data/control flow mechanisms. The present disclosure provides systems and methods that provide locations of MRO aspects that perform segmentation. The present disclosure provides systems and methods that provide support for detecting and helping to correct connection failures caused by Intra-radio access technology (Intra-RAT) mobility, as well as support for unnecessary inter-system handovers to other Radio Access Technologies (RATs). The present disclosure provides systems and methods that address scenarios such as early handoff, late handoff, handoff to a wrong cell, ping-pong handoff, fast handoff, very fast handoff, etc. The present disclosure provides a system and method that solves problems such as premature handover, too late handover, handover to a wrong cell, ping-pong handover, fast handover, very fast handover, etc., by optimizing Handover (HO) parameters such as cell individual offset, hysteresis, trigger time, Q offset, etc.

The present disclosure also provides systems and methods for collecting data that facilitates MRO function execution in near real time radio access network intelligent controller (near RT RIC) entities and non real time radio access network intelligent controller (non RT RIC) entities. The present disclosure provides systems and methods for optimizing HO parameters for use in idle and connected mode mobility scenarios. The present disclosure provides systems and methods for two mechanisms for implementing MRO functionality in an O-RAN architecture, such as MRO implementation in a near RT RIC entity, a non-RT RIC entity, and MRO implementation in a management entity and a near RT RIC.

Referring to fig. 2, fig. 2 illustrates an exemplary network architecture (200) (also referred to as network architecture (200)) for optimizing mobile robustness in which or with which the Service Management and Orchestration (SMO) system (208) of the present disclosure may be implemented or simply referred to as SMO system (208) according to an embodiment of the present disclosure. As shown, the exemplary network architecture (200) may include a non-RT RIC (210) and a near-RT RIC (214A) associated with the SMO system (208). The non-RT RIC (210) and the near-RT RIC (214A) may be configured to advance mobile robustness optimization based on schemes received from users (228-1, 228-2, 228-3, …, 228-N) (individually referred to as one user (228) and collectively referred to as multiple users (228)) associated with one or more mobile computing devices (224-1, 224-2, …, 224-N) (individually referred to as one computing device (224) and collectively referred to as multiple computing devices (224)). The SMO system (208) may also be operatively coupled to a mobile computing device (not shown in fig. 1) via an open radio access network radio unit (O-RU) (204). The SMO (208) may be communicatively coupled to one or more computing devices (224).

Further, the non-RT RIC (210) may include rApps (212), and the near-RT RIC (214A) may include xApps (214B). The SMO system (208) and the near RT RIC (214A) may be coupled to an open radio access network distributed unit (O-DU) (206). The O-DU (206) may be coupled to an open radio access network central unit control plane (O-CU-CP) (216) and an open radio access network central unit user plane (O-CU-UP) (218). Near RT RICs (214A) may also be coupled to O-CU-CPs (216) and O-CU-UPs (218). The O-CU-CP (216) may be coupled to the O-CU-UP (218). In addition, the O-CU-CP (216) may be coupled to a fifth generation (5G) core network (5 GC) (220), and the O-CU-UP (218) may be coupled to a User Plane Function (UPF) (222).

In one embodiment, the SMO system (208) may implement a Mobile Robustness Optimization (MRO) function and data collection interworking method for a self-organizing network (SON) in an open radio access network (O-RAN) architecture. The O-RAN architecture may have two different entities, a near RT RIC (214A) and a non-RT RIC (210), in which near RT RIC (214A) and non-RT RIC (210) the functional partitioning of the MROs and related functional flows between the two entities may be implemented.

In one embodiment, the SMO system (208) may perform functional segmentation of the MROs and locate segmented MRO executions.

In one embodiment, SMO system (208) may collect data to advance execution of MRO functions in near RT RIC (214A) and non-RT RIC (210) entities.

In one embodiment, the SMO system (208) may detect and correct connection failures caused by mobility within a Radio Access Technology (RAT) and unnecessary inter-system handovers to other RATs.

In one embodiment, SMO system (208) may handle scenarios such as, but not limited to, early handoff, too late handoff, handoff to a wrong cell, ping-pong handoff, fast handoff, very fast handoff, etc.

In one embodiment, the SMO system (208) may correct the problem by optimizing handover parameters such as cell individual offset, hysteresis, trigger time, Q offset, etc.

In one embodiment, the SMO system (208) may optimize handover parameters applicable to both idle mode mobility scenarios and connected mode mobility scenarios.

In one embodiment, the field data acquisition, storage, matching, processing, decision making, and actuation logic may be encoded using a micro-service architecture (MSA), but is not limited thereto. The plurality of micro-services may be containerized and may be event-based to support portability.

In one embodiment, because an approximation process for optimizing mobile robustness in a telecommunications network may be obtained, the network architecture (200) may be modular and flexible to accommodate any kind of variation in SMO systems (208) and near RT RIC (214A). SMO system (208) and near RT RIC (214A) configuration details may be modified on the fly.

In one embodiment, the SMO system (208) may be monitored remotely and the data, applications, and physical security of the SMO system (208) may be fully ensured. In one embodiment, the data may be carefully collected and stored in a cloud-based data lake for processing to extract operational advice. Thus, predictive maintenance may be achieved.

In an exemplary embodiment, the communication network (not shown in fig. 1) may include, by way of example and without limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, exchange, process, or a combination thereof, etc., one or more messages, data packets, signals, waves, voltages, current levels, or some combination thereof. The network may include, by way of example and not limitation, one or more of the following: wireless networks, wireline networks, the internet, intranets, public networks, private networks, packet-switched networks, circuit-switched networks, point-to-point (ad hoc) networks, infrastructure networks, public Switched Telephone Networks (PSTN), wireline networks, cellular networks, satellite networks, fiber optic networks, and some combination thereof.

In another exemplary embodiment, a server (not shown in FIG. 1) may be included in the architecture (200). The near RT RIC (214A) and SMO system (208) may be implemented on a server. The server may include, by way of example and not limitation, one or more of the following: individual servers, server blades, server racks, server groups, server clusters, hardware supporting a cloud service or part of a system, home servers, hardware running virtualized servers, one or more processors executing code to function as servers, one or more machines executing server-side functions described herein, at least part of any of the foregoing, and some combination.

In one embodiment, one or more computing devices (224) and one or more mobile computing devices (not shown in FIG. 1) may communicate with SMO system (208) via a set of executable instructions residing on any operating system, including but not limited to Android ^TM 、iOS ^TM And Kai OS ^TM Etc. In one embodiment, the one or more computing devices (224) and the one or more mobile computing devices may include, but are not limited to, any electrical device, electronic device, electromechanical device, any device, or combination of one or more of the foregoing, such as a mobile phone, smart phone, virtual Reality (VR) device, augmented Reality (AR) device, notebook computer, general purpose computer, desktop computer, personal digital assistant, tablet computer, mainframe computer, or any other computing device, where the computing devices may include one or more built-in or externally coupled accessories including, but not limited to, a visual aid such as a camera, an audio aid, a microphone, a keyboard, an input device (e.g., a touchpad, a touch-enabled screen, an electronic pen) for receiving input from a user, a receiving device for receiving any audio or video signal in any frequency range, and a transmitting device capable of transmitting any audio or video signal in any frequency range. It is to be appreciated that the one or more first computing devices (224) and the one or more mobile computing devices may not be limited to the noted devices, and that various other devices may be used. The smart computing device may be one of the appropriate systems for storing data and other private/sensitive information.

Fig. 3 illustrates an exemplary representation (300) of a proposed Service Management and Orchestration (SMO) system (208) for optimizing mobile robustness of a telecommunications network using an open RAN (O-RAN) according to an embodiment of the present disclosure. In one aspect, the SMO system (208) may include one or more processors (302). The one or more processors (302) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge microcontrollers or mist microcontrollers (Fog microcontroller), digital signal processors, central processing units, logic circuits, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processors (302) may be configured to obtain and execute computer-readable instructions stored in a memory (304) of the SMO system (208). The memory (304) may store one or more computer readable instructions or routines in a non-transitory computer readable storage medium that may be extracted and executed to create or share data packets through a web service. Memory (304) may include any non-transitory storage device including, for example, volatile memory such as RAM or non-volatile memory such as EPROM, flash memory, etc.

In one embodiment, the SMO system (208) may include an interface (306). The interface (306) may also provide a communication path for one or more components of the SMO system (208). Examples of such components may include, but are not limited to, a processing unit/engine (308) and a database (310).

The processing unit/engine (308) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to implement one or more functions of the processing engine (308). In the examples described herein, such a combination of hardware and programming may be implemented in several different ways. For example, the programming for the processing engine (308) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the processing engine (308) may include processing resources (e.g., one or more processors) for executing the above-described instructions. In this example, the machine-readable storage medium may store instructions that, when executed by a processing resource, implement a processing engine (308). In such examples, the SMO system (208) may include a machine-readable storage medium storing instructions and a processing resource executing the instructions, or the machine-readable storage medium may be separate but available to the SMO system (208) and the processing resource. In other examples, the processing engine (308) may be implemented by electronic circuitry. Further, the SMO system (208) may include a Machine Learning (ML) module.

The processing engine (308) may include one or more engines selected from any of a data acquisition engine (312), a signal acquisition engine (314), and other engines (316). The data acquisition engine (312) and the signal acquisition engine (314) may include Machine Learning (ML) modules. The processing engine (308) may also include, but is not limited to, edge-based micro-service event processing.

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

The system architecture (400) is an O-RAN architecture. The rApps (212) may have an interface through which external information may be fed back to the operator network. As shown in fig. 4, the near RT RIC (406) may be a logic function that enables near real-time control and optimization of RAN elements and resources through fine-grained data collection and actions over the E2 interface. Near RT RIC (406) may include an Artificial Intelligence (AI)/Machine Learning (ML) workflow that includes model training, reasoning, and updating handled by xApps (214B).

Further, as shown in fig. 4, the non-RT RIC (404) may include logic functions within a service management and orchestration System (SMO) (402) that may drive content delivered over the A1 interface. The non-RT RIC (404) may include a non-RT RIC framework and a non-RT RIC application, such as rApps (212). Furthermore, the non-RT RIC framework may function inside the SMO system (402) and may logically terminate the A1 interface to the near RT RIC (406). The non-RT RIC framework may also disclose to the rApps (212) via the R1 interface a set of internal SMO services that are required in its running process. The non-RT RIC framework may function within the non-RT RIC (404) and may provide AI/ML workflows that include model training, reasoning, and updating required by the rApps (412).

In addition, the O1 interface from the O-RAN component terminates at the SMO system (402). The O-CU-CP (408) may be a logical node hosting the control plane portion of the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP). Further, the O-CU-UP (410) may be a logical node hosting the user plane portion of the PDCP protocol and the service data adaptation protocol (Service Data Adaptation Protocol, SDAP) protocol. The O-DUs (412) may be logical nodes hosting Radio Link Control (RLC)/Medium Access Control (MAC)/high Physical (PHY) layers based on lower layer functional segmentation. The E2 node may be a logical node that terminates at the E2 interface. Furthermore, the O-RAN node that may terminate at the E2 interface is for NR access at an O-CU-CP (408), O-CU-UP (410), O-DU (412), or any combination, and for evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access (E-UTRA) access such as O-eNB (418).

A non-RT RIC application such as rApps (212) may be a modular application that utilizes functionality disclosed via the R1 interface of the non-RT RIC framework to provide value added services with respect to RAN operation. Value added services that operate with respect to the RAN may include, but are not limited to, driving the A1 interface, recommending values and actions that may then be applied on the O1/O2 interface, generating "rich information (EI)" for use by the rApps (212), and so forth. The rApps (212) may function within a non-RT RIC (404) to enable non-real-time control and optimization of RAN elements and resources.

The rApps (212) may also provide policy-based guidance to applications/features in the near RT RIC (406). In addition, near RT RIC applications such as xApps (214B) may be run on near RT RIC (406). xApps (214B) may be composed of one or more micro-services and may identify which data itself consumes and which data itself provides when online. xApps (214B) may be independent of the near RT RIC (406) and may be provided by any third party. The E2 interface may enable a direct association between xApps (214B) and RAN functions.

Further, the open Cloud (O-Cloud) (416) may be a Cloud computing platform, which may include a collection of physical infrastructure nodes. These nodes may meet the O-RAN requirements to host the relevant O-RAN functions of near RT RIC (405), O-CU-CP (408), O-CU-UP (410) and O-DU (412) to support software components (e.g., operating systems, virtual machine monitors, container runtime, etc.) as well as appropriate management and orchestration functions. Furthermore, an O1 interface may be between SMO system (208) and O-RAN managed elements for operation and management. The O1 interface may enable failure, configuration, accounting, performance, security (FCAPS) management, physical Network Function (PNF) software management, and file management.

In addition, an O2 interface may be between the SMO system (208) and the O-Cloud (416) for supporting O-RAN virtual network functions. Furthermore, the A1 interface between the non-RT RIC (404) and the near-RT RIC (406) may enable the non-RT RIC function to provide policy-based guidance, ML model management, and rich information to the near-RT RIC function so that the RAN may optimize Radio Resource Management (RRM) under certain conditions. Thereafter, the E2 interface may connect the near RT RIC (406) and one or more O-Cu-CPs (408), one or more O-Cu-UPs (410), and one or more O-DUs (412). The R1 interface may be between the rApps (212) and the non-RT RIC (404) framework.

Although not shown in fig. 4, the O-eNB (418) may not support the O-DU (412) and O-RU (414) functions with an open fronthaul interface between the O-DU (412) and O-RU (414) functions. The management side includes SMO systems (402) that include non-RT-RIC (404) functionality. On the other hand, O-Cloud (416) is a Cloud computing platform that includes a set of physical infrastructure nodes that meet O-RAN requirements to host relevant O-RAN functions (e.g., near RT RIC (406), O-CU-CP (408), O-CU-UP (410), and O-DU (412), etc.), supporting software components (e.g., operating systems, virtual machine monitors, container runtime, etc.), and appropriate management and orchestration functions. As shown in fig. 4, the O-RU (414) terminates the open forwarding management Plane (M-Plane) interface towards the O-DU (414) and SMO system (402).

Fig. 5A illustrates an exemplary block diagram representation of Mobile Robustness Optimization (MRO) in near real-time radio intelligent controller (near RT RIC) (512) and non-real-time radio intelligent controller (non-RT RIC) (508) entities of an O-RAN according to an embodiment of the disclosure.

In an embodiment, mobile Robustness Optimization (MRO) may be performed using non-RT aspects of MRO functions enabled in non-RT RIC (508). Mobile Robustness Optimization (MRO) may also be performed using near RT aspects of MRO functions enabled in near RT RIC (512). A Management Data Analysis Service (MDAS) of the management entity (504) may track all PM data, events, and error logs received as part of FCAPS data associated with all possible cells in a particular geographic location. By default, FCAPS data at the management entity (504) may be non-RT in nature. The MDAS may perform a big data analysis on FCAPS data and generate one or more data patterns.

When a cell is ready to be started, the cell may have to be configured with initial values of handover parameters for both "idle mode" and "connected mode". Some handover parameters may be broadcast while some other handover parameters may be configured separately during connection setup. Typically, the handover parameters may be set to default values or operator configured values. The MRO rApp (510) in the non-RT RIC (508) may use the data pattern generated by the MDAS and the geographic location of the cell to select the data pattern. The selected data pattern may be closely adapted to the cell being deployed. MRO rApp (510) in the non-RT RIC (508) may derive an initial set of values for the handover parameters. The derived values may be communicated to the management entity (504) via an internal interface of an SMO (502) module of the O-RAN. During the plug-and-play or plug-and-play phase of cell deployment, the management entity (504) may configure these values to the appropriate E2 node via the successfully established O1 interface.

The MRO rApp (510) may also generate a handover optimization policy based on the selected data pattern and communicate the handover optimization policy to the near RT RIC (512) via the A1 interface. The cell may now be successfully started and an E2 interface may be successfully established between the E2 node and the near RT RIC (512). MRO xApp (514) may begin collecting near RT measurement data, PM data, and other data from the associated E2 node. MRO xApp (514) may request RT data analysis function to generate relevant data analysis by sharing all data collected from E2 nodes. When MRO xApp (514) receives the requested data analysis, MRO xApp (514) may use the policies received from non-RT RICs (508) and derive new values for the handover parameters. If a change is predicted to be made to the handover parameters at the E2 node, the MRO xApp (514) may configure the updated values of the handover parameters to the E2 node via the E2 interface.

The E2 node may collect all MRO related counters and share the MRO related counters with the near RT RIC (512). Furthermore, the E2 node may share a connection failure indication with the near RT RIC (512) whenever a handover failure indication is received from a neighboring cell and UE.

Fig. 5B illustrates an exemplary block diagram representation of Mobile Robustness Optimization (MRO) in a management entity (504) and near real-time radio intelligent controller (near RT RIC) (512) entity of an O-RAN according to an embodiment of the disclosure.

In an embodiment, mobile Robustness Optimization (MRO) may be performed using non-RT aspects of MRO functions that may be fully enabled in the management entity (504). Mobile Robustness Optimization (MRO) may also be performed using near RT aspects of MRO functions enabled in near RT RIC (512). In this context, most of the functions of the MROs remain the same as explained in fig. 5A. However, the entire non-RT aspect of the MRO function may be enabled only within the management entity (504). An MRO function within the management entity (504) may derive initial handover parameters and provide the initial handover parameters to the E2 node via the successfully established O1 interface. The same MRO function module of the management entity (504) may derive the handover optimization policy and share the handover optimization policy with the near RT RIC (512) via the A1 interface. The use of MDAS by the MRO function will be the same as explained in fig. 5A.

Fig. 6A illustrates a sequence diagram representation (600 a) of detecting a premature handover during handover execution according to an embodiment of the present disclosure.

A radio link failure may occur in the target cell (606) immediately after the handover is completed. Radio link failure may also occur during the performance of the handover procedure when the UE (602) may attempt to reestablish a radio link in the source cell (604). Fig. 6A illustrates a scenario that may occur during handover execution when a UE (602) may not be able to successfully access a target cell (606).

At steps (612-1) and (612-2), SMO (208) may provide initial handover parameters during its deployment phase to source cell (604) and target cell (606), respectively, via the O1 interface, after which source cell (604) and target cell (606) begin operation. At step (612-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization function. When the source cell (604) can decide to trigger a handover of the UE (602) to which it is connected, the source cell (604) can prepare for the handover with the target cell (606) and issue a handover command to the UE (602) via an RRC reconfiguration message. After receiving the handover command, the UE (602) may attempt handover access with the target cell (606), but may fail due to insufficient strong Radio Frequency (RF) conditions.

As a result, in step (612-4), the UE (602) may reselect the source cell (604) and initiate an RRC reestablishment procedure. Because the source cell (604) has the UE (602) context, the RRC reestablishment procedure may be successful and the UE (604) may continue to be in a connected state. The source cell (604) may conclude that it is a premature handover scenario and may increment a premature Handover (HO) counter.

In step (612-5), the source cell (604) may prompt the occurrence of a premature handover via the E2 interface to the MRO xApp (514) at the near RT RIC (512) by detecting an indication of a premature handover. The indication of detection of a premature handover may carry data regarding the source cell (604), the target cell (606), the latest premature handover count, and other relevant details. The algorithm in MRO xApp (514) and near RT data analysis functions can now process the data and check if any modifications to the HO parameters are needed. If there may be a need for modification, the MRO xApp (514) may instruct the updated HO parameters to the specific source cell (604) and/or other cells in general via the E2 node and E2 interface (this is not shown in the sequence diagram).

Fig. 6B illustrates a sequence diagram representation (600B) of detecting a premature handover immediately after successful handover execution in accordance with an embodiment of the present disclosure.

At step (614-1) and step (614-2), SMO (208) may provide initial handover parameters during its deployment phase to both the source cell (604) and the target cell (606), respectively, via the O1 interface, after which the source cell (604) and the target cell (606) start to operate. At step (614-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for optimization functions.

Herein, due to insufficient or inconsistent strong RF conditions, the UE (602) may experience radio link failure with the target cell (606) immediately after successful HO execution. Thus, the UE (602) may reselect the previous source cell (604) and trigger the RRC reestablishment procedure and set the cause to HO failure.

In step (614-4), the source cell (604) may receive an Xn from the target cell (606) as part of successful HO execution: and deleting the UE context when the UE context releases the message.

In step (614-5) and step (614-6), upon receipt of the RRC reestablishment request message, the previous source cell (604) may send Xn to the failed cell: fault indication message. The failed cell is the target cell (606) indicated by the UE (602) in the RRC reestablishment request message. The target cell (606) may process the received failure indication, analyze the conditions, and detect a premature HO scenario. In step (614-7), the target cell (606) may set the handover report type to Xn for "premature HO": a handover report message is sent to the source cell (604). Upon receiving the handover report message, the source cell (604) may increment a premature HO counter. In step (614-8), the source cell (604) may inform the MRO xApp (514) at the near RT RIC (214A) of the premature HO scenario via the E2 interface. The detected "premature handover" indication and further processing may remain the same as explained in the previous scenario.

Fig. 6C illustrates a sequence diagram representation (600C) of detecting a premature handover immediately after successful handover execution, wherein User Equipment (UE) context is coordinated and deleted with an access and mobility management function (AMF), according to an embodiment of the present disclosure.

At steps (616-1) and (616-2), SMO (208) may provide initial handover parameters during its deployment phase to both source cell (604) and target cell (606), respectively, via the O1 interface, and source cell (604) and target cell (606) begin operation. At step (616-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization function.

This scenario is the same as that shown in fig. 6B, however, the timer txnrreloc may generally send Xn at the target cell (606) as part of HO execution: the UE context release message expires before. Upon expiration of the timer, the source cell (604) may send NG: the UE context release request message requests an AMF (610) for UE (602) context release. The AMF (610) may then accept NG: UE context release request and sending NG to source cell (604): UE context release command message. The source cell (604) may then delete the UE context and send NG: the UE context release complete message acknowledges the same content to the AMF (610). These sequences are not shown in fig. 6C.

In steps (616-5) and (616-6), upon receiving the RRC reestablishment request message, the previous source cell (604) may send Xn to the failed cell (target cell (606)) indicated by the UE (602) in the RRC reestablishment request message: fault indication message. The target cell (606) may process the received failure indication, analyze the conditions, and detect that this is a premature HO condition.

In step (616-7), the target cell (606) may set the handover report type to Xn for "premature HO": a handover report message is sent to the source cell (604). Upon receiving the handover report message, the source cell (604) may increment a premature HO counter. At step (616-8), the source cell (604) may notify the MRO xApp (514) at the near RT RIC (214A) of the occurrence of the premature HO by detecting an indication of the premature handover via the E2 interface. The further process may be the same as explained in the previous scenario.

Fig. 6D illustrates a sequence diagram representation (600D) of detecting an too late handover during handover execution according to an embodiment of the present disclosure.

At steps (618-1) and (618-2), SMO (208) may provide initial handover parameters during the deployment phase to both source cell (604) and target cell (606), respectively, via the O1 interface, after which source cell (604) and target cell (606) begin operation. At step (618-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization functions.

At step (618-4), a radio link failure may occur in the source cell (604) prior to or during the handover procedure. The UE (602) may then attempt to reestablish its radio link in another cell or target cell (606).

Herein, the UE (602) may experience a radio link failure with the source cell (604) even before receiving the HO command. In step (618-5), the UE (602) may initiate an RRC reestablishment procedure with the target cell (606) and the cause is set to another failure. Since HO preparation may be successful, the target cell (606) may have a UE context. At step (618-6), upon receiving the RRC reestablishment request message from the same UE (602), the target cell (606) may send Xn to the source cell (604): fault indication message to indicate an too late HO scenario. Furthermore, the target cell (606) may send Xn to the source cell (604): UE context release message.

The source cell (604) may process the received failure indication, analyze the conditions, and detect an too late HO scenario. In steps (618-7) and (618-8), the source cell (604) may increment an too late HO counter and inform the MRO xApp (514) at the near RT RIC (214A) of the occurrence of the too late HO by detecting an indication of the too late handover via the E2 interface. Furthermore, the process at the near RT RIC (214A) may remain the same as explained in the early scenario.

Fig. 6E illustrates a sequence diagram representation (600E) of detecting an too late handoff prior to handoff execution according to an embodiment of the present disclosure.

At steps (620-1) and (620-2), SMO (208) may provide initial handover parameters during the deployment phase to both the source cell (604) and the target cell (606), respectively, via the O1 interface, after which the source cell (604) and the target cell (606) begin to operate. At step (620-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization function.

In step (620-4), the UE (602) may experience a radio link failure with the source cell (604) and initiate an RRC reestablishment procedure with the target cell (606) even before any HO preparation and the cause is set to another failure. The target cell (606) may not have the UE context since HO preparation may not have been initiated. At steps (620-5) and (620-6), upon receiving the RRC reestablishment request message from the UE (602), the target cell (606) may reject the reestablishment request and send Xn to the source cell (604): fault indication message indicating an too late HO scenario.

The source cell (604) may process the received failure indication, analyze the conditions, and detect an too late HO condition. The source cell (604) may increment an too late HO counter and notify the occurrence of the too late HO via the E2 interface by detecting an indication of the too late HO, near the MRO xApp (514) at RT RIC (214A). Further processing at the near RT RIC (214A) may remain the same as explained in the previous scenario.

Fig. 6F illustrates a sequence diagram representation of detecting a handover to a wrong cell after successful handover execution with a wrong target cell (600F), according to an embodiment of the present disclosure.

At steps (622-1) and (622-2), SMO (208) may provide initial handover parameters during the deployment phase to both source cell (604) and target cell (606), respectively, via the O1 interface, after which source cell (604) and target cell (606) begin operation. At step (622-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization functions.

A radio link failure may occur in the target cell (606) after or during the handover procedure and the UE (602) may attempt to re-establish its radio link in a cell that is neither the source cell nor the target cell.

In step (622-6), the UE (602) may experience radio link failure with the wrong target cell (606A) immediately after successful HO execution due to insufficient or inconsistent strong RF conditions. Thus, the UE (602) may reselect the true target cell (606B) and trigger the RRC reestablishment procedure and the cause is set to another failure. Upon receiving the RRC reestablishment request message, the real target cell (606B) may send Xn to the failed cell (erroneous target cell (606A)) indicated by the UE (602) in the RRC reestablishment request message: fault indication message. The wrong target cell (606A) may process the received failure indication, analyze the conditions, and detect a HO to wrong cell scenario.

At step (622-7), the wrong target cell (606A) may set the handover report type to Xn for "HO to wrong cell": a handover report message is sent to the source cell (604). Upon receiving the handover report message, the source cell (604) may increment the HO to the wrong cell counter. In step (622-8), the source cell (604) may notify the MRO xApp (514) at the near RT RIC (214A) of the occurrence of the handover to the wrong cell via the detected indication of the handover to the wrong cell by the E2 interface. The further process may be the same as explained in the previous scenario.

Fig. 6G illustrates a sequence diagram representation (600G) of detecting a handover to a wrong cell after preparation for a successful handover with a wrong target cell according to embodiments of the present disclosure.

At steps (624-1) and (624-2), SMO (208) may provide initial handover parameters during its deployment phase to both the source cell (604) and the target cell (606), respectively, via the O1 interface, after which the source cell (604) and the target cell (606) start to operate. At step (624-3), SMO (208) may provide handover optimization policy information to near RT RIC (214A) via the A1 interface for its optimization function.

Herein, due to insufficient or inconsistent strong RF conditions, the UE (602) may experience radio link failure with the wrong target cell (606A) immediately after successful HO preparation. Thus, the UE (602) may reselect the true target cell (606B) and trigger the RRC reestablishment procedure and the cause is set to another failure. In steps (624-4) and (624-5), upon receipt of the RRC reestablishment request message, the real target cell may send Xn to the failed cell (source cell (604)) indicated by the UE (602) in the RRC reestablishment request message: fault indication message. The source cell (604) may process the received failure indication, analyze the conditions, and detect a HO to error cell scenario.

In step (624-7), the source cell (604) may send Xn to the wrong target cell (606A): the handover cancel message to cancel the handover preparation. In addition, the source cell (604) may increment the HO to the wrong cell counter. In step (624-8), the source cell (604) may notify the MRO xApp (514) at the near RT RIC (214A) of the occurrence of the handover to the wrong cell via the E2 interface via detection of an indication to handover to the wrong cell. The further process may remain the same as explained in the previous scenario.

Ping-pong switching scene: in a ping-pong handover scenario, radio link failure may not occur, but after a successful handover, the UE (602) may stay in the cell being handed over for a very short time. The UE (602) may continue to move rapidly (hop) between the two cells frequently. Typically, in a ping-pong handover scenario, ping-pong occurs between two identical neighboring cells of the same or different RATs. The MRO xApp (514) may detect the ping-pong handover scenario and correct the ping-pong handover scenario by optimizing HO parameters. The MRO xApp (514) may also recommend handover to a higher layer cell of the same or a different RAT or, if applicable, to have a dual connection between the two cells to correct the ping-pong handover scenario.

Fast or very fast switching scenario: a fast or very fast handoff scenario may be similar to a ping-pong handoff scenario. In a fast or very fast handover scenario, the UE (602) may move quickly between different cells and stay in each cell for a very short time. The time of stay in each cell may depend on the moving speed of the UE. The MRO xApp (514) may have to detect fast or very fast switching scenes and distinguish between scenes that may be unavoidable and scenes that may be corrected.

For example, very fast switching scenarios may occur along railway lines and aircraft paths using ground to air communication, and along attended highways and the like. Such a very fast switching scenario may be unavoidable. In this context, no correction may be needed. MRO xApp (514) may detect scenes that may need correction. The MRO xApp (514) may then recommend handover to a higher layer cell, such as an NTN cell.

FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present disclosure may be implemented, in accordance with embodiments of the present disclosure. As shown in FIG. 7, computer system 700 may include an external storage device (710), a bus (720), a main memory (730), a read-only memory (740), a mass storage device (750), a communication port (760), and a processor (770). Those skilled in the art will appreciate that a computer system may include more than one processor and communication ports. Examples of processors (770) include, but are not limited to

Or Itanium 2A physical device, or Ruilong->

Or->

(Athlon/>

) The processor may be configured to perform the steps of,

processor, forti soc ^TM A system-on-chip processor, or other future processor.

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

Mass memory (750) may be any current or future mass storage 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., with Universal Serial Bus (USB) and/or Firewire (Firewire) interfaces), such as drives available from the greek (Seagate) (e.g., the harlequin (barreda) 782 family) or the Hitachi (Hitachi) (e.g., the Hitachi desktop star (Deskstar) 13K 800), one or more optical disks, redundant array of independent disks (Redundant Array of Independent Disk, RAID) storage devices, e.g., disk arrays available from various vendors (e.g., SATA arrays).

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

Optionally, carrier and management interfaces (e.g., display, keyboard, and cursor control devices) may also be coupled to bus (720) to support direct carrier interaction with the computer system. Other operators and management interfaces may be provided through network connections connected via a communication port (760). The external storage device (710) may be any kind of external hard disk drive, floppy disk drive,

Henpu (/ -)>

Zip) drive, compact Disc-Re-Writable (CD-ROM), digital video Disc-ROM (Digital Video Disk-Read Only Memory, DVD-ROM). The above components are only used to illustrate various possibilities. The above-described exemplary computer systems should in no way limit the scope of the present disclosure.

Although the preferred embodiments are well-appreciated herein, it should be understood that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the present invention. These 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 to be taken by way of illustration of the invention and not by way of limitation.

Advantages of the present disclosure

The present disclosure provides systems and methods for optimizing mobile robustness of a telecommunications network using an open radio access network (O-RAN).

The present disclosure provides systems and methods for implementing Mobile Robustness Optimization (MRO) functions of self-organizing networks (SONs) in an O-RAN architecture.

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

The present disclosure provides systems and methods that provide locations of MRO aspects that perform segmentation.

The present disclosure provides systems and methods that provide support for detecting and helping to correct connection failures caused by Intra-radio access technology (Intra-RAT) mobility, as well as support for unnecessary inter-system handovers to other Radio Access Technologies (RATs).

The present disclosure provides systems and methods that address scenarios such as early handoff, late handoff, handoff to a wrong cell, ping-pong handoff, fast handoff, very fast handoff, etc.

The present disclosure provides systems and methods that address issues such as premature handover, too late handover, handover to a wrong cell, ping-pong handover, fast handover, very fast handover, etc., by optimizing HO parameters such as cell individual offset, hysteresis, trigger time, Q offset, etc.

The present disclosure provides systems and methods for collecting data that facilitates MRO function execution in near RT RIC entities and non-RT RIC entities.

The present disclosure provides systems and methods to optimize HO parameters for mobility scenarios for both idle and connected modes.

The present disclosure provides systems and methods for two mechanisms for implementing MRO functionality in an O-RAN architecture, such as MRO implementation in a near RT RIC entity, a non-RT RIC entity, and MRO implementation in a management entity and a near RT RIC.

Reservation rights

A portion of the disclosure of this patent document contains material subject to intellectual property rights (e.g., but not limited to, copyrights, design, branding, IC layout design, and/or trade dress protection) that is owned by the intelligent platform company (Jio Platforms Limited, JPL) or its affiliated company (hereinafter referred to as the owner). Because this patent document appears in the patent and trademark office patent file or records, the owner is not against any facsimile reproduction by anyone of the patent document or patent disclosure, but reserves all rights whatsoever. The owner fully reserves all rights to such intellectual property rights. The present disclosure may relate to an O-RAN specification as provided in 3gpp TR 21.905[1 ].

Claims (20)

1. A system for implementing a Mobile Robustness Optimization (MRO) function 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 (RT RIC), wherein the non-RT RIC comprises:

a processor;

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

receiving one or more data patterns of a cell from a Management Data Analysis Service (MDAS);

selecting a data pattern for the cell based on the received one or more data patterns;

generating one or more handover optimization policies for the cell based on the selected data pattern;

transmitting the one or more handover optimization policies of the cell to a near real-time radio access network intelligent controller (RT RIC) associated with the system (512); and

an optimized value of a handover parameter of the cell is received from the near RT RIC (512), wherein the optimized value of the handover parameter is generated by the near RT RIC (512) based on the one or more handover optimization policies.

2. The system of claim 1, wherein the MDAS is configured to keep track of and monitor Phase Modulation (PM) data, events, and error logs received as fault, configuration, specification, performance, security (FCAPS) data associated with the cells deployed in a geographic location.

3. The system of claim 1, wherein the MDAS is configured to perform big data analysis on fault, configuration, specification, performance, security (FCAPS) data to generate the one or more data patterns.

4. The system of claim 1, wherein a management entity provides initial values of the handover parameters during a deployment phase to the cell via an O1 interface.

5. The system of claim 4, wherein the management entity provides initial values of the handover parameters to the cell during a plug-and-play phase or a plug-and-play phase of the cell deployment.

6. The system of claim 1, wherein the cell is preconfigured with initial values of the handover parameters in idle mode and connected mode.

7. The system of claim 1, wherein the selected data pattern corresponds to a geographic location of one or more cells.

8. The system of claim 1, wherein the one or more handover optimization policies are communicated by the non-RT RIC to the near-RT RIC via an A1 interface (512).

9. The system of claim 1, wherein the handover parameters of the cell include a cell individual offset value, a hysteresis value, a trigger time, and a Q offset value.

10. The system of claim 1, wherein the near RT RIC is configured to:

collecting near real-time (RT) measurement data, phase Modulation (PM) data, and other data from an E2 node;

sharing the collected data with an RT data analysis function;

receiving a data analysis from the RT data analysis function based on the collected data;

based on the received data analysis, using the one or more handover optimization policies received from the non-RT RIC;

deriving an optimized value of the handover parameter based on the one or more handover optimization policies; and

the optimized handover parameters are sent to the near RT RIC.

11. A method for implementing a Mobile Robustness Optimization (MRO) function of a self-organizing network (SON) of a cell in an open radio access network (O-RAN), the method comprising:

receiving, by a processor, one or more data patterns of a cell from a Management Data Analysis Service (MDAS);

Selecting, by the processor, a data pattern for the cell based on the received one or more data patterns;

generating, by the processor, one or more handover optimization policies for the cell based on the selected data pattern;

transmitting, by the processor, the one or more handover optimization policies of the cell to a near real-time radio access network intelligent controller (RT RIC) associated with the system (512); and

an optimized value of a handover parameter for the cell is received by the processor from the near RT RIC (512), wherein the optimized value of the handover parameter is generated by the near RT RIC (512) based on the one or more handover optimization policies.

12. The method of claim 11, wherein the MDAS is configured to keep track of and monitor Phase Modulation (PM) data, events, and error logs received as fault, configuration, specification, performance, security (FCAPS) data associated with the cells deployed in a geographic location.

13. The method of claim 11, wherein the MDAS is configured to perform big data analysis on fault, configuration, specification, performance, security (FCAPS) data to generate the one or more data patterns.

14. The method of claim 11, wherein a management entity provides initial values of the handover parameters during a deployment phase to the cell via an O1 interface.

15. The method of claim 11, wherein during a plug-and-play phase or a plug-and-play phase of the cell deployment, a management entity provides initial values of the handover parameters during a deployment phase to the cell via an O1 interface.

16. The method of claim 11, wherein the cell is preconfigured with initial values of the handover parameters in idle mode and connected mode.

17. The method of claim 11, wherein the selected data pattern corresponds to a geographic location of one or more cells.

18. The method of claim 11, wherein the one or more handover optimization policies are communicated by the non-RT RIC to the near-RT RIC via an A1 interface (512).

19. The method of claim 11, wherein the handover parameters of the cell comprise an individual cell offset value, a hysteresis value, a trigger time, and a Q offset value.

20. The method of claim 11, wherein the near RT RIC is configured to:

Collecting near real-time (RT) measurement data, phase Modulation (PM) data, and other data from an E2 node;

sharing the collected data with an RT data analysis function;

receiving a data analysis from the RT data analysis function based on the collected data;

based on the received data analysis, using the one or more handover optimization policies received from the non-RT RIC;

deriving an optimized value of the handover parameter based on the one or more handover optimization policies; and

the optimized handover parameters are sent to the near RT RIC.

Images