Systems and methods for optimizing mobility robustness of telecommunications networks

Abstract

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

Description

Technology Field

[0001] The embodiments of the present disclosure generally relate to wireless telecommunications networks. More particularly, the present disclosure relates to systems and methods for optimizing the mobility robustness of a telecommunications network using an Open Radio Access Network (O-RAN). Background Technology

[0002] The following description of the relevant technology is intended to provide background information related to the field of the present disclosure. This section may include specific aspects of the technical field that may be relevant to the various features of the present disclosure. However, it should be understood that this section is used merely to enhance the reader's understanding of the present disclosure, and not as an acknowledgment of the prior art.

[0003] Generally, as cellular networks evolve from the 4th and 5th generations to the 6th generation (6G) alongside other radio access technologies such as Wi-Fi, mobile subscriptions are also increasing exponentially. Therefore, mobile operators may be compelled to deploy ultra-high-density heterogeneous networks (HetNets) to meet subscriber demands. HetNets can typically be built using multi-portfolio and multi-vendor-based solutions. One of the major challenges operators face during the greenfield or brownfield deployment of HetNets may be the requirement for high-quality installations. Another challenge lies in the continuous monitoring of the performance and health of deployed networks. Dynamic adaptation to changing environments is also an issue, as are active adjustments and optimizations.

[0004] The aforementioned challenges can require very high levels of manual work and latency due to regular / frequent site visits, and can incur additional operational costs. To overcome these drawbacks and drastically reduce operational costs (OPEX), Self-Organizing Networks (SONs) can be used. An SON can be a self-organizing network or a self-optimizing network. An SON is an automation technology that enables the network to set up itself and self-manages resources and configurations to achieve optimal performance. SONs ​​can operate under three categories. The first category is self-configuration. Self-configuration can assist in seamless integration into the network through the automatic configuration of key parameters. Self-configuration is most critical during initial network deployments. It includes various capabilities such as Plug-and-Play (PnP) functions, Automatic Neighbor Relationship (ANR) functions, and Physical Layer Cell Identity (PCI) selection and conflict resolution functions.

[0005] The second category is self-optimization. Self-optimization helps enhance network performance through near-real-time optimization of radio and network configurations. Self-optimization is important throughout the entire lifecycle of a network. Self-optimization includes various capabilities such as Mobility Load Balancing [MLB], Mobility Robustness Optimization [MRO], RACH Optimization, Energy Saving [ES], Radio Link Fault Reporting, Coverage and Capacity Optimization [CCO], [DL Power Control, RET], Forward Handover, Frequent Handover Mitigation [FHM], and Interference Mitigation [Cell-to-Cell, In-Cell, In-RAT, Inter-RAT].

[0006] The third category is self-healing. Self-healing allows adjacent cells to maintain network quality in the event of a cell / sector failure, providing resilience (reliability) in the face of unexpected power outages. Self-healing includes various capabilities such as cell outage detection [dead / anomaly / sleeping cells / sectors / beams], cell outage recovery, cell outage compensation, and cell outage compensation recovery.

[0007] Minimization of Drive Test (MDT) functions are designed to operate independently of SONs, but these functions are reused whenever possible. The aforementioned SON functions can be handled individually or in groups by SON algorithms. SON algorithms can perform functions such as monitoring network(s) by analyzing management data and collecting management data, including MDAS data, to determine whether there are issues in the network(s) that need to be resolved. SON algorithms can also determine SON actions to resolve issues and execute SON actions for resolution. Furthermore, SON algorithms can evaluate whether issues have been resolved by analyzing management data.

[0008] Based on the location of the SON algorithm, SON can be classified into four different solutions that may enable the implementation of various SON use cases. The solution can be selected depending on the requirements of the SON use cases. Centralized SON (C-SON) may include functions where the SON algorithm executes in a management system. Cross-domain centralized SON (CD C-SON) may include functions where the SON algorithm can execute at the cross-domain (CD) layer. Furthermore, domain centralized SON (DC-SON) may be a SON algorithm that can execute at the domain layer. Moreover, distributed SON (D-SON) may be a SON algorithm in NFs.

[0009] Subsequently, a hybrid SON (H-SON) can be a SON algorithm that can be executed at two or more levels, such as an NF layer, a domain layer, or a cross-domain (CD) layer. Since SON algorithms depend on implementation examples, different vendors may adopt different approaches for their SON solutions. Some vendors may adopt a C-SON approach, some may adopt a D-SON approach, and others may adopt H-SON approach-based solutions. Operators may inevitably use multi-vendor solutions when deploying HetNets.

[0010] FIG. 1 illustrates an exemplary block diagram representation (100) of a 5G HetNet deployment scenario. In a 5G HetNet deployment scenario, the 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 sets of vendors. The operator may also use management entities such as radio access network (RAN) nodes, such as next-generation node B centralized units (gNB-CU) from different sets of vendors and next-generation node B distributed units (gNB-DU) from different sets of vendors. The operator may encounter issues in the deployed HetNet of FIG. 1. One of the issues is that the D-SONs of gNB-CU-1 (116) and gNB-CU-2 (124), even though they communicate with each other via an open Xn interface, may not cooperate well because both come from different vendors.

[0011] Another issue is that the D-SON of gNB-CU-2 (124) and the hybrid SON (D-SON + DC-SON) of gNB-CU-n (130), even though they communicate with each other through an open Xn interface, may not cooperate well because both come from different vendors. The main issue is that C-SON can be implemented either as a place with management entities [like EMS / NMS] or as a standalone entity. Integrating C-SON as a standalone entity with RAN nodes is very difficult because the interface is left to implementation. Furthermore, the CD C-SON in the NMS (106) can affect the performance of DC C-SON and D-SON functions operating in a multi-vendor environment.

[0012] Another issue lies in the partial integration of third-party SON solutions in HetNet, which causes a degradation of overall key performance indicators (KPIs). Furthermore, L3-RRM coordination across neighboring NB-CUs (116, 124, 130) may be insufficient regardless of whether it is the same or multi-vendor scenario, which will affect overall KPI performance. L3-RRM and L2-RRM coordination across multi-vendor gNB-CUs (116, 124, 130) and gNB-DUs (118, 120, 122, 126, 128, 132) may affect dynamic resource sharing and allocation.

[0013] Proprietary implementations such as SON and Radio Resource Management (RRM) have a significant impact on overall performance while multiple vendors collaborate across Xn interfaces. Each algorithm behaves differently and has its own limitations. Even if vendors are prepared to integrate with third-party solutions [SON and / or RRM], they may not be able to definitively quantify or verify output performance, primarily due to the vendors' solutions. This situation always ends in conflict between agreed-upon vendors. One possible solution to address these issues or limitations may be to create as many interfaces and open interfaces as possible between Radio Access Network (RAN) nodes interacting with SON solutions. The Open Radio Access Network (O-RAN) Alliance can be a worldwide community of mobile network operators, vendors, and research and educational institutions operating in the RAN industry.

