WO2023026177A1

WO2023026177A1 - Systems and methods for optimizing mobility robustness of a telecommunication network

Info

Publication number: WO2023026177A1
Application number: PCT/IB2022/057876
Authority: WO
Inventors: Satish Nanjunda Swamy Jamadagni; Mahesh Nayaka Mysore ANNAIAH; Mathew Oommen
Original assignee: Jio Platforms Limited
Priority date: 2021-08-23
Filing date: 2022-08-23
Publication date: 2023-03-02
Also published as: JP2024533918A; CN116325868A; EP4315929A1; KR20230132438A

Abstract

The present disclosure generally relates to wireless telecommunication networks, and more particularly relates to systems and methods for optimizing mobility robustness of a telecommunication network using an Open Radio Access Network (O-RAN). The system and method realize the Mobility Robustness Optimization (MRO) functionality of Self Organizing Networks (SON) in an O-RAN architecture and data collection interworking methods. The O-RAN architecture has two distinct entities called the Near-Real Time Radio Intelligent Controller (Near-RT RIC (210)) and the Non-Real Time Radio Intelligent Controller (Non-RT RIC (214A)) for a functional split for MRO and the related functional flows between the two entities. The system collects data to facilitate the MRO functional execution in the Near-RT RIC and Non-RT RIC entities.

Description

SYSTEMS AND METHODS FOR OPTIMIZING MOBILITY ROBUSTNESS OF A TELECOMMUNICATION NETWORK

FIELD OF INVENTION

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

BACKGROUND OF THE INVENTION

[0002] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0003] In general, as cellular networks evolve from Fourth Generation (4G), Fifth Generation (5G) and then to Six Generation (6G) along with other radio access technologies such as Wireless Fidelity (Wi-Fi), mobile subscriptions may also be exponentially increasing. Hence, mobile operators may be forced to deploy very high-density heterogeneous networks (HetNets) to fulfil the demands of subscribers. The HetNets may be generally built by multiportfolio and multi-vendor-based solutions. One of the key challenges that the operators face during greenfield or brownfield deployments of the HetNets may be the demand for high quality installations. Another challenge lies in the continuous monitoring of performance and health of deployed networks. Dynamic adaptation to changing environments is also an issue and so is proactive adjustments and optimization.

[0004] The aforementioned challenges may demand very high manual work and delay due to regular/frequent field visits and may lead to additional operational expenses. To overcome these deficiencies and drastically reduce Operational Expenses (OPEX), a SelfOrganizing Network (SON) can be used. The SON may be a Self-Organizing Network or a Self- Optimizing Network. The SON may be an automation technology that may enable the network to set itself up and self-manage resources and configuration to achieve optimal performance. The SON may function under three categories. The first category is selfconfiguration. Self-configuration may aid in seamlessly integrating into the network through an automatic configuration of key parameters. Self-configuration is the most valuable during initial network deployments. It includes several capabilities such as Plug-and-Play functionalities [PnP], Automatic Neighbour Relation function [ANR], and Physical layer cell identity [PCI] selection and conflict resolution functions.

[0005] The second category is self-optimization. Self-optimization aids in enhanced network performance through near real-time optimization of radio and network configurations. Self-optimization is valuable throughout the lifetime of the network. Selfoptimization includes various capabilities such as Mobility Load Balancing [MLB], Mobility Robustness Optimization [MRO], RACH Optimization, Energy Saving [ES], Radio Link Failure Reporting, Coverage and Capacity Optimization [CCO], [DL Power control, RET], Forward Handover, Frequent Handover Mitigation [FHM], and Interference Mitigation. [Inter-Cell, Intra-Cell, Intra- RAT, Inter- RAT].

[0006] The third category is self-healing. Self-healing allows adjacent cells to maintain network quality in case a cell/sector fails, providing resiliency (reliability) in the face of unforeseen outage conditions. Self-healing is valuable throughout the lifetime of the network. Self-healing includes various capabilities such as Cell Outage Detection. [Dead/Sick/Sleeping cell/sector/beam], Cell Outage Recovery, Cell Outage Compensation, and Cell Outage Compensation Recovery.

[0007] Minimization of Drive Test (MDT) functionality may have been designed to operate independently from the SON, although its functionalities are reused wherever possible. The above SON functions may be handled by SON algorithms either individually or in groups. The SON algorithms may perform the functionalities like monitoring the network(s) by collecting management data including MDAS data and analysis of the management data to determine if there are issues in the network(s) that need to be resolved. The SON algorithms may also decide on the SON actions to resolve the issues and execute the SON actions for resolution. Further, the SON algorithms may evaluate whether the issues have been resolved by analyzing the management data.

[0008] Based on the location of the SON algorithm, the SON may be categorized into four different solutions that may be possible for implementing various SON use cases. The solution may be selected depending on the needs of the SON use cases. A Centralized SON (C-SON) may include the function that the SON algorithm executes in the management system. A Cross Domain-Centralized SON (CD C-SON) may include the function that the SON algorithms may execute in the Cross-Domain (CD) layer. Further, a Domain- Centralized SON (D C-SON) may be the SON algorithm that may execute in the Domain layer. Furthermore, a Distributed SON (D-SON) may be the SON algorithm in the NFs. [0009] Thereafter, a Hybrid SON (H-SON) may be the SON algorithm that may be executed at two or more levels like the NF layer, Domain layer, or Cross Domain (CD) layer. Since the SON algorithms are according to implementation, different vendors may choose different approaches for their SON solutions. Some vendors may choose the C-SON approach, some may choose the D-SON approach and others may choose the H-SON approach-based solutions. The operators may inevitably use multivendor solutions while deploying HetNets.

[0010] FIG. 1 illustrates an exemplary block diagram representation (100) of a 5G HetNet deployment scenario. In the 5G HetNet deployment scenario, the operator may use the management entities like Network Management System (NMS) from a different vendor and a set of Element Management System (EMSes) from a different set of vendors. The operator may also use the management entities like Radio Access Network (RAN) nodes such as Next Generation NodeB Centralized Units (gNB-CUs) from a different set of vendors and Next Generation NodeB Distributed Units (gNB-DUs) from a different set of vendors. The operator may face issues in the deployed HetNet of FIG. 1. One of the issues is that D- SON of gNB-CU-1 (116) and gNB-CU-2 (124) may not coordinate well as both are from different vendors, though they communicate each other via an open Xn interface.

