System and method for optimizing the mobility robustness of telecommunications networks

Abstract

The present disclosure relates generally to wireless telecommunications networks, and more particularly to a system and method for optimizing mobility robustness in telecommunications networks using Open Radio Access Networks (O-RAN). The system and method realize a mobility robustness optimization (MRO) function of a self-organizing network (SON) in an O-RAN architecture, and a data collection interworking method. The O-RAN architecture has two distinct entities called a near real-time radio intelligent controller (near RT RIC (210)) and a non-real-time radio intelligent controller (non-RT RIC (214A)) for functional division for MRO and related functional flows between the two entities. The system collects data to facilitate the execution of the functions of MRO in the near RT RIC and non-RT RIC entities.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to wireless electrical communication networks. More particularly, the present disclosure relates to systems and methods for optimizing the mobility robustness of communication networks using an Open Radio Access Network (O-RAN).

Background Art

[0002] The following description of related art is intended to provide background information related to the field of the present disclosure. This section may include certain aspects of technologies that may be related to various features of the present disclosure. However, it should be understood that this section is used only to deepen the reader's understanding of the present disclosure and is not used as an admission of prior art.

[0003] Generally, as cellular networks evolve from the fourth generation (4G) to the fifth generation (5G), and then to the sixth generation (6G), along with other wireless access technologies such as Wireless Fidelity (Wi-Fi), mobile subscriptions may increase exponentially. Therefore, mobile operators may be forced to deploy very high-density heterogeneous networks (HetNets) to meet subscriber demand. HetNets may generally be constructed by multi-portfolio and multi-vendor-based solutions. One of the important issues that operators face during the greenfield or brownfield deployment of HetNets may be the need for high-quality installations. Another issue is the continuous monitoring of the performance and soundness of the deployed network. Dynamic adaptation to changing environments is also a problem, as is preventive adjustment and optimization.

[0004] The aforementioned challenges can lead to very laborious manual processes and delays due to regular / frequent site visits, potentially resulting in additional operational costs. To overcome these drawbacks and significantly reduce operating expenses (OPEX), self-organizing networks (SONs) may be used. A SON can be a self-organizing network or a self-optimizing network. A SON can be an automated technology that allows a network to configure itself and self-manage resources and configurations to achieve optimal performance. SONs ​​can function in three categories. The first category is self-configuration. Self-configuration can help seamlessly integrate into a network by automatically configuring key parameters. Self-configuration is most beneficial during the initial deployment of a network. Self-configuration includes several capabilities such as plug-and-play functionality [PnP], automatic neighbor relation function [ANR], and physical layer cell identity [PCI] selection and conflict resolution capabilities.

[0005] The second category is self-optimization. Self-optimization helps improve network performance through near real-time optimization of wireless and network configurations. Self-optimization is beneficial throughout the entire lifetime of the network. Self-optimization includes various capabilities such as Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), RACH optimization, Energy Saving (ES), Wireless Link Failure Reporting, Coverage and Capacity Optimization (CCO), DL Power Control (RET), Forward Handover, Frequent Handover Mitigation (FHM), and Interference Mitigation (inter-cell, intra-cell, intra-RAT, inter-RAT).

[0006] The third category is self-healing. Self-healing allows neighboring cells to maintain network quality when a cell / sector fails, providing resilience (reliability) even in the event of an unexpected power outage. Self-healing is beneficial throughout the entire lifecycle of the network. Self-healing includes various capabilities such as Cell Outage Detection [hibernation / malfunctioning / sleeping cells / sectors / beams], Cell Outage Recovery, Cell Outage Compensation, and Cell Outage Compensation Recovery.

[0007] SON functions are reused whenever possible, but the Minimization of Drive Test (MDT) function may have been designed to operate independently of SON. The above SON functions may be handled individually or in groups by the SON algorithm. The SON algorithm may perform functions such as network monitoring by collecting management data, including MDAS data, and analyzing the management data to determine if there are any problems in the network that need to be resolved. The SON algorithm may also determine and execute SON actions to resolve the problems. Furthermore, the SON algorithm may evaluate whether the problems have been resolved by analyzing the management data.

[0008] Based on the location of the SON algorithm, SON may be categorized into four different solutions that may be possible to implement various SON use cases. The solution may be selected according to the needs of the SON use case. Centralized SON (C-SON) may include functions that the SON algorithm performs in a management system. Cross-Domain-Centralized SON (CD-SON) may include functions that the SON algorithm may perform in a cross-domain (CD) layer. Furthermore, Domain-Centralized SON (D-SON) may be an SON algorithm that may be performed in a domain layer. Furthermore, Distributed SON (D-SON) may be an SON algorithm in a non-fundamental network (NF).

[0009] Accordingly, Hybrid SON (H-SON) may be an SON algorithm that can be implemented at two or more levels, such as the NF layer, domain layer, or cross-domain (CD) layer. Because SON algorithms are implementation-dependent, different vendors may choose different approaches for their SON solutions. Some vendors may choose the C-SON approach, some the D-SON approach, and others the H-SON approach-based solution. Operators may inevitably use multi-vendor solutions while deploying a HetNet.

[0010] Figure 1 shows an exemplary block diagram representation (100) of a 5G HetNet deployment scenario. In a 5G HetNet deployment scenario, operators may use management entities such as network management systems (NMS) from different vendors and sets of element management systems (EMS) from different sets of vendors. Operators may also use management entities such as radio access network (RAN) nodes, such as Next Generation NodeB Centralized Units (gNB-CUs) and Next Generation NodeB Distributed Units (gNB-DUs) from different sets of vendors. Operators may face problems in the deployed HetNet shown in Figure 1. One problem is that the D-SONs of gNB-CU-1 (116) and gNB-CU-2 (124) communicate with each other via an open Xn interface, but may not work well together because they are from different vendors.

[0011] Another issue is that while the D-SON of gNB-CU-2(124) and the hybrid SON (D-SON + DC-SON) of gNB-CU-n(130) communicate with each other via an open Xn interface, they may not work well together because they are from different vendors. A key issue is that the C-SON can be implemented either as something deployed with a management entity [such as an EMS / NMS] or as a standalone entity. Integrating the C-SON as a standalone entity into a RAN node is extremely difficult because the interface is left to the implementation. Furthermore, the CD C-SON of NMS(106) may affect the performance of the D C-SON and D-SON functions when operating in a multi-vendor environment.

[0012] Another issue lies in the partial integration of third-party SON solutions into HetNet, and such integrations can lead to a decline in overall Key Performance Indicators (KPIs). Furthermore, L3-RRM coordination between neighboring gNB-CUs (116, 124, 130) may be lacking, regardless of whether it's the same or multi-vendor scenario, which impacts overall KPI performance. L3-RRM and L2-RRM coordination between multi-vendor gNB-CUs (116, 124, 130) and gNB-DUs (118, 120, 122, 126, 128, 132) may affect dynamic resource sharing and allocation.

[0013] SON and Radio Resource Management (RRM) are proprietary implementations that significantly impact overall performance when multiple vendors interact with each other via the Xn interface. Each algorithm behaves differently and has its own limitations. Even if a vendor is ready to integrate with third-party solutions [SON and / or RRM], they may not definitively quantify / verify output performance, primarily due to their own solutions. Such situations always end in conflict between agreed-upon vendors. One possible solution to these problems or limitations might be to make the interface between the SON solution and the interacting Radio Access Network (RAN) nodes as open as possible. The Open Radio Access Network (O-RAN) Alliance could be a global community of mobile network operators, vendors, and research and academic institutions active in the RAN industry.

[0014] The O-RAN Alliance's mission may be to reinvent the RAN industry toward more intelligent, open, virtualized, and fully interoperable mobile networks. New O-RAN standards could enable a more competitive and vibrant ecosystem of RAN suppliers through faster innovation to improve the user experience. O-RAN-based mobile networks would simultaneously improve the efficiency of RAN deployment and operation by mobile operators. However, conventional systems and methods may not provide the mechanisms to realize mobility robustness optimization capabilities in O-RAN architectures.