[0014] The mission of the O-RAN Alliance may be to reshape the RAN industry into more intelligent, open, virtualized, and fully interoperable mobile networks. New O-RAN standards can enable a more competitive and vibrant ecosystem of RAN providers with faster innovation to improve user experience. O-RAN-based mobile networks will simultaneously improve the efficiency of operations by mobile operators as well as RAN deployments. However, conventional systems and methods may not provide mechanisms to realize mobility robustness optimization functions in O-RAN architectures.

[0015] Therefore, there is a need for mobility and robustness optimization functions in O-RAN architectures, along with mechanisms for functional separation between different entities within O-RAN architectures and associated data / control flow mechanisms. Consequently, there is a demand in this technical field for systems and methods capable of overcoming the shortcomings of existing conventional technologies. Objects of the present disclosure

[0016] Some of the objectives of the present disclosure, which are satisfied by at least one embodiment of the present invention, are listed below.

[0017] The object of the present disclosure is to provide efficient and reliable systems and methods for optimizing the mobility robustness of telecommunications networks using an Open Radio Access Network (O-RAN).

[0018] The object of the present disclosure is to provide systems and methods for realizing Mobility Robustness Optimization (MRO) functions of Self-Organizing Networks (SONs) in O-RAN architectures.

[0019] The object of the present disclosure is to provide systems and methods for functional separation between different entities in O-RAN architectures and associated data / control flow mechanisms.

[0020] The object of the present disclosure is to provide systems and methods for providing locality of execution of separated MRO aspects.

[0021] The object of the present disclosure is to provide systems and methods for detecting and correcting connection failures caused by radio-intra-RAT mobility and for providing support for unnecessary system-to-system handovers to other radio-intra-RATs.

[0022] The object of the present disclosure is to provide systems and methods for handling scenarios such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc.

[0023] The object of the present disclosure is to provide systems and methods for solving issues such as too early handover, too late handover, handover to the wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc. by optimizing HO parameters such as individual cell offset, hysteresis, trigger time, Q offset, etc.

[0024] The object of the present disclosure is to provide systems and methods for collecting data to facilitate the execution of MRO functions in quasi-RT RIC entities.

[0025] The object of the present disclosure is to provide systems and methods for optimizing HO parameters applicable to both idle and connected mode mobility scenarios.

[0026] The object of the present disclosure is to provide systems and methods of two mechanisms for realizing MRO functions in O-RAN architectures, such as MRO implementation in quasi-RT RICs and non-RT RIC entities, and MRO implementation in management entities and quasi-RT RICs.

[0027] This section is provided to introduce, in a simplified form, specific objects and aspects of the invention that are further described in the following detailed description. This summary is not intended to identify the principal features or scope of the claimed subject matter.

[0028] In one aspect, the present disclosure provides a system for realizing Mobility Robust Optimization (MRO) functions of a Self-Organizing Network (SON) for a cell 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 for a cell from a Management Data Analysis Service (MDAS). The MDAS is configured to track and monitor Phase Modulation (PM) data, events, and error logs received as Fault, Configuration, Accounting, Performance, Security (FCAPS) data associated with a cell deployed at a geographic location. The MDAS is configured to perform big data analyses on the FCAPS data to generate one or more data patterns.

[0029] In addition, 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 handover parameters during the deployment phase via the O1 interface from the management entity. The cell receives initial values ​​for handover parameters during the deployment phase via the O1 interface from the management entity during the plug-and-connect phase or plug-and-play phase of the cell's deployment. The selected data pattern corresponds to the geographic location of one or more cells. The cell is pre-configured with initial values ​​for handover parameters in idle mode and connection mode. One or more handover optimization policies are transmitted from the non-RT RIC to the quasi-RT RIC (512) via the A1 interface. Handover parameters for a cell include the cell's individual offset value, hysteresis value, time to trigger, and Q offset value.

[0030] The quasi-RT RIC is configured to collect quasi-RT measurement data, phase modulation (PM) data, and other data from E2 nodes. 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 analyses 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 analyses. The quasi-RT RIC is further configured to derive optimized values ​​for handover parameters based on one or more handover optimization policies. Furthermore, the quasi-RT RIC is configured to transmit the optimized handover parameters to the quasi-RT RIC.

[0031] Furthermore, the system's non-RT RIC generates one or more handover optimization policies for the cell based on selected data patterns. In addition, the system's non-RT RIC transmits the cell's one or more handover optimization policies to the quasi-real-time radio access network intelligent controller (quasi-RT RIC) associated with the system. Furthermore, the system's non-RT RIC receives optimization values ​​for the cell's handover parameters from the quasi-RT RIC, where the optimization values ​​for the handover parameters are generated by the quasi-RT RIC based on one or more handover optimization policies.

[0032] In one aspect, the present disclosure provides a method for realizing Mobility Robustness Optimization (MRO) of a Self-Organizing Network (SON) for a cell in an Open Radio Access Network (O-RAN). The method comprises receiving one or more data patterns for a cell from Management Data Analytics Services (MDAS). The MDAS is configured to track and monitor PM data, events, and error logs received as Failure, Configuration, Account, Performance, Security (FCAPS) data associated with a cell deployed at a geographic location. The MDAS is configured to perform big data analytics on the FCAPS data to generate one or more data patterns.

[0033] In addition, the method includes selecting a data pattern for a cell based on one or more received data patterns. The cell receives initial values ​​for handover parameters during deployment time via the O1 interface from the management entity. The cell receives initial values ​​for handover parameters during deployment time via the O1 interface from the management entity during the plug-and-connect or plug-and-play phases of the cell's deployment. The selected data pattern corresponds to the geographic 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 transmitted from the non-RT RIC to the quasi-RT RIC (512) via the A1 interface. Handover parameters for the cell include the cell's individual offset value, hysteresis value, time to trigger, and Q offset value.

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

[0035] Furthermore, the method includes generating one or more handover optimization policies for a cell based on selected data patterns. Furthermore, the method includes transmitting one or more handover optimization policies for the cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) associated with the system. Furthermore, the method includes receiving optimization values ​​for handover parameters for the cell from the quasi-RT RIC, wherein the optimization values ​​for the handover parameters are generated by the quasi-RT RIC based on one or more handover optimization policies. Brief explanation of the drawing

[0036] The attached drawings, incorporated herein and constituting part of the invention, illustrate representative embodiments of the disclosed methods and systems, wherein similar reference numbers indicate the same parts throughout the different drawings. The components in the drawings are not necessarily in a fixed proportion, but may instead be emphasized to clearly illustrate the principles of the invention. Some drawings may use block diagrams to illustrate components and may not show the internal circuitry of each component. It will be understood by those skilled in the art that the invention of these drawings includes the invention of electrical components, electronic components, or circuitry commonly used to implement such components.

[0037] FIG. 1 illustrates an exemplary block diagram representation (100) of a 5th generation (5G) heterogeneous network (HetNet) deployment scenario.

