KR20230132438A - Systems and methods for optimizing mobility robustness of communication networks - Google Patents

Abstract

This disclosure relates generally to wireless telecommunication networks, and more particularly to systems and methods for optimizing the mobility robustness of a telecommunication network using an open radio access network (O-RAN). The system and method realize mobility robustness optimization (MRO) functionality of self-organizing networks (SON) in O-RAN architecture and data collection interworking methods. The O-RAN architecture is comprised of two separate entities called the Quasi-Real-Time Radio Intelligent Controller (Quasi-RT RIC (210)) and the Non-Real-Time Radio Intelligent Controller (Non-RT RIC (214A)) for functional separation for MRO. and have associated functional flows between the two entities. The system collects data to facilitate execution of MRO functions from quasi-RT RIC and non-RT RIC entities.

Description

Systems and methods for optimizing mobility robustness of communication networks

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

[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 specific aspects of the art that may be relevant to various features of the present disclosure. However, it should be understood that this section is intended solely to enhance the reader's understanding of the present disclosure and not as an admission of prior art.

[0003] In general, as cellular networks evolve from the fourth generation (4G), fifth generation (5G) and then to the sixth generation (6G) along with other radio access technologies such as wireless fidelity (Wi-Fi), mobile Subscriptions are also increasing exponentially. Therefore, mobile operators may be forced to deploy ultra-high-density heterogeneous networks (HetNet) to fulfill subscribers' demands. HetNets can generally be built by multi-portfolio and multi-vendor-based solutions. One of the main challenges facing operators during greenfield or brownfield deployments of HetNets can be the need for high quality installations. Another challenge lies in continuous monitoring of the performance and health of deployed networks. Dynamic adaptation to changing environments is also an issue, as are active adjustments and optimization.

[0004] The aforementioned challenges may require very high manual effort and delays due to regular/frequent site visits and may result in additional operational costs. To overcome these drawbacks and drastically reduce operational costs (OPEX), a Self-Organizing Network (SON) can be used. SON may be a self-organizing network or a self-optimizing network. SON can be an automation technology that allows a network to set up itself and self-manage its resources and configuration to achieve optimal performance. SON can function under three categories: The first category is self-organization. Self-configuration can help seamless integration into the network through automatic configuration of key parameters. Self-configuration is most important during initial network deployments. It includes several capabilities such as plug-and-play functions [PnP], automatic neighbor relationship function [ANR], 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 lifespan of a network. Self-optimization includes mobility load balancing [MLB], mobility robustness optimization [MRO], RACH optimization, energy savings [ES], radio link failure reporting, coverage and capacity optimization [CCO], [DL power control, RET], and forward hand. Includes various capabilities such as overload, 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 adjacent cells to maintain network quality in the event of a cell/sector failure, providing resilience in the face of unexpected outage conditions. Self-healing includes various capabilities such as cell outage detection [dead/abnormal/sleeping cell/sector/beam], cell outage recovery, cell outage compensation, and cell outage compensation recovery.

[0007] The Minimization of Drive Test (MDT) function is designed to operate independently from SON, but its functions are reused whenever possible. The SON functions can be handled individually or in groups by SON algorithms. SON algorithms may perform functions such as monitoring the network(s) by collecting management data, including MDAS data and analysis of management data to determine if there are issues in the network(s) that need to be addressed. SON algorithms can also determine SON operations to resolve issues and execute SON operations to resolve them. In addition, 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 be possible to implement various SON use cases. A solution can be selected depending on the needs of SON use cases. Centralized SON (C-SON) may include functions executed by the SON algorithm in the management system. Cross-domain-focused SON (CD C-SON) may include functionality that SON algorithms can execute at the cross-domain (CD) layer. In addition, domain-intensive SON (DC-SON) can be a SON algorithm that can be executed at the domain layer. Moreover, distributed SON (D-SON) can be a SON algorithm in NFs.

[0009] Then, hybrid SON (H-SON) can be a SON algorithm that can run on two or more levels, such as NF layer, domain layer, or cross-domain (CD) layer. Because SON algorithms are implementation dependent, different vendors may take different approaches to their SON solutions. Some vendors may take the C-SON approach, some may take the D-SON approach and others may take H-SON approach-based solutions. Operators may inevitably use multi-vendor solutions while deploying HetNets.

[0010] Figure 1 illustrates an example 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 a different vendor and a set of element management systems (EMSs) from a different set of vendors. The operator may also use radio access networks (RAN), such as Next-Generation NodeB Centralized Units (gNB-CU) from different sets of vendors and Next-Generation NodeB Distributed Units (gNB-DU) from different sets of vendors. You can use managed entities such as nodes. Operators may encounter issues in the deployed HetNet of Figure 1. One of the issues is that although the D-SON of gNB-CU-1 (116) and gNB-CU-2 (124) communicate with each other through an open Xn interface, they do not cooperate well as both come from different vendors. That may not be the case.

[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) are connected to each other through the open Xn interface. Even if they communicate, they may not cooperate well as both sides come from different vendors. The main issue is that C-SON can be realized either co-located with management entities [like EMS/NMS] or as a stand-alone entity. Integrating C-SON with RAN nodes as a standalone entity is very difficult, as the interface is left to the implementation. Additionally, CD C-SON in NMS 106 may impact the performance of D C-SON and D-SON functions, operating in a multi-vendor environment.

[0012] Another issue is partially integrating third-party SON solutions in HetNet, which causes degradation of overall key performance indicators (KPIs). Additionally, L3-RRM coordination across neighboring NB-CUs 116, 124, 130 may be lacking regardless of same or multi-vendor scenarios, which will impact 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) will affect dynamic resource sharing and allocation. You can.