[0011] Another issue is that D-SON of gNB-CU-2 (124) and the Hybrid SON of gNB-CU-n (130)(D-SON + DC-SON) may not coordinate well as both are from different vendors, though they communicate with each other via the open Xn interface. A key issue is that C-SON can be realized as either collocated with management entities [Like EMS/NMS] or as a standalone entity. Integrating the C-SON as a standalone entity with RAN nodes is extremely difficult, as the interface is left to implementation. Moreover, CD C-SON in the NMS (106) may impact the performance of the D C-SON and D-SON functionalities, operating in the multi-vendor environment.

[0012] Another issue lies in integrating the 3rd party SON solutions partially in the HetNet which leads to degradation of the overall Key Performance Indicators (KPIs). Further, L3-RRM coordination across the neighborg NB-CUs (116, 124, 130) may be lacking irrespective of the same or multivendor scenarios, which will have an impact on the overall KPI performance.L3-RRM and L2-RRM coordination across the multi-vendor gNB-CU (116, 124, 130) and gNB-DUs (118, 120, 122, 126, 128, 132) may have an impact on the dynamic resource sharing and allocation.

[0013] The SON and Radio Resource Management (RRM), being a proprietary implementation, have a significant impact on the overall performance while multiple vendors coordinate with one other across the Xn interface. Each algorithm behaves differently and has its own limitations. Even if the vendors are ready to integrate with the third-party solutions [SON and/or RRM], the vendors may not deterministically quantify/confirm the output performance, mainly due to the vendors’ solutions. Such a situation always ends with a clash among the agreed vendors. One possible solution to resolve these issues or limitations may be to make the interface between SON solutions and the interacting Radio Access Network (RAN) nodes an open interface as much as possible. An Open Radio Access Network (O- RAN) alliance may be a worldwide community of mobile network operators, vendors, and research and academic institutions operating in the RAN industry.

[0014] The O-RAN alliance mission may be to re-shape the RAN industry towards more intelligent, open, virtualized, and fully interoperable mobile networks. The new O-RAN standards may enable a more competitive and vibrant RAN supplier ecosystem with faster innovation to improve user experience. O-RAN -based mobile networks will at the same time improve the efficiency of RAN deployments as well as operations by the mobile operators. However, conventional systems and methods may not provide mechanisms to realize the mobility robustness optimization function in an O-RAN Architecture.

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

OBJECTS OF THE PRESENT DISCLOSURE

[0016] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.

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

[0018] An object of the present disclosure is to provide systems and methods for realizing the Mobility Robustness Optimization (MRO) functionality of Self Organizing Network (SON) in an O-RAN architecture.

[0019] An object of the present disclosure is to provide systems and methods for a functional split between different entities in an O-RAN architecture and the associated data/control flow mechanisms. [0020] An object of the present disclosure is to provide systems and methods to provide locality of execution of the split MRO aspects.

[0021] An object of the present disclosure is to provide systems and methods to provide support for detecting and helping to correct connection failures caused by Intra Radio Access Technology (Intra-RAT) mobility and also for unnecessary inter-system handovers to other Radio Access Technologies (RATs).

[0022] An object of the present disclosure is to provide systems and methods to address scenarios such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, and so on.

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

[0024] An object of the present disclosure is to provide systems and methods to collect data for facilitating the MRO functional execution in the Near and Non-RT RIC entities.

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

[0026] An object of the present disclosure is to provide systems and methods of two mechanisms for the realization of the MRO function in the 0-RAN architecture such as MRO implementation in the Near-RT RIC, Non-RT RIC entities, and MRO implementation in the management entity and the Near-RT RIC.

SUMMARY

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

[0028] In an aspect, the present disclosure provides a system for realizing the Mobility Robustness Optimization (MRO) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (0-RAN). The system comprises a Non-Real- Time Radio Access Network Intelligent Controller (non-RT RIC) that is configured to receive one or more data patterns for a cell from a Management Data Analytics Services (MDAS). The MDAS is configured to keep 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 in a geographical location. The MDAS is configured to perform big data analytics on FCAPS data to generate the one or more data patterns.

[0029] Further, the Non-RT RIC of the system selects a data pattern for the cell based on the received one or more data patterns. The cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface. The cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface during a Plug-n-Connect phase or a Plug-n- Play phase of a deployment of the cell. The selected data pattern corresponds to a geographical location of one or more cells. The cell is pre-configured with initial values for the handover parameters in idle mode and connected mode. The one or more handover optimization policies are conveyed by the Non-RT RIC to the Near-RT RIC (512) via an Al interface. The handover parameters for the cell comprise a cell individual offset value, a hysteresis value, a time to trigger, and a Q offset value.

[0030] The Near-RT RIC is configured to collect Near-RT measurement data, Phase Modulation (PM) data and other data from E2 nodes. The Near-RT RIC is further configured to share the collected data with RT data analytics function. The Near-RT RIC is further configured to receive data analytics from the RT data analytics function based on the collected data. The Near-RT RIC is further configured to use the one or more handover optimization policies received from the Non-RT RIC based on the received data analytics. The Near-RT RIC is further configured to derive optimized values for the Handover parameters based on the one or more handover optimization policies. Furthermore, the Near- RT RIC is configured to transmit the optimized Handover parameters to the Near-RT RIC.

[0031] Further, the Non-RT RIC of the system generates one or more handover optimization policies for the cell based on the selected data pattern. Further, the Non-RT RIC of the system conveys the one or more handover optimization policies of the cell to a Near- Real-Time Radio Access Network Intelligent Controller (Near-RT RIC) associated with the system. Further, the Non-RT RIC of the system receives optimized values for handover parameters for the cell from the Near-RT RIC, wherein the optimized values for handover parameters are generated by the Near-RT RIC based on the one or more handover optimization policies.

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