[0038] FIG. 2 illustrates an exemplary network architecture (200) in which the proposed system of the present disclosure can be implemented according to an embodiment of the present disclosure.

[0039] FIG. 3 illustrates an exemplary representation (300) of a proposed service management and coordination (SMO) system for optimizing the mobility robustness of a telecommunications network using an open radio access network (O-RAN) according to an embodiment of the present disclosure.

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

[0041] FIG. 5a illustrates an exemplary block diagram representation (500a) of Mobility Robustness Optimization (MRO) in quasi-real-time radio intelligent controller (quasi-RT RIC) and non-real-time radio intelligent controller (non-RT RIC) entities of an O-RAN according to an embodiment of the present disclosure.

[0042] FIG. 5b illustrates an exemplary block diagram representation (500b) of Mobility Robustness Optimization (MRO) in a management entity of an O-RAN and a quasi-real-time radio intelligent controller (quasi-RT RIC) entity according to an embodiment of the present disclosure.

[0043] FIG. 6a illustrates a sequence diagram representation (600a) of the detection of an early handover during a handover execution according to an embodiment of the present disclosure.

[0044] FIG. 6b illustrates a sequence diagram representation (600b) of the detection of an early handover immediately after a successful handover execution, according to an embodiment of the present disclosure.

[0045] FIG. 6c illustrates a sequence diagram representation (600c) of the detection of an early handover immediately after a successful handover execution according to an embodiment of the present disclosure, wherein the user device (UE) works in cooperation with the access and mobility management function (AMF) to delete the context.

[0046] FIG. 6d illustrates a sequence diagram representation (600d) of the detection of a handover that is too late during a handover execution, according to an embodiment of the present disclosure.

[0047] FIG. 6e illustrates a sequence diagram representation (600e) of the detection of a handover that is too late before the handover is executed, according to an embodiment of the present disclosure.

[0048] FIG. 6f illustrates a sequence diagram representation (600f) of the detection of a handover to an incorrect cell after a successful handover with an incorrect target cell, according to an embodiment of the present disclosure.

[0049] FIG. 6g illustrates a sequence diagram representation (600g) of the detection of a handover to an incorrect cell after preparation for a successful handover with an incorrect target cell, according to an embodiment of the present disclosure.

[0050] FIG. 7 illustrates an exemplary computer system (700) in which embodiments of the present invention may be used, according to embodiments of the present disclosure.

[0051] What has been said above will become more apparent from the following more detailed description of the present invention. Specific details for implementing the invention

[0052] In the following description, for the purposes of explanation, various specific details are presented to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent that the embodiments of the present disclosure can be practiced without these specific details. The various features described below may each be used independently of one another or in any combination with other features. An individual feature may not address all of the problems discussed above, or may address only some of the problems discussed above. Some of the problems discussed above may not be fully addressed by any of the features described herein.

[0053] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with a practicable description for implementing the exemplary embodiments. It should be understood that various variations may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as presented.

[0054] Specific details are provided in the following description to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be illustrated as components in block diagram form so as not to obscure the embodiments with unnecessary details. In other instances, well-known circuits, processes, algorithms, structures, and technologies may be illustrated without unnecessary details to avoid obscuring the embodiments.

[0055] Additionally, it is noted that individual embodiments may be described as processes depicted as flowcharts, flow diagrams, data flow diagrams, structure diagrams, or block diagrams. While flowcharts may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Furthermore, the order of operations may be rearranged. A process may have additional steps not included in the drawings, but terminates when its operation is completed. A process may correspond to a method, function, procedure, subroutine, subprogram, etc. When a process corresponds to a function, its termination may correspond to a return to the function's calling function or the main function.

[0056] The words “exemplary” and / or “demonstrative” are used herein to mean that which serves as an example, instance, or illustration. Clearly, the subject matter disclosed herein is not limited by these examples. Furthermore, any aspect or design described herein as “exemplary” and / or “demonstrative” is not to be interpreted as being preferred or advantageous over other aspects or designs, nor is it intended to make impossible equivalent exemplary structures and techniques known to those skilled in the art. Moreover, insofar as the terms “include,” “have,” “contain,” and other similar words are used in the detailed description or claims, these terms are intended to be inclusive—in a manner similar to the term “included” as an open conjunction—without excluding any additional or other elements.

[0057] Throughout this specification, references to “one embodiment,” “an example,” “an instance,” or “one instance” mean that a particular feature, structure, or characteristic described in relation to an example is included in at least one embodiment of the present invention. Accordingly, phrases and appearances of “in one embodiment” or “in an example” in various places throughout this specification do not necessarily all refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0058] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include plural forms as well, unless the context otherwise clearly indicates. It will be further understood that the terms “comprising” and / or “comprising,” as used herein, specify the presence of the described 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. As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0059] The present disclosure provides systems and methods for optimizing the mobility robustness of a telecommunications network using an Open Radio Access Network (O-RAN). The present disclosure provides systems and methods for realizing Mobility Robust Optimization (MRO) functions of a Self-Organizing Network (SON) in an O-RAN architecture. The present disclosure provides systems and methods for functional separation between data / control flow mechanisms associated with different entities in an O-RAN architecture. The present disclosure provides systems and methods for providing locality of execution of separated MRO modes. The present disclosure provides systems and methods for helping to detect and correct connection failures caused by intra-RAT mobility, and for providing support for unnecessary inter-system handovers to other Radio Access Technologies (RATs). The present disclosure provides systems and methods for handling scenarios such as too early handovers, too late handovers, handovers to the wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc. The present disclosure provides systems and methods for solving issues such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc. by optimizing HO parameters such as individual cell offset, hysteresis, time to trigger, Q offset, etc.

[0060] The present disclosure also provides systems and methods for collecting data to facilitate the execution of MRO functions in quasi- and non-RT RIC entities. The present disclosure provides systems and methods for optimizing HO parameters applicable to both idle and connected mode mobility scenarios. The present disclosure provides systems and methods of two mechanisms for realizing MRO functions in O-RAN architectures, such as MRO implementation in quasi-RT RIC and non-RT RIC entities, and MRO implementation in management entities and quasi-RT RIC entities.

[0061] Refer to FIG. 2, which illustrates an exemplary network architecture (200) (also referred to as network architecture (200)) for optimizing mobility robustness in which a Service Management and Orchestration (SMO) system (208) (or simply called SMO system (208)) of the present disclosure can be implemented according to an embodiment of the present disclosure. As illustrated, 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). The non-RT RIC (210) and quasi-RT RIC (214A) may be configured to facilitate mobility robustness optimization based on techniques received from users (228-1, 228-2, 228-3, ..., 228-N) (individually referred to as computing device (224) and collectively referred to as computing devices (224)) associated with one or more mobile computing devices (224-1, 224-2, 228-3, ..., 228-N) (individually referred to as user (228) and collectively referred to as users (228)). The SMO system (208) may be additionally operablely coupled to mobile computing devices (not shown in FIG. 1) via an open radio access network radio unit (O-RU (204)). The SMO (208) may be communicably coupled to one or more computing devices (224).