[0013] SON and Radio Resource Management (RRM), both proprietary implementations, have a significant impact on overall performance while multiple vendors collaborate across the Xn interface. Each algorithm behaves differently and has its own limitations. Although vendors may be prepared to integrate with third party solutions [SON and/or RRM], they may not be able to conclusively quantify/verify output performance, primarily due to their solutions. These situations always end in conflict between the agreed upon vendors. One possible solution to address these issues or limitations may be to create as many open interfaces and interfaces between radio access network (RAN) nodes that interact with SON solutions. The Open Radio Access Network (O-RAN) Alliance may be a worldwide community of mobile network operators, vendors, and research and education institutions operating in the RAN industry.

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

[0015] Therefore, there is a need for a mobility robustness optimization function in the O-RAN architecture along with a functional separation mechanism between different entities in the O-RAN architecture and associated data/control flow mechanisms. Therefore, there is a need in the art for systems and methods that can overcome the shortcomings of the existing prior art.

Objectives of this disclosure

[0016] Listed below are some of the objectives of the present disclosure, which are satisfied by at least one embodiment herein.

[0017] The purpose of the present disclosure is to provide efficient and reliable systems and methods for optimizing the mobility robustness of a telecommunication network using Open Radio Access Network (O-RAN).

[0018] The purpose of the present disclosure is to provide systems and methods for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) in an O-RAN architecture.

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

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

[0021] The purpose of the present disclosure is to detect and help correct connection failures caused by intra-radio access technology (intra-RAT) mobility and also to prevent unnecessary inter-system handovers to other radio access technologies (RATs). The goal is to provide systems and methods for providing support.

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

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

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

[0025] The purpose 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 two methods for realization of MRO functionality in the O-RAN architecture, such as MRO implementation in quasi-RT RIC, non-RT RIC entities, and MRO implementation in management entity and quasi-RT RIC. To provide systems and methods of mechanisms.

[0027] This section is provided to introduce in a simplified form certain objects and aspects of the invention that are further described in the Detailed Description below. This summary is not intended to identify key features or scope of the claimed subject matter.

[0028] In one aspect, the present disclosure provides a system for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) for cells in an open radio access network (O-RAN). The system includes a non-real-time radio access network intelligent controller (non-RT RIC) configured to receive one or more data patterns for a cell from a Management Data Analysis Service (MDAS). MDAS tracks phase modulation (PM) data, events, and error logs received as Fault, Configuration, Accounting, Performance, Security (FCAPS) data associated with cells deployed in a geographical location. and is configured to monitor. MDAS is configured to perform big data analyzes on FCAPS data to generate one or more data patterns.

[0029] Additionally, the non-RT RIC of the system selects a data pattern for the cell based on one or more data patterns received. The cell is provided with initial values for handover parameters during the deployment phase via the O1 interface by the management entity. The cell is provided by the management entity with initial values for the handover parameters during the deployment phase via the O1 interface during the plug-and-connect 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 connected mode. One or more handover optimization policies are communicated by the non-RT RIC to the quasi-RT RIC 512 through the A1 interface. Handover parameters for a cell include cell-specific offset values, hysteresis values, time to trigger, and Q offset values.

[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 analyzes 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 optimization values for handover parameters based on one or more handover optimization policies. Moreover, the quasi-RT RIC is configured to transmit optimized handover parameters to the quasi-RT RIC.

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

[0032] In one aspect, the present disclosure provides a method for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) for cells in an open radio access network (O-RAN). The method includes receiving one or more data patterns for the cell from Management Data Analysis Services (MDAS). MDAS is configured to track and monitor PM data, events, and error logs received as Fault, Configuration, Accounting, Performance, and Security (FCAPS) data associated with cells deployed in a geographical location. MDAS is configured to perform big data analyzes on FCAPS data to generate one or more data patterns.

[0033] Additionally, the method includes selecting a data pattern for a cell based on one or more data patterns received. The cell is provided with initial values for handover parameters during deployment time by the management entity via the O1 interface. The cell is provided by the management entity with initial values for the handover parameters during the deployment time via the O1 interface during the plug-and-connect 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 connected mode. One or more handover optimization policies are communicated by the non-RT RIC to the quasi-RT RIC 512 through the A1 interface. Handover parameters for a cell include cell-specific offset values, hysteresis values, time to trigger, and Q offset values.

[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 further configured to receive data analyzes 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 optimization values for handover parameters based on one or more handover optimization policies. Moreover, the quasi-RT RIC is configured to transmit optimized handover parameters to the quasi-RT RIC.

[0035] Additionally, the method includes generating one or more handover optimization policies for the cell based on the selected data pattern. In addition, the method includes communicating one or more handover optimization policies of the cell to a quasi-real-time radio access network intelligent controller (quasi-RT RIC) associated with the system. In addition, the method includes receiving optimization values for handover parameters for a cell from a quasi-RT RIC, wherein optimization values for handover parameters are provided based on one or more handover optimization policies. -RT is generated by RIC.

[0036] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate representative embodiments of the disclosed methods and systems, in which like reference numerals indicate like parts throughout the different drawings. Elements in the drawings are not necessarily to scale; instead, emphasis may be placed on clearly illustrating the principles of the invention. Some drawings may use block diagrams to represent 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 figures includes the invention of electrical components, electronic components or circuitry commonly used to implement such components.
[0037] Figure 1 illustrates an example block diagram representation 100 of a fifth generation (5G) heterogeneous network (HetNet) deployment scenario.
[0038] Figure 2 illustrates an example network architecture 200 in which the proposed system of the present disclosure may be implemented, in accordance with an embodiment of the present disclosure.
[0039] Figure 3 is an example representation of a proposed service management and coordination (SMO) system for optimizing mobility robustness of telecommunication networks using open radio access network (O-RAN), according to an embodiment of the present disclosure. (300) is illustrated.
[0040] Figure 4 illustrates an example block diagram representation 400 of a system architecture, according to an embodiment of the present disclosure.
[0041] Figure 5A shows mobility robustness optimization (quasi-RT RIC), non-real-time radio intelligent controller (non-RT RIC) entities in O-RAN, according to an embodiment of the present disclosure. illustrates an example block diagram representation 500a of MRO).
[0042] FIG. 5B is an example block diagram representation 500b of mobility robustness optimization (MRO) in a management entity of O-RAN and a quasi-real-time radio intelligent controller (quasi-RT RIC) entity, according to an embodiment of the present disclosure. exemplifies.
[0043] Figure 6A illustrates a sequence diagram representation 600a of detection of premature handover during handover execution, according to an embodiment of the present disclosure.
[0044] FIG. 6B illustrates a sequence diagram representation 600b of detection of premature handover immediately following successful handover execution, according to an embodiment of the present disclosure.
[0045] FIG. 6C illustrates a sequence diagram representation 600c of detection of premature handover immediately after successful handover execution, in accordance with an embodiment of the present disclosure, where a user equipment (UE) performs access and mobility management functions ( Context is deleted in cooperation with AMF).
[0046] Figure 6D illustrates a sequence diagram representation 600D of detection of too late handover during handover execution, according to an embodiment of the present disclosure.
[0047] Figure 6E illustrates a sequence diagram representation 600e of detection of too late handover before handover execution, according to an embodiment of the present disclosure.
[0048] FIG. 6F illustrates a sequence diagram representation 600f of detection of a handover to an incorrect cell following successful execution of a handover with an incorrect target cell, according to an embodiment of the present disclosure.
[0049] FIG. 6G illustrates a sequence diagram representation 600g of detection of handover to an incorrect cell following preparation for successful handover with an incorrect target cell, according to an embodiment of the present disclosure.
[0050] Figure 7 illustrates an example computer system 700 in which embodiments of the invention may be used, in accordance with embodiments of the present disclosure.
[0051] The foregoing will become more apparent from the following more detailed description of the invention.

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

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

