Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0803—Configuration setting
  • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W24/00—Supervisory, monitoring or testing arrangements
  • H04W24/02—Arrangements for optimising operational condition
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/14—Reselecting a network or an air interface
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/24—Reselection being triggered by specific parameters
  • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/34—Reselection control
  • H04W36/38—Reselection control by fixed network equipment
  • H04W36/385—Reselection control by fixed network equipment of the core network
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/0005—Control or signalling for completing the hand-off
  • H04W36/0083—Determination of parameters used for hand-off, e.g. generation or modification of neighbour cell lists
  • H04W36/00837—Determination of triggering parameters for hand-off
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/04—Reselecting a cell layer in multi-layered cells
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W36/00—Hand-off or reselection arrangements
  • H04W36/24—Reselection being triggered by specific parameters
  • H04W36/30—Reselection being triggered by specific parameters by measured or perceived connection quality data
  • H04W36/305—Handover due to radio link failure
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W76/00—Connection management
  • H04W76/20—Manipulation of established connections
  • H04W76/27—Transitions between radio resource control [RRC] states

Definitions

• 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).
• OF-RAN Open Radio Access Network
• HetNets very high-density heterogeneous networks
• Wi-Fi Wireless Fidelity
• HetNets very high-density heterogeneous networks
• 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.
• a SelfOrganizing Network 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.
• PnP Plug-and-Play functionalities
• ANR Automatic Neighbour Relation function
• PCI Physical layer cell identity
• 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.
• MLB Mobility Load Balancing
• MRO Mobility Robustness Optimization
• ES Radio Link Failure Reporting
• CCO Radio Link Failure Reporting
• RET Forward Handover, Frequent Handover Mitigation
• Interference Mitigation Inter-Cell, Intra-Cell, Intra- RAT, Inter- RAT.
• 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.
• 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.
• a Centralized SON may include the function that the SON algorithm executes in the management system.
• a Cross Domain-Centralized SON may include the function that the SON algorithms may execute in the Cross-Domain (CD) layer.
• a Domain- Centralized SON may be the SON algorithm that may execute in the Domain layer.
• a Distributed SON may be the SON algorithm in the NFs.
• Hybrid 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.
• FIG. 1 illustrates an exemplary block diagram representation (100) of a 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.
• RAN Radio Access Network
• gNB-CUs Next Generation NodeB Centralized Units
• gNB-DUs Next Generation NodeB Distributed Units
• the operator may face issues in the deployed HetNet of FIG. 1.
• 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.
• 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.
• 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.
• 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.
• L3-RRM coordination across the neighborg NB-CUs 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 may have an impact on the dynamic resource sharing and allocation.
• 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.
• 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.
• conventional systems and methods may not provide mechanisms to realize the mobility robustness optimization function in an O-RAN Architecture.
• 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).
• O-RAN Open Radio Access Network
• 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.
• MRO Mobility Robustness Optimization
• SON Self Organizing Network
• 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.
• 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).
• Intra-RAT Intra Radio Access Technology
• RATs Radio Access Technologies
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• PM Phase Modulation
• FCAPS Fault, Configuration, Accounting, Performance, Security
• 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.
• 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.
• the Near- RT RIC is configured to transmit the optimized Handover parameters to the Near-RT RIC.
• 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.
• Near-RT RIC Near- Real-Time Radio Access Network Intelligent Controller
• 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).
• 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.
• FCAPS Fault, Configuration, Accounting, Performance, Security
• the MDAS is configured to perform big data analytics on FCAPS data to generate the one or more data patterns.
• 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.
• 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.
• the Near- RT RIC is configured to transmit the optimized Handover parameters to the Near-RT RIC.
• 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.
• Near-RT RIC Near-Real-Time Radio Access Network Intelligent Controller
• FIG. 1 illustrates an exemplary block diagram representation (100) of Fifth Generation 5G Heterogenous Network (HetNet) deployment scenario.
• HetNet Fifth Generation 5G Heterogenous Network
• 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.
• 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.
• SMO Service Management and Orchestration
• FIG. 4 illustrates an exemplary block diagram representation (400) of a system architecture, in accordance with an embodiment of the present disclosure.
• 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.
• MRO Mobility Robustness Optimization
• 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.
• MRO Mobility Robustness Optimization
• Near-RT RIC Near Real-Time Radio Intelligent Controller
• 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.
• 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.
• 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.
• UE User Equipment
• AMF Access and mobility Management Function
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the present disclosure provides systems and methods for optimizing mobility robustness of a telecommunication network using an Open Radio Access Network (O-RAN).
• O-RAN Open Radio Access Network
• 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.
• MRO Mobility Robustness Optimization
• SON Self Organizing Network
• 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).
• RATs Radio Access Technologies
• 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.
• 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.
• 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.
• 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).
• Non-RT RIC Non-Real Time Radio Intelligent Controller
• Near-RT RIC Near-Real Time Radio Intelligent Controller
• 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).
• 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).
• 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).
• 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.
• MRO Mobility Robustness Optimization
• O-RAN Open Radio Access Network
• 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.
• the SMO system (208) may perform the functional split of MRO and the locality of execution of the split MRO.
• 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.
• 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.
• RAT Radio Access Technology
• 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.
• 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.
• the SMO system (208) may optimize the handover parameters applicable for both idle and connected mode mobility scenarios.
• 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.
• MSA Micro-Services Architecture
• a plurality of microservices may be containerized and may be event-based in order to support portability.
• 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.
• the SMO system (208) may be remotely monitored and the data, application, and physical security of the SMO system (208) may be fully ensured.
• 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.
• a communication network 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.
• PSTN Public-Switched Telephone Network
• 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.
• 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 TM, iOS TM, Kai OS TM and the like.
• 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.
• 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
• 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.
• SMO Service Management and Orchestration
• 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.
• 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.
• 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).
• 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).
• 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.
• the machine -readable storage medium may store instructions that, when executed by the processing resource, implement the processing engine(s) (308).
• 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.
• the processing engine(s) (308) may be implemented by electronic circuitry.
• the SMO system (208) may include Machine Learning (ML) modules.
• 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.
• FIG. 4 illustrates an exemplary block diagram representation of the system architecture (400), in accordance with an embodiment of the present disclosure.
• 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).
• 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 include a Non-RT RIC Framework and Non-RT RIC Applications such as the rApps (212).
• 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).
• 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.
• 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.
• 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).
• UMTS Universal Mobile Telecommunications System
• E-UTRA Evolved Universal Mobile Telecommunications System
• O-eNB the O-eNB
• 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.
• 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.
• 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.
• 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.
• FCAPS Fault, Configuration, Accounting, Performance, Security,
• PNF Physical Network Function
• the 02 interface may be between the SMO system (208) and the O- Cloud (416) for supporting 0-RAN virtual network functions.
• 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.
• 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.
• 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) 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.
• the O-RU (414) terminates the Open Fronthaul M-Plane interface towards the O-DU (414) and the SMO system (402).
• 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.
• MRO Mobility Robustness Optimization
• the Mobility Robustness Optimization may be performed using the Non-RT aspects of the MRO functionality enabled in the Non-RT RIC (508).
• the Mobility Robustness Optimization 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.
• a cell 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.
• 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.
• 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.
• 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.
• MRO Mobility Robustness Optimization
• Near-RT RIC Near Real-Time Radio Intelligent Controller
• the Mobility Robustness Optimization 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).
• most of the functionalities of the MRO remain the same as explained in FIG. 5A.
• 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.
• 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.
• 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.
• 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.
• the SMO (208) may provide a handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• 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.
• 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.
• RF Radio Frequency
• 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.
• 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 indication may carry data about the source cell (604), the target cell (606), latest too early handover counts, and other related details.
• 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.
• 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.
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for an optimization functionality.
• 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.
• 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.
• 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.
• 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”.
• the source cell (604) may increment the too early HO counter.
• 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.
• 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.
• UE User Equipment
• AMF Access and Mobility Management Function
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• the timer TXnRELOC may expire before the target cell (606) sends the Xn: UE Context Release message as part of the HO execution.
• 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).
• 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.
• 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.
• 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”.
• the source cell (604) may increment the too early HO counter.
• 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.
• 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.
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• 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).
• the UE (602) may experience the radio link failure with the source cell (604) even before receiving the HO command.
• 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.
• 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).
• 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 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.
• 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.
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• 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.
• 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.
• 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.
• 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.
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• 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.
• 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.
• 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.
• 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”.
• the source cell (604) may increment the HO to the wrong cell counter.
• 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.
• 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.
• 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.
• the SMO (208) may provide the handover optimization policy information to the Near-RT RIC (214A) via the Al interface, for its optimization functionality.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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, FortiSOCTM system on chip processors, or other future processors.
• 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.
• PROM Programmable Read Only Memory
• 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.
• PATA Parallel Advanced Technology Attachment
• SATA Serial Advanced Technology Attachment
• USB Universal Serial Bus
• Firewire interfaces e.g. those available from Seagate (e.g., the Seagate Barracuda 782 family)
• 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.
• PCI Peripheral Component Interconnect
• PCI-X PCI Extended
• SCSI Small Computer System Interface
• FFB front side bus
• operator and administrative interfaces e.g. a display, keyboard, and a cursor control device
• bus (720) 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).
• CD-ROM Compact Disc - Read Only Memory
• CD-RW Compact Disc-Re- Writable
• DVD-ROM Digital Video Disk-Read Only Memory
• the present disclosure provides systems and methods for optimizing mobility robustness of a telecommunication network using an Open Radio Access Network (O-RAN).
• OF-RAN Open Radio Access Network
• 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.
• MRO Mobility Robustness Optimization
• SON Self Organizing Network
• 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).
• RATs Radio Access Technologies
• 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.
• 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.
• 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.
• 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, and the Near RT RIC.
• 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).
• JPL Jio Platforms Limited
• 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].

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=85322726

Family Applications (1)

Country Status (5)

Family Cites Families (2)

• 2022
  • 2022-08-23 JP JP2023520002A patent/JP2024533918A/ja active Pending
  • 2022-08-23 WO PCT/IB2022/057876 patent/WO2023026177A1/en active Application Filing
  • 2022-08-23 CN CN202280006692.3A patent/CN116325868A/zh active Pending
  • 2022-08-23 EP EP22860734.7A patent/EP4315929A1/de active Pending
  • 2022-08-23 KR KR1020237010282A patent/KR20230132438A/ko active Search and Examination

Also Published As

Similar Documents

Legal Events