[0062] In addition, the non-RT RIC (210) may include rApps (212), and the quasi-RT RIC (214A) may include xApps (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 the O-CU-UP (218). The O-CU-CP (216) may be coupled to the O-CU-UP (218). In addition, O-CU-CP (216) can be combined with a 5th generation (5G) core (5GC) (220) and O-CU-UP (218) can be combined with a user plane function (UPF) (222).

[0063] In an embodiment, the SMO system (208) can realize Mobility Robustness Optimization (MRO) functions and data collection interworking methods of a Self-Organizing Network (SON) in an Open Radio Access Network (O-RAN) architecture. The O-RAN architecture may have two separate entities, a quasi-RT RIC (214A) and a non-RT RIC (210), where functional separation of MRO and related functional flows between the two entities can be implemented.

[0064] In an embodiment, the SMO system (208) can perform functional separation of the MRO and localization of the execution of the separated MRO.

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

[0066] In an embodiment, the SMO system (208) can detect and correct connection failures caused by intra-radio access technology (RAT) mobility and unnecessary system-to-system handovers to other RATs.

[0067] In an embodiment, the SMO system (208) can handle scenarios such as (but not limited to) too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc.

[0068] In an embodiment, the SMO system (208) can correct issues by optimizing handover parameters such as individual cell offsets, hysteresis, trigger time, Q offset, etc.

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

[0070] In the embodiments, field data capture, storage, matching, processing, decision-making, and operation logic may be coded using a micro-services architecture (MSA), but are not limited thereto. Multiple microservices may be transported in containers and may be event-based to support portability.

[0071] In an embodiment, the network architecture (200) can be modular and flexible to accommodate any kind of changes in the SMO system (208) and the quasi-RT RIC (214A) as proximity processing can be acquired toward optimizing mobility robustness in the telecommunications network. The configuration details of the SMO system (208) and the quasi-RT RIC (214A) can be modified on the fly.

[0072] In an embodiment, the SMO system (208) can be monitored remotely, and the data, applications, and physical security of the SMO system (208) can be fully guaranteed. In an embodiment, data can be placed in a cloud-based data lake to be collected and processed in a granular manner to extract actionable insights. Thus, aspects of predictive maintenance can be achieved.

[0073] In an exemplary embodiment, a communication network (not shown in FIG. 1) may include, as an example but not a limitation, at least part of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or any combination thereof one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, etc. The network may include, as an example but not a limitation: a wireless network, a wired network, the Internet, an intranet, a public network, a private network, a packet-switching network, a circuit-switching network, an ad hoc network, an infrastructure network, a public-switched telephone network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0074] In another exemplary embodiment, a server (not shown in FIG. 1) may be included in the architecture (200). A quasi-RT RIC (214A) and an SMO system (208) may be implemented on the server. The server may include, as an example but not a limitation: a standalone server, a server blade, a server rack, a stack of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualization server, one or more processors executing code to function as a server, one or more machines performing server-side functions as described herein, at least one part of any of the above, or one or more combinations thereof.

[0075] In an embodiment, one or more computing devices (224) and one or more mobile computing devices (not shown in FIG. 1) can communicate with an SMO system (208) through a set of executable commands existing on any operating system including (but not limited to) Android™, iOS™, Kai OS™. In an embodiment, one or more computing devices (224) and one or more mobile computing devices may include any electrical, electronic, electromechanical, or any combination of one or more of said devices, such as a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device (but not limited thereto), wherein the computing device may include one or more embedded or externally coupled accessories, including (but not limited thereto) visual aid devices such as a camera, audio assistant, microphone, keyboard, input devices for receiving input from a user such as a touchpad, touch-enabled screen, or electronic pen, receiving devices for receiving any audio or visual signal in any range of frequencies, and transmitting devices capable of transmitting any audio or visual signal in any range of frequencies. It may 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 above and various other devices may be used. Smart computing devices can be one of the appropriate systems for storing data and other personal / sensitive information.