[0033] Further, the method includes selecting a data pattern for the cell based on the received one or more data patterns. The cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface. The cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface during a Plug-n-Connect phase or a Plug-n-Play phase of a deployment of the cell. The selected data pattern corresponds to a geographical location of one or more cells. The cell is pre-configured with initial values for the handover parameters in idle mode and connected mode. The one or more handover optimization policies are conveyed by the Non-RT RIC to the Near-RT RIC (512) via an Al interface. The handover parameters for the cell comprise a cell individual offset value, a hysteresis value, a time to trigger, and a Q offset value.

[0034] The Near-RT RIC is configured to collect Near-RT measurement data, Phase Modulation (PM) data and other data from E2 nodes. The Near-RT RIC is further configured to share the collected data with RT data analytics function. The Near-RT RIC is further configured to receive data analytics from the RT data analytics function based on the collected data. The Near-RT RIC is further configured to use the one or more handover optimization policies received from the Non-RT RIC based on the received data analytics. The Near-RT RIC is further configured to derive optimized values for the Handover parameters based on the one or more handover optimization policies. Furthermore, the Near- RT RIC is configured to transmit the optimized Handover parameters to the Near-RT RIC.

[0035] Further, the method includes generating one or more handover optimization policies for the cell based on the selected data pattern. Further, the method includes conveying the one or more handover optimization policies of the cell to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC) associated with the system. Further, the method includes receiving optimized values for handover parameters for the cell from the Near-RT RIC, wherein the optimized values for handover parameters are generated by the Near-RT RIC based on the one or more handover optimization policies. BRIEF DESCRIPTION OF DRAWINGS

[0036] The accompanying drawings, which are incorporated herein, and constitute a part of this invention, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that invention of such 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 Fifth Generation 5G Heterogenous Network (HetNet) deployment scenario.

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

[0039] FIG. 3 illustrates an exemplary representation (300) of the proposed Service Management and Orchestration (SMO) system for optimizing mobility robustness of a telecommunication network using an Open Radio Access Network (O-RAN), in accordance with an embodiment of the present disclosure.

[0040] FIG. 4 illustrates an exemplary block diagram representation (400) of a system architecture, in accordance with an embodiment of the present disclosure.

[0041] FIG. 5A illustrates an exemplary block diagram representation (500a) of Mobility Robustness Optimization (MRO) in a Near-Real-Time Radio Intelligent Controller (Near-RT RIC), Non-Real-Time Radio Intelligent Controller (Non-RT RIC) entities of the O- RAN, in accordance with 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 and a Near Real-Time Radio Intelligent Controller (Near-RT RIC) entity of the O-RAN, in accordance with an embodiment of the present disclosure.

[0043] FIG. 6A illustrates a sequence diagram representation (600a) of detection of too early handover during handover execution, in accordance with an embodiment of the present disclosure. [0044] FIG. 6B illustrates a sequence diagram representation (600b) of detection of too early handover immediately after successful handover execution, in accordance with an embodiment of the present disclosure.

[0045] FIG. 6C illustrates a sequence diagram representation (600c) of detection of too early handover immediately after successful handover execution, in which User Equipment (UE) context deleted in co-ordination with Access and mobility Management Function (AMF), in accordance with an embodiment of the present disclosure.

[0046] FIG. 6D illustrates a sequence diagram representation (600d) of detection of too late handover during handover execution, in accordance with an embodiment of the present disclosure.

[0047] FIG. 6E illustrates a sequence diagram representation (600e) of detection of too late handover before handover execution, in accordance with an embodiment of the present disclosure.

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

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

[0050] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present invention can be utilized, in accordance with embodiments of the present disclosure.

[0051] The foregoing shall be more apparent from the following more detailed description of the invention.

DETAILED DESCRIPTION OF INVENTION

[0052] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. [0053] The ensuing description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It 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 given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0055] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0056] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive — in a manner similar to the term “comprising” as an open transition word — without precluding any additional or other elements.

[0057] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

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

[0059] The present disclosure provides systems and methods for optimizing mobility robustness of a telecommunication network using an Open Radio Access Network (O-RAN). The present disclosure provides systems and methods for realizing the Mobility Robustness Optimization (MRO) functionality of the Self Organizing Network (SON) in an O-RAN architecture. The present disclosure provides systems and methods for a functional split between different entities in an O-RAN architecture and the associated data/control flow mechanisms. The present disclosure provides systems and methods to provide locality of execution of the split MRO aspects. The present disclosure provides systems and methods to provide support for detecting and helping to correct connection failures caused by Intra-RAT mobility and also for unnecessary Inter-system handovers to other Radio Access Technologies (RATs). The present disclosure provides systems and methods to address the scenarios such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, and so on. The present disclosure provides systems and methods to resolve issues such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, and so on by optimizing the HO parameters such as cell individual offset, hysteresis, time to trigger, Q offset, and so on.

[0060] The present disclosure also provides systems and methods to collect data for facilitating the MRO functional execution in the Near- and Non-RT RIC entities. The present disclosure provides systems and methods to optimize the HO parameters applicable for both idle and connected mode mobility scenarios. The present disclosure provides systems and methods of two mechanisms for the realization of the MRO function in the O-RAN architecture such as MRO implementation in the Near RT RIC, Non-RT RIC entities, and MRO implementation in the management entity, the Near RT RIC.

[0061] Referring to FIG. 2 that illustrates an exemplary network architecture (200) for optimizing mobility robustness (also referred to as network architecture (200)) in which or with which a Service Management and Orchestration (SMO) system (208) or simply referred to as the SMO system (208) of the present disclosure can be implemented, in accordance with 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) associated with the SMO system (208), and a Near-Real Time Radio Intelligent Controller (Near-RT RIC) (214A). The Non-RT RIC (210) and the Near-RT RIC (214A) may be configured for facilitating mobility robustness optimization based on schemes received from users (228-1, 228-2, 228-3,... , 228-N) (individually referred to as the user (228) and collectively referred to as the users (228)) associated with one or more mobile computing devices (224-1, 224-2,. .. ,224-N) (individually referred to as the computing device (224) and collectively referred to as the computing devices (224)). The SMO system (208) may be further operatively 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 communicatively coupled to the one or more computing devices (224).