[0054] Specific details are provided in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one 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 shown as components in block diagram form so as not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0055] Additionally, it is noted that individual embodiments may be described as a process depicted as a flowchart, flow diagram, data flow diagram, structure diagram, or block diagram. A flowchart can describe operations as a sequential process, but many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. The process terminates when its operations are complete, but may have additional steps not included in the diagram. A process can 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 main function.

[0056] The words “exemplary” and/or “empirical” are used herein to mean serving as an example, instance, or illustration. To be clear, the subject matter disclosed herein is not limited by these examples. Additionally, any aspect or design described herein as “exemplary” and/or “empirical” is not necessarily to be construed as preferred or advantageous over other aspects or designs, and should be understood by those skilled in the art. It is not intended to preclude equivalent example structures and techniques known to those skilled in the art. Moreover, to the extent that the terms “comprise,” “have,” “contain,” and other similar words are used in the description or claims, such terms are intended to be inclusive and not exclude any additional or other elements. It is intended—in a similar manner to the term “comprising”—as an open conjunction.

[0057] Throughout this specification, reference to “one embodiment” or “an embodiment” or “instance” or “one instance” refers to a particular feature, structure, or characteristic described in connection with the embodiment of the invention. It means that it is included in at least one embodiment. Accordingly, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Moreover, specific features, structures, or characteristics may be combined in any suitable way in one or more embodiments.

[0058] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. . The terms “comprise” and/or “comprising”, when used herein, specify the presence of described features, integers, steps, operations, elements, and/or components, but It will be further understood that the above does not exclude the presence or addition of other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

[0059] This disclosure provides systems and methods for optimizing mobility robustness of a telecommunication network using an open radio access network (O-RAN). This disclosure provides systems and methods for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) in an O-RAN architecture. This 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 separate MRO aspects. This disclosure provides systems and methods for detecting and helping to correct connection failures caused by intra-RAT mobility, and for providing support for unnecessary inter-system handovers to other radio access technologies (RATs). to provide. This 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. do. The present disclosure addresses premature handover, too late handover, handover to wrong cells, ping-pong handovers, and fast handover by optimizing HO parameters such as cell-specific offset, hysteresis, time to trigger, Q offset, etc. Provides systems and methods for solving issues such as handovers, very fast handovers, etc.

[0060] The present disclosure also provides systems and methods for collecting data to facilitate MRO function execution in quasi- and non-RT RIC entities. This 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 realization of MRO functionality in an O-RAN architecture, such as MRO implementation in quasi-RT RIC, non-RT RIC entities, and management entity, MRO implementation in quasi-RT RIC. provides them.

[0061] In accordance with an embodiment of the present disclosure, the Service Management and Orchestration (SMO) system 208 (or simply referred to as SMO system 208) of the present disclosure may be implemented to optimize mobility robustness. 2, which illustrates an example network architecture 200 (also referred to as network architecture 200) for doing so. As illustrated, the example network architecture 200 includes a non-real-time radio intelligent controller (non-RT RIC) 210 associated with the SMO system 208, and a quasi-real-time radio intelligent controller (quasi-RT RIC) ( 214A) may be included. Non-RT RIC 210 and quasi-RT RIC 214A may be connected to one or more mobile computing devices 224-1, 224-2, ..., 224-N (individually referred to as computing device 224 and collectively Users 228-1, 228-2, 228-3, ..., 228-N) (individually referred to as users 228 and collectively referred to as users 228) (hereinafter referred to as computing devices 224) ) may be configured to facilitate mobility robustness optimization based on techniques received from ). The SMO system 208 may be further operably coupled to mobile computing devices (not shown in FIG. 1) via an open radio access network radio unit (O-RU 204). SMO 208 may be communicatively coupled to one or more computing devices 224.

[0062] In addition, non-RT RIC 210 may include rApps 212 and quasi-RT RIC 214A may include xApps 214B. The SMO system 208 and quasi-RT RIC 214A may be coupled to an open radio access network distributed unit (O-DU) 206. 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. Quasi-RT RIC (214A) may also be coupled to O-CU-CP (216) and O-CU-UP (218). O-CU-CP (216) can be coupled to O-CU-UP (218). In addition, O-CU-CP 216 can be coupled to the 5th-generation (5G) core (5GC) 220 and O-CU-UP 218 can be coupled to user plane function (UPF) 222. can be combined

[0063] In an embodiment, the SMO system 208 may implement mobility robustness optimization (MRO) functionality 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, quasi-RT RIC 214A and non-RT RIC 210, where functional separation for MRO and associated functional flows between the two entities may be implemented. You can.