[0076] FIG. 3 illustrates an exemplary representation (300) of a proposed Service Management and Coordination (SMO) system (208) for optimizing the mobility 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 processor(s) (302). The one or more processor(s) (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 devices that process data based on operation instructions. Among other capabilities, the one or more processor(s) (302) may be configured to fetch and execute computer-readable instructions stored in the memory (304) of the SMO system (208). Memory (304) may store one or more computer-readable instructions or routines on a non-transient computer-readable storage medium, which may be retrieved and executed to generate or share data packets through network services. Memory (304) may include any non-transient storage device, including volatile memory such as RAM, for example, or non-volatile memory such as EPROM, flash memory, etc.

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

[0078] The processing unit / engine(s) (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(s) (308). In the examples described herein, such combinations of hardware and programming may be implemented in various different ways. For example, programming for the processing engine(s) (308) may be processor-executable instructions stored on a non-transient machine-readable storage medium, and the hardware for the processing engine(s) (308) may include processing resources (e.g., one or more processors) to execute these instructions. In the examples, the machine-readable storage medium may store instructions that implement the processing engine(s) (308) when executed by the processing resources. In these examples, the SMO system (208) may include a machine-readable storage medium for storing commands and a processing resource for executing commands, or the machine-readable storage medium may be separate but accessible to the SMO system (208) and the processing resource. In other examples, the processing engine(s) (308) may be implemented by an electronic circuit. In addition, the SMO system (208) may include machine learning (ML) modules.

[0079] The processing engine (308) may include one or more engines selected from any of the data acquisition engine (312), the 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 edge-based microservice event processing (but is not limited thereto).

[0080] FIG. 4 illustrates a representative block diagram representation of a system architecture (400) according to an embodiment of the present disclosure.

[0081] The system architecture (400) is an O-RAN architecture. rApps (212) may have an interface through which external information can be supplied to the operator network. The quasi-RT RIC (406) may be a logic function that enables quasi-real-time control and optimization of RAN elements and resources through granular data collection and operations via the E2 interface, as illustrated in FIG. 4. The quasi-RT RIC (406) may include artificial intelligence (AI) / machine learning (ML) workflows, including model training, inference, and updates, handled by xApps (214B).

[0082] In addition, the non-RT RIC (404) may include a logical function capable of driving content carried across the A1 interface within the Service Management and Coordination System (SMO) (402), as illustrated in FIG. 4. The non-RT RIC (404) may include non-RT RIC applications such as non-RT RIC frameworks and rApps (212). Furthermore, the non-RT RIC framework may function within the SMO system (402) and may logically terminate the A1 interface to the non-RT RIC (406). The non-RT RIC framework may also expose a set of internal SMO services required for their runtime processing to the rApps (212) via the R1 interface. The non-RT RIC framework may function within the non-RT RIC (404) and may provide AI / ML workflows, including model training, inference, and updates required for the rApps (412).

[0083] In addition, the O1 interface from the O-RAN components may terminate at the SMO system (402). 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) protocols. In addition, O-CU-UP (410) may be a logical node hosting the user plane portion of the PDCP protocol and Service Data Adaptation Protocol (SDAP) protocols. O-DU (412) may be a logical node hosting the Radio Link Control (RLC) / Media Access Control (MAC) / Upper-Physical (PHY) layers based on lower-layer functional separation. The E2 node may be a logical node terminated at the E2 interface. In addition, O-RAN nodes that can be terminated at the E2 interface are for NR access in O-CU-CP (408), O-CU-UP (410), O-DU (412) or any combination, and for advanced universal mobile telecommunications system (UMTS) terrestrial radio access (E-UTRA) such as O-eNB (418).

[0084] Non-RT RIC applications, such as rApps (212), may be modular applications that leverage capabilities exposed through the R1 interface of the non-RT RIC framework to provide value-added services for RAN operations. Value-added services for RAN operations may include driving the A1 interface, recommending values ​​and operations available through the O1 / O2 interface, and generating "enrichment information (EI)" for use by the rApps (212) (but are not limited thereto). The rApps (212) may function within the non-RT RIC (404) to enable non-real-time control and optimization of RAN elements and resources.

[0085] rApps (212) can also provide policy-based guidance to applications / features in the quasi-RT RIC (406). In addition, quasi-RT RIC applications such as xApps (214B) can operate on the quasi-RT RIC (406). xApps (214B) may consist of one or more microservices and can identify what data they consume and what data they provide upon deployment. xApps (214B) may be independent of the quasi-RT RIC (406) and may be provided by any third party. The E2 interface can enable a direct association between xApps (214B) and RAN functions.

[0086] In addition, the O-cloud (416) may be a cloud computing platform that includes a collection of physical infrastructure nodes. The nodes meet O-RAN requirements to host relevant O-RAN functions of the quasi-RT RIC (406), O-CU-CP (408), O-CU-UP (410), and O-DU (412), thereby supporting software components (such as operating systems, virtual machine monitors, container runtimes, etc.) and appropriate management and coordination functions. Additionally, an O1 interface may exist between the SMO system (208) and O-RAN management elements for operation and management. The O1 interface may enable fault, configuration, account, performance, security, (FCAPS) management, physical network function (PNF) software management, and file management.

[0087] In addition, the O2 interface may be located between the SMO system (208) and the O-cloud (416) to support O-RAN virtual network functions. Furthermore, the A1 interface between the non-RT RIC (404) and the quasi-RT RIC (406) enables the non-RT RIC function to provide policy-based guidance, ML model management, and enrichment information to the quasi-RT RIC function so that the RAN can optimize radio resource management (RRM) under specific conditions. Subsequently, the E2 interface may connect the quasi-RT RIC (406) with 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 located between the rAPPs (212) and the non-RT RIC (404) framework.

[0088] Although not shown in FIG. 4, the O-eNB (418) may not have an open fronthall interface between them and may not support O-DU (412) and O-RU (414) functions. The management side includes an SMO system (402) that includes non-RT-RIC (404) functions. The O-Cloud (416), on the other hand, is a cloud computing platform that includes a collection of physical infrastructure nodes meeting O-RAN requirements to host relevant O-RAN functions (such as quasi-RT RIC (406), O-CU-CP (408), O-CU-UP (410), and O-DU (412), etc.), supporting software components (such as operating systems, virtual machine monitors, container runtimes, etc.), and appropriate management and coordination functions. As shown in FIG. 4, the O-RU (414) terminates an open fronthall M-plane interface toward the O-DU (414) and the SMO system (402).

[0089] FIG. 5a illustrates an exemplary block diagram representation of Mobility Robustness Optimization (MRO) in the entities of a quasi-real-time radio intelligent controller (quasi-RT RIC) (512) and a non-real-time radio intelligent controller (non-RT RIC) (508) of an O-RAN according to an embodiment of the present disclosure.

[0090] In the embodiment, Mobility Robustness Optimization (MRO) can be performed using non-RT aspects of the MRO function enabled in the non-RT RIC (508). Mobility Robustness Optimization (MRL) can also be performed using quasi-RT aspects of the MRO function enabled in the quasi-RT RIC (512). The Management Data Analysis Services (MDAS) of the Management Entity (504) can track all PM data, events, and error logs as part of the FCAPS data associated with all possible cells at a specific geographic location. In the Management Entity (504), the FCAPS data may be by default non-RT. The MDAS performs big data analyses on the FCAPS data and can generate one or more data patterns.

[0091] When a cell is assigned, it may be configured with initial values ​​for handover parameters for both "idle mode" and "connected mode". Some of the handover parameters may be broadcast, and several other handover parameters may be configured individually during connection establishment. Generally, handover parameters may be set to default values ​​or operator-configured values. In a non-RT RIC (508), the MRO rApp (510) may use the cell's geographic location and data patterns generated by MDAS to select data patterns. The selected data patterns may be closely applicable to the cell being deployed. In a non-RT RIC (508), the MRO rApp (510) may derive an initial set of values ​​for the handover parameters. The derived values ​​may be transported to the management entity (504) through the internal interfaces of the O-RAN's SMO (502) module. The management entity (504) can configure these values ​​into appropriate E2 nodes through a successfully established O1 interface during the plug-and-connect or plug-and-play period of the cell's deployment.

[0092] The MRO rApp (510) can also generate handover optimization policies based on selected data patterns and transmit them to the quasi-RT RIC (512) via the A1 interface. Now the cell can be successfully appointed and the E2 interface can be successfully established between the E2 nodes and the quasi-RT RIC (512). The MRO xApp (514) can begin collecting quasi-RT measurement data, PM data, and other data from the associated E2 nodes. The MRO xApp (514) can request the RT data analysis function to generate relevant data analyses by sharing all the data collected from the E2 nodes. When the MRO xApp (514) receives the requested data analyses, it can use the policies received from the non-RT RIC (508) and derive new values ​​for the handover parameters. If it is deemed that changes to the handover parameters are being made at the E2 nodes, the MRO xApp (514) can configure the updated values ​​for the handover parameters to the E2 nodes via the E2 interface.

[0093] E2 nodes can capture all MRO-related counters and share the MRO-related counters with the quasi-RT RIC (512). Additionally, whenever E2 nodes receive handover failure indications from neighboring cells and UEs, they can share connection failure indications with the quasi-RT RIC (512).

[0094] FIG. 5b illustrates 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) according to an embodiment of the present disclosure.

[0095] In the embodiment, Mobility Robustness Optimization (MRO) can be performed using non-RT aspects of the MRO function fully enabled in the management entity (504). Mobility Robustness Optimization (MRO) can also be performed using quasi-RT aspects of the MRO function enabled in the quasi-RT RIC (512). Here, most of the functions of the MRO remain the same as those described in FIG. 5a. However, all non-RT aspects of the MRO function may be enabled only within the management entity (504). The MRO function module within the management entity (504) derives initial handover parameters and can provide them to E2 nodes via a successfully established O1 interface. The same MRO function module in the management entity (504) derives handover optimization policies and can share them with the quasi-RT RIC (512) via an A1 interface. The use of MDAS by the MRO function will be the same as described for FIG. 5a.