[0062] Further, the Non-RT RIC (210) may include rApps (212) and the Near-RT RIC (214A) may include xApps (214B). The SMO system (208) and the Near-RT RIC (214A) may be coupled to an Open Radio Access Network Distributed Unit (O-DU) (206). The O-DU (206) may be coupled to an Open Radio Access Network Central Unit Control Plane (O-CU-CP) (216) and an Open Radio Access Network Central Unit User Plane (O-CU- UP) (218). The Near-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). Further, the O- CU-CP (216) may be coupled to the Fifth-Generation (5G) Core (5GC) (220) and the O-CU- UP (218) may be coupled to a User Plane Function (UPF) (222).

[0063] In an embodiment, the SMO system (208) may realize the Mobility Robustness Optimization (MRO) functionality of the Self Organizing Network (SON) in an Open Radio Access Network (O-RAN) architecture and the data collection interworking methods. The O-RAN architecture may have two distinct entities, the Near-RT RIC (214A) and the Non-RT RIC (210), in which the functional split for the MRO and the related functional flows between the two entities may be implemented.

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

[0065] In an embodiment, the SMO system (208) may collect data to facilitate the MRO functional execution in the Near-RT RIC (214A) and the Non-RT RIC (210)entities.

[0066] In an embodiment, the SMO system (208) may detect and correct connection failures caused by Intra- Radio Access Technology (RAT) mobility and unnecessary intersystem handovers to other RATs.

[0067] In an embodiment, the SMO system (208) may address 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, and the like.

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

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

[0070] In an embodiment, an onsite data capture, storage, matching, processing, decision-making, and actuation logic may be coded using Micro-Services Architecture (MSA) but not limited to it. A plurality of microservices may be containerized and may be event-based in order to support portability.

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

[0072] In an embodiment, the SMO system (208) may be remotely monitored and the data, application, and physical security of the SMO system (208) may be fully ensured. In an embodiment, the data may get collected meticulously and deposited in a cloud-based data lake to be processed to extract actionable insights. Therefore, the aspect of predictive maintenance can be accomplished.

[0073] In an exemplary embodiment, a communication network (not shown in FIG. 1) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. A network may include, by way of example but not limitation, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet- switched network, a circuit- switched 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, some combination thereof.

[0074] In another exemplary embodiment, a server (not shown in FIG. 1) may be included in the architecture (200). The Near-RT RIC (214A) and the SMO system (208) may be implemented on a server. The server may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server- side functionality as described herein, at least a portion of any of the above, some combination thereof.

[0075] In an embodiment, the one or more computing devices (224) and the one or more mobile computing devices (not shown in FIG. 1) may communicate with the SMO system (208) via a set of executable instructions residing on any operating system, including but not limited to, Android ™, iOS ™, Kai OS ™ and the like. In an embodiment, one or more computing devices (224) and the one or more mobile computing devices may include, but not limited to, any electrical, electronic, electro-mechanical or any equipment or a combination of one or more of the above devices such as mobile phone, smartphone, Virtual Reality (VR) devices, Augmented Reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device, wherein the computing device may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as camera, audio aid, a microphone, a keyboard, input devices for receiving input from a user such as a touch pad, a touch-enabled screen, electronic pen, receiving devices for receiving any audio or visual signal in any range of frequencies and transmitting devices that can transmit any audio or visual signal in any range of frequencies. It may be appreciated that the one or more first computing devices (224), and the one or more mobile computing devices may not be restricted to the mentioned devices and various other devices may be used. A smart computing device may be one of the appropriate systems for storing data and other private/sensitive information. [0076] FIG. 3 illustrates an exemplary representation (300) of the proposed Service Management and Orchestration (SMO) system (208)for optimizing mobility robustness of telecommunication network using an Open-RAN (O-RAN), in accordance with an embodiment of the present disclosure. In an 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 circuitries, and/or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (302) may be configured to fetch and execute computer-readable instructions stored in a memory (304) of the SMO system (208). The memory (304) may store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory (304) may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.

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

[0078] The processing unit/engine(s) (308) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processing engine(s) (308). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, programming for the processing engine(s) (308) may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processing engine(s) (308) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine -readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (308). In such examples, the SMO system (208) may comprise the machine -readable storage medium storing the instructions and the processing resource to execute the instructions, 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 electronic circuitry. Further, 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 a data acquisition engine (312), 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 an edgebased micro service event processing but not limited to the like.

[0080] FIG. 4 illustrates an exemplary block diagram representation of the system architecture (400), in accordance with an embodiment of the present disclosure.

[0081] The system architecture (400) is an O-RAN architecture. The rApps (212) may have an interface where external information can be fed to the Operator network. The Near- RT RIC (406) may be a logical function that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over an E2 interface, as shown in FIG. 4. The Near-RT RIC (406) may include an/a Artificial Intelligence (Al)/ Machine Learning (ML) workflow including model training, inference, and updates which are handled by the xApps (214B).

[0082] Further, the Non-RT RIC (404) may include a logical function within the Service Management and Orchestration system (SMO) (402), that may drive the content carried across an Al interface, as shown in FIG. 4. The Non-RT RIC (404) may includea Non-RT RIC Framework and Non-RT RIC Applications such as the rApps (212). Furthermore, the Non-RT RIC framework may function internal to the SMO system (402) and may logically terminate the Al interface to the Near-RT RIC (406). The Non-RT RIC framework may also expose a set of internal SMO services needed for their runtime processing, to the rApps (212), via a R1 interface. The Non-RT RIC framework may function within the Non-RT RIC (404) and may provide an/a AI/ML workflow including model training, inference and updates needed for rApps (412).

[0083] Further, anOl interface from the O-RAN components may terminate at the SMO system (402). The O-CU-CP (408) may be a logical node hosting the Radio Resource Control (RRC) and the control plane part of the Packet Data Convergence Protocol (PDCP) protocol. Further, the O-CU-UP (410) may be a logical node hosting the user plane part of the PDCP protocol and the Service Data Adaptation Protocol (SDAP) protocol. The O-DU (412) may be a logical node hosting Radio Link Control (RLC)/Medium Access Control (MAC)/High-Physical (PHY) layers based on a lower layer functional split. The E2 node may be a logical node terminating at the E2 interface. Further, the O-RAN nodes that may be terminating at the E2 interface are for NR access at the O-CU-CP (408), the O-CU-UP (410), the O-DU (412) or any combination, and for an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (E-UTRA) access such as the O-eNB (418).