[0064] In an embodiment, the SMO system 208 may perform functional separation of MROs and localization of execution of separate MROs.

[0065] In an embodiment, the SMO system 208 may collect data to facilitate MRO function execution from semi-RT RIC 214A and non-RT RIC 210 entities.

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

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

[0068] In an embodiment, the SMO system 208 may correct issues by optimizing handover parameters such as cell-specific offset, hysteresis, time to trigger, Q offset, etc.

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

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

[0071] In an embodiment, the network architecture 200 can accommodate any kind of change in the SMO system 208 and the quasi-RT RIC 214A such that proximity processing can be achieved toward optimizing mobility robustness in a telecommunication network. It can be modular and flexible to accommodate various requirements. SMO system 208, and quasi-RT RIC 214A configuration details can be modified on the fly.

[0072] In embodiments, the SMO system 208 can be remotely monitored and the data, applications, and physical security of the SMO system 208 can be fully ensured. In embodiments, data may be placed in a cloud-based data lake where it will be granularly collected and processed to extract actionable insights. Therefore, an aspect of predictive maintenance can be achieved.

[0073] In an exemplary embodiment, a communications network (not shown in FIG. 1) may contain, by way of example and not by way of limitation, one or more messages, packets, signals, waves, voltage or current levels, several thereof. At least a portion of one or more networks having one or more nodes transmitting, receiving, forwarding, generating, buffering, storing, routing, switching, processing, or combinations thereof, etc. It can be included. Networks include, by way of example and not by way of limitation: 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 ( PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0074] In another example embodiment, a server (not shown in FIG. 1) may be included in architecture 200. Quasi-RT RIC 214A and SMO system 208 may be implemented on servers. Server, by way of example and not by way of limitation: a standalone server, a server blade, a server rack, a stack of servers, a server farm, hardware that supports a cloud service or part of a system, a home server, hardware that runs a virtualized server, functions as a server. one or more processors that execute code to: one or more machines that perform server-side functions as described herein, at least a portion of any of the foregoing, some combination thereof, or It can be included.

[0075] In an embodiment, one or more computing devices 224 and one or more mobile computing devices (not shown in Figure 1) include, but are not limited to, Android™, iOS™, Kai OS™ ), may communicate with the SMO system 208 via a set of executable instructions existing on any operating system. In an embodiment, one or more computing devices 224 and one or more mobile computing devices include mobile phones, smartphones, virtual reality (VR) devices, augmented reality (AR) devices, laptops, general purpose computers, desktops, personal may include (but are not limited to) any electrical, electronic, electro-mechanical or any equipment or a combination of one or more of the foregoing devices, such as a digital assistant, tablet computer, mainframe computer, or any other computing device; ), where the computing device includes any range of input devices for receiving input from the user, such as a camera, an audio assistant, a microphone, a visual aid device such as a keyboard, a touch pad, a touch-enabled screen, an electronic pen, etc. One including, but not limited to, receiving devices for receiving any audio or visual signal in any frequencies and transmitting devices capable of transmitting any audio or visual signal in any range of frequencies. It may include the above built-in or externally coupled accessories. It can be understood that the one or more first computing devices 224, and one or more mobile computing devices may not be limited to the devices mentioned above and a variety of other devices may be used. Smart computing devices may be one of the suitable systems for storing data and other personal/sensitive information.

[0076] FIG. 3 is an illustration of a proposed service management and coordination (SMO) system 208 for optimizing mobility robustness of telecommunication networks using open-RAN (O-RAN), according to an embodiment of the present disclosure. This example illustrates a typical expression (300). In one aspect, SMO system 208 may include one or more processor(s) 302. One or more processor(s) 302 may be one or more microprocessors, microcomputers, microcontrollers, edge or fog microcontrollers, digital signal processors, central processing units, logic circuitry, and/ or may be implemented as any devices that process data based on operation instructions. Among other capabilities, one or more processor(s) 302 may be configured to retrieve and execute computer-readable instructions stored in memory 304 of SMO system 208. Memory 304 may store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be retrieved and executed to generate or share data packets via a network service. Memory 304 may include any non-transitory storage device, including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, etc.

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

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

[0079] Processing engine 308 may include one or more engines selected from any of data acquisition engine 312, signal acquisition engine 314, and other engines 316. Data acquisition engine 312 and signal acquisition engine 314 may include machine learning (ML) modules. Processing engine 308 may further include (but is not limited to) edge-based microservice event processing.

[0080] Figure 4 illustrates a representative block diagram representation of 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 logical function that enables quasi-real-time control and optimization of RAN elements and resources through granular data collection and operations through the E2 interface, as shown in FIG. 4. Quasi-RT RIC 406 may include an artificial intelligence (AI)/machine learning (ML) workflow including model training, inference, and updates, which are handled by xApps 214B.

[0082] In addition, the non-RT RIC 404 includes logical functions that can drive content carried across the A1 interface, within the service management and coordination system (SMO) 402, as shown in FIG. may include. Non-RT RIC 404 may include non-RT RIC applications such as the non-RT RIC framework and rApps 212. Moreover, a non-RT RIC framework may function internally to the SMO system 402 and logically terminate the A1 interface to the quasi-RT RIC 406. The non-RT RIC framework may also expose a set of internal SMO services required for their runtime processing to rApps 212, via the R1 interface. The non-RT RIC framework may function within the non-RT RIC 404 and provide an AI/ML workflow including model training, inference and updates required for rApps 412.

[0083] Additionally, O1 interfaces from O-RAN components may be terminated in SMO system 402. O-CU-CP 408 may be a logical node that hosts the control plane portion of the Radio Resource Control (RRC) and Packet Data Convergence Protocol (PDCP) protocols. Additionally, 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. O-DU 412 may be a logical node hosting Radio Link Control (RLC)/Medium Access Control (MAC)/Higher-Physical (PHY) layers based on lower layer functional separation. An E2 node can be a logical node that terminates at the E2 interface. In addition, O-RAN nodes that may be terminated at the E2 interface may have NR access in O-CU-CP 408, O-CU-UP 410, O-DU 412 or any combination, and For evolved Universal Mobile Telecommunications System (UMTS) terrestrial radio access (E-UTRA) access, such as O-eNB 418.