[0096] FIG. 6a illustrates a sequence diagram representation (600a) of the detection of an early handover during a handover execution according to an embodiment of the present disclosure.

[0097] Radio link failure may occur in the target cell (606) immediately after the handover is completed. Radio link failure may also occur when the UE (602) attempts to re-establish a radio link from the source cell (604) during the execution of the handover procedure. FIG. 6a illustrates a scenario that may occur when the UE (602) is unable to successfully access the target cell (606) during the execution of the handover.

[0098] In steps (612-1) and (612-2), the SMO (208) may provide initial handover parameters to the source cell (604) and the target cell (606), respectively, via the O1 interface during their deployment time before the source cell (604) and the target cell (606) begin operation. In step (612-3), the SMO (208) may provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for its optimization function. When the source cell (604) determines that it has triggered a handover for its connected UE (602), the source cell (604) prepares for a handover with the target cell (606) and may issue a handover command to the UE (602) via an RRC reconfiguration message. After receiving a handover command, the UE (602) may attempt to access the handover with the target cell (606), but may fail due to insufficient strong radio frequency (RF) conditions.

[0099] As a result, in step (612-4), the UE (602) may re-select the source cell (604) and initiate an RRC re-establishment procedure. Since the source cell (604) has the UE (602) context, the RRC re-establishment procedure may be successful, and the UE (604) may remain connected. The source cell (604) may conclude this is an too early handover scenario and increment the too early handover (HO) counter.

[0100] In steps (612-5), the source cell (604) may notify the occurrence of an early handover from the quasi-RT RIC (512) to the MRO xApp (514) via the E2 interface by an early handover detection indication. The early handover detection indication may carry data regarding the source cell (604), the target cell (606), recent early handover counters, and other related details. Now, algorithms in the MRO xApp (514), along with quasi-RT data analysis functions, process the data and determine whether any modifications may be required for the HO parameters. If modifications are required, the MRO xApp (514) may command the updated HO parameters to the source cell (604) in a specific and / or different cell via the E2 nodes and the E2 interface, which is not illustrated in the sequence.

[0101] FIG. 6b illustrates a sequence diagram representation (600b) of the detection of an early handover immediately after a successful handover execution, according to an embodiment of the present disclosure.

[0102] In steps (614-1) and (614-2), the SMO (208) can provide initial handover parameters to both the source cell (604) and the target cell (606) via the O1 interface during the deployment period before the source cell (604) and the target cell (606) begin operation, respectively. In step (614-3), the SMO (208) can provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for optimization functions.

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

[0104] In steps (614-4), the source cell (604) can delete the UE context upon receiving the Xn: UE context release message from the target cell (606) as part of a successful HO execution.

[0105] In steps (614-5) and (614-6), upon receiving an RRC re-establishment request message, the previous source cell (604) may send an Xn: Failure Indication message toward the failure cell. The failure cell is the target cell (606) indicated by the UE (602) in the RRC re-establishment request message. The target cell (606) may process the received failure indication, analyze the status, and detect a Too Early HO scenario. In step (614-7), the target cell (606) may send an Xn: Handover Report message to the source cell (604) with a handover report type set to "Too Early HO". Upon receiving the handover report message, the source cell (604) may increment the Too Early HO counter. In steps (614-8), the source cell (604) can notify the MRO xApp (514) in the quasi-RT RIC (214A) of an "too early handover" scenario via the E2 interface. The "too early handover" detection indication and additional processes will remain the same as those described in the previous scenario.

[0106] FIG. 6c illustrates a sequence diagram representation (600c) of the detection of an early handover immediately after a successful handover execution according to an embodiment of the present disclosure, wherein the user device (UE) context can be deleted in cooperation with the access and mobility management function (AMF).

[0107] In steps (616-1) and (616-2), the SMO (208) can provide initial handover parameters to both the source cell (604) and the target cell (606), respectively, via the O1 interface during the deployment period, and the source cell (604) and the target cell (606) begin to operate. In step (616-3), the SMO (208) can provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for its optimization function.

[0108] This scenario is identical to the scenario depicted in FIG. 6b, but the entire timer (TXnRELOC) may expire before the target cell (606) transmits the Xn: UE context release message as part of the HO execution. Upon expiration of the timer, the source cell (604) may request the AMF (610) to release the UE (602) context by transmitting the NG: UE context release request message. The AMF (610) may then authorize the NG: UE context release request and transmit the NG: UE context release command message to the source cell (604). Afterward, the source cell (604) may delete the UE context and confirm this to the AMF (610) by transmitting the NG: UE context release completion message. These sequences are not illustrated in FIG. 6c.

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

[0110] In steps (616-7), the target cell (606) may send an Xn: handover report message to the source cell (604) with a handover report type set to "Too early HO". Upon receiving the handover report message, the source cell (604) may increment the Too early HO counter. In steps (616-8), the source cell (604) may notify the MRO xApp (514) in the quasi-RT RIC (214A) of this occurrence via the E2 interface through an Too early handover detection indication. Further processes may be the same as those described in the previous scenario.

[0111] FIG. 6d illustrates a sequence diagram representation (600d) of the detection of a handover that is too late during a handover execution, according to an embodiment of the present disclosure.

[0112] In steps (618-1) and (618-2), the SMO (208) can provide initial handover parameters to both the source cell (604) and the target cell (606) via the O1 interface during the deployment period before the source cell (604) and the target cell (606) begin operation, respectively. In step (618-3), the SMO (208) can provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for its optimization function.

[0113] In step (618-4), a radio link failure may occur in the source cell (604) before or during the handover procedure. The UE (602) may then attempt to re-establish its radio link in another cell or target cell (606).

[0114] Here, 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 re-establishment procedure with the target cell (606) with a cause set as another failure. Since the HO preparation may be successful, the target cell (606) may have the UE context. In step (618-6), upon receiving an RRC re-establishment request message from the same UE (602), the target cell (606) may send an Xn: failure indication message to the source cell (604) indicating a HO scenario that is too late. Additionally, the target cell (606) may send an Xn: UE context release message to the source cell (604).

[0115] The source cell (604) can process the received failure indication, analyze the status, and detect a too late HO scenario. In steps (618-7) and (618-8), the source cell (604) can increment the too late HO counter and notify the MRO xApp (514) in the quasi-RT RIC (214A) of this occurrence via the E2 interface through a too late handover detection indication. Furthermore, the process in the quasi-RT RIC (214A) will remain the same as described in the previous scenarios.

[0116] FIG. 6e illustrates a sequence diagram representation (600e) of the detection of a handover that is too late before the handover is executed, according to an embodiment of the present disclosure.

[0117] In steps (620-1) and (620-2), the SMO (208) can provide initial handover parameters to both the source cell (604) and the target cell (606) via the O1 interface during the deployment period before the source cell (604) and the target cell (606) begin operation, respectively. In step (620-3), the SMO (208) can provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for its optimization function.

