WO2023031744A1 - Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation - Google Patents

Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation Download PDF

Info

Publication number
WO2023031744A1
WO2023031744A1 PCT/IB2022/058001 IB2022058001W WO2023031744A1 WO 2023031744 A1 WO2023031744 A1 WO 2023031744A1 IB 2022058001 W IB2022058001 W IB 2022058001W WO 2023031744 A1 WO2023031744 A1 WO 2023031744A1
Authority
WO
WIPO (PCT)
Prior art keywords
ric
cell
load
nodes
reports
Prior art date
Application number
PCT/IB2022/058001
Other languages
English (en)
Inventor
Satish Nanjunda Swamy Jamadagni
Mahesh Nayaka Mysore ANNAIAH
Mathew Oommen
Original Assignee
Jio Platforms Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jio Platforms Limited filed Critical Jio Platforms Limited
Priority to CN202280006683.4A priority Critical patent/CN116325866A/zh
Priority to KR1020237010281A priority patent/KR20230131169A/ko
Publication of WO2023031744A1 publication Critical patent/WO2023031744A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/16—Performing reselection for specific purposes
    • H04W36/22—Performing reselection for specific purposes for handling the traffic
    • 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
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0883—Load balancing or load distribution between entities in ad-hoc networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0925—Management thereof using policies
    • H04W28/0942—Management thereof using policies based on measured or predicted load of entities- or links
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0958—Management thereof based on metrics or performance parameters
    • 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/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/0085—Hand-off measurements
    • 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