[0084] The Non-RT RIC applications such as the rApps (212) may be modular applications that leverage the functionality exposed via the R1 interface of the Non-RT RIC frameworkto provide value-added services relative to RAN operation. The value-added services relative to the RAN operation may include, but not limited to, driving the Al interface, recommending values and actions that may be subsequently applied over the 01/02 interface, and generating “enrichment information (El)” for the use of the rApps (212), and the like. 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] The rApps (212) may also provide policy-based guidance to the applications/features in the Near-RT RIC (406). Further, the Near-RT RIC applications such as the xApps (214B) may run on the Near-RT RIC (406). The xApps (214B) may likely consist of one or more microservices and at the point of on-boarding may identify which data it consumes and which data it provides. The xApps (214B) may be independent of the Near- RT RIC (406) and may be provided by any third party. The E2 interface may enable a direct association between the xApps (214B) and the RAN functionality.

[0086] Further, an O-Cloud (416)may be a cloud computing platform that may include a collection of physical infrastructure nodes. The nodes may meet the 0-RAN requirements to host the relevant 0-RAN functions of the Near-RT RIC (405), the O-CU-CP (408), the O-CU-UP (410), and the 0-DU (412), supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.) and the appropriate management and orchestration functions. In addition, the 01 interface may exist between the SMO system (208) and O-RAN-managed elements for operation and management. The 01 interface may enable Fault, Configuration, Accounting, Performance, Security, (FCAPS) management, Physical Network Function (PNF) software management, and file management. [0087] Further, the 02 interface may be between the SMO system (208) and the O- Cloud (416) for supporting 0-RAN virtual network functions. Furthermore, theAl interface between the Non-RT RIC (404) and the Near-RT RIC (406) may enable the Non-RT RIC function to provide policy-based guidance, ME model management, and enrichment information to the Near-RT RIC function so that the RAN can optimize the Radio Resource Management (RRM) under certain conditions. Thereafter, the E2 interface may be to connect the Near-RT RIC (406) and the one or more O-CU-CPs (408), the one or more O-CU-Ups (410), and the one or more O-DUs (412). The R1 interface may be between the rApps (212) and the Non-RT RIC (404) framework.

[0088] Although not shown in FIG. 4, the O-eNB (418) may not support the O-DU (412) and the O-RU (414) functions with an Open Fronthaul interface between them. The management side includes the SMO system (402) containing a Non-RT-RIC (404) function. The O-Cloud (416), on the other hand, is a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions (such as Near-RT RIC (406), O-CU-CP (408), O-CU-UP (410) and O-DU (412) etc.), the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.) and the appropriate management and orchestration functions. As shown in FIG. 4, the O-RU (414) terminates the Open Fronthaul M-Plane interface towards 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 Near Real-Time Radio Intelligent Controller (Near- RT RIC) (512) and the Non-Real-Time Radio Intelligent Controller (Non-RT RIC) (508) entities of the O-RAN, in accordance with an embodiment of the present disclosure.

[0090] In an embodiment, the Mobility Robustness Optimization (MRO) may be performed using the Non-RT aspects of the MRO functionality enabled in the Non-RT RIC (508). The Mobility Robustness Optimization (MRO) may also be performed using the Near- RT aspects of the MRO functionality enabled in the Near-RT RIC (512). A Management Data Analytics Services (MDAS) of the management entity (504) may track all the PM data, events, and error logs received as part of the FCAPS data associated with all possible cells in a particular geographical location. The FCAPS data at the management entity (504) may be by default Non-RT in nature. The MDAS may perform big data analytics on the FCAPS data and generate one or more data patterns.

[0091] When a cell is being commissioned, it may have to be configured with initial values for handover parameters both for the “idle mode” and the “connected mode”. Some of the handover parameters may get broadcasted while a few other handover parameters may get configured individually during the connection establishment. Generally, the handover parameters may either be set to default values or to operator-configured values. An MRO rApp (510) in the Non-RT RIC (508) may use the data patterns generated by the MDAS and a geographical location of the cell to choose the data patterns. The selected data patterns may be closely applicable for the cell being deployed. The MRO rApp (510) in the Non-RT RIC (508) may derive an initial set of values for the handover parameters. The derived values may be conveyed to the management entity (504) via internal interfaces of the O-RAN’s SMO (502) module. The management entity (504) may configure these values to the appropriate E2 Nodes via the successfully established 01 interface, during the Plug-n-Connect or Plug-n- play phase of the deployment of the cell.

[0092] The MRO rApp (510), may also generate the handover optimization policies based on the chosen data patterns and convey them to the Near-RT RIC (512) via the Al interface. Now the cell may be successfully commissioned and the E2 interface maybe successfully established between E2 nodes and the Near-RT RIC (512).An MRO xApp (514) may start collecting Near-RT measurement data, PM data, and other data from the associated E2 nodes. The MRO xApp (514) may request the RT data analytics function to generate relevant data analytics by sharing all the data collected from the E2 Nodes. When the MRO xApp (514) receives the requested data analytics, it may use the policies received from the Non-RT RIC (508) and derives new values for the Handover parameters. If it is reckoned to make changes to the Handover parameters at the E2 node, the MRO xApp (514) may configure the updated values for the handover parameters to the E2 nodes via the E2 interface.

[0093] The E2 Nodes may capture all MRO-related counters and share the MRO- related counters with the Near-RT RIC (512). Also, the E2 Nodes may share the connection failure indications with the Near-RT RIC (512), whenever there is a reception of Handover failure indications from neighboring cells and from the UEs.

[0094] FIG. 5B illustrates an exemplary block diagram representation of the Mobility Robustness Optimization (MRO) in the management entity (504) and the Near Real-Time Radio Intelligent Controller (Near-RT RIC) (512) entity of the O-RAN, in accordance with an embodiment of the present disclosure.