[0118] In step (620-4), the UE (602) may initiate an RRC re-establishment procedure with the target cell (606) even before any HO preparation, having experienced a radio link failure with the source cell (604) and a cause set as another failure. Since HO preparation has not yet been initiated, the target cell (606) may not have a UE context. In steps (620-5) and (620-6), upon receiving an RRC re-establishment request message from the UE (602), the target cell (606) may reject the re-establishment request and send an Xn: failure indication message to the source cell (604), indicating an HO scenario that is too late.

[0119] The source cell (604) can process the received failure indication, analyze the status, and detect a too late HO scenario. The source cell (604) can increment the too late HO counter and notify the occurrence to the MRO xApp (514) in the quasi-RT RIC (214A) via the E2 interface through the too late HO detection indication. Further processes in the quasi-RT RIC (214A) will remain the same as those described in the previous scenarios.

[0120] FIG. 6f illustrates a sequence diagram representation (600f) of the detection of a handover to an incorrect cell after a successful handover with an incorrect target cell, according to an embodiment of the present disclosure.

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

[0122] 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.

[0123] In step (622-6), the UE (602) may experience a radio link failure with the wrong target cell (606A) immediately after a successful HO execution due to an insufficient or inconsistent strong RF state. Therefore, the UE (602) may re-select the actual target cell (606B) and trigger an RRC re-establishment procedure with a different cause set for failure. Upon receipt of the RRC re-establishment request message, the actual target cell (606B) may send an Xn: failure indication message to the failure cell (wrong target cell (606A)) indicated by the UE (602) in the RRC re-establishment request message. The wrong target cell (606A) may process the received failure indication, analyze the state, and detect an HO scenario to the wrong cell.

[0124] In step (622-7), the wrong target cell (606A) may send a handover report message Xn: Handover Report Message to the source cell (604) with a handover report type set to “HO to Wrong Cell”. Upon receipt of the handover report message, the source cell (604) may increment the HO to Wrong Cell counter. In step (622-8), the source cell (604) may notify the MRO xApp (514) in the quasi-RT RIC (214A) of this occurrence via the E2 interface through a handover detection indication to the wrong cell. Further processes may remain the same as described in the previous scenario.

[0125] FIG. 6g illustrates a sequence diagram representation (600g) of the detection of a handover to an incorrect cell after preparation for a successful handover with an incorrect target cell, according to an embodiment of the present disclosure.

[0126] In steps (624-1) and (624-2), the SMO (208) can provide initial handover parameters to both the source cell (604) and the target cell (606) via the O1 interface during their deployment time before the source cell (604) and the target cell (606) begin operation, respectively. In step (624-3), the SMO (208) can provide handover optimization policy information to the quasi-RT RIC (214A) via the A1 interface for its optimization function.

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

[0128] In steps (624-7), the source cell (604) may send an Xn: Handover Cancel message to the wrong target cell (606A) to cancel the handover preparation. Additionally, the source cell (604) may increment the HO counter to the wrong cell. In steps (624-8), the source cell (604) may notify the MRO xApp (514) in the quasi-RT RIC (214A) of this occurrence via the E2 interface through a handover detection indication to the wrong cell. The additional process will remain the same as described in the previous scenario.

[0129] Ping-Pong Handover Scenarios: In a ping-pong handover scenario, no radio link failure may occur, but after a successful handover, the UE (602) may remain in the handover cell for a very short duration. The UE (602) may continue to hop frequently between the two cells. Generally, in a ping-pong handover scenario, the ping-pong occurs between two identical adjacent cells of the same or different RATs. The MRO xApp (514) can detect the ping-pong handover scenario and correct it by optimizing the HO parameters. The MRO xApp (514) can also suggest a handover to the upper-level cells of the same or different RATs, or, if feasible, suggest having dual connectivity between the two cells to correct the ping-pong handover scenario.

[0130] Fast or very fast handover scenarios: Fast or very fast handover scenarios may be similar to ping-pong handover scenarios. In a fast or very fast handover scenario, the UE (602) hops to different cells and may stay in each cell for a very short duration. The duration of stay in each cell may depend on the UE's mobility rate. The MRO xApp (514) will detect fast or very fast handover scenarios and distinguish between scenarios that may be inevitable and those that can be corrected.

[0131] For example, very fast handover scenarios can occur along line lines and aircraft paths, and along protected highways, etc., by using ground-to-air communications. These very fast handover scenarios may be inevitable. Here, corrections may not be required. Scenarios where corrections may be required can be detected by the MRO xApp (514). The MRO xApp (514) can then suggest a handover to higher-level cells, such as NTN cells.

[0132] FIG. 7 illustrates an exemplary computer system (700) in which embodiments of the present invention may be utilized according to embodiments of the present disclosure. As illustrated in FIG. 7, the 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 understand that the computer system may include one or more processors and communication ports. Examples of the processor (770) include Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), processors of the Motorola® line, FortiSOC™ system-on-chip processors, or other future processors (but are not limited thereto).

[0133] 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 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 other existing or future ports. 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 connects. The memory (730) may be random access memory (RAM) or any other dynamic storage device generally known in the art. The read-only memory (740) may be any static storage device(s), such as programmable read-only memory (PROM) chips for storing static information, such as startup or BIOS instructions for the processor (770) (but is not limited thereto).

[0134] The mass storage device (750) may be any current or future mass storage solution that can be used to store information and / or commands. Exemplary mass storage solutions include Parallel Advanced Technology Access (PATA) or Serial Advanced Technology Access (SATA) hard disk drives or solid-state drives (with internal or external, e.g., Universal Serial Bus (USB) and / or FireWire interfaces), such as Seagate (e.g., Seagate Barracuda 782 family) or Hitachi (e.g., Hitachi Deskstar 13K800), one or more optical disks, redundant array of independent disks (RAID) storage devices, such as arrays of disks (e.g., SATA arrays) (but are not limited thereto).

[0135] The bus (720) enables the processor(s) (770) to communicate with other memory, storage devices, and communication blocks. The bus (720) may be other servers, such as a Peripheral Component Interconnect (PCI) / PCI Expansion (PCI-X) bus, Small Computer System Interface (SCSI), USB, etc., for connecting expansion cards, drives, and other subsystems, as well as a Front Side Bus (FSB) for connecting the processor (770) to a software system.

[0136] Optionally, operator and operational interfaces, such as a display, keyboard, and cursor control device, may also be coupled to the bus (720) to support direct operator interaction with the computer system. Other operator and operational interfaces may be provided via network connections connected through the communication port (760). The external storage device (710) may be any type of external hard drive, 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 merely to exemplify various possibilities. The exemplary computer system mentioned above should not in any way limit the scope of the present disclosure.