[0084] Non-RT RIC applications, such as rApps 212, may be modular applications that leverage functionality exposed through the R1 interface of the non-RT RIC framework to provide value-added services for RAN operations. You can. Value-added services for RAN operation include driving the A1 interface, recommending values and operations that can then be used via the O1/O2 interface, and providing “enhancement information” for use by rApps 212. It may include (but is not limited to) generating “enrichment information (EI)”. 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 may 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 run on quasi-RT RIC 406. xApps 214B may potentially consist of one or more microservices and, upon deployment, may identify what data it consumes and what data it provides. xApps 214B may be independent of the quasi-RT RIC 406 and may be provided by any third party. The E2 interface may enable direct association between xApps 214B and RAN functionality.

[0086] Additionally, O-Cloud 416 may be a cloud computing platform that may include a collection of physical infrastructure nodes. Nodes are connected to the O-RAN to host relevant O-RAN functions of quasi-RT RIC (406), O-CU-CP (408), O-CU-UP (410), and O-DU (412). Satisfying the requirements, it can support software components (such as operating system, virtual machine monitor, container runtime, etc.) and appropriate management and coordination functions. Additionally, the O1 interface can be used with the SMO system 208 and O1 for operation and management. -RAN-Management elements may exist between: O1 interfaces may enable fault, configuration, accounting, performance, security, (FCAPS) management, physical network function (PNF) software management, and file management.

[0087] Additionally, an O2 interface may be between the SMO system 208 and the O-Cloud 416 to support O-RAN virtual network functions. Moreover, the A1 interface between the non-RT RIC 404 and the quasi-RT RIC 406 allows the non-RT RIC functionality to be integrated into the quasi-RT RIC functionality so that the RAN can optimize radio resource management (RRM) under certain conditions. It enables providing policy-based guidance, ML model management, and enrichment information. The E2 interface then connects the quasi-RT RIC 406 and one or more O-CU-CPs 408, one or more O-CU-UPs 410, and one or more O-DUs 412. You will be able to. The R1 interface may be between rAPPs 212 and the non-RT RIC 404 framework.