[0095] In an embodiment, the Mobility Robustness Optimization (MRO) may be performed using the Non-RT aspects of the MRO functionality that may be completely enabled in the management entity (504). The Mobility Robustness Optimization (MRO) may also be performed using the Near-RT aspects of the MRO functionality enabled in the Near- RT RIC (512). Here, most of the functionalities of the MRO remain the same as explained in FIG. 5A. However, the entire Non-RT aspects of the MRO functionality may be enabled within the management entity (504) only. The MRO function module within the management entity (504) may derive and provide the initial handover parameters to the E2 nodes via the successfully established 01 Interface. The same MRO function module of the management entity (504) may derive the handover optimization policies and share the same with the Near- RT RIC (512) via the Al interface. The usage of the MDAS by the MRO function will be the same as explained for FIG. 5A.

[0096] FIG. 6A illustrates a sequence diagram representation (600a) of detection of too early handover during handover execution, in accordance with an embodiment of the present disclosure.

[0097] A radio link failure may occur in a target cell (606) immediately after a handover may get completed. The radio link failure may also occur during a handover procedure execution when a UE (602) may attempt to re-establish a radio link in a source cell (604). FIG. 6A illustrates the scenario which may occur during the handover execution, when the UE (602) may not be able to access the target cell (606) successfully.

[0098] At steps (612-1) and (612-2), the SMO (208) may provide the initial handover parameters to the source cell (604) and the target cell (606), respectively, during their deployment phase via the 01 interface after which source cell (604) and the target cell (606) start operating. At step (612-3), the SMO (208) may provide a handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality. When the source cell (604) may decide to trigger a handover for its connected UE (602), the source cell (604) may prepare the handover with the target cell (606) and issue a handover command to the UE (602) via an RRC reconfiguration message. After receiving the handover command, the UE (602) may try for a handover access with the target cell (606) but may fail due to insufficiency of strong Radio Frequency (RF) conditions.

[0099] As a result, at step (612-4), the UE (602) may reselect 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 become successful, and the UE (604) may continue to be in the connected state. The source cell (604) may conclude this as atoo early handover scenario and may increment atoo early handover (HO) counter.

[00100] At step (612-5), the source cell (604) may intimate the occurrence of the too early handover to the MRO xApp (514) at the Near-RT RIC (512) via the E2 interface by a too early handover detected indication. The too early handover detected indicationmay carry data about the source cell (604), the target cell (606), latest too early handover counts, and other related details. Now, algorithms in the MRO xApp (514) along with the Near-RT data analytics function may process the data and check whether any modifications may be needed for the HO parameters. If there may be a need for modifications, the MRO xApp (514) may command the updated HO parameters to the source cell (604) in particular and/or other cells in general, via the E2 nodes and the E2 interface, which is not shown in the sequence. [00101] FIG. 6B illustrates a sequence diagram representation (600b) of detection of a too early handover immediately after a successful handover execution, in accordance with an embodiment of the present disclosure.

[00102] At steps (614-1) and (614-2), the SMO (208) may provide initial handover parameters to both the source cell (604) and the target cell (606), respectively, during the deployment phase via the 01 interface after which the source cell (604) and the target cell (606) start operating. At step (614-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for an optimization functionality.

[00103] Here, the UE (602) may experience the radio link failure with the target cell (606) immediately after the successful HO execution, due to insufficient or inconsistent strong RF conditions. Hence 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] At steps (614-4), the source cell (604) may have deleted the UE context at the reception of the Xn: UE context release message from the target cell (606), as part of the successful HO execution.

[00105] At steps (614-5) and (614-6), at the reception of an RRC re-establishment request message, the previous source cell (604) may send an Xn: failure Indication message towards a 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 on the received failure indication, analyse the condition, and detect a too early HO scenario. At 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”. At the reception of the handover report message, the source cell (604) may increment the too early HO counter. At step (614-8), the source cell (604) may intimate the too early HO scenario to the MRO xApp (514) at the Near-RT RIC (214A) via the E2 interface. The “too early handover” detected indication and the further process may remain the same as explained in the earlier scenario.

[00106] FIG. 6C illustrates a sequence diagram representation (600c) of detection of too early handover immediately after successful handover execution, in which the User Equipment (UE) context may be deleted in coordination with an Access and Mobility Management Function (AMF), in accordance with an embodiment of the present disclosure.