[0015] Therefore, there is a need for mobility robustness optimization features in O-RAN architectures, along with functional partitioning mechanisms between different entities in the O-RAN architecture and associated data / control flow mechanisms. Consequently, there is a need in the art to provide systems and methods that can overcome the shortcomings of existing prior arts. [Prior art documents] [Non-patent literature]

[0016] [Non-Patent Document 1] 3GPP TR 21.905[1] [Overview of the project] [Problems that the invention aims to solve]

[0017] Some of the objectives of this disclosure that at least one embodiment of this specification satisfies are listed below herein.

[0018] The purpose of this disclosure is to provide an efficient and reliable system and method for optimizing the mobility robustness of telecommunications networks using open radio access networks (O-RAN).

[0019] The purpose of this disclosure is to provide a system and method for realizing the mobility robustness optimization (MRO) function of a self-organizing network (SON) in an O-RAN architecture.

[0020] The purpose of this disclosure is to provide a system and method for functional partitioning between different entities in an O-RAN architecture and for associated data / control flow mechanisms.

[0021] The purpose of this disclosure is to provide a system and method for providing locality in the execution of a segmented MRO configuration.

[0022] An object of the present disclosure is to provide a system and method for assisting in detecting and correcting connection failures caused by mobility within a radio access technology (RAT), and further for supporting unnecessary inter-system handovers to other radio access technologies (RATs).

[0023] An object of the present disclosure is to provide a system and method for dealing with scenarios such as premature handover, delayed handover, handover to the wrong cell, ping-pong handover, high-speed handover, ultra-high-speed handover, etc.

[0024] An object of the present disclosure is to provide a system and method for solving problems such as premature handover, delayed handover, handover to the wrong cell, ping-pong handover, high-speed handover, ultra-high-speed handover, etc. by optimizing HO parameters such as cell individual offset, hysteresis, time to trigger, Q offset, etc.

[0025] An object of the present disclosure is to provide a system and method for collecting data to facilitate the execution of the MRO function in quasi- and non-RT RIC entities.

[0026] An object of the present disclosure is to provide a system and method for optimizing HO parameters applicable to both idle-mode mobility scenarios and connected-mode mobility scenarios.

[0027] An object of the present disclosure is to provide a system and method for two mechanisms for realizing the MRO function in the O-RAN architecture, such as the implementation of MRO in quasi-RT RIC and non-RT RIC entities, and the implementation of MRO in the management entity and quasi-RT RIC.

Means for Solving the Problems

[0028] This section is provided to introduce, in a simplified form, certain objects and aspects of the present invention that will be further described in detail below. This summary is not intended to identify key features or bounds of the claimed subject matter.

[0029] In an aspect, the present disclosure provides a system for implementing a Mobility Robustness Optimization (MRO) function of a Self-Organizing Network (SON) for cells of 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 Analytics Service (MDAS). The MDAS is configured to track and monitor impairment, configuration, accounting, performance, security (FCAPS) data, phase modulation (PM) data, events, and error logs received as FCAPS data related to cells deployed in a geographical location. The MDAS is configured to perform big data analysis on the FCAPS data to generate one or more data patterns.

[0030] Furthermore, the non-RT RIC of the system selects a data pattern for a cell based on one or more received data patterns. The cell receives initial values ​​for its handover parameters from the management entity during the deployment phase via the O1 interface. The cell receives initial values ​​for its handover parameters from the management entity during the deployment phase via the O1 interface during the Plug-n-Connect or Plug-n-Play phase of the cell deployment. The selected data pattern corresponds to the geographical location of one or more cells. The cell is pre-configured with initial values ​​for its handover parameters in idle mode and connected mode. One or more handover optimization policies are communicated by the non-RT RIC to the quasi-RT RIC (512) via the A1 interface. The cell's handover parameters include a cell-specific offset value, hysteresis value, time to trigger, and Q offset value.

[0031] The quasi-RT RIC is configured to collect quasi-RT measurement data, phase modulation (PM) data, and other data from the E2 node. The quasi-RT RIC is further configured to share the collected data with the RT data analysis function. The quasi-RT RIC is further configured to receive data analysis from the RT data analysis function based on the collected data. The quasi-RT RIC is further configured to use one or more handover optimization policies received from the non-RT RIC based on the received data analysis. The quasi-RT RIC is further configured to derive optimized values ​​for handover parameters based on one or more handover optimization policies. In addition, the quasi-RT RIC is configured to send the optimized handover parameters to the quasi-RT RIC.

[0032] Furthermore, the system's non-RT RIC generates one or more cell handover optimization policies based on selected data patterns. The system's non-RT RIC then communicates these policies to the system's associated Near-Real-Time Radio Access Network Intelligent Controller (near-RT RIC). Finally, the system's non-RT RIC receives optimized values ​​for the cell handover parameters from the rear-RT RIC, which are generated by the rear-RT RIC based on the one or more handover optimization policies.

[0033] In some embodiments, the Disclosure provides a method for implementing Mobility Robustness Optimization (MRO) capabilities for Self-Organizing Networks (SONs) for Open Radio Access Network (O-RAN) cells. The method includes the step of receiving one or more data patterns of a cell from a Management Data Analysis Service (MDAS). The MDAS is configured to track and monitor PM data, events, and error logs received as fault, configuration, accounting, performance, and security (FCAPS) data related to cells deployed at geographical locations. The MDAS is configured to perform big data analytics on the FCAPS data to generate one or more data patterns.

[0034] Furthermore, the method includes the step of selecting a data pattern for a cell based on one or more received data patterns. The cell is provided with initial values ​​for handover parameters by the management entity during the deployment phase via the O1 interface. The cell is provided with initial values ​​for handover parameters by the management entity during the deployment phase via the O1 interface during the Plug-n-Connect or Plug-n-Play phase of the cell deployment. The selected data pattern corresponds to the geographical location of one or more cells. The cell is pre-configured with initial values ​​for handover parameters in idle mode and connected mode. One or more handover optimization policies are communicated by the non-RT RIC to the quasi-RT RIC (512) via the A1 interface. The cell's handover parameters include a cell-specific offset value, a hysteresis value, a time to trigger, and a Q offset value.

[0035] The quasi-RT RIC is configured to collect quasi-RT measurement data, phase modulation (PM) data, and other data from the E2 node. The quasi-RT RIC is further configured to share the collected data with the RT data analysis function. The quasi-RT RIC is further configured to receive data analysis from the RT data analysis function based on the collected data. The quasi-RT RIC is further configured to use one or more handover optimization policies received from the non-RT RIC based on the received data analysis. The quasi-RT RIC is further configured to derive optimized values ​​for handover parameters based on one or more handover optimization policies. In addition, the quasi-RT RIC is configured to send the optimized handover parameters to the quasi-RT RIC.

[0036] Furthermore, the method includes the step of generating one or more handover optimization policies for a cell based on a selected data pattern. Furthermore, the method includes the step of communicating one or more handover optimization policies for a cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) associated with the system. Furthermore, the method includes the step of receiving optimized values ​​for the cell's handover parameters from the quasi-RT RIC, wherein the optimized values ​​for the handover parameters are generated by the quasi-RT RIC based on one or more handover optimization policies.

[0037] The accompanying drawings incorporated herein and constituting part of the present invention illustrate exemplary embodiments of the disclosed methods and systems, and similar reference numerals refer to the same parts throughout the various drawings. The components in the drawings are not necessarily to the correct scale, and instead, the emphasis is on clearly illustrating the principles of the invention. Some drawings may use block diagrams to show components, and the internal circuitry of each component may not be shown. It will be understood by those skilled in the art that the inventions in such drawings include inventions of electrical components, electronic components, or circuits commonly used to implement such components. [Brief explanation of the drawing]