[0088] Although not shown in FIG. 4, O-eNB 418 may not support O-DU 412 and O-RU 414 functions with an open fronthaul interface therebetween. The management side includes a SMO system 402 including non-RT-RIC 404 functionality. O-Cloud 416, on the other hand, supports related O-RAN functions (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 a collection of physical infrastructure nodes that meet O-RAN requirements to host appropriate management and orchestration functions. It is a computing platform. As shown in Figure 4, O-RU 414 terminates an open fronthaul M-plane interface towards O-DU 414 and SMO system 402.

[0089] FIG. 5A illustrates O-RAN's quasi-real-time radio intelligent controller (quasi-RT RIC) 512 and non-real-time radio intelligent controller (non-RT RIC) 508 entities, according to an embodiment of the present disclosure. Illustrates an example block diagram representation of mobility robust optimization (MRO) in the field.

[0090] In an embodiment, mobility robustness optimization (MRO) may be performed using non-RT aspects of the MRO function enabled in the non-RT RIC 508. Mobility Robustness Optimization (MRL) may also be performed using quasi-RT aspects of the MRO functionality enabled in quasi-RT RIC 512. Management data analysis services (MDAS) of management entity 504 may track all PM data, events, and error logs as part of FCAPS data associated with all possible cells in a particular geographic location. The FCAPS data at the management entity 504 may be default non-RT in nature. MDAS performs big data analyzes on FCAPS data and can generate one or more data patterns.

[0091] When a cell is appointed, it may have to be configured with initial values for handover parameters for both “idle mode” and “connected mode”. Some of the handover parameters may be broadcast and some other handover parameters may be individually configured during connection establishment. In general, handover parameters can be set to default values or operator-configured values. The MRO rApp 510 in the non-RT RIC 508 may use the data patterns generated by the MDAS and the cell's geographic location to select data patterns. Selected data patterns may be closely applicable to the cell being placed. MRO rApp 510 at non-RT RIC 508 may derive an initial set of values for handover parameters. The derived values may be conveyed to the management entity 504 via internal interfaces of the O-RAN's SMO 502 module. The management entity 504 can configure these values with the appropriate E2 nodes via a successfully established O1 interface during the plug-and-connect or plug-and-play phase of the cell's deployment.

[0092] MRO rApp 510 may also generate handover optimization policies based on the selected data patterns and communicate them to the quasi-RT RIC 512 via the A1 interface. The cell can now be successfully appointed and the E2 interface can be successfully established between the E2 nodes and the quasi-RT RIC 512. MRO xApp 514 may begin collecting quasi-RT measurement data, PM data, and other data from associated E2 nodes. MRO xApp 514 may request the RT data analysis function to generate relevant data analyzes by sharing all of the data collected from 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 to be making changes to the handover parameters at the E2 node, MRO xApp 514 may configure updated values for the handover parameters to the E2 nodes via the E2 interface.

[0093] E2 nodes may capture all MRO-related counters and share the MRO-related counters with the quasi-RT RIC 512. Additionally, E2 nodes may share connection failure indications with the quasi-RT RIC 512 whenever there is reception of handover failure indications from neighboring cells and from UEs.

[0094] Figure 5B shows an example block of mobility robustness optimization (MRO) in the management entity 504 of the O-RAN and the quasi-real-time radio intelligent controller (quasi-RT RIC) 512, according to an embodiment of the present disclosure. also illustrates the expression.

[0095] In an embodiment, mobility robustness optimization (MRO) may be performed using non-RT aspects of the MRO function fully enabled in the management entity 504. Mobility robustness optimization (MRO) may also be performed using quasi-RT aspects of the MRO function enabled in quasi-RT RIC 512. Here, most of the functions of MRO remain the same as described in Figure 5A. However, the entire 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 may derive initial handover parameters and provide them to the E2 nodes via the successfully established O1 interface. The same MRO functional module in management entity 504 may derive handover optimization policies and share them with quasi-RT RIC 512 via the A1 interface. The use of MDAS by the MRO function will be the same as described for Figure 5A.

[0096] Figure 6A illustrates a sequence diagram representation 600a of detection of premature handover during handover execution, according to an embodiment of the present disclosure.

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

[0098] In steps 612-1 and 612-2, the SMO 208 performs the following: Initial handover parameters may be provided to the source cell 604 and target cell 606, respectively. At step 612-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for its optimization function. When the source cell 604 determines that a handover has been triggered for its connected UE 602, the source cell 604 prepares for a handover with the target cell 606 and initiates the handover via an RRC reconfiguration message. Commands may be issued to UE 602. After receiving the handover command, UE 602 may strive for handover access 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 reselect the source cell 604 and initiate the 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. Source cell 604 may conclude this is a premature handover scenario and may increment the premature handover (HO) counter.

[00100] At step 612-5, the source cell 604 determines the occurrence of a premature handover from the quasi-RT RIC 512 to the MRO xApp 514 via the E2 interface by indicating a premature handover detection. You can inform. The premature handover detection indication may carry data about the source cell 604, target cell 606, recent premature handover counters, and other related details. Now, algorithms in the MRO xApp 514 with quasi-RT data analysis functionality can process the data and determine if any modifications may be required to the HO parameters. If there is a need for modifications, MRO Not shown in sequence.

[00101] Figure 6B illustrates a sequence diagram representation 600b of detection of premature handover immediately following successful handover execution, according to an embodiment of the present disclosure.

[00102] In steps 614-1 and 614-2, the SMO 208 connects the source cell 604 and the target cell 606, respectively, during the deployment period via the O1 interface before they begin operation. Initial handover parameters may be provided to both cell 604 and target cell 606. At step 614-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for optimization functions.

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

[00104] In steps 614-4, the source cell 604 may delete the UE context upon receipt of an Xn: UE Context Release message from the target cell 606, as part of a successful HO execution.

[00105] In steps 614-5 and 614-6, upon receipt of the RRC re-establishment request message, the old source cell 604 may transmit an Xn: failure indication message toward the failed cell. The failed cell is the target cell 606 indicated by the UE 602 in the RRC Re-establishment Request message. Target cell 606 may process the received failure indication, analyze the status, and detect premature HO scenarios. At step 614-7, the target cell 606 may send an Xn: Handover Report message to the source cell 604 with the handover report type set to “too early HO”. Upon receiving the handover report message, the source cell 604 may increment the early HO counter. At step 614-8, the source cell 604 may inform the MRO xApp 514 at the quasi-RT RIC 214A via the E2 interface of a premature HO scenario. The “premature handover” detection indication and further process will remain the same as described in the previous scenario.

[00106] FIG. 6C illustrates a sequence diagram representation 600c of detection of premature handover immediately following successful handover execution, in accordance with an embodiment of the present disclosure, where the user equipment (UE) context is an access and mobility management function. It can be removed in cooperation with (AMF).

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

[00108] This scenario is identical to the scenario depicted in FIG. 6B, but the timer TXnRELOC may all 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 AMF 610 for UE 602 context release by sending an NG: UE Context Release Request message. AMF 610 may then grant the NG: UE context release request and send an NG: UE context release command message to the source cell 604. Afterwards, the source cell 604 deletes the UE context and can confirm this to the AMF 610 by sending an NG: UE context release complete message. These sequences are not shown in Figure 6C.

[00109] In steps 616-5 and 616-6, upon receipt of the RRC re-establishment request message, the previous source cell 604 fails as indicated by the UE 602 in the RRC re-establishment request message. An Xn: failure indication message may be transmitted to the cell (target cell 606). Target cell 606 may process the received failure indication, analyze the condition, and detect that it is a premature HO scenario.

[00110] At step 616-7, the target cell 606 may send an Xn: Handover Report message to the source cell 604 with the handover report type set to “too early HO”. Upon receiving the handover report message, the source cell 604 may increment the early HO counter. At step 616-8, source cell 604 may notify MRO xApp 514 in quasi-RT RIC 214A of this occurrence via the E2 interface via a premature handover detection indication. The further process may be the same as described in the previous scenario.

[00111] Figure 6D illustrates a sequence diagram representation 600D of detection of too late handover during handover execution, according to an embodiment of the present disclosure.

[00112] In steps 618-1 and 618-2, the SMO 208 connects the source cell 604 and the target cell 606, respectively, during the deployment period via the O1 interface before they begin operation. Initial handover parameters may be provided to both cell 604 and target cell 606. At step 618-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for its optimization function.

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

[00114] Here, the UE 602 may experience radio link failure with the source cell 604 even before receiving the HO command. At step 618-5, the UE 602 may initiate an RRC re-establishment procedure with the target cell 606, with the cause set to another failure. Since the HO preparation may be successful, the target cell 606 may have a UE context. At step 618-6, upon receipt of 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 too late HO scenario. You can. Additionally, the target cell 606 may transmit an Xn: UE context release message to the source cell 604.

[00115] The source cell 604 may 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 increments the too late HO counter and MRO at the quasi-RT RIC 214A via the E2 interface with a too late handover detection indication. This occurrence can be notified to xApp (514). Additionally, the process in quasi-RT RIC 214A will remain the same as described in the previous scenarios.

[00116] Figure 6E illustrates a sequence diagram representation 600e of detection of too late handover before handover execution, according to an embodiment of the present disclosure.

[00117] In steps 620-1 and 620-2, the SMO 208 connects the source cell 604 and the target cell 606, respectively, during the deployment period via the O1 interface before they begin operation. Initial handover parameters may be provided to both cell 604 and target cell 606. At step 620-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for its optimization function.

[00118] At step 620-4, the UE 602 experiences a radio link failure with the source cell 604 even before any HO preparation and has the cause set to another failure, and the RRC with the target cell 606. The re-establishment procedure may be initiated. Since HO preparation has not yet begun, the target cell 606 may not have a UE context. In steps 620-5 and 620-6, upon receipt of an RRC re-establishment request message from UE 602, the target cell 606 rejects the re-establishment request, indicating a too late HO scenario. , Xn: A failure indication message can be transmitted to the source cell 604.

[00119] The source cell 604 may process the received failure indication, analyze the status, and detect a too-late HO scenario. The source cell 604 may increment the HO too late counter and notify the MRO xApp 514 in the quasi-RT RIC 214A by the E2 interface of the occurrence via the HO too late detection indication. The further process in the quasi-RT RIC 214A will remain the same as described in the previous scenarios.

[00120] FIG. 6F illustrates a sequence diagram representation 600f of detection of a handover to an incorrect cell following successful execution of a handover with an incorrect target cell, according to an embodiment of the present disclosure.

[00121] In steps 622-1 and 622-2, the SMO 208 operates on the source cell 604 and target cell 606, respectively, during the deployment phase after the O1 interface before the source cell 604 and target cell 606 begin operation. Initial handover parameters may be provided to both 604 and target cell 606. At step 622-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for its optimization function.

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

[00123] At step 622-6, the UE 602 may experience radio link failure with the incorrect target cell 606A immediately after successful HO execution due to insufficient or inconsistent strong RF conditions. Therefore, the UE 602 may reselect the actual target cell 606B and trigger the RRC re-establishment procedure with another failure cause set. Upon receipt of the RRC Re-Establishment Request message, the actual target cell 606B may send an there is. The incorrect target cell 606a may process the received failure indication, analyze the status, and detect an HO scenario to the incorrect cell.

[00124] At step 622-7, the incorrect target cell 606A may send an Xn: Handover Report message to the source cell 604 with the handover report type set to “HO to incorrect cell”. Upon receiving the handover report message, the source cell 604 may increment the HO counter to the incorrect cell. At step 622-8, the source cell 604 may notify this occurrence to the MRO The further process can remain the same as described in the previous scenario.

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

[00126] In steps 624-1 and 624-2, the SMO 208 performs the following: Initial handover parameters may be provided to both the source cell 604 and the target cell 606, respectively. At step 624-3, SMO 208 may provide handover optimization policy information to quasi-RT RIC 214A via the A1 interface for its optimization function.

[00127] Here, the UE 602 may experience radio link failure with the incorrect target cell 606A immediately after successful HO preparation, due to insufficient or inconsistent strong RF conditions. Therefore, the UE 602 may reselect the actual target cell 606B and trigger the RRC re-establishment procedure with another failure cause set. In steps 624-4 and 624-5, upon receipt of the RRC re-establishment request message, the actual target cell is the failed cell (source cell 604) indicated by the UE 602 in the RRC re-establishment request message. You can send an Xn: failure indication message to )). Source cell 604 may process the received failure indication, analyze the status, and detect an HO to the wrong cell scenario.