[00107] At steps (616-1) and (616-2), the SMO (208) may provide the initial handover parameters to both the source cell (604) and the target cell (606), respectively, during their deployment phase via 01 interface and the source cell (604) and the target cell (606) start operating. At step (616-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.

[00108] This scenario is that same as the scenario depeicted in FIG. 6B, however, the timer TXnRELOC overall may expire before the target cell (606) sends the Xn: UE Context Release message as part of the HO execution. At an expiry of the timer, the source cell (604) may request the AMF (610) for the UE (602) context release by sending an NG: UE context release request message. The AMF (610) may then admit the NG: UE context release request and send an NG: UE context release command message to the source cell (604). Then, the source cell (604) may delete the UE context and confirm the same to the AMF (610) by sending the NG: UE context release complete message. These sequences have not been shown in FIG. 6C.

[00109] At steps (616-5) (616-6), at the reception of the RRC re-establishment request message, the previous source cell (604) may send the Xn: failure Indication message towards the failure cell (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 condition, and detect that it is a too early HO scenario.

[00110] At step (616-7), the target cell (606) may send the Xn: handover report message to the source cell (604) with the handover report type set to “Too Early HO”. At the reception of the handover report message, the source cell (604) may increment the too early HO counter. At step (616-8), the source cell (604) may intimate this occurrence to the MRO xApp (514) at the Near-RT RIC (214A) via the E2 interface via the too early handover detected indication. The further process may be the same as explained in the earlier scenario.

[00111] FIG. 6D illustrates a sequence diagram representation (600d) of detection of too late handover during handover execution, in accordance with an embodiment of the present disclosure.

[00112] At steps (618-1) and (618-2), the SMO (208) may provide the initial handover parameters to both the source cell (604) and the target cell (606), respectively, during the deployment phase via the 01 interface after which the source cell (604) and the target cell (606) start operating. At step (618-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality. [00113] At step (618-4), the 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 the target cell (606).

[00114] Here, the UE (602) may experience the radio link failure with the source cell (604) even before receiving the HO command. At step (618-5), the UE (602) may initiate the 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 be having the UE context. At step (618-6), at the reception of the RRC re-establishment request message from the same UE (602), the target cell (606) may send the Xn: failure Indication message to the source cell (604), indicating the too late HO scenario. Also, the target cell (606) may send the Xn: UE context release message to the source cell (604).

[00115] The source cell (604) may process the received failure indication, analyze the condition, and detect the too late HO scenario. At step (618-7) and (618-8), the source cell (604) may increment the too late HO counter and intimate this occurrence to the MRO xApp (514) at the Near-RT RIC (214A) via the E2 interface via the too late handover detected indication. Further, the process at the Near-RT RIC (214A) may remain the same as explained in the earlier scenarios.

[00116] FIG. 6E illustrates a sequence diagram representation (600e) of detection of too late handover before handover execution, in accordance with an embodiment of the present disclosure.

[00117] At steps (620-1) and (620-2), the SMO (208) may provide the initial handover parameters to both the source cell (604) and the target cell (606), respectively, during the deployment phase via the 01 interface after which the source cell (604) and the target cell (606) start operating. At step (620-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.

[00118] At step (620-4), the UE (602) may experience the radio link failure with the source cell (604) even before any HO preparation and initiate the RRC re-establishment procedure with the target cell (606), with the cause set to another failure. Since the HO preparation may not have been initiated yet, the target cell (606) may not be having the UE context. At step (620-5) and (620-6), at the reception of the RRC re-establishment request message from the UE (602), the target cell (606) may reject the re-establishment request and send the Xn: failure indication message to the source cell (604), indicating the too late HO scenario. [00119] The source cell (604) may process the received failure indication, analyze the condition, and detect the too late HO scenario. The source cell (604) may increment the too Late HO counter and intimate the occurrence to the MRO xApp (514) at the Near-RT RIC (214A) by the E2 interface via the too late HO detected indication. The further process at the Near-RT RIC (214A) may remain the same as explained in the earlier scenarios.

[00120] FIG. 6F illustrates a sequence diagram representation (600f) of detection of handover to a wrong cell after a successful handover execution with a wrong target cell, in accordance with an embodiment of the present disclosure.

[00121] At steps (622-1) and (622-2), the SMO (208) may provide the initial handover parameters to both the source cell (604) and the target cell (606), respectively, during the deployment phase via the 01 interface after which the source cell (604) and the target cell (606) start operating. At step (622-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.

[00122] The 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 which is not the source cell nor the target cell.

[00123] At step (622-6), the UE (602) may experience the radio link failure with the wrong target cell (606 A) immediately after the successful HO execution, due to the insufficient or inconsistent strong RF condition. Hence the UE (602) may reselect the real target cell (606B) and trigger the RRC re-establishment procedure with the cause set to the other failure. At the reception of the RRC Re-establishment Request message, the real target cell (606B) may send the 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 (606 A) may process the received failure indication, analyze the condition, and detect that the HO to the wrong cell scenario.

[00124] At step (622-7) the wrong target cell (606A), may send the Xn: handover report message to the source cell (604) with the handover report type set to “HO to wrong cell”. At the reception of the Handover report message, the source cell (604) may increment the HO to the wrong cell counter. At step (622-8), the source cell (604) may intimate this occurrence to the MRO xApp (514) at the Near-RT RIC (214A) by the E2 interface via the Handover to the wrong cell detected indication. Further process may remain the same as explained in the earlier scenario. [00125] FIG. 6G illustrates a sequence diagram representation (600g) of detection of handover to the wrong cell after successful handover preparation with the wrong target cell, in accordance with an embodiment of the present disclosure.

[00126] At steps (624-1) and (624-2), the SMO (208) may provide the initial handover parameters to both the source cell (604) and the target cell (606), respectively, during their deployment phase via 01 interface after which the source cell (604) and the target cell (606) start operating. At step (624-3), the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.

[00127] Here, the UE (602) may experience the radio link failure with the wrong target cell (606A) immediately after the successful HO preparation, due to the insufficient or inconsistent strong RF condition. Hence the UE (602) may reselect the real target cell (606B) and trigger the RRC re-establishment procedure with the cause set to the other failure. At step (624-4) and (624-5), on the reception of the RRC re-establishment request message, the real target cell may send the Xn: failure indication message towards 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 condition, and detect the HO to the wrong cell scenario.

[00128] At step (624-7), the source cell (604) may send the Xn: handover cancel message to the wrong target cell (606A) to cancel the handover preparation. Also, the source cell (604) may increment the HO to the wrong cell counter. At step (624-8) the source cell (604) may intimate this occurrence to the MRO xApp (514) at the Near-RT RIC (214A) by the E2 interface via the Handover to wrong cell detected indication. The further process may remain the same as explained in the earlier scenario.

[00129] Ping-pong handover scenarios: In a ping-pong handover scenario, no radio link failure may occur, but after the successful handover, the UE (602) may stay in the handed over cell for a very short duration. The UE (602) may continue to hop between the two cells frequently. Normally, in the ping-pong handover scenario the ping-pong happens between the same two adjacent cells of the same or different RATs. The MRO xApp (514) may detect the ping-pong handover scenario and correct it by optimizing the HO parameters. The MRO xApp (514) may also propose to handover to the higher layer cells of the same or different RATs or if feasible, propose to have dual connectivity between the two cells to correct the ping-pong handover scenario. [00130] Fast or very fast handover scenarios: In a fast or very fast handover scenario may be similar to the ping-pong handover scenario. In the 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 mobility speed of the UE. The MRO xApp (514) may have to detect the fast or very fast handover scenario and distinguish the scenarios that may be inevitable and those that may be corrected.

[00131] For example, the very fast handover scenario may occur along railway lines and airplane paths by using ground-to-air communications, and along guarded highways etc. Such very fast handover scenarios may be inevitable. Here, corrections may not be needed. The scenarios, where corrections may be needed may be detected by the MRO xApp (514). The MRO xApp (514) may then propose to handover to the higher layer cells like NTN cells. [00132] FIG. 7 illustrates an exemplary computer system (700) in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present disclosure. As shown in FIG. 7, the computer system (700) can include an external storage device (710), a bus (720), a main memory (730), a read only memory 740, a mass storage device (750), communication port (760), and a processor (770). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. Examples of the processor (770) include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on chip processors, or other future processors.

[00133] The processor (770) may include various modules associated with embodiments of the present invention. Communication port (760) can be any of a RS-232 port for use with a modem-based dialup 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 chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which computer system connects. The memory (730) can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (740) can be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or BIOS instructions for processor 770.

[00134] The mass storage (750) may be any current or future mass storage solution, which can be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 782 family) or Hitachi (e.g., the Hitachi Deskstarl3K8OO), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors.

[00135] The bus (720) communicatively couples the processor(s) (770) with the other memory, storage, and communication blocks. The bus (720) can be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB, or the like, for connecting expansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects processor (770) to software system.

[00136] Optionally, operator and administrative interfaces, e.g. a display, keyboard, and a cursor control device, may also be coupled to bus (720) to support direct operator interaction with a computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port (760). The external storage device (710) can be any kind of external harddrives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc-Re- Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM). The components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.

[00137] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter to be implemented merely as illustrative of the invention and not as limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE

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

[00139] The present disclosure provides systems and methods for realizing the Mobility Robustness Optimization (MRO) functionality of Self Organizing Network (SON) in an O-RAN architecture. [00140] The present disclosure provides systems and methods for a functional split between different entities in an O-RAN architecture and the associated data/control flow mechanisms.

[00141] The present disclosure provides systems and methods to provide locality of execution of the split MRO aspects.

[00142] The present disclosure provides systems and methods to provide support for detecting and helping to correct connection failures caused by Intra-RAT mobility and also for unnecessary inter-system handovers to other Radio Access Technologies (RATs).

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

[00144] The present disclosure provides systems and methods to resolve issues such as too early handover, too late handover, handover to wrong cells, ping-pong handovers, fast handovers, very fast handovers, and so on by optimizing the HO parameters such ascell individual offset, hysteresis, time to trigger, Q offset, and so on.

[00145] The present disclosure provides systems and methods to collect data for facilitating the MRO functional execution in the Near and the Non-RT RIC entities.

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

[00147] The present disclosure provides systems and methods of two mechanisms for the realization of the MRO function in the O-RAN architecture such as MRO implementation in the Near RT RIC, Non-RT RIC entities, and MRO implementation in the management entity, and the Near RT RIC.

RESERVATION OF RIGHTS

A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, IC layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. The present disclosure may pertain to O-RAN specifications as given in 3GPP TR 21.905 [1].

Claims

29 We Claim:

1. A system for realizing the Mobility Robustness Optimization (MRO) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN), the system comprising: a Non-Real-Time Radio Access Network Intelligent Controller (non-RT RIC), wherein the non-RT RIC comprises: a processor; a memory coupled to the processor, wherein the memory comprises processor-executable instructions, which on execution, causes the processor to: receive one or more data patterns for a cell from a Management Data Analytics 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; convey the 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 receive optimized values for handover parameters for the cell from the Near-RT RIC (512), wherein the optimized values for handover parameters are generated by the Near-RT RIC (512) based on the one or more handover optimization policies.

2. The system as claimed in claim 1, wherein the MDAS is configured to keep track of and monitor Phase Modulation (PM) data, events, and error logs received as Fault, Configuration, Accounting, Performance, Security (FCAPS) data associated with the cell deployed in a geographical location.

3. The system as claimed in claim 1, wherein the MDAS is configured to perform big data analytics on Fault, Configuration, Accounting, Performance, Security (FCAPS) data to generate the one or more data patterns.

4. The system as claimed in claim 1, wherein the cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface. 30

5. The system as claimed in claim 4, wherein the cell is provided by a management entity with initial values for the handover parameters during a Plug-n- Connect phase or a Plug-n-Play phase of the deployment of the cell.

6. The system as claimed in claim 1, wherein the cell is pre-configured with initial values for the handover parameters in idle mode and connected mode.

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

8. The system as claimed in claim 1, wherein the one or more handover optimization policies are conveyed by the Non-RT RIC to the Near-RT RIC (512) via an Al interface.

9. The system as claimed in claim 1, wherein the handover parameters for the cell comprise a cell individual offset value, a hysteresis value, a time to trigger, and a Q offset value.

10. The system as claimed in claim 1, wherein the Near-RT RIC is configured to: collect Near-RT measurement data, Phase Modulation (PM) data and other data from E2 nodes; share the collected data with RT data analytics function; receive data analytics from the RT data analytics 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 analytics; derive optimized values for the Handover parameters based on the one or more handover optimization policies; and transmit the optimized Handover parameters to the Near-RT RIC.

11. A method for realizing the Mobility Robustness Optimization (MRO) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN), the method comprising: receiving, by a processor, one or more data patterns for a cell from a Management Data Analytics 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; conveying, by the processor, the 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 receiving, by the processor, optimized values for handover parameters for the cell from the Near-RT RIC (512), wherein the optimized values for handover parameters are generated by the Near-RT RIC (512) based on the one or more handover optimization policies.

12. The method as claimed in claim 11, wherein the MDAS is configured to keep 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 in a geographical location.

13. The method as claimed in claim 11, wherein the MDAS is configured to perform big data analytics on Fault, Configuration, Accounting, Performance, Security (FCAPS) data to generate the one or more data patterns.

14. The method as claimed in claim 11, wherein the cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface.

15. The method as claimed in claim 11, wherein the cell is provided by a management entity with initial values for the handover parameters during a deployment phase via an 01 interface during a Plug-n-Connect phase or a Plug-n-Play phase of a deployment of the cell.

16. The method as claimed in claim 11, wherein the cell is pre-configured with initial values for the handover parameters in idle mode and connected mode.

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

18. The method as claimed in claim 11, wherein the one or more handover optimization policies are conveyed by the Non-RT RIC to the Near-RT RIC (512) via an Al interface.

19. The method as claimed in claim 11, wherein the handover parameters for the cell comprise a cell individual offset value, a hysteresis value, a time to trigger, and a Q offset value.

20. The method as claimed in claim 11, wherein the Near-RT RIC is configured to: collect Near-RT measurement data, Phase Modulation (PM) data and other data from E2 nodes; share the collected data with RT data analytics function; receive data analytics from the RT data analytics 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 analytics; derive optimized values for the Handover parameters based on the one or more handover optimization policies; and transmit the optimized Handover parameters to the Near-RT RIC.