[0038] [Figure 1] This figure (100) shows an exemplary block diagram representation of a fifth-generation (5G) heterogeneous network (HetNet) deployment scenario. [Figure 2] This figure shows an exemplary network architecture (200) in which the proposed system of this disclosure may be implemented according to embodiments of this disclosure. [Figure 3]Figure (300) shows an exemplary representation of a proposed Service Management and Orchestration (SMO) system for optimizing the mobility robustness of telecommunications networks using open radio access networks (O-RAN) according to embodiments of the present disclosure. [Figure 4] This figure shows an exemplary block diagram representation (400) of a system architecture according to an embodiment of the present disclosure. [Figure 5A] This figure (500a) shows an exemplary block diagram representation of mobility robustness optimization (MRO) in Near-Real-Time Radio Intelligent Controller (Near-RT RIC) and Non-Real-Time Radio Intelligent Controller (Non-RT RIC) entities of O-RAN according to embodiments of the present disclosure. [Figure 5B] This figure (500b) shows an exemplary block diagram representation of mobility robustness optimization (MRO) in an O-RAN management entity and a quasi-real-time radio intelligent controller (quasi-RT RIC) entity according to an embodiment of the present disclosure. [Figure 6A] This figure (600a) shows a sequence diagram representation of detecting an early handover during handover execution according to an embodiment of the present disclosure. [Figure 6B] This figure (600b) shows a sequence diagram representation of the detection of an early handover immediately following a successful handover, according to an embodiment of the present disclosure. [Figure 6C] This figure (600c) shows a sequence diagram representation of premature handover detection immediately after a successful handover, in which the user device (UE) context is deleted in cooperation with the Access and Mobility Management Function (AMF) according to an embodiment of the present disclosure. [Figure 6D]This figure shows a sequence diagram representation (600d) of detecting a handover that is too late during the execution of a handover, according to an embodiment of the present disclosure. [Figure 6E] This figure shows a sequence diagram representation (600e) of detecting a handover that is too late before the handover is performed, according to an embodiment of the present disclosure. [Figure 6F] This figure (600f) shows a sequence diagram representation of the detection of a handover to an incorrect cell after a successful handover to an incorrect cell, according to an embodiment of the present disclosure. [Figure 6G] This figure (600g) shows a sequence diagram representation of the detection of a handover to an incorrect cell after preparation for a successful handover to the incorrect handover destination cell, according to an embodiment of the present disclosure. [Figure 7] This figure shows an exemplary computer system (700) in which embodiments of the present invention may be used according to embodiments of the present disclosure. [Modes for carrying out the invention]

[0039] The above will become clearer from the following more detailed description of the present invention.

[0040] In the following description, various specific details are given for illustrative purposes to provide a complete understanding of the embodiments of the Disclosure. However, it will be apparent that embodiments of the Disclosure may be implemented without these specific details. Some of the features described hereafter may be used independently of each other or in any combination of other features. Individual features may not address all of the issues discussed above, or may address only some of the issues discussed above. Some of the issues discussed above may not be fully addressed by any of the features described herein.

[0041] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of this disclosure. Rather, the following description of exemplary embodiments provides a description that enables the implementation of exemplary embodiments for those skilled in the art. It should be understood that various modifications may be made to the function and configuration of the elements without departing from the spirit and scope of the invention as presented.

[0042] Certain details are given in the following description to allow for a full understanding of the embodiments. However, it will be understood by those skilled in the art that embodiments may be carried out without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as building blocks in the form of block diagrams to avoid obscuring the embodiments with unnecessary detail. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0043] It should also be noted that individual embodiments may be described as processes depicted as flowcharts, dataflow diagrams, structural diagrams, or block diagrams. While flowcharts may show operations as sequential processes, many operations may be executed in parallel or simultaneously. In addition, the order of operations may be rearranged. A process terminates when its operations are completed, but it may have additional steps not shown in the diagram. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to its calling function or the main function.

[0044] The words “exemplary” and / or “explanatory” are used herein to mean an example, specific example, or case. To avoid misunderstanding, the subject matter disclosed herein is not limited by such examples. In addition, all embodiments or designs described herein as “exemplary” and / or “explanatory” should not necessarily be considered preferable or advantageous to other embodiments or designs, nor are they intended to exclude equivalent exemplary structures and techniques known to those skilled 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—as with the open transitional term “comprising”—without excluding any additional or other elements.

[0045] Throughout this specification, any reference to “one embodiment,” “an embodiment,” “an instance,” or “one instance” means that a particular feature, structure, or characteristic described in relation to an embodiment is included in at least one embodiment of the present invention. Therefore, the phrases “in one embodiment” or “in an embodiment” appearing in various places throughout this specification do not necessarily all refer to the same embodiment. Furthermore, certain features, structures, or characteristics may be combined in any preferred manner in one or more embodiments.

[0046] The terms used herein are intended solely to describe specific embodiments and are not intended to limit the invention. Where used herein, the singular forms “a,” “an,” and “the” are intended to include the plural form unless the context explicitly indicates otherwise. Where used herein, the terms “comprises” and / or “comprising” specify the presence of the mentioned features, integers, steps, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof. Where used herein, the terms “and / or” include any and all combinations of one or more of the related enumerated items.

[0047] This disclosure provides systems and methods for optimizing the mobility robustness of telecommunications networks using open radio access networks (O-RAN). This disclosure provides systems and methods for realizing mobility robustness optimization (MRO) functions of self-organizing networks (SONs) in O-RAN architectures. This disclosure provides systems and methods for functional partitioning between different entities and associated data / control flow mechanisms in O-RAN architectures. This disclosure provides systems and methods for providing locality in the execution of partitioned MRO configurations. This disclosure provides systems and methods for assisting in the detection and correction of connectivity failures caused by RAT mobility, and for providing support for unnecessary inter-system handovers to other radio access technologies (RATs). This disclosure provides systems and methods for addressing scenarios such as premature handover, late handover, handover to the wrong cell, ping-pong handover, fast handover, and ultrafast handover. This disclosure provides a system and method for solving problems such as premature handover, late handover, handover to the wrong cell, ping-pong handover, fast handover, and ultrafast handover by optimizing HO parameters such as cell-specific offset, hysteresis, time to trigger, and Q offset.

[0048] This disclosure also provides systems and methods for collecting data to facilitate the execution of MRO functions in quasi-RT RIC entities. This disclosure provides systems and methods for optimizing HO parameters applicable to both idle-mode mobility scenarios and connected-mode mobility scenarios. This disclosure provides systems and methods for two mechanisms for realizing MRO functions in an O-RAN architecture, including the execution of MRO in quasi-RT RIC and non-RT RIC entities, and the execution of MRO in management entities and quasi-RT RIC entities.

[0049] Referring to Figure 2, the figure shows an exemplary network architecture (200) (also referred to as Network Architecture (200)) for optimizing mobility robustness in which the Service Management and Orchestration (SMO) System (208) or simply the SMO System (208) of the Disclosure may be implemented according to embodiments of the Disclosure. As shown, the exemplary network architecture (200) may include a non-real-time radio intelligent controller (non-RT RIC) (210) and a quasi-real-time radio intelligent controller (quasi-RT RIC) (214A) associated with the SMO System (208). Non-RT RICs (210) and quasi-RT RICs (214A) may be configured to facilitate the optimization of mobility robustness based on schemes received from users (228-1, 228-2, 228-3, ..., 228-N) (individually referred to as users (228), and collectively referred to as users (228)) associated with one or more mobile computing devices (224-1, 224-2, ..., 224-N) (individually referred to as computing devices (224), and collectively referred to as computing devices (224)). The SMO system (208) may be further coupled to mobile computing devices (not shown in Figure 1) via open radio access network radio units (O-RUs) (204). The SMO system (208) may be coupled to one or more computing devices (224) in a communicative manner.