Definitions

  • the embodiments of the present disclosure generally relate to telecommunication deployment. More particularly, the present disclosure relates to systems and methods for enabling mobility load balancing of self-organising networks in an Open Radio Access Network (O-RAN).
  • OF-RAN Open Radio Access Network
  • Load balancing is a methodical and efficient distribution of network or application traffic across multiple servers in a server farm. Each load balancer sits between different types of cell combinations and receives and distributes incoming requests to any available server capable of fulfilling them.
  • a modem mobile communications network comprises a combination of different cell types and different access technologies.
  • 4G 4th generation
  • 5G 5th generation
  • 6G 6th generation
  • WiFi Wireless Fidelity
  • mobile subscriptions also increase exponentially.
  • the deployment and load balancing of very high- density heterogeneous networks (HetNets) also increase to fulfill the demands of the increasing number of subscribers.
  • the HetNets are generally built by Multi-Portfolio and Multi- Vendor-based solutions.
  • the operator facesmultiple challenges during greenfield or brownfield deployments of HetNets.
  • One of the challenges is the demand for high-quality installations that covers continuous monitoring of performance and health of the deployed networks.
  • dynamically adapting to changing environments and making proactive adjustments and optimization are also challenging for mobile operators.
  • the SON may be a Self-Organizing Network or a SelfOptimizing 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-configurationis 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.
  • Self- optimization includes various capabilities such as Mobility Load Balancing (MLB), Mobility Robustness Optimization (MRO), Random Access Channel (RACH) Optimization, Energy Saving (ES), Radio Link Failure Reporting, Coverage and Capacity Optimization (CCO), Data Link (DL) Power control, Remote Electrical Tilt (RET), Forward Handover, Frequent Handover Mitigation (FHM]), and Interference Mitigation (Inter-Cell, Intra-Cell, Intra Radio Access Technology (Intra-RAT), Inter Radio Access Technology (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.
  • SON algorithms perform the functionalities like Monitoring the network(s) by collecting management data including Management Data Analytics Services (MDAS) data, Analysis of the management data to determine if there are issues in the network(s) that need to be resolved, decision on the SON actions to resolve the issues, execution the SON actions and Evaluation of whether the issues have been solved by analysing the management data.
  • MDAS Management Data Analytics Services
  • SON is categorized into four different solutions that are possible for implementing various SON use cases, the solution is selected depending on the needs of the SON use cases.
  • MDT Minimization of Drive Test
  • 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.
  • 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.
  • a Domain- Centralized SON (D C-SON) may be the SON algorithm that may execute in the Domain layer.
  • D-SON Distributed SON
  • D-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 Network Function (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. 2A illustrates a typical 5G HetNet deployment scenario wherein management entities like Network Management System (NMS) from a different vendor, a set of Element Management Systems (EMSes) from a different set of vendors, Radio Access Network (RAN) nodes like Next Generation NodeB (gNB)-Control units (CU) from a different set of vendors, and gNB -distributed units (DU) from a different set of vendors.
  • NMS Network Management System
  • EMSes Element Management Systems
  • RAN Radio Access Network
  • gNB Next Generation NodeB
  • CU Next Generation NodeB
  • DU gNB -distributed units
  • D-SON of gNB-CU-2 (124) and the Hybrid SON of gNB-CU-n (130) (D-SON + D C-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 (such as EMS or 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-Radio Resource Management (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.
  • RRM Radio Resource Management
  • O-RAN alliance is a worldwide community of mobile network operators, vendors, and research and academic institutions operating in the Radio Access Network (RAN) industry.
  • RAN ALLIANCE’S mission is to re-shape the RAN industry towards more intelligent, open, virtualized, and fully interoperable mobile networks.
  • the new O-RAN standards will 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.
  • FIG. 2 illustrates the logical Architecture defined by the O-RAN.
  • the radio side includes Near-Real Time (RT) RAN Intelligent controller (224) (RIC), O-RAN Central Unit Control Plane (O-CU-CP) (228), O-RAN Central Unit-User Plane (O-CU-UP) (230), O-RAN Distributed Unit (O-DU) (232-1), and O-RAN Radio Unit (O-RU) (232-2) functions.
  • the E2 interface connects Evolved Node B (O-eNB) to Near Real-Time RAN Intelligent Controller (Near-RT RIC).
  • O-eNB Evolved Node B
  • Near-RT RIC Near-Time RAN Intelligent Controller
  • the O-eNB does support O-DU and O-RU functions with an Open Fronthaul interface between them.
  • the management side includes Service and Management Orchestration (SMO) Framework containing a Non Real-Time RAN Intelligent Controller (Non-RT-RIC) function.
  • SMO Service and Management Orchestration
  • Non-RT-RIC Non Real-Time RAN Intelligent Controller
  • the ORAN-Cloud (O-Cloud) (234) 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, O-CU- CP, O-CU-UP, and O-DU, 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 terminates the Open Fronthaul M-Plane (236) interface towards the O-DU and SMO.
  • the traditional approaches have many limitations.
  • the mobile subscription is exponentially increasing, the data demand is becoming very high for each subscriber.
  • Wi-Fi Access points AP
  • the operator is densely deploying the Wi-Fi Access Points which may operate at 2.4GHz, 5GHz, and even at higher frequencies.
  • the operator is forced to use multivendor solutions to deploy in its network for the scenarios like carrier-grade Wi-Fi, enterprise Wi-Fi, Mi-Fi, Home Wi-Fi, etc.
  • the interference is becoming a crucial issue to deal with.
  • An object of the present disclosure is to provide a system and methods for realizing the Mobility Load Balancing (MLB) functionality of SON in an 0-RAN architecture.
  • MLB Mobility Load Balancing
  • An object of the present disclosure is to provide a system and method for enabling data collection and interworking methods thereof.
  • An object of the present disclosure is to provide a system and method for facilitating functional split for MLB and the related functional flows between the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the Non-Real Time Radio Intelligent Controller (Non-RT RIC).
  • Near-RT RIC Near-Real Time Radio Intelligent Controller
  • Non-RT RIC Non-Real Time Radio Intelligent Controller
  • An object of the present disclosure is to provide a system and method that cover the locality of execution of the MLP function including a possible split between the gNB (called the E2 node in the 0-RAN Architecture), Non-RT RIC, and the Near RT RIC.
  • An object of the present disclosure is to provide a system and method that facilitate specific mechanisms of data collection to facilitate the MLB functional execution in the Near and Non-RT RIC entities.
  • the present disclosure provides a system for realizing Mobility Load Balancing (MLB) 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 transmit a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC.
  • the resource status request is transmitted to the one or more E2 nodes via an E2 interface.
  • the Non-RT RIC of the system receives load information of the cell from the one or more E2 nodes based on the transmitted resource status request.
  • the Non-RT RIC of the system obtains reports from the one or more E2 nodes based on the collected load information.
  • the reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipments (UEs) associated with the cell.
  • the reports obtained from the one or more E2 nodes further comprise a measurement of the load information.
  • the measurement of the load information is performed by one or more E2 nodes.
  • the Non-RT RIC of the system transmits the obtained reports to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC).
  • the reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure.
  • the Non-RT RIC of the system receives a Handover (HO) Trigger value from the Near-RT RIC based on the reports.
  • the HO Trigger value is received from the Near-RT RIC via an E2 interface.
  • the Non-RT RIC of the system reduces a load of the cell based on the modified HO Trigger value.
  • the load of the cell is restored by the Near- RT RIC when the load of the cell becomes less than an average load within a given time.
  • the Near-RT RIC is configured to receive reports based on load information of the cell. Further, the Near-RT RIC offloads the cell based on the received reports to one or more neighbour cells.
  • the Near-RT RIC obtains load information from the one or more neighbour cells. Further, the Near-RT RIC generates a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information. Further, the Near-RT RIC transmits the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell.
  • the one or more neighbour cells have cell load less than an average load within a given time period.
  • the present disclosure provides a method for realizing Mobility Eoad Balancing (MEB) functionality of Self Organizing Network (SON) for a cell in an open Radio Access Network (O-RAN).
  • the method includes transmitting a resource status request to one or more E2 nodes, wherein the one or more E2 nodes of an E2 interface are in communication with the Non-RT RIC.
  • the resource status request is transmitted to the one or more E2 nodes via an E2 interface.
  • the method includes receiving load information of the cell from the one or more E2 nodes based on the transmitted resource status request.
  • the method includes obtaining reports from the one or more E2 nodes based on the collected load information.
  • the reports obtained from the one or more E2 nodes comprise a Radio Resource status (RR), a Composite Available Capacity Group (CACG), a Slice Available Capacity (SliAC), and a number of Active User Equipment (UEs) associated with the cell.
  • RR Radio Resource status
  • CACG Composite Available Capacity Group
  • the reports obtained from the one or more E2 nodes further comprise a measurement of the load information.
  • the measurement of the load information is performed by one or more E2 nodes.
  • the method includes transmitting the obtained reports to a Near-Real-Time Radio Access Network Intelligent Controller (Near-RT RIC).
  • the reports are conveyed to the Near-RT RIC periodically via an F1AP Resource Status Initiation procedure.
  • the method includes receiving a Handover (HO) Trigger value from the Near-RT RIC based on the reports.
  • the HO Trigger value is received from the Near-RT RIC via an E2 interface.
  • the method include sreducing a load of the cell based on the modified HO Trigger value.
  • the load of the cell is restored by the Near-RT RIC when the load of the cell becomes less than an average load within a given time.
  • the Near-RT RIC is configured to receive reports based on load information of the cell. Further, the Near-RT RIC offloads the cell based on the received reports to one or more neighbour cells. Further, the Near-RT RIC obtains load information from the one or more neighbour cells. Further, the Near-RT RIC generates a Handover (HO) Trigger value for the one or more neighbour cells based on the obtained load information. Further, the Near-RT RIC transmits the generated Handover (HO) Trigger value to an O-CU-CP for reconfiguration of one or more user equipments associated with the cell. The one or more neighbour cells have a cell load less than an average load within a given time period.
  • FIG. 1 illustrates an exemplary network architecture (100) in which or with which the proposed system of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure.
  • FIGs. 2A and 2B illustrate exemplary representations (200 and 220) of existing HetNet deployment and the components associated with it, in accordance with an embodiment of the present disclosure.
  • FIG. 3 illustrates an exemplary block diagram representation (300) of system architecture, in accordance with an embodiment of the present disclosure.
  • FIG. 4 illustrates an exemplary MLB xApp [UC-1] representation (400) highlighting a tentative sequence flow for collecting load information for the serving cell from the associated E2 nodes in accordance with an embodiment of the present disclosure.
  • FIG. 5 illustrates an exemplary MLB xApp [UC-1] representation (500) highlighting flow for processing on load information for the serving cell received from the associated E2 nodes. in accordance with an embodiment of the present disclosure.
  • FIG. 6 illustrates an exemplary MLB xApp [UC-1] representation (600) of a tentative sequence flow for restoring to normal condition, post the MLB offload in accordance with an embodiment of the present disclosure.
  • FIG. 7 is an illustrated embodiment (700) of an alternative deployment scenario for MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure.
  • FIG. 8 illustrates an exemplary MLB xApp [UC-2] representation (800) of a tentative sequence flow for configuring load information collection across Xn interface in accordance with an embodiment of the present disclosure.
  • FIG. 9 illustrates an exemplary MLB xApp [UC-2] representation (900) of a tentative sequence flow for collecting and post processing of received load information across Xn interface in accordance with an embodiment of the present disclosure.
  • FIG. 10 is an illustrated embodiment of a Functional block diagram (1000) for MLB support at Non-RT RIC in accordance with an embodiment of the present disclosure.
  • FIG. 11 illustrates an exemplary representation (1100) of a sequence flow of data across different O-RAN entities for MLB support in accordance with an embodiment of the present disclosure.
  • FIG. 12 is an illustrated embodiment (1200) of a Functional Architecture for MLB support across SMO and E2 Node only in accordance with an embodiment of the present disclosure.
  • FIG. 13 is an illustrated embodiment (1300) of a Functional Architecture for MLB support across SMO and E2 Node only, excluding Non-RT RIC in accordance with an embodiment of the present disclosure.
  • FIG. 14 illustrates an exemplary computer system (1400) in which or with which embodiments of the present invention can be utilized, in accordance with embodiments of the present disclosure.
  • 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.
  • 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 invention provides a system for realizing afirst set of instructions (interchangeably referred to as Mobility Load Balancing (MLB) functionality) of SON in an O-RAN architecture and the data collection interworking methods thereof.
  • the O-RAN architecture has at least two entities called the Near-Real Time Radio Intelligent Controller (Near-RT RIC) and the Non-Real Time Radio Intelligent Controller (Non-RT RIC).
  • the method mayfurther provide for a functional split for the MLB and related functional flows between at least two entities.
  • the method may further ensure locality of execution of the MLB including a possible split between a gNB (interchangeably referred to as the E2 node in the O-RAN Architecture), the Non-RTRIC, and the Near-RT RIC.
  • the methods and system may further provide for data collection to facilitate the MLB functional execution in the Near and Non-RT RIC entities.
  • FIG. 1 illustrates an exemplary network architecture for a self-organizing network (100) (also referred to as network architecture (100)) in which or with which a Service Management and Orchestration (SMO) system (110) or simply referred to as the system (110) of the present disclosure can be implemented, in accordance with an embodiment of the present disclosure.
  • the exemplary network architecture (100) may be equipped with Non-Real Time Radio Intelligent Controller (Non-RT RIC) (122) associated with the SMO system (110), and Near-Real Time Radio Intelligent Controller (Near-RT RIC) (124) communicatively coupled to the SMO system (110) for the SON.
  • Non-RT RIC Non-Real Time Radio Intelligent Controller
  • Near-RT RIC Near-Real Time Radio Intelligent Controller
  • the SMO system (110) may be communicatively coupled to a plurality of first computing devices (102-1, 102-2, 102-3... 102-N) (interchangeably referred to as user equipment (102-1, 102-2, 102-3... 102-N) and (individually referred to as the user equipment (UE) (124) and collectively referred to as the UE (102)) through a second computing devices (104-1, 104-2,. . . 104-N) (interchangeably referred to as the base station (104-1, 104-2,. . .
  • the SMO (110) may be further communicatively coupled to the one or more third computing devices (106) (interchangeably referred to as gNB distributed units (DU) or gNB DU 106), and one or more fourth computing devices (116) (interchangeably referred to as gNB control units (CU) or gNB CU 116).
  • the one or more fourth computing devices (116) may be communicatively coupled to a plurality of fifth computing devices (118) (interchangeably referred to as first nodes (118) hereinafter).
  • the first, second, third, fourth, and fifth computing devices may pertain to a plurality of neighbor cells or a serving cell.
  • the Serving cell and the plurality of Neighbor cells may be spread across a plurality ofCUs (116) and a plurality of DUs(106).
  • a first interface also referred to as the Xn interface hereinafter
  • the SMO (110) may be configured to execute a first set of instructions (interchangeably referred to as the mobility load balancing or MLB hereinafter).
  • the MLB when executed, may manage data acquisition from the plurality of the first, second, third, fourth, and fifth computing devices associated with the Near-RT RIC (124).
  • the MLB implementation in the Near-RT RIC (124) may architecturally cover the data collection mechanisms when the plurality of neighbor cells is across thesame Near- RT RIC (124).
  • the serving cell and the neighbor cells may be under different Near-RT RIC, wherein each cell is associated with a different near RT RIC and may be spread across different CUs (116) and different O-DUs (106).
  • the Xn interface may not be used here for collecting the data.
  • the SMO system (110) and the Near-RT RIC (124) may be a System on Chip (SoC) system but not limited to the like.
  • SoC System on Chip
  • 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 to support portability.
  • the network architecture (100) may be modular and flexible to accommodate any kind of changes in the SMO system (110), and the Near-RT RIC (124).
  • the SMO system (110) and the Near-RT RIC (124) configuration details can be modified on the fly.
  • the SMO system (110) may be remotely monitored and the data, application, and physical security of the SMO system (110) 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.
  • the MLB may be split between the Near-RT RIC and the Non-RT RIC and the SMO may play a key role for MLB SON feature support.
  • the MLB may be split between the SMO and the gNB node (not shown in FIG. 1 and interchangeably referred to as the E2 node hereinafter), across an open second interface (interchangeably referred to as the 01 interface hereinafter).
  • a communication network (108) 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
  • the centralized server (112) may be included in architecture (100).
  • the centralized server (112) 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 first computing devices (124), the one or more mobile devices (not shown in FIG. 1) may communicate with the SMO system (108) via 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 first computing devices (124) and the one or more mobile devices may include, but not limited to, any electrical, electronic, electro-mechanical or an 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 touch pad, 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 touch pad, touch enabled screen, electronic pen
  • FIG. 3 illustrates an exemplary block diagram representation (300) of a system architecture, in accordance with an embodiment of the present disclosure.
  • the serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-ql) are under the same Near-RT RIC (302).
  • the serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304- p2, 304-ql) may be spread across different O-CU-CPs (308-1, 308-2, 308-n) and different O- DUs (314-1, 314-2,. .
  • the Xn interface may not be used for load information collection for MLB support.
  • Cell-1 301-l
  • Th-U Threshold
  • the subset of the plurality of neighbor cells may be assumed to have a cell load below a Lower Threshold [Th-L], which are the candidate cells to offload.
  • FIG. 4 illustrates an exemplary MLB xApp [UC-1] representation (400) highlighting a tentative sequence flow for collecting load information for the serving cell from the associated E2 nodes in accordance with an embodiment of the present disclosure.
  • the tentative sequence flow for a cell context creation at the Near-RT RIC (406) where Cell-lmay be successfully commissioned (408).
  • the cell may collect the load information from the associated E2 nodes by triggering the Resource Status Request (414) to the E2 nodes via E2 interface.
  • the E2 nodes may perform measurements (422) and may report the measured load information (424) to the Near-RT RIC (406) based on the configured periodicity via the E2 interface.
  • the cell when a cell is deployed and commissioned (408), the cellmay establishan E2 link (410) with the Near-RT RIC [RIC] (406).
  • the RIC (406) may create a cell context for the cell (412).
  • the RIC (406) may transmit a RIC Subscription Request (414) to the O-CU-CP-1 (404) to start the measurements for this cell (418) and start reporting periodically.
  • the O-CU-CP-1 (404) may configure the measurements (422) in theO-DU-1 (402) for the cell via an F1AP Resource Status Initiation procedure (424).
  • the O-DU-1 may start the measurements (422) for the cell and startreporting (424) to the O-CU-CP, at set periodicity on Radio Resource status(RR), Composite Available Capacity Group (CACG), Slice Available Capacity (SliAC), Number of Active UEs, etc.
  • the O-CU-CP- 1 may forward the resource status updates (426 and 428) along with the Number of RRC connections (430 and 434) to the Near-RT RIC (406).
  • the Near-RT RIC (406) may check all the resource status updates (426 and 428) and store the resource status updates (426 and 428) against the cell. This procedure sequence may be followed for every cell that may get commissioned under the Near-RT RIC (406).
  • FIG. 5 illustrates an exemplary MFB xApp [UC-1] representation (500) highlighting flow for processing on load information for the serving cell received from the associated E2 nodes in accordance with an embodiment of the present disclosure. As illustrated, the tentative sequence flow for the processing of the received cell load information is shown that needs necessary steps further if the load situation demands, to offload UEs towards the chosen neighbor cells.
  • anRIC Indication (510) may be received at the Near- RT RIC (508), and if the Cell load is > Th-U for some time duration ‘TU, the cell may decide to offload some of its load towards the plurality of neighbor cells (512).
  • the Near-RT RIC (508) may collect the list of the plurality of neighbors cells of the loaded cell, from the local ANR xApp (514). From the list of the plurality of neighbor cells, both the serving cell and the plurality of neighbor cells may appear to belong to the same Near-RT RIC (508) (516). Further, the Near-RT RIC (508) may collect the load information for this list of the plurality of neighbor cells from the relevant cell contexts within the MFB xApp (518).
  • the Near-RT RIC may analyze the load information and identify a subset of cells whose cell load is ⁇ Th-E for some time duration ‘T’ (520).
  • the cells whose cell load is ⁇ Th-L for some time duration ‘T’ may become candidate cells for offload.
  • the Near-RT RIC maydynamically choose the appropriate value for the HO Trigger parameter for the subset cells (522).
  • the MFB xApp may coordinate with the MRO xApp to decide on the appropriate HO Trigger parameters.
  • the Near-RT RIC (508) may request the O-CU-CP-1 (506)via a RIC Subscription Request (524) to start using the modified HO Trigger value via the E2 interface.
  • the O-CU-CP-1 (506) may reconfigure (528) the UEs (502) of the cells with new measurement configurations. Consequently, the UEs (502) within the loaded cell may send early measurement reports to trigger HO towards the plurality of neighbor cells.
  • FIG. 6 illustrates an exemplary MLB xApp [UC-1] representation (600) of a tentative sequence flow for restoring to normal condition, post the MLB offload in accordance with an embodiment of the present disclosure.
  • the tentative sequence flow for restoring to normal operating condition of the cell, post the successful MLB offload is described herewith.
  • the load on the cell may start getting reduced.
  • the Near-RT RIC 608 may decide to revert (610) the changes made for the HO Trigger parameter for those cells.
  • the Near-RT RIC (608), based on AI/ML, may dynamically choose (612) an appropriate value for the HO Trigger parameter for the neighboring cells and the serving cell.
  • the MLB xApp may coordinate with the MRO xApp, if needed, to decide on the appropriate HO Trigger parameters.
  • the Near-RT RIC (608) may request the O-CU-CP-1 (606) via a RIC Subscription Request(614) to start using the modified HO Trigger value via the E2 interface.
  • the O-CU-CP-1 (606) may reconfigure (618) the UEs (602) of these cells with new Measurement Configurations and the operation starts moving towards normal.
  • FIG. 7 is an illustrated embodiment of an alternative deployment scenario representation (700) for MLB with integrated O-RAN architecture in accordance with an embodiment of the present disclosure.
  • the deployment scenario highlights an alternative embodiment (also Usecase 2 (UC-2) or Option 2).
  • the serving cell (304-1) and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-ql) may be under different Near-RT RIC entities (302-1 and 302-2).
  • the serving cell (304-l)and the plurality of neighbor cells (304-m, 304-m2, 304-p2, 304-ql) may be spread across different O-CU-CPs (308-1 and 308-n) and different O-DUs (314-1) as shown in FIG. 7.
  • the Xn interface may be used here for collecting the load information for the plurality of neighbor cells (304-m, 304- m2, 304-p2, 304-ql) which are under different Near-RT RIC entities (302-1 and 302-2) needed for the MLB support.
  • Cell-1 is the serving cell, which is loaded above an upper Threshold [Th-U].
  • the plurality of neighbor cells of Cell-1, as per ANR table, may be identified by theshaded box.
  • the subset of the plurality of neighbor cells may be assumed to have cell load below a lower Threshold [Th-L], which may be the candidate cells to offload.
  • FIG. 8 illustrates an exemplary MLB xApp [UC-2] representation (800) of a tentative sequence flow for configuring load information collection across Xn interface in accordance with an embodiment of the present disclosure.
  • the tentative sequence flow shows the collection of the load information from the associated E2 nodes, that may be spread across multiple Near-RT RICs, by triggering the Resource Status Request to the E2 nodes via the E2 interface.
  • the E2 nodes may use the Xn interface to request and fetch the load information.
  • the E2 nodes may perform measurements and report the measured load information to the requested E2 nodes via the Xn interface based on the configured periodicity in the way described herewith.
  • the Near-RT RIC (808) may collect (810) the load information for the plurality of neighbor cells that belong to the same RIC within the MLB xApp locally. For the plurality of neighbor cells, which belongs to a different Near-RT RIC, the Near-RT RIC (808) mayrequesttheO-CU-CP-1 (806) to collect (814) the load information.
  • the O-CU-CP-1 (806) may then request O-CU-CP-n (836), which belongs to another RIC, to provide (816) the load information for the list of cells via XnAP Resource Status Initiation procedure (818).
  • the O-CU-CP-n (836) may startcollecting the load information for all those cells from theO-DUs (804) via an F1AP Resource Status Initiation procedure (826).
  • FIG. 9 illustrates an exemplary MLB xApp [UC-2] representation (900) of a tentative sequence flow for collecting and post-processing of received load information across the Xn interface in accordance with an embodiment of the present disclosure.
  • the tentative sequence for collecting the load information by the O-CU-CP-n (910) from their respective O-DUs (904) and forwarding the Resource status shows reports according to the set periodicity to the requested O-CU-CP-1 (906), which in turn forwards them to the Near- RT RIC (908).
  • the Near-RT RIC (908) may process the received load information along with the load information collected locally and takethe necessary action on similar lines as explained in Usecase- 1 embodimentdescribed herewith.
  • the O-CU-CP-n (910) may start receiving the load information from theO-DUs (904) via an F1AP Resource Status Reporting procedure (922), the O-CU-CP-n (910) may forward the F1AP: Resource Status Update report (922) to the O-CU-CP-1 (906) via an XnAP Resource Status Reporting procedure (924).
  • the Near-RT RIC (908) based on AI/ML, may dynamically choose the appropriate value for the HO Trigger parameter for each of the plurality of neighbor cells.
  • the Near-RT RIC (908) mayrequest the O-CU-CP-1 (906) to start using the modified HO Trigger value for the plurality of neighbor cells.
  • the O-CU-CP-1 (906) may reconfigure (928) the UEs (902) of the cells which belong to the Near-RT RIC (908) with new measurement configurations.
  • theO-CP-CU-1 may forward Modified HO Trigger value to the O-CU-CP-n (910) via an XnAP Mobility Settings Change procedure (930).
  • the O-CU-CP-n (910) may reconfigure (928) all the UEs (902) of the cells which belong to the Near-RT RIC (908) with new measurement configurations. The remaining procedure remains the same as explained for Use case-1 in an earlier embodiment.
  • FIG. 10 is an illustrated embodiment (1000) of a Functional block diagram for MLB support at Non-RT RIC in accordance with an embodiment of the present disclosure.
  • the E2 Node (1022) may performthe measurements and capture PM data, and store it locally. Based on the PM data reporting configurations (T), the E2 node (1022) may report the PM data, Events/Alarms, logs, etc., to the SMO (1002) via the 01 interface.
  • the reporting configurations can be for example T [5min, lOmin, 15min, 20min, 25min, 30min, 45min, 60min, 90min, etc.,].
  • the EMS (1012) within the SMO (1002) may forward the data to MDAS (1006) and NMS (1004) internally.
  • the MDAS (1006) may store the data and execute big data analytics considering the overall data accumulated so far in its storage.Further, the MDAS (1006) may generate the relevant load patterns for each concerned cell.
  • the accumulation of data may be envisioned as days or months or years of data. As the data accumulation duration may be high, the accuracy and the closeness to the reality of the generated pattern may also be very high.
  • the generated patterns like load pattern, time duration pattern, etc. may be shared with the Non-RT RIC (1008).
  • the Non-RT RIC [rApp] (1008) may analyze the patterns and try to derive whether a specific peak cell load pattern and a specific lower cell load pattern may be periodic or aperiodic, a duration of such patterns, anda probable occurrence of such patterns in future.
  • the Non-RT RIC [rApp] (1008) may also analyze the similar pattern for the plurality of neighbor cells as well. From this analysis, the Non-RT RIC (1008) may predict the next immediate occurrence of the peak load of the cell and its duration, and for that duration, the Non-RT RIC (1008) may also examine the behavior of all the neighbor cells. Further, the Non-RT RIC (1008) may shortlist the subset of the sure-shot neighbor cells that can be candidate neighbor cells for offload. The predicted load condition, the predicted time duration of occurrence, the tentative list of neighbor cells for offload, etc. may be shared with the Near-RT RIC (1014) across a third interface (also referred to as the Al interface hereinafter).
  • FIG. 11 illustrates an exemplary representation (1100) of a sequence flow of data across different 0-RAN entities for MLB support in accordance with an embodiment of the present disclosure.
  • the Non-RT RIC (1106) may use the predicted data to guide the Near-RT RIC (1108) accordingly.
  • the Non-RT RIC (1106) can guide the Near-RT RIC (1108) to reduce a use ofCarrier aggregation, reduce a use of Dual connectivity, reduce Bandwidth of operation, reduce MIMO configurations to the minimum possible, switch to lower Modulation classes, enable to attract more incoming Handovers, etc., applicable for the set time duration.
  • the Non-RT RIC (1106) can guide the Near-RT RIC (1108) to get prepared for enabling the above said features to maximum usage possible appropriately.
  • the Non-RT RIC (1106) may provide guidance in the form of policies, while the Near-RT RIC (1108)may assess the current situation based on the received guidance and its own Real-time analytics and takes the decision accordingly.
  • FIG. 12 is an illustrated embodiment representation (1200) of a Functional Architecture for MLB support across the SMO (1002) and the E2 Node (1022) only in accordance with an embodiment of the present disclosure.
  • the MLB functionality is split between the SMO (1002) and the E2 Node (1022), across the Open 01 interface (1018).
  • the functionality of MLB rApp (1010) at Non-RT RIC is same as explained in the earlier embodiments, except that the MLB rApp (1010) may provide the derived MLB policies to the MLB controller (1204) locally.
  • the MLB Controller (1204) at the Management entity (1012) can do the data analytics on the received PM data from the E2 node (1022) directly and take the appropriate decisions of the load balancing.
  • the MLB Controller (1204) can also utilize the load/time patterns generated by the MDAS (1006) on the accumulated PM data, to take the MLB decisions.
  • the MLB Agent (1202) may execute the MLB decisions/Commands received from the MLB Controller (1204) across the open 01 interface (1018).
  • the MLB Agent (1202) can access the near-RT PM data locally within E2 Node (1022), perform the real-time analytics on it and can take the decisions on load balancing locally.
  • the MLB decisions may be aligned with the decisions/commands received from the MLB Controller (1204).
  • TheMLB Agent(1202) may be specific to the E2 node (1022) and implementation specific. However, adhering to the MLB guidelines received across the open 01 interface (1018), may still make the MLB function vendor- agnostic.
  • FIG. 13 is an illustrated representation (1300) of a Functional Architecture for MLB support across the SMO (1002) and the E2 Node (1022) only, excluding the Non-RT RIC in accordance with an embodiment of the present disclosure.
  • the Non-RT RIC does not have any role to play w.r.t the MLB feature and the MLB controller (1204) itself takes care of all the functionalities explained for MLB rApp within Non-RT RIC under earlier embodiments. Rest of the functionalities are similar as explained above.
  • FIG. 14 illustrates an exemplary computer system (1400) in which or with which embodiments of the present invention can be utilized in accordance with embodiments of the present disclosure.
  • the computer system (1400) can include an external storage device (1410), a bus (1420), a main memory (1430), a read only memory (1440), a mass storage device (1450), a communication port (1460), and a processor (1470).
  • the computer system may include more than one processor and communication ports.
  • processors (1470) examples 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 (1470) may include various modules associated with embodiments of the present invention.
  • the communication port (1460) 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 (1460) may be chosen depending on a network, such as a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system connects.
  • the memory (1430) can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art.
  • Read-only memory (1440) 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 the processor (1470).
  • PROM Programmable Read Only Memory
  • the mass storage (1450) 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 Deskstar 13K8OO), 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) or
  • the bus (1420) communicatively couples the processor(s) (1470) with the other memory, storage, and communication blocks.
  • the bus (1420) 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 (1470) 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 (1420) may also be coupled to bus (1420) 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 (1460).
  • the external storage device (1410) can be any kind of external hard drives, 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 mobility load balancing of a cell in 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 Load Balancing (MLB) functionality of a Self-Organizing Network (SON) in an O- RAN architecture.
  • MLB Mobility Load Balancing
  • 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 of two mechanisms for the realization of the MLB function in the O-RAN architecture such as MLB implementation in the Near RT RIC, Non-RT RIC entities, and MLB implementation in the management entity, and the Near RT RIC.
  • the present disclosure provides systems and methods to collect data for facilitating the MLB functional execution in the Near and the Non-RT RIC entities.
  • the present disclosure provides systems and methods to offload a cell to the neighbouring cells in a telecommunication network, thereby improving network efficiency, in an O-RAN architecture.
  • 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 (hereinafter 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)

Abstract

La présente invention concerne des systèmes efficaces et fiables et pour réaliser un premier ensemble d'instructions (désigné de manière interchangeable en tant qu'équilibrage de charge de mobilité (MLB)) de SON dans une architecture O-RAN et leurs procédés d'interfonctionnement de collecte de données. L'architecture O-RAN comprend au moins deux entités citées comme contrôleur intelligent de réseau d'accès radio en temps quasi-réel (RIC en temps quasi-réel) (124) et contrôleur intelligent de réseau d'accès radio non en temps quasi-réel (RIC non en temps quasi-réel) (122). Le procédé peut en outre fournir une division fonctionnelle pour le MLB et des flux fonctionnels associés entre lesdites au moins deux entités. Le procédé assure en outre la localité d'exécution du MLB comprenant une division éventuelle entre un nœud gNB (désigné de manière interchangeable en tant que nœud E2 dans l'architecture O-RAN), le RIC non en temps quasi-réel et le RIC en temps quasi-réel. Les procédés et le système peuvent en outre permettre la collecte de données pour faciliter l'exécution fonctionnelle MLB dans les entités RIC en temps quasi-réel et RIC non en temps quasi-réel.
PCT/IB2022/058001 2021-08-30 2022-08-26 Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation WO2023031744A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202280006683.4A CN116325866A (zh) 2021-08-30 2022-08-26 实现自组织网络的移动性负载均衡的系统及方法
KR1020237010281A KR20230131169A (ko) 2021-08-30 2022-08-26 자체 구성 네트워크의 이동성 로드 밸런싱을 인에이블하는 시스템 및 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IN202121039244 2021-08-30
IN202121039244 2021-08-30

Publications (1)

Publication Number Publication Date
WO2023031744A1 true WO2023031744A1 (fr) 2023-03-09

Family

ID=85410892

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2022/058001 WO2023031744A1 (fr) 2021-08-30 2022-08-26 Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation

Country Status (3)

Country Link
KR (1) KR20230131169A (fr)
CN (1) CN116325866A (fr)
WO (1) WO2023031744A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117412333A (zh) * 2023-10-16 2024-01-16 东莞理工学院 一种基于o-ran系统的移动负载均衡方法、系统、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2532793A (en) * 2014-11-28 2016-06-01 Vodafone Ip Licensing Ltd Telecommunications control in a self-organizing network
WO2020242987A1 (fr) * 2019-05-24 2020-12-03 Apple Inc. Nouvel équilibrage de charge radio 5g et robustesse de mobilité
US20200383040A1 (en) * 2019-05-28 2020-12-03 Verizon Patent And Licensing Inc. Methods and systems for intelligent amf assignment to minimize re-direction

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2532793A (en) * 2014-11-28 2016-06-01 Vodafone Ip Licensing Ltd Telecommunications control in a self-organizing network
WO2020242987A1 (fr) * 2019-05-24 2020-12-03 Apple Inc. Nouvel équilibrage de charge radio 5g et robustesse de mobilité
US20200383040A1 (en) * 2019-05-28 2020-12-03 Verizon Patent And Licensing Inc. Methods and systems for intelligent amf assignment to minimize re-direction

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117412333A (zh) * 2023-10-16 2024-01-16 东莞理工学院 一种基于o-ran系统的移动负载均衡方法、系统、设备及介质

Also Published As

Publication number Publication date
CN116325866A (zh) 2023-06-23
KR20230131169A (ko) 2023-09-12

Similar Documents

Publication Publication Date Title
Peng et al. Self-configuration and self-optimization in LTE-advanced heterogeneous networks
US10498613B2 (en) Method and apparatus for coordinating network
Østerbø et al. Benefits of Self‐Organizing Networks (SON) for Mobile Operators
US20140349661A1 (en) Method and system for coordinating cellular networks operation
Wang et al. Local cooperation architecture for self-healing femtocell networks
FI20175725A1 (en) Customer-centered cognitive self-organizing networks
KR20160147957A (ko) 자동-구성 네트워크들에서 검증
EP3432629B1 (fr) Partitionnement d'une pluralité de points d'accès sans fil en grappes de gestion
Barth et al. Self-organization in 4G mobile networks: Motivation and vision
CN115146691A (zh) 管控模型训练的方法及装置、系统
Yu et al. Self‐Organized Cell Outage Detection Architecture and Approach for 5G H‐CRAN
Chernogorov et al. N-gram analysis for sleeping cell detection in LTE networks
GB2536241A (en) Self-organising network engine for per user optimisation in a telecommunications network
Mahimkar et al. Aurora: conformity-based configuration recommendation to improve LTE/5G service
US20240015790A1 (en) System and method of enabling a self organizing network in open ran
Xue et al. Cell outage detection and compensation in two‐tier heterogeneous networks
de la Bandera et al. Improving cell outage management through data analysis
WO2022017626A1 (fr) Surveillance de performance basée sur la trajectoire dans un réseau de communication sans fil
Manzanilla-Salazar et al. ENodeB failure detection from aggregated performance KPIs in smart-city LTE infrastructures
WO2023031744A1 (fr) Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation
EP4397074A1 (fr) Système et procédé pour permettre un équilibrage de charge de mobilité d'un réseau à auto-organisation
EP3085142B1 (fr) Définition de cellules logiques
WO2023026177A1 (fr) Systèmes et procédés pour optimiser la robustesse de mobilité d'un réseau de télécommunication
Görçin A Neighbor Relation Whitelisting Method for Wireless Cellular Systems
WO2023233309A1 (fr) Système et procédé pour permettre un interfonctionnement dans des réseaux auto-organisateurs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22863728

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022863728

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022863728

Country of ref document: EP

Effective date: 20240402