[00128] At step 624-7, the source cell 604 may send an Xn: Handover Cancel message to the incorrect target cell 606A to cancel handover preparation. Additionally, the source cell 604 may increment the HO counter to the incorrect cell. At step 624-8, the source cell 604 may notify this occurrence to the MRO The further process will remain the same as described in the previous scenario.

[00129] Ping-Pong Handover Scenarios: In a ping-pong handover scenario, no radio link failure may occur, but after a successful handover, the UE 602 remains in the handed over cell for a very short duration. You can stay. UE 602 may continue to hop frequently between two cells. Typically, in a ping-pong handover scenario, ping-pong occurs between the same two adjacent cells of the same or different RATs. MRO xApp 514 can detect a ping-pong handover scenario and correct it by optimizing HO parameters. MRO xApp 514 may also propose handover to higher layer cells of the same or different RATs or, if feasible, propose to have dual connectivity between two cells to correct a ping-pong handover scenario.

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

[00131] For example, very fast handover scenarios can occur along rail lines and airplane routes, 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 in which corrections may be required may be detected by MRO xApp 514. MRO xApp 514 may then propose handover to higher layer cells, such as NTN cells.

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

[00133] Processor 770 may include various modules associated with embodiments of the present invention. Communications port 760 may be an RS-232 port, a 10/100 Ethernet port, Gigabit, or 10 Gigabit port using copper or fiber for use with a modem-based dial-up connection, a serial port, a parallel port, or another conventional port. It may be any of the or future ports. 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. Memory 730 may be random access memory (RAM), or any other dynamic storage device commonly known in the art. 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 processor 770. (but not limited to this).

[00134] Mass storage device 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 Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, such as Universal Serial Bus (USB)), available from various vendors. and/or with FireWire interfaces), such as Seagate (e.g., Seagate Barracuda 782 family) or Hitachi (e.g., Hitachi Deskstar13K800), one or more optical disks, redundant array of independent disks (RAID) storage, such as an array of disks. (e.g., but not limited to SATA arrays).

[00135] Bus 720 communicatively couples processor(s) 770 with other memory, storage, and communication blocks. Bus 720 may be used to connect expansion cards, drives, and other subsystems, such as the Peripheral Component Interconnect (PCI)/PCI Expansion (PCI-X) bus, Small Computer System Interface (SCSI), USB, etc. etc., as well as other servers, such as a front side bus (FSB), connecting the processor 770 to the software system.

[00136] Optionally, operator and operational interfaces, such as displays, keyboards, and cursor control devices, may also be coupled to bus 720 to support direct operator interaction with the computer system. Other operator and operational interfaces may be provided through network connections connected through communications port 760. External storage device 710 may be any type of external hard drive, floppy drive, IOMEGA® Zip drive, compact disk-read only memory (CD-ROM), compact disk-rewritable (CD-RW). , it may be a digital video disc-read only memory (DVD-ROM). The components described above are merely intended to exemplify the various possibilities. The example computer systems mentioned above should in no way limit the scope of this disclosure.