[0137] Although substantial emphasis has been placed herein on preferred embodiments, it will be understood that many embodiments can be made and many variations can be made in the preferred embodiments without departing from the principles of the invention. These and other variations in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, and it will be clearly understood thereby that the foregoing illustrative problem is implemented merely as an example of the invention and not as a limitation. Advantages of the present disclosure

[0138] The present disclosure provides systems and methods for optimizing the mobility robustness of a telecommunications network using an Open Radio Access Network (O-RAN).

[0139] The present disclosure provides systems and methods for realizing Mobility Robustness Optimization (MRO) functions of a Self-Optimizing Network (SON) in an O-RAN architecture.

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

[0141] The present disclosure provides systems and methods for providing locality of execution of separated MRO aspects.

[0142] The present disclosure provides systems and methods to help detect and correct connection failures caused by mobility within a RAT and to provide support for unnecessary system-to-system handovers to other radio access technologies (RATs).

[0143] The present disclosure provides systems and methods for handling scenarios such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc.

[0144] The present disclosure provides systems and methods for solving issues such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, etc. by optimizing HO parameters such as individual cell offset, hysteresis, time to trigger, Q offset, etc.

[0145] The present disclosure provides systems and methods for collecting data to facilitate the execution of MRO functions in quasi-RT RIC entities.

[0146] The present disclosure provides systems and methods for optimizing HO parameters applicable to both idle and connected mode mobility scenarios.

[0147] The present disclosure provides systems and methods of two mechanisms for realizing MRO functions in O-RAN architectures, such as MRO implementation in quasi-RT RICs, non-RT RIC entities, and MRO implementation in management entities and quasi-RT RICs. Reservation of permissions Part of the disclosure of this patent document contains materials subject to intellectual property rights, such as (but not limited to) copyrights, designs, trademarks, IC layout designs, and / or trade dress protections, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred to as the Owners). The Owners have no objection to facsimile reproduction by either the patent document or the patent disclosure as it appears in the patent files or records of the Patent Office, but otherwise retain all rights. All rights to such intellectual property are fully retained by the Owners. This disclosure relates to O-RAN specifications as given in 3GPP TR 21.905[1].

Claims

Claim 1 A system for realizing Mobility Robustness Optimization (MRO) functions of a Self Organizing Network (SON) for a cell in an Open Radio Access Network (O-RAN), wherein the system comprises: a non-real-time radio access network intelligent controller (non-RT RIC), and the non-RT RIC comprises: a processor; a memory coupled to the processor, wherein the memory comprises processor-executable instructions, and wherein, upon execution, the processor comprises: receiving one or more data patterns for a cell from Management Data Analytics Services (MDAS); selecting a data pattern for the cell based on the one or more received data patterns — the selected data pattern corresponds to the geographic location of one or more cells —; and generating one or more handover optimization policies for the cell based on the selected data pattern; A system that transmits one or more handover optimization policies of the cell to a near-real-time radio access network intelligent controller (near-RT RIC) (512) associated with the system; and receives optimized values ​​for handover parameters for the cell from the near-RT RIC (512), wherein the optimized values ​​for the handover parameters are generated by the near-RT RIC (512) based on the one or more handover optimization policies. Claim 2 In claim 1, the MDAS is a system configured to track and monitor phase modulation (PM) data, events, and error logs received as Fault, Configuration, Accounting, Performance, Security (FCAPS) data associated with the cell deployed at a geographic location. Claim 3 In claim 1, the MDAS is a system configured to perform big data analyses on failure, configuration, account, performance, and security (FCPAS) data to generate one or more data patterns. Claim 4 A system according to claim 1, wherein the cell receives initial values ​​for the handover parameters during the deployment phase through an O1 interface from a management entity. Claim 5 In claim 4, the system wherein the cell receives initial values ​​for the handover parameters from a management entity during the Plug-n-Connect phase or Plug-n-Play phase of the cell's deployment. Claim 6 In claim 1, the cell is pre-configured with initial values ​​for the handover parameters in idle mode and connection mode, in a system. Claim 7 delete Claim 8 In claim 1, the system wherein one or more handover optimization policies are transmitted to the quasi-RT RIC (512) via the A1 interface by the non-RT RIC. Claim 9 In claim 1, the handover parameters for the cell include an offset value, a hysteresis value, a time to trigger, and a Q offset value for each individual cell, in a system. Claim 10 A system according to claim 1, wherein the quasi-RT RIC is configured to: collect quasi-RT measurement data, phase modulation (PM) data and other data from E2 nodes; share the collected data with an RT data analysis function; receive data analyses from the RT data analysis function based on the collected data; use one or more handover optimization policies received from the non-RT RIC based on the received data analyses; derive optimized values ​​for the handover parameters based on the one or more handover optimization policies; and transmit the optimized handover parameters to the quasi-RT RIC. Claim 11 A method for realizing Mobility Robust Optimization (MRO) of a Self-Organizing Network (SON) for a cell in an Open Radio Access Network (O-RAN), the method comprises: receiving one or more data patterns for a cell from Management Data Analysis Services (MDAS) by a processor; selecting a data pattern for the cell based on the one or more received data patterns by the processor — the selected data pattern corresponds to the geographic location of one or more cells —; generating one or more handover optimization policies for the cell based on the selected data pattern by the processor; transmitting the one or more handover optimization policies for the cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) (512) associated with the system by the processor; A method comprising the step of receiving optimized values ​​for handover parameters for the cell from the quasi-RT RIC (512) by the processor, wherein the optimized values ​​for the handover parameters are generated by the quasi-RT RIC (512) based on one or more handover optimization policies. Claim 12 A 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, account, performance, and security (FCAPS) data associated with the cell deployed at a geographic location. Claim 13 In claim 11, the MDAS is configured to perform big data analyses on failure, configuration, account, performance, and security (FCAPS) data to generate one or more data patterns. Claim 14 In claim 11, the method wherein the cell receives initial values ​​for the handover parameters during the deployment period through the O1 interface from the management entity. Claim 15 A method according to claim 11, wherein the cell receives initial values ​​for the handover parameters during the deployment time via the O1 interface from the management entity during the plug-and-connect or plug-and-play time of the cell's deployment. Claim 16 In claim 11, the method wherein the cell is pre-configured with initial values ​​for the handover parameters in idle mode and connection mode. Claim 17 delete Claim 18 In claim 11, the method wherein one or more handover optimization policies are transmitted to the quasi-RT RIC (512) via the A1 interface by the non-RT RIC. Claim 19 In claim 11, the handover parameters for the cell include an offset value, a hysteresis value, a time to trigger, and a Q offset value for each individual cell. Claim 20 A method according to claim 11, wherein the quasi-RT RIC is configured to: collect quasi-RT measurement data, phase modulation (PM) data and other data from E2 nodes; share the collected data with an RT data analysis function; receive data analyses from the RT data analysis function based on the collected data; use one or more handover optimization policies received from a non-RT RIC based on the received data analyses; derive optimized values ​​for the handover parameters based on the one or more handover optimization policies; and transmit the optimized handover parameters to the quasi-RT RIC.

Images