[0050] Furthermore, the non-RT RIC (210) may include rApp (212), and the quasi-RT RIC (214A) may include xApp (214B). The SMO system (208) and the quasi-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). The quasi-RT RIC (214A) may also be coupled to the O-CU-CP (216) and O-CU-UP (218). The O-CU-CP (216) may be coupled to the O-CU-UP (218). Furthermore, O-CU-CP(216) may be coupled to a fifth-generation (5G) core (5GC)(220), and O-CU-UP(218) may be coupled to a user plane function (UPF)(222).

[0051] In some embodiments, the SMO system (208) may implement mobility robustness optimization (MRO) functions and a 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 distinct entities, a quasi-RT RIC (214A) and a non-RT RIC (210), and functional partitioning for MRO and related functional flows between the two entities may be implemented in the O-RAN architecture.

[0052] In an embodiment, the SMO system (208) may perform functional partitioning of the MRO and locality of execution of the partitioned MRO.

[0053] In an embodiment, the SMO system (208) may collect data to facilitate the execution of MRO functions in quasi-RT RIC (214A) and non-RT RIC (210) entities.

[0054] In an embodiment, the SMO system (208) may detect and correct connectivity failures and other unnecessary inter-system handovers to the RAT caused by mobility within the radio access technology (RAT).

[0055] In embodiments, the SMO system (208) may address scenarios such as premature handover, late handover, handover to the wrong cell, ping-pong handover, fast handover, and ultrafast handover, and are not limited to these.

[0056] In an embodiment, the SMO system (208) may correct the problem by optimizing handover parameters such as individual cell offset, hysteresis, time to trigger, and Q offset.

[0057] In an embodiment, the SMO system (208) may optimize handover parameters that are applicable to both idle mode mobility scenarios and connected mode mobility scenarios.

[0058] In embodiments, on-site data capture, storage, matching, processing, decision-making, and operational logic may, but are not limited to, be coded using a microservices architecture (MSA). Multiple microservices may be containerized and event-based to support portability.

[0059] In some embodiments, the network architecture (200) may be modular and flexible to accommodate all types of changes to the SMO system (208) and quasi-RT RIC (214A), where proximity processing may be achieved for mobility robustness optimization in the telecommunications network. The configuration details of the SMO system (208) and quasi-RT RIC (214A) may be modified on the fly.

[0060] In embodiments, the SMO system (208) may be remotely monitored, and the data, applications, and physical security of the SMO system (208) may be fully guaranteed. In embodiments, data may be carefully collected and stored in a cloud-based data lake to be processed for extracting usable insights. Thus, a form of predictive maintenance may be realized.

[0061] In exemplary embodiments, a communication network (not shown in Figure 1) may include, but not limited to, at least part of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or perform any combination thereof, one or more messages, packets, signals, waves, voltage or current levels, or any combination thereof. The network may include, but not limited to, one or more wireless networks, wired networks, the Internet, intranets, public networks, private networks, packet-switched networks, circuit-switched networks, ad-hoc networks, infrastructure networks, public switched telephone networks (PSTNs), cable networks, cellular networks, satellite networks, optical fiber networks, or any combination thereof.

[0062] In another exemplary embodiment, a server (not shown in Figure 1) may be included in the architecture (200). A quasi-RT RIC (214A) and SMO system (208) may be implemented in the server. The server may include, but is not limited to, a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors running code that functions as a server, one or more machines performing server-side functions described herein, at least some of the above, or any combination thereof.

[0063] In embodiments, one or more computing devices (224) and one or more mobile computing devices (not shown in Figure 1) may communicate with the SMO system (208) via a set of executable instructions present on any operating system, including but not limited to Android®, iOS®, Kai OS®, etc. In embodiments, one or more computing devices (224) and one or more mobile computing devices may include, but not limited to, any electrical, electronic, electromechanical, or any equipment, or one or more combinations of such devices, such as a mobile phone, smartphone, virtual reality (VR) device, augmented reality (AR) device, laptop, multipurpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device. A computing device may include, but not limited to, one or more built-in or external accessories, including, but not limited to, visual assistance devices such as a camera, audio assistance devices, microphones, keyboards, touchpads, touch-enabled screens, and electronic pens, input devices for receiving user input, receiving devices for receiving any audio or visual signals of any range of frequencies, and transmitting devices capable of transmitting any audio or visual signals of any range of frequencies. It will be understood that one or more first computing devices (224) and one or more mobile computing devices may not be limited to the devices mentioned, and that various other devices may be used. A smart computing device may be one of several suitable systems for storing data and other private / confidential information.

[0064] Figure 3 shows an exemplary representation (300) of a proposed service management and orchestration (SMO) system (208) for optimizing the mobility robustness of a telecommunications network using an open RAN (O-RAN), according to embodiments of the present disclosure. In embodiments, the SMO system (208) may include one or more processors (302). One or more processors (302) may be implemented as one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuits, and / or any device that processes data based on operational instructions. Among other capabilities, one or more processors (302) may be configured to fetch and execute computer-readable instructions stored in the memory (304) of the SMO system (208). The memory (304) may store one or more computer-readable instructions or routines in a non-temporary computer-readable storage medium, which may be fetched and executed to create or share data packets over network services. The memory (304) may include any non-temporary storage device, such as volatile memory like RAM, or non-volatile memory like EPROM or flash memory.

[0065] In embodiments, the SMO system (208) may include an interface (306). The interface (306) may also provide a communication path to 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).

[0066] A processing unit / engine (308) may be implemented as a combination of hardware and programming (e.g., programmable instructions) to perform 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 in a non-temporary machine-readable storage medium, and the hardware for the processing engine (308) may include processing resources (e.g., one or more processors) for executing such instructions. In this example, the machine-readable storage medium may store instructions that perform the processing engine (308) when executed by the processing resources. In such an example, the SMO system (208) may include a machine-readable storage medium for storing instructions and processing resources for executing instructions, or the machine-readable storage medium may be separate but accessible by the SMO system (208) and the processing resources. In other examples, the processing engine (308) may be implemented by electronic circuits. Furthermore, the SMO system (208) may include a machine learning (ML) module.

[0067] The processing engine (308) may include one or more engines selected from 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 further include, but is not limited to, edge-based microservice event processing.

[0068] Figure 4 shows an exemplary block diagram representation of the system architecture (400) according to an embodiment of the present disclosure.

[0069] The system architecture (400) is an O-RAN architecture. The rApp (212) may have an interface that allows external information to be supplied to the operator network. The quasi-RT RIC (406) may be a logical function that enables quasi-real-time control and optimization of RAN elements and resources through granular data collection and actions via the E2 interface, as shown in Figure 4. The quasi-RT RIC (406) may include artificial intelligence (AI) / machine learning (ML) workflows, including training, inference, and updating of models processed by the xApp (214B).

[0070] Furthermore, the non-RT RIC(404) may include logical functions within a service management and orchestration system (SMO)(402) that may drive content carried via the A1 interface, as shown in Figure 4. The non-RT RIC(404) may include a non-RT RIC framework and non-RT RIC applications such as rApp(212). Furthermore, the non-RT RIC framework may function within the SMO system(402) and logically terminate the A1 interface to the quasi-RT RIC(406). The non-RT RIC framework may expose a set of internal SMO services required for their runtime processing to rApp(212) via the R1 interface. The non-RT RIC framework may function within the non-RT RIC(404) and provide AI / ML workflows, including model training, inference, and updating, required for rApp(412).