[00137] Although considerable emphasis has been placed herein on the preferred embodiments, it will be understood that many embodiments may be made and many changes may 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, whereby the foregoing descriptive matter is implemented by way of example only and not as a limitation. This will be clearly understood.

Advantages of the Present Disclosure

[00138] This disclosure provides systems and methods for optimizing the mobility robustness of a telecommunications network using an open radio access network (O-RAN).

[00139] This disclosure provides systems and methods for realizing mobility robustness optimization (MRO) functionality of a self-optimizing network (SON) in an O-RAN architecture.

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

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

[00142] The present disclosure is intended to help detect and correct connection failures caused by intra-RAT mobility and also provide support for unnecessary inter-system handovers to other radio access technologies (RATs). and methods are provided.

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

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

[00145] This disclosure provides systems and methods for collecting data to facilitate MRO function execution in quasi- and non-RT RIC entities.

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

[00147] The present disclosure provides two mechanisms for realization of MRO functionality in an O-RAN architecture, such as a management entity, MRO implementation in quasi-RT RIC, non-RT RIC entities, and MRO implementation in quasi-RT RIC. Systems and methods are provided.

Reservation of Rights

Portions of the disclosure of this patent document belong to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred to as the owner), including copyright, design, trade name, IC layout design, and/or trade dress protection. (but not limited to) material that is subject to intellectual property rights. The Owner has no objection to facsimile reproduction of any of the patent document or patent disclosure as it appears in the Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. This disclosure relates to O-RAN specifications as given in 3GPP TR 21.905 [1].

Claims (20)

A system for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) for cells in an open radio access network (O-RAN), comprising:
A non-real-time radio access network intelligent controller (non-RT RIC), wherein the non-RT RIC:
processor;
comprising a memory coupled to the processor,
The memory includes processor-executable instructions that, when executed, cause the processor to:
Receive one or more data patterns for the cell from Management Data Analysis Services (MDAS);
select a data pattern for the cell based on the received one or more data patterns;
generate one or more handover optimization policies for the cell based on the selected data pattern;
communicate 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
receive optimized values for handover parameters for the cell from the quasi-RT RIC 512, wherein the optimized values for the handover parameters are configured to receive optimized values for the handover parameters based on the one or more handover optimization policies. Created by quasi-RT RIC (512)—,system. According to claim 1,
The MDAS stores phase modulation (PM) data, events, and error logs received as Fault, Configuration, Accounting, Performance, Security (FCAPS) data associated with cells deployed in a geographical location. A system configured to track and monitor things. According to claim 1,
The system of claim 1, wherein the MDAS is configured to perform big data analyzes on fault, configuration, accounting, performance, and security (FCPAS) data to generate the one or more data patterns. According to claim 1,
The system of claim 1, wherein the cell is provided with initial values for the handover parameters during deployment time via an O1 interface by a management entity. According to clause 4,
The system wherein the cell is provided with initial values for the handover parameters by a management entity during the plug-and-connect phase or plug-and-play phase of the cell's deployment. According to claim 1,
The system of claim 1, wherein the cell is pre-configured with initial values for the handover parameters in idle mode and connected mode. According to claim 1,
The system of claim 1, wherein the selected data pattern corresponds to a geographic location of one or more cells. According to claim 1,
The system of claim 1, wherein the one or more handover optimization policies are communicated by the non-RT RIC to the quasi-RT RIC (512) via an A1 interface. According to claim 1,
The system wherein the handover parameters for the cell include a cell-specific offset value, hysteresis value, time to trigger, and Q offset value. According to claim 1,
The quasi-RT RIC is:
Collect quasi-RT measurement data, phase modulation (PM) data and other data from E2 nodes;
Share the collected data with RT data analysis function;
receive data analyzes from the RT data analysis function based on the collected data;
use the 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;
A system configured to transmit optimized handover parameters to the quasi-RT RIC. A method for realizing mobility robustness optimization (MRO) functionality of a self-organizing network (SON) for cells in an open radio access network (O-RAN), comprising:
Receiving, by the processor, one or more data patterns for a cell from Management Data Analysis Services (MDAS);
selecting, by the processor, a data pattern for the cell based on the received one or more data patterns;
generating, by the processor, one or more handover optimization policies for the cell based on the selected data pattern;
communicating, by the processor, 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, by the processor, optimized values for handover parameters for the cell from the quasi-RT RIC 512, wherein the optimized values for the handover parameters are in accordance with the one or more handover optimization policies. generated by the quasi-RT RIC 512 based on - a method comprising: According to claim 11,
The method of 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, security (FCAPS) data associated with cells deployed in the geographic location. According to claim 11,
The method of claim 1, wherein the MDAS is configured to perform big data analyzes on fault, configuration, accounting, performance, security (FCAPS) data to generate the one or more data patterns. According to claim 11,
The method of claim 1, wherein the cell is provided with initial values for the handover parameters during deployment time via an O1 interface by a management entity. According to claim 11,
The method of claim 1, wherein the cell is provided with initial values for the handover parameters during deployment time via an O1 interface during the plug-and-connect or plug-and-play phase of deployment of the cell by a management entity. According to claim 11,
The method of claim 1, wherein the cell is pre-configured with initial values for the handover parameters in idle mode and connected mode. According to claim 11,
The method of claim 1, wherein the selected data pattern corresponds to a geographic location of one or more cells. According to claim 11,
The method of claim 1, wherein the one or more handover optimization policies are communicated by a non-RT RIC to the quasi-RT RIC (512) via an A1 interface. According to claim 11,
The method of claim 1 , wherein the handover parameters for the cell include a cell-specific offset value, hysteresis value, time to trigger, and Q offset value. According to claim 11,
The quasi-RT RIC is:
Collect quasi-RT measurement data, phase modulation (PM) data and other data from E2 nodes;
Share the collected data with RT data analysis function;
receive data analyzes 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
and transmit the optimized handover parameters to a quasi-RT RIC.