[0071] Furthermore, the O1 interface from the O-RAN component may be terminated in the SMO system (402). The O-CU-CP (408) may be a logical node hosting Radio Resource Control (RRC) and the control plane portion of the Packet Data Convergence Protocol (PDCP) protocol. Furthermore, 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 (SDAP) protocol. The O-DU (412) may be a logical node hosting the Radio Link Control (RLC) / Media Access Control (MAC) / High Physical (PHY) layer based on the functional partitioning of the lower layers. The E2 node may be a logical node terminated at the E2 interface. Furthermore, O-RAN nodes that may be terminated on the E2 interface are for NR access in O-CU-CP(408), O-CU-UP(410), O-DU(412), or any combination thereof, and for Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) access such as O-eNB(418).

[0072] Non-RT RIC applications, such as rApp(212), may be modular applications that provide value-added services related to the operation of the RAN by utilizing functions exposed through the R1 interface of the non-RT RIC framework. Value-added services related to the operation of the RAN may include, but are not limited to, driving the A1 interface, recommending values ​​and actions that may be subsequently applied via the O1 / O2 interfaces, and generating "enrichment information (EI)" for the use of rApp(212). rApp(212) may function within non-RT RIC(404) to enable non-real-time control and optimization of RAN elements and resources.

[0073] Furthermore, rApp(212) may provide policy-based guidance to applications / features of the quasi-RT RIC(406). In addition, quasi-RT RIC applications such as xApp(214B) may run on the quasi-RT RIC(406). xApp(214B) may consist of one or more microservices, and at the time of onboarding, it may be determined what data it consumes and what data it provides. xApp(214B) may be independent of the quasi-RT RIC(406) and may be provided by any third party. The E2 interface may allow a direct association between xApp(214B) and RAN functions.

[0074] Furthermore, the O-Cloud (416) may be a cloud computing platform that includes a collection of physical infrastructure nodes. The nodes may meet the requirements of O-RAN to host the associated O-RAN functions of the quasi-RT RIC (405), O-CU-CP (408), O-CU-UP (410), and O-DU (412), supporting software components (such as operating systems, virtual machine monitors, and container runtimes), and appropriate management and orchestration functions. In addition, an O1 interface may exist between the SMO system (208) and the elements managed by O-RAN for operational and management purposes. The O1 interface may enable fault, configuration, accounting, performance, security (FCAPS) management, physical network function (PNF) software management, and file management.

[0075] Furthermore, an O2 interface may be located between the SMO system (208) and the O-cloud (416) to support O-RAN virtual network functionality. Additionally, an A1 interface between the non-RT RIC (404) and the quasi-RT RIC (406) may enable the non-RT RIC functionality to provide policy-based guidance, ML model management, and enrichment information to the quasi-RT RIC functionality, so that the RAN can optimize radio resource management (RRM) under specific conditions. Subsequently, an E2 interface may connect the quasi-RT RIC (406) to one or more O-CU-CPs (408), one or more O-CU-UPs (410), and one or more O-DUs (412). An R1 interface may be located between the rApp (212) and the non-RT RIC (404) framework.

[0076] Although not shown in Figure 4, the O-eNB(418) may not support the functions of the O-DU(412) and O-RU(414) with an open fronthaul interface between their functions. The management side includes the SMO system(402), which includes non-RT-RIC(404) functions. On the other hand, the O-cloud(416) is a cloud computing platform that includes related O-RAN functions (such as quasi-RT-RIC(406), O-CU-CP(408), O-CU-UP(410), and O-DU(412)), supporting software components (such as operating systems, virtual machine monitors, and container runtimes), and a collection of physical infrastructure nodes that meet the requirements of O-RAN to host appropriate management and orchestration functions. As shown in Figure 4, the O-RU(414) terminates the open fronthaul M-plane interface toward the O-DU(414) and the SMO system(402).

[0077] Figure 5A shows an exemplary block diagram representation of mobility robustness optimization (MRO) in O-RAN quasi-real-time radio intelligent controller (quasi-RT RIC) (512) and non-real-time radio intelligent controller (non-RT RIC) (508) entities according to embodiments of the present disclosure.

[0078] In some embodiments, Mobility Robustness Optimization (MRO) may be performed using a non-RT aspect of the MRO functionality enabled in a non-RT RIC (508). Mobility Robustness Optimization (MRO) may also be performed using a quasi-RT aspect of the MRO functionality enabled in a quasi-RT RIC (512). The 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 related to all possible cells at a particular geographic location. The FCAPS data in the Management Entity (504) may, in effect, be non-RT by default. The MDAS may perform big data analysis on the FCAPS data to generate one or more data patterns.

[0079] A cell may need to be configured with initial values ​​for both “idle mode” and “connected mode” handover parameters when it is started up. Some handover parameters may be broadcast, while some other handover parameters may be configured individually during connection establishment. Generally, handover parameters may be set to either default values ​​or values ​​configured by the operator. The MRO rApp(510) of a non-RT RIC(508) may select a data pattern using the data pattern generated by the MDAS and the geographical location of the cell. The selected data pattern may be closely applied to the deployed cell. The MRO rApp(510) of a 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 the internal interface of the O-RAN's SMO(502) module. The management entity (504) may configure these values ​​on the appropriate E2 node via a successfully established O1 interface during the Plug-n-Connect or Plug-n-Play phase of the cell deployment.

[0080] Furthermore, the MRO rApp(510) may generate handover optimization policies based on selected data patterns and communicate these handover optimization policies to the quasi-RT RIC(512) via the A1 interface. Here, the cell may be successfully started up and the E2 interface may be successfully established between the E2 node and the quasi-RT RIC(512). The MRO xApp(514) may begin collecting quasi-RT measurement data, PM data, and other data from the relevant E2 node. The MRO xApp(514) may request the RT data analysis function to generate relevant data analysis by sharing all the data collected from the E2 node. When the MRO xApp(514) receives the requested data analysis, it may use the policies received from the non-RT RIC(508) to derive new values ​​for the handover parameters. If it is conceivable that changes will be made to the handover parameters at the E2 node, the MRO xApp(514) may configure the updated values ​​for the handover parameters to the E2 node via the E2 interface.

[0081] The E2 node may capture all MRO-related counters and share MRO-related counters with the quasi-RT RIC(512). The E2 node may also share connection failure indications with the quasi-RT RIC(512) whenever it receives handover failure indications from neighboring cells and UEs.

[0082] Figure 5B shows an exemplary block diagram representation of mobility robustness optimization (MRO) in an O-RAN management entity (504) and a quasi-real-time radio intelligent controller (quasi-RT RIC) (512) entity according to an embodiment of the present disclosure.

[0083] In some embodiments, Mobility Robustness Optimization (MRO) may be performed using a non-RT aspect of the MRO functionality, which may be fully enabled in the management entity (504). Mobility Robustness Optimization (MRO) may also be performed using a quasi-RT aspect of the MRO functionality, which may be enabled in the quasi-RT RIC (512). Here, most of the MRO functionality is the same as that described in Figure 5A. However, the entire non-RT aspect of the MRO functionality may be enabled only within the management entity (504). The MRO functionality module within the management entity (504) may derive initial handover parameters and provide them to the E2 node via a successfully established O1 interface. The same MRO functionality module in the management entity (504) may derive a handover optimization policy and share it with the quasi-RT RIC (512) via an A1 interface. The use of MDAS by the MRO functionality is the same as that described in Figure 5A.

[0084] Figure 6A shows a sequence diagram representation (600a) of detecting an early handover during handover execution according to an embodiment of the present disclosure.

[0085] A wireless link failure may occur in the handover destination cell (606) immediately after the handover may be completed. A wireless link failure may also occur during the execution of the handover procedure when the UE (602) is allowed to attempt to re-establish the wireless link in the handover source cell (604). Figure 6A illustrates a scenario that may occur during the execution of the handover when the UE (602) may not be able to successfully access the handover destination cell (606).

[0086] In steps (612-1) and (612-2), SMO(208) may provide initial handover parameters to the source cell (604) and the destination cell (606) via the O1 interface during their deployment phases, after which the source cell (604) and the destination cell (606) begin operation. In step (612-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A)'s optimization function. When the source cell (604) decides to trigger a handover for its connected UE(602), it may prepare for the handover with the destination cell (606) and issue a handover command to the UE(602) via an RRC reconfiguration message. After receiving a handover command, UE(602) may attempt to access the handover target cell (606), but this may fail due to insufficient radio frequency (RF) conditions.

[0087] As a result, in step (612-4), UE(602) may re-select the cell (604) from which the handover was initiated and start the RRC re-establishment procedure. Since the cell (604) from which the handover was initiated has the context of UE(602), the RRC re-establishment procedure may be successful and UE(604) may remain connected. The cell (604) from which the handover was initiated may conclude that this is a premature handover scenario and may increment the premature handover (HO) counter.

[0088] In step (612-5), the cell from which the handover is being performed (604) may notify the MRO xApp (514) of the quasi-RT RIC (512) via the E2 interface of the occurrence of a premature handover by a premature handover detection indication. The premature handover detection indication may carry data about the cell from which the handover is being performed (604), the cell to which the handover is being performed (606), the most recent premature handover count, and other relevant details. Here, the algorithm of the MRO xApp (514), together with the quasi-RT data analysis function, may process the data and check whether any modifications to the HO parameters may be necessary. If modifications may be necessary, the MRO xApp (514) may instruct the cell from which the handover is being performed (604) and / or generally the other cells, via the E2 node and E2 interface, to update the HO parameters, in particular, which are not shown in the sequence.

[0089] Figure 6B shows a sequence diagram representation (600b) of the detection of an early handover immediately following the execution of a successful handover, according to an embodiment of the present disclosure.

[0090] In steps (614-1) and (614-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during the deployment phase, after which the source cell (604) and the destination cell (606) begin operation. In step (614-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for optimization functionality.

[0091] Here, UE(602) may experience a radio link failure with the handover target cell (606) immediately after a successful HO execution due to insufficient or inconsistent strong RF conditions. Therefore, UE(602) may re-select the previous handover source cell (604) and trigger the RRC re-establishment procedure with the cause set to HO failure.

[0092] In step (614-4), the cell from which the handover originated (604) may have deleted the UE context upon receiving the Xn: UE context release message from the cell to which the handover was received (606) as part of the successful execution of the HO.

[0093] In steps (614-5) and (614-6), upon receiving the RRC re-establishment request message, the previous handover source cell (604) may send an Xn:fault indication message to the faulty cell, which is the handover destination cell (606) indicated by UE (602) in the RRC re-establishment request message. The handover destination cell (606) may process the received fault indication, analyze its status, and detect any premature HO scenarios. In step (614-7), the handover destination cell (606) may send an Xn:handover report message to the handover source cell (604) such that the handover report type is set to "premature HO". Upon receiving the handover report message, the handover source cell (604) may increment the premature HO counter. In step (614-8), the cell from which the handover originated (604) may inform the MRO xApp (514) of the quasi-RT RIC (214A) of the premature HO scenario via the E2 interface. The "premature handover" detection indication and further processes may be the same as those described in the previous scenario.

[0094] Figure 6C shows a sequence diagram representation (600c) of premature handover detection immediately following a successful handover, in which the user device (UE) context may be deleted in cooperation with the Access and Mobility Management Function (AMF) according to an embodiment of the present disclosure.

[0095] In steps (616-1) and (616-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during their deployment phases, and the source cell (604) and the destination cell (606) begin operation. In step (616-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A) optimization function.

[0096] This scenario is the same as the one shown in Figure 6B, except that the timer TXnRELOC overall may expire before the handover cell (606) sends the Xn: UE context release message as part of the execution of HO. Upon timer expiration, the handover cell (604) may request AMF (610) to release the context of UE (602) by sending the NG: UE context release request message. AMF (610) may then acknowledge the NG: UE context release request and send the NG: UE context release command message to the handover cell (604). The handover cell (604) may then delete the UE context and confirm this to AMF (610) by sending the NG: UE context release complete message. These sequences are not shown in Figure 6C.

[0097] In steps (616-5) and (616-6), upon receiving the RRC re-establishment request message, the previous handover source cell (604) may send an Xn: fault indication message to the fault cell (handover destination cell (606)) indicated by UE (602) in the RRC re-establishment request message. The handover destination cell (606) may process the received fault indication, analyze its status, and detect that it is an early HO scenario.

[0098] In step (616-7), the receiving cell (606) may send an Xn:Handover Report message to the originating cell (604) such that the Handover Report Type is set to "Early HO". Upon receiving the Handover Report message, the originating cell (604) may increment the Early HO counter. In step (616-8), the originating cell (604) may notify the MRO xApp (514) of the quasi-RT RIC (214A) of this occurrence via the E2 interface using an Early Handover Detection Indication. Further processes may be the same as those described in the previous scenario.

[0099] Figure 6D shows a sequence diagram representation (600d) of detecting a handover that is too late during the execution of a handover, according to an embodiment of the present disclosure.

[0100] In steps (618-1) and (618-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during the deployment phase, after which the source cell (604) and the destination cell (606) begin operation. In step (618-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A) optimization function.

[0101] In step (618-4), a radio link failure may occur in the cell from which the handover is being performed (604) before or during the handover procedure. In that case, UE (602) may attempt to re-establish its radio link in another cell or the cell to which the handover is being performed (606).

[0102] Here, UE(602) may experience a radio link failure with the handover source cell (604) even before receiving the HO command. In step (618-5), UE(602) may initiate the RRC re-establishment procedure with the handover destination cell (606) such that the cause is set to a different failure. The handover destination cell (606) may have a UE context because the HO preparation may have been successful. In step (618-6), upon receiving an RRC re-establishment request message from the same UE(602), the handover destination cell (606) may send an Xn: failure indication message to the handover source cell (604) indicating a delayed HO scenario. The handover destination cell (606) may also send an Xn: UE context release message to the handover source cell (604).

[0103] The handover source cell (604) may process the received fault indication, analyze its status, and detect a delayed HO scenario. In steps (618-7) and (618-8), the handover source cell (604) may increment a delayed HO counter and notify the MRO xApp (514) of the quasi-RT RIC (214A) of this occurrence via a delayed handover detection indication through the E2 interface. Furthermore, the process in the quasi-RT RIC (214A) may be the same as that described in the previous scenario.

[0104] Figure 6E shows a sequence diagram representation (600e) of detecting a handover that is too late before the handover is performed, according to an embodiment of the present disclosure.

[0105] In steps (620-1) and (620-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during the deployment phase, after which the source cell (604) and the destination cell (606) begin operation. In step (620-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A) optimization function.

[0106] In step (620-4), UE (602) may experience a radio link failure with the handover source cell (604) even before any HO preparation has begun, and may initiate the RRC re-establishment procedure with the handover destination cell (606) with the cause set to a different failure. The handover destination cell (606) may not have a UE context because HO preparation may not have begun yet. In steps (620-5) and (620-6), upon receiving an RRC re-establishment request message from UE (602), the handover destination cell (606) may reject the re-establishment request and send an Xn: failure indication message to the handover source cell (604) indicating that the HO scenario is too late.

[0107] The handover originating cell (604) may process the received fault indication, analyze its status, and detect a delayed HO scenario. The handover originating cell (604) may increment a delayed HO counter and notify the MRO xApp (514) of the quasi-RT RIC (214A) of its occurrence via the delayed HO detection indication through the E2 interface. Further processes in the quasi-RT RIC (214A) may be the same as those described in the previous scenario.

[0108] Figure 6F shows a sequence diagram representation (600f) of the detection of a handover to an incorrect cell after a successful handover to the incorrect cell, according to an embodiment of the present disclosure.

[0109] In steps (622-1) and (622-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during the deployment phase, after which the source cell (604) and the destination cell (606) begin operation. In step (622-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A) optimization function.

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

[0111] In step (622-6), UE (602) may experience a radio link failure with the wrong handover cell (606A) immediately after a successful HO due to insufficient or inconsistent strong RF conditions. Therefore, UE (602) may re-select the true handover cell (606B) and trigger the RRC re-establishment procedure with the cause set to another failure. Upon receiving the RRC re-establishment request message, the true handover cell (606B) may send an Xn:fault indication message to the faulty cell (wrong handover cell (606A)) indicated by UE (602) in the RRC re-establishment request message. The wrong handover cell (606A) may process the received fault indication, analyze its state, and detect the HO scenario to the wrong cell.

[0112] In step (622-7), the incorrectly handed-over destination cell (606A) may send an Xn:Handover Report message to the handover source cell (604) such that the handover report type is set to "HO to Incorrect Cell". Upon receiving the handover report message, the handover source cell (604) may increment the HO to Incorrect Cell counter. In step (622-8), the handover source cell (604) may notify the MRO xApp (514) of the quasi-RT RIC (214A) of this occurrence via the E2 interface through the handover detection indication to the incorrect cell. Further processes may be the same as those described in the previous scenario.

[0113] Figure 6G shows a sequence diagram representation (600g) of the detection of a handover to the wrong cell after preparation for a successful handover to the wrong cell, according to an embodiment of the present disclosure.

[0114] In steps (624-1) and (624-2), SMO(208) may provide initial handover parameters to both the source cell (604) and the destination cell (606) via the O1 interface during their deployment phases, after which the source cell (604) and the destination cell (606) begin operation. In step (624-3), SMO(208) may provide handover optimization policy information to the quasi-RT RIC(214A) via the A1 interface for the quasi-RT RIC(214A) optimization function.

[0115] Here, UE(602) may experience a radio link failure with the wrong handover cell (606A) immediately after a successful HO preparation due to insufficient or inconsistent strong RF conditions. Therefore, UE(602) may re-select the true handover cell (606B) and trigger the RRC re-establishment procedure with the cause set to another failure. In steps (624-4) and (624-5), upon receiving the RRC re-establishment request message, the true handover cell may send an Xn:fault indication message to the faulty cell (the handover source cell (604)) indicated by UE(602) in the RRC re-establishment request message. The handover source cell (604) may process the received fault indication, analyze its status, and detect the HO scenario to the wrong cell.

[0116] In step (624-7), the cell originating from the handover (604) may send an Xn: Handover Cancel message to the incorrect handover destination cell (606A) to cancel the handover preparation. The cell originating from the handover (604) may also increment the HO counter for the incorrect cell. In step (624-8), the cell originating from the handover (604) may notify the MRO xApp (514) of the quasi-RT RIC (214A) of this occurrence via the E2 interface through a handover detection indication for the incorrect cell. Further processes may be the same as those described in the previous scenario.

[0117] Ping-Pong Handover Scenario: In a ping-pong handover scenario, wireless link failure may not occur, but after a successful handover, the UE(602) may remain in the handover cell for a very short period. The UE(602) may continue to hop frequently between the two cells. Typically, in a ping-pong handover scenario, ping-pong occurs between the same two adjacent cells of the same or different RATs. The MRO xApp(514) may detect the ping-pong handover scenario and correct it by optimizing the HO parameters. Alternatively, the MRO xApp(514) may propose handing over to a higher-layer cell of the same or different RATs, or, if feasible, propose having dual connectivity between the two cells to correct the ping-pong handover scenario.

[0118] Fast or ultrafast handover scenarios: Fast or ultrafast handover scenarios can be similar to ping-pong handover scenarios. In fast or ultrafast handover scenarios, the UE(602) may hop to different cells and remain in each cell for a very short period. The duration of stay in each cell may depend on the speed of the UE's mobility. The MRO xApp(514) may need to detect fast or ultrafast handover scenarios and distinguish between scenarios that may be unavoidable and those that may be correctable.

[0119] For example, ultrafast handover scenarios may occur along railway lines, aircraft routes using ground-to-air communications, and protected highways. Such ultrafast handover scenarios may be unavoidable. In these cases, no correction may be required. Scenarios that may require correction may be detected by MRO xApp(514). In that case, MRO xApp(514) may propose a handover to a higher-layer cell, such as an NTN cell.

[0120] Figure 7 shows an exemplary computer system (700) in which embodiments of the present invention may be used according to embodiments of the present disclosure. As shown in Figure 7, the computer system (700) may include an external storage device (710), a bus (720), main memory (730), read-only memory (740), a mass storage device (750), a communication port (760), and a processor (770). Those skilled in the art will understand that the computer system may include two or more processors and communication ports. Examples of processors (770) include, but are not limited to, Intel® Itanium® or Itanium 2 processors, or AMD® Opteron® or Athlon MP® processors, Motorola® lineage processors, FortiSOC® system-on-chip processors, or other future processors.

[0121] The processor (770) may include various modules related to embodiments of the present invention. The communication port (760) can be any of the following: an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or any other existing or future port. The communication port (760) may be selected depending on the network, such as a local area network (LAN), a wide area network (WAN), or any network to which the computer system is connected. The memory (730) can be random access memory (RAM) or any other dynamic storage device widely known in the art. The read-only memory (740) can be any static storage device, for example, a programmable read-only memory (PROM) chip for storing static information, such as startup or BIOS instructions for the processor 770, but not limited to these.

[0122] Mass storage (750) may be any current or future mass storage solution that can be used to store information and / or instructions. Exemplary mass storage solutions include, but are not limited to, parallel advanced technology attachment (PATA) or serial advanced technology attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), e.g., those available from Seagate (e.g., the Seagate Barracuda 782 family) or Hitachi (e.g., the Hitachi Deskstar 13K800), one or more optical disks, and redundant array of independent disks (RAID) storage, e.g., arrays of disks available from various vendors (e.g., SATA arrays).

[0123] The bus (720) connects the processor (770) to other memory, storage, and communication blocks so that it can communicate with them. The bus (720) can be, for example, a Peripheral Component Interconnect (PCI) / PCI Expansion (PCI-X) bus for connecting expansion cards, drives, and other subsystems, a Small Computer System Interface (SCSI), USB, etc., as well as other buses such as a Front Side Bus (FSB) for connecting the processor (770) to a software system.

[0124] Optionally, operator and management interfaces, such as displays, keyboards, and cursor control devices, may also be coupled to the bus (720) to support direct operator interaction with the computer system. Other operator and management interfaces may be provided through a network connection connected via a communication port (760). The external storage device (710) can be any type of external hard disk, floppy drive, IOMEGA® Zip drive, compact disc read-only memory (CD-ROM), compact disc rewritable (CD-RW), or digital video disc read-only memory (DVD-ROM). The components described above are intended only to illustrate various possibilities. The exemplary computer system described above should not limit the scope of this disclosure in any way.

[0125] While this specification places considerable emphasis on preferred embodiments, it will be understood that many embodiments can be made and that many modifications can be made to the preferred embodiments without departing from the principles of the present invention. These and other modifications to the preferred embodiments of the present invention will be apparent to those skilled in the art from this disclosure, and it will be clearly understood that the above-mentioned explanatory matters are implemented merely to illustrate the invention, and not as limitations.

[0126] Benefits of this disclosure This disclosure provides a system and method for optimizing the mobility robustness of telecommunications networks using open radio access networks (O-RAN).

[0127] This disclosure provides a system and method for realizing mobility robustness optimization (MRO) functionality for self-organizing networks (SONs) in an O-RAN architecture.

[0128] This disclosure provides a system and method for functional partitioning between different entities in an O-RAN architecture and for associated data / control flow mechanisms.

[0129] This disclosure provides a system and method for providing locality in the execution of a segmented MRO configuration.

[0130] This disclosure provides a system and method for assisting in the detection and correction of connectivity failures caused by mobility within a RAT, and for providing support for unnecessary inter-system handovers to other radio access technologies (RATs).

[0131] This disclosure provides systems and methods for addressing scenarios such as premature handover, late handover, handover to the wrong cell, ping-pong handover, fast handover, and ultrafast handover.

[0132] This disclosure provides a system and method for solving problems such as premature handover, late handover, handover to the wrong cell, ping-pong handover, fast handover, and ultrafast handover by optimizing HO parameters such as cell-specific offset, hysteresis, time to trigger, and Q offset.

[0133] This disclosure provides a system and method for collecting data to facilitate the performance of MRO functions in quasi-RT and non-RT RIC entities.

[0134] This disclosure provides a system and method for optimizing HO parameters applicable to both idle mode mobility scenarios and connected mode mobility scenarios.

[0135] This disclosure provides systems and methods for two mechanisms for realizing MRO functions in an O-RAN architecture, including the implementation of MRO in quasi-RT RIC and non-RT RIC entities, and the implementation of MRO in management entities and quasi-RT RIC entities.

[0136] Reservation of rights Parts of the disclosures in this patent specification include materials subject to intellectual property rights, including but not limited to copyrights, designs, trademarks, IC layout designs, and / or trade dress, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred to as the Owner). The Owner has no objection to any reproduction of the patent documents or patent disclosures by any person as they appear in the patent files or records of the Patent and Trademark Office, but otherwise reserves all rights. All rights relating to such intellectual property are fully reserved by the Owner. This disclosure may relate to the O-RAN specification given in 3GPP® TR21.905[1]. [Explanation of symbols]

[0137] 106 NMS 116 gNB-CU-1 118 gNB-DU 120 gNB-DU 122 gNB-DU 124 gNB-CU-2 126 gNB-DU 128 gNB-DU 130 gNB-CU-n 132 gNB-DU 200 Network Architectures 204 Open Wireless Access Network Wireless Unit (O-RU) 206. Open Wireless Access Network Distributed Unit (O-DU) 208 Service Management and Orchestration (SMO) Systems 210 Non-Real-Time Wireless Intelligent Controllers (Non-RT RICs) 212 rApp 214A Near Real-Time Wireless Intelligent Controller (Near RT RIC) 214B xApp 216 Open Wireless Access Network Central Unit Control Plane (O-CU-CP) 218 Open Wireless Access Network Central Unit User Plane (O-CU-UP) 220 5th Generation (5G) Core (5GC) 222 User Plane Function (UPF) 224, 224-1, 224-2, ..., 224-N computing devices 228, 228-1, 228-2, 228-3, ..., 228-N users 302 Processors 304 memory 306 Interface 308 Processing Units / Engines 310 Databases 312 Data Acquisition Engines 314 Signal Acquisition Engine 316 Other Engines 400 System Architectures 402 Service Management and Orchestration System (SMO) 404 Non-RT RIC 406 Semi-RT RIC 408 O-CU-CP 410 O-CU-UP 412 O-DU 416 O-Cloud 418 O-eNB 502 SMO 504 Administrative Entity 508 Non-Real-Time Wireless Intelligent Controller (Non-RT RIC) 510 MRO rApp 512 O-RAN Near Real-Time Wireless Intelligent Controller (Near RT RIC) 514 MRO xApp 602 UE 604 Handover to original cell 606 Handover destination cell 606A Incorrect handover destination cell 606B The actual handover destination cell 610 AMF 700 Computer Systems 710 External storage devices 720 Bus 730 Main Memory 740 Read-only memory 750 High-Capacity Storage Devices 760 communication ports 770 processor

Claims

1. A system for implementing mobility robustness optimization (MRO) functions for self-organizing networks (SONs) for open radio access network (O-RAN) cells, Includes a non-real-time wireless access network intelligent controller (non-RT RIC), wherein the non-RT RIC is Processor and A memory coupled to the aforementioned processor, which, when executed, is used by the aforementioned processor. Receiving one or more data patterns of cells from the Management Data Analysis Service (MDAS), Based on the received one or more data patterns, select the data pattern of the cell. Based on the selected data pattern, generate a one-territory handover optimization policy for the cell. Communicating one or more handover optimization policies of the cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) (512) associated with the system, and Receiving optimized values ​​of the cell's handover parameters from the quasi-RT RIC(512), wherein the optimized values ​​of the handover parameters are generated by the quasi-RT RIC(512) based on one or more handover optimization policies. The memory contains instructions that the processor can execute, which cause the processor to perform the action. A system that includes this.

2. The system according to claim 1, wherein the MDAS is configured to track and monitor phase modulation (PM) data, events, and error logs received as fault, configuration, accounting, performance, and security (FCAPS) data related to the cells deployed at geographical locations.

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

4. The system according to claim 1, wherein the initial values ​​of the handover parameters are provided by the management entity during the deployment phase via the O1 interface of the cell.

5. The system according to claim 4, wherein the initial values ​​of the handover parameters are provided by the management entity during the Plug-n-Connect or Plug-n-Play phase of the cell's deployment.

6. The system according to claim 1, wherein the cell is pre-configured using the initial values ​​of the handover parameters for idle mode and connection mode.

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

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

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

10. The aforementioned quasi-RT RIC is From the E2 node, we collect quasi-RT measurement data, phase modulation (PM) data, and other data. The collected data is shared with the RT data analysis function. Based on the collected data, the data analysis from the RT data analysis function is received. Based on the analysis of the received data, using the one or more handover optimization policies received from the non-RT RIC, Based on the aforementioned one or more handover optimization policies, the optimized values ​​of the handover parameters are derived. The system according to claim 1, configured to transmit the optimized handover parameters to the E2 node.

11. A method for implementing mobility robustness optimization (MRO) functionality for a self-organizing network (SON) for an open radio access network (O-RAN) cell, The processor receives one or more data patterns of cells from the Management Data Analysis Service (MDAS), The processor selects the data pattern of the cell based on the received one or more data patterns. The processor generates one or more handover optimization policies for the cells based on the selected data patterns. The processor transmits one or more handover optimization policies of the cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) (512) associated with the system, A method comprising the steps of: receiving optimized values ​​of the cell's handover parameters from the quasi-RT RIC(512) by the processor, wherein the optimized values ​​of the handover parameters are generated by the quasi-RT RIC(512) based on one or more handover optimization policies.

12. The method according to claim 11, wherein the MDAS is configured to track and monitor phase modulation (PM) data, events, and error logs received as fault, configuration, accounting, performance, and security (FCAPS) data related to the cells deployed at geographical locations.

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

14. The method according to claim 11, wherein the initial values ​​of the handover parameters are provided by the management entity during the deployment phase via the O1 interface of the cell.

15. The method according to claim 11, wherein the initial values ​​of the handover parameters are provided by the management entity during the deployment phase via the O1 interface, during the Plug-n-Connect or Plug-n-Play phase of the cell's deployment.

16. The method according to claim 11, wherein the cell is preconfigured using the initial values ​​of the handover parameters for idle mode and connection mode.

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

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

19. The method according to claim 11, wherein the handover parameters of the cell include a cell-specific offset value, a hysteresis value, a time to trigger, and a Q offset value.

20. The aforementioned quasi-RT RIC is From the E2 node, we collect quasi-RT measurement data, phase modulation (PM) data, and other data. The collected data is shared with the RT data analysis function. Based on the collected data, the data analysis from the RT data analysis function is received. Based on the analysis of the received data, using the one or more handover optimization policies received from the non-RT RIC, Based on the aforementioned one or more handover optimization policies, the optimized values ​​of the handover parameters are derived. The method according to claim 11, wherein the optimized handover parameters are configured to be transmitted to the E2 node.

Images