Handover / migration method, and related devices
A context-aware handover method integrates LEO, MEO, GEO satellites, HAPS, and UAVs into a unified network, addressing seamless connectivity challenges by optimizing handovers based on diverse contexts, ensuring efficient and flexible communication.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- GUANGDONG OPPO MOBILE TELECOMMUNICATIONS CORP LTD
- Filing Date
- 2024-11-07
- Publication Date
- 2026-05-15
AI Technical Summary
Current wireless communication technologies do not adequately address the seamless integration of Non-Terrestrial Networks (NTNs) across various orbits and altitudes into a unified system, failing to provide efficient and flexible handover mechanisms that consider diverse network layers and user contexts.
Implementing a context-aware handover/migration method that utilizes Integrated Access and Backhaul (IAB) technology to integrate LEO, MEO, GEO satellites, HAPS, and UAVs into a multi-layered communication network, employing advanced algorithms and artificial intelligence to optimize handover decisions based on network, user, environmental, and service contexts.
Ensures robust, flexible, and efficient network connectivity by dynamically selecting the optimal communication layer, enhancing user experience and optimizing resource utilization in next-generation wireless communications.
Smart Images

Figure CN2024130383_15052026_PF_FP_ABST
Abstract
Description
HANDOVER / MIGRATION METHOD, AND RELATED DEVICESTECHNICAL FIELD
[0001] The present application relates to wireless communication, and more particularly, to a handover / migration method, and related devices.BACKGROUND ART
[0002] 3GPP Release 17 introduces Non-Terrestrial Networks (NTN) within the 5G framework, emphasizing initial integration and basic use cases. Internet of Things (IoT) services over satellite are supported, targeting coverage gaps in remote areas. The Release 17 extends New Radio (NR) to NTNs, incorporating satellite-specific adaptations to manage higher latency and Doppler shifts, integrated within the existing 5G architecture.
[0003] The 3GPP Release 17 adopts a "bent-pipe" model, utilizing transparent payloads and an NTN gateway. Radio protocols terminate at the ground-based gNB, with both feeder and service links utilizing the Uu interface. A new 5G QoS Identifier (5QI) addresses the extended latency characteristic of satellite access and backhaul.
[0004] Primary focus is given to transparent payloads on LEO and GEO satellites, assuming UE GNSS capabilities. Platforms include LEO, MEO, GEO, and HAPS. NTN nodes operate as repeaters, forwarding signals without processing, ensuring transparency between NTN and terrestrial nodes for NR UEs.
[0005] 3GPP Release 18 introduces NG-RAN-based NTN enhancements for GEO and NGSO deployments. Earth-fixed tracking areas are supported, along with fixed and mobile cells in NGSO systems. This release also adds "Unavailability Period Support, " improving mobility management and power savings. Satellite coverage availability information is provisioned to the UE or AMF, indicating expected availability of both service and feeder link connectivity.
[0006] In GEO satellite backhaul scenarios, satellites may serve as part of the backhaul between RAN and the 5G Core (5GC) , with UPF potentially deployed onboard. Edge computing or local switching via UPF is also supported for satellite deployments. The AMF communicates satellite backhaul categories to the PCF, enabling adjustments to the URSP for services routed via GEO satellites.
[0007] 3GPP Release 19 focuses on regenerative payloads, enabling 3GPP RAN and Core Network functions directly onboard the satellite. This capability reduces user and control plane latency and enables inter-satellite communication (ISL) . For network management, regenerative payloads offer flexibility in ground segment deployment relative to the space segment. Support is extended to advanced use cases, including store-and-forward and direct UE-to-satellite-to-UE communication.
[0008] Previous studies have primarily concentrated on the architecture necessary to support onboard eNB / gNB and select core network functions to accommodate specific service scenarios.
[0009] In recent years, the demand for ubiquitous connectivity has grown, especially in remote or underserved areas where terrestrial networks are not viable. Applications such as global IoT networks, real-time monitoring, and emergency services require seamless integration across different types of networks. Advancements in satellite technology, High-Altitude Platform Systems (HAPS) , and Unmanned Aerial Vehicles (UAVs) are driving the tighter integration of these platforms into communication systems.
[0010] However, much of the previous work has focused on single-orbit networks, with limited attention to the seamless integration of Non-Terrestrial Networks (NTNs) across various orbits and altitudes into a unified system. There is still a gap in developing a globally ubiquitous communication network that integrates multiple layers of NTNs and Terrestrial Networks (TNs) to meet next-generation connectivity demands.SUMMARY
[0011] In a first aspect, some embodiments of the present application provide a handover / migration method, including establishing connectivity to communicate with a core network via a source network node; receiving from the source network node configuration of one or more candidate communication connections and context aware handover / migration execution condition; determining whether the context aware handover / migration execution condition is satisfied; if the context aware handover / migration execution condition is satisfied for a target communication connection among the one or more candidate communication connections, executing handover / migration to the target communication connection, which belongs to a target network node.
[0012] In a second aspect, some embodiments of the present application provide a handover / migration method, including receiving context aware handover / migration information from a core network; making context aware handover / migration decision at least based on the context aware handover / migration information; sending to a network node configuration of one or more candidate communication connections and context aware handover / migration execution condition for the network node to handover / migrate to a target communication connection of the one or more candidate communication connections based on the context aware handover / migration execution condition.
[0013] In a third aspect, some embodiments of the present application provide a handover / migration method, including receiving analytics information that is related to handover / migration and is obtained by analyzing context data using a machine learning model; deriving context aware handover / migration condition or parameter based on the received analytics information; provisioning context aware handover / migration information including the context aware handover / migration condition or parameter, wherein the context aware handover / migration condition or parameter is for being used to make context aware handover / migration decision.
[0014] In a fourth aspect, some embodiments of the present application provide a communication device, including a processor, configured to call and run program instructions stored in a memory, to execute the method in accordance with the first aspect.
[0015] In a fifth aspect, some embodiments of the present application provide a communication device, including a processor, configured to call and run program instructions stored in a memory, to execute the method in accordance with the second aspect.
[0016] In a sixth aspect, some embodiments of the present application provide a communication device, including a processor, configured to call and run program instructions stored in a memory, to execute the method in accordance with the third aspect.
[0017] In a seventh aspect, some embodiments of the present application provide a chip includes a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute any of the above methods.
[0018] In an eighth aspect, some embodiments of the present application provide a computer readable storage medium, in which a computer program is stored, causes a computer to execute any of the above methods.
[0019] In a ninth aspect, some embodiments of the present application provide a computer program product includes a computer program, and the computer program causes a computer to execute any of the above methods.
[0020] In a tenth aspect, some embodiments of the present application provide a computer program causes a computer to execute any of the above methods.DESCRIPTION OF DRAWINGS
[0021] In order to more clearly illustrate the embodiments of the present application or related art, the following figures that will be described in the embodiments are briefly introduced. It is obvious that the drawings are merely some embodiments of the present application, a person having ordinary skill in this field can obtain other figures according to these figures without paying the premise.
[0022] Figure 1 is a schematic diagram illustrating a 5th-Generation (5G) architecture according to an embodiment of the present application.
[0023] Figure 2 is a block diagram of a user equipment (UE) and one or more network devices in a communication network system according to an embodiment of the present application.
[0024] Figure 3 is a schematic diagram illustrating IAB deployment in a multi-orbit network according to some embodiments of the present application.
[0025] Figure 4 is a flowchart of a handover / migration method according to an embodiment of the present application.
[0026] Figure 5 is a flowchart of a handover / migration method according to another embodiment of the present application.
[0027] Figure 6 is a flowchart of a handover / migration method according to still another embodiment of the present application.
[0028] Figure 7 is a schematic diagram illustrating gNB onboard NTN Platforms according to some embodiments of the present application.
[0029] Figure 8 is a flowchart of context aware handover for the scenario depicted in Figure 2 according to some embodiments of the present application.
[0030] Figure 9 is a schematic diagram illustrating mobile IAB node onboard satellite according to some embodiments of the present application.
[0031] Figure 10 is a flowchart of context aware handover for the scenario depicted in Figure 4 according to some embodiments of the present application.
[0032] Figure 11 is a schematic diagram illustrating mobile IAB node DU handover in multi-layer network in a case of IAB donor onboard satellite according to some embodiments of the present application.
[0033] Figure 12 is a flowchart of context aware handover for the scenario depicted in Figure 6 according to some embodiments of the present application.
[0034] Figure 13 is a schematic diagram illustrating mobile IAB-MT handover with the application of context aware handover according to some embodiments of the present application.
[0035] Figure 14 is a flowchart of context aware handover for the scenario depicted in Figure 8 according to some embodiments of the present application.DETAILED DESCRIPTION OF EMBODIMENTS
[0036] Embodiments of the disclosure are described in detail with the technical matters, structural features, achieved objects, and effects with reference to the accompanying drawings as follows. Specifically, the terminologies in the embodiments of the present application are merely for describing the purpose of the certain embodiment, but not to limit the disclosure.
[0037] In this document, a combination such as “at least one of A, B, or C, ” “one or more of A, B, or C, ” “at least one of A, B, and C, ” “one or more of A, B, and C, ” or “A, B, and / or C” may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, where any combination may contain one or more members of A, B, or C.
[0038] The following table includes some abbreviations used in some embodiments of the present application:
[0039] Figure 1 shows a 5G architecture. Devices involved in the 5G architecture include user equipment (UE) , a Radio Access Network (RAN) , a User Plane Function (UPF) , a Data Network (DN) , an Access and Mobility Management Function (AMF) , a Session Management Function (SMF) , a Policy Control Function (PCF) , an Application Function (AF) , an Authentication Server Function (AUSF) , and Unified Data Management (UDM) . It is noted that this application may be applicable to the architecture shown in Figure 1, but is not limited thereto. The application can also be applied to future communication system such as 6G system.
[0040] As shown in Figure 1, the UPF plays a crucial role in the user plane architecture of the core network, specifically within the 5G Core (5GC) . Once the SMF provisions the UPF with PDRs, i.e. the rules for detecting and handling the packets, the UPF becomes responsible for managing and forwarding user plane data traffic between the RAN and external data networks, such as the Internet or private networks. Policy related network elements mainly include the PCF, which enforced the policy by communicating these to the AMF, the SMF, the RAN, and the UE. The PCF determines policy rules for network behaviors. This may include deciding how network resources are allocated, ensuring efficiency of network capabilities. The SMF is mainly responsible for executing session management tasks. The AMF is mainly responsible for executing access and UE mobility management tasks. Policy transmission and update of the two network elements (the AMF and the SMF) are managed and controlled by the PCF.
[0041] Figure 2 illustrates that, in some embodiments, a user equipment (UE) 10 and one or more network elements or network devices 20 (i.e., network nodes) in a communication network system 30 according to an embodiment of the present application are provided. The communication network system 30 includes the UE 10 and one or more network elements or network devices 20. The UE 10 may include a memory 12, a transceiver 13, and a processor 11 coupled to the memory 12 and the transceiver 13. The one or more network elements or network devices 20 (i.e., network nodes) may include a memory 22, a transceiver 23, and a processor 21 coupled to the memory 22 and the transceiver 23. The processor 11 or 21 may be configured to implement proposed functions, procedures and / or methods described in this description. Layers of radio interface protocol may be implemented in the processor 11 or 21. The memory 12 or 22 is operatively coupled with the processor 11 or 21 and stores a variety of information to operate the processor 11 or 21. The transceiver 13 or 23 is operatively coupled with the processor 11 or 21, and the transceiver 13 or 23 transmits and / or receives a radio signal.
[0042] The processor 11 or 21 may include application-specific integrated circuit (ASIC) , other chipset, logic circuit and / or data processing device. The memory 12 or 22 may include read-only memory (ROM) , random access memory (RAM) , flash memory, memory card, storage medium and / or other storage device. The transceiver 13 or 23 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in the memory 12 or 22 and executed by the processor 11 or 21. The memory 12 or 22 can be implemented within the processor 11 or 21 or external to the processor 11 or 21 in which case those can be communicatively coupled to the processor 11 or 21 via various means as is known in the art.
[0043] This application discloses methods for utilizing Integrated Access and Backhaul (IAB) technology and context-aware handover mechanisms to integrate satellites in e.g., Low Earth Orbit (LEO) , Medium Earth Orbit (MEO) , and Geostationary Earth Orbit (GEO) , along with e.g., HAPS, UAVs, and TN nodes, into a multi-layered communication network.
[0044] As the landscape of wireless communication rapidly evolves, the deployment of 6G networks represents a significant technological leap. A key enabler of this evolution is the integration of a multi-layer network infrastructure, combining LEO, MEO, GEO satellites, HAPS, Low Altitude Platforms (LAPS) , such as UAVs, and terrestrial networks. This diverse, multi-layer architecture allows 6G networks to dynamically select the optimal communication layer based on specific user needs and service requirements.
[0045] By leveraging the unique advantages of each layer, 6G networks will provide unprecedented flexibility and performance. For example, GEO satellites offer wide-area coverage, ideal for broadcast services, while LEO and MEO satellites offer lower latency and higher throughput, essential for real-time applications. HAPS and UAVs add further adaptability, allowing rapid deployment for coverage in underserved areas or during emergencies. The intelligent selection of communication layers is powered by advanced algorithms and artificial intelligence, which consider factors such as user location, service type, network congestion, and environmental conditions. This approach enhances the user experience and optimizes resource utilization, promoting efficiency and sustainability in next-generation wireless communications.
[0046] To support seamless integration of this multi-layer network infrastructure-including e.g., LEO, MEO, GEO satellites, HAPS, and LAPS platforms-this application discloses methods for deploying IAB nodes on airborne and spaceborne platforms. Additionally, a context-aware handover strategy is introduced, ensuring robust, flexible, and efficient network connectivity.
[0047] Please refer to the following context for more details.
[0048] In the coming years, there will be a significant increase in the deployment of satellites across various orbits, including Low Earth Orbit (LEO) , Medium Earth Orbit (MEO) , and Geostationary Orbit (GEO) . Additionally, the growing popularity of Low Altitude Platforms (LAPS) and High-Altitude Platform Systems (HAPS) will provide more flexible options for deploying communication instances on hot air balloons, UAVs, etc. This multi-layered infrastructure will enable robust, flexible, and efficient network connectivity, delivering seamless access anytime, anywhere, for any content and any device.
[0049] To fully harness the unique advantages of each communication layer, a mechanism must be in place to ensure optimal performance and flexibility. For instance, GEO satellites provide extensive coverage and are ideal for broadcast services, while LEO and MEO satellites offer lower latency and higher throughput, which are critical for real-time applications. HAPS and UAVs add further adaptability, allowing for rapid deployment in underserved areas or during emergencies. Intelligent layer selection, driven by advanced algorithms and artificial intelligence, considers factors such as user location, service type, network congestion, and environmental conditions. This approach enhances user experience, optimizes resource utilization, and promotes efficiency and sustainability in next-generation wireless communications.
[0050] Furthermore, network densification may require the deployment of additional RAN nodes on satellites to support coverage across a given geographical area. However, considering the high cost of satellite backhaul and the expense of establishing ground-based backhaul-connected earth stations, providing individual backhaul for each RAN node and building extensive earth station infrastructure can be both time-consuming and costly. In this context, IAB (Integrated Access and Backhaul) offers a more efficient solution to support network densification by allowing multiple IAB nodes to share a single IAB donor that provides high-bandwidth backhauling functions.
[0051] In an IAB setup, the backhaul (connection to the core network) and access network (connection to UEs) are separated. The IAB donor manages the backhaul, while the IAB nodes handle both access and local backhaul communications. This architecture provides greater flexibility in how access and backhaul are managed and makes more efficient use of satellite bandwidth by sharing the backhaul link among multiple access nodes. Instead of each access node requiring its own direct link to the core network, the IAB architecture aggregates traffic from multiple nodes and efficiently backhauls it via the satellite.
[0052] In one embodiment, the satellite provides backhaul (via an onboard IAB donor) , and multiple IAB nodes on the ground or on other satellites can share that backhaul link. This reduces the need for extensive infrastructure to connect each individual gNB to the core network, simplifying deployment and lowering costs.
[0053] In another embodiment, to enhance network densification over a specific coverage area, additional IAB nodes could be deployed on the satellite itself. These nodes would connect to an IAB donor located on the ground or on another satellite. Deploying IAB nodes in this way can significantly reduce the satellite payload compared to deploying a full gNB / eNB or RAN node, as an IAB node only includes the IAB-node DU (Distributed Unit) and IAB-node MT (Mobile Termination) , which are simpler and lighter. In contrast, a full gNB / eNB or RAN node requires more complex hardware to manage the full RAN protocol stack and backhaul functionalities.
[0054] By separating access and backhaul functions, IAB allows for simpler backhaul interfaces compared to a gNB, offering a more lightweight and efficient solution for satellite-based deployments while reducing costs and complexity.
[0055] As illustrated in Figure 3, a User Equipment, UE1, located in a disaster-hit area attempts to connect to the 6G network but cannot find any available base stations due to infrastructure damage. The rugged terrain causes signal obstructions, which can be mitigated by satellite communication.
[0056] Given the disruption of terrestrial lines, immediate connectivity needs, and geographic constraints, first responders activate their 3GPP NTN UEs. These devices establish an emergency communication channel with the rescue headquarters via a GEO satellite with an Integrated Access and Backhaul (IAB) node onboard, allowing them to report the field situation. The IAB-node MT module in this IAB-node facilitates satellite communication by connecting to another IAB donor within the satellite’s coverage area, which is still connected to a functioning 5G / 6G network.
[0057] After some time, a rescue team member notices missed video conferencing requests sent over the GEO communication channel. Although the transmission bandwidth and signal strength could support the video conferencing, realizing that the latency through the GEO satellite is insufficient for real-time video streaming, the 6G network-based on a context-aware strategy-determines that the best route is to switch to a IAB node deployed in LEO. The network makes this decision using data from sources like the context-aware handover information provisioned from an Application Function (AF) , or derives from analytics functions deployed in the network, e.g. NWDAF, which processes real-time network information.
[0058] The IAB node onboard LEO has connections to the IAB donor node in the nearby city maintains connectivity to the 6G network, facilitated by the 6G core infrastructure.
[0059] Later, a support team deploys a HAPS platform at an altitude of 20 kilometers to ensure critical communications are maintained.
[0060] At a certain point, a real-time monitoring camera equipped with IoT functionality to transmit live footage of the earthquake site to the rescue center located in another city. Using the context-aware handover strategy, the IoT camera UE automatically switches connectivity from the satellite to the HAPS platform, ensuring a more reliable and uninterrupted communication link. The context-aware handover takes into account factors such as service type, latency, and Quality of Service (QoS) .
[0061] As demonstrated, current technologies do not fully address the communication needs described in this scenario. The IAB combined with a more flexible handover mechanism must be in place to support these connectivity’s.
[0062] From the use case, one can see in a multi-orbit network (LEO, MEO, GEO satellites) , HAPS, UAVS, combined with terrestrial networks, UEs may need to hand over not only based on signal strength. It might need to handover to other NTN or TN instance to support certain service QoS, latency etc. However, managing handovers across different network layers (terrestrial to satellite and vice versa) and different orbits introduces complexity due to varying latency, coverage patterns, and network characteristics, which is not considered in the current 3GPP specifications where the 5G standards primarily address handovers within terrestrial networks and do not comprehensively cover inter-network handovers between terrestrial and various non-terrestrial platforms.
[0063] While IAB is specified in 3GPP TS 23.501, clause 5.35, the current specifications do not provide details on how to deploy IAB on satellites or NTN networks to enable multi-orbit communications and seamless handovers between different NTN layers.
[0064] Additionally, although Mobile IAB is introduced in 3GPP TS 38.300, clause 4.7, the application of the context-aware handover strategy proposed in this application is not covered in the current TS 38.300 specification.
[0065] The complexity of managing mobility in 6G networks is further heightened by the presence of moving network nodes and heterogeneous network layers, challenges are not fully addressed by Conditional Handover (CHO) in 5G.
[0066] Figure 4 is a flowchart of a handover / migration method according to an embodiment of the present application. Referring to Figure 4, the method 100 includes the followings. In Step 110, a network node (e.g., a user equipment (UE) , IAB-node distributed unit (DU) , or IAB-node mobile-termination (MT) ) establishes connectivity to communicate with a core network (e.g., 5GC or 6GC) via a source network node. While connected to or attaching to the source network node, the network node may indicate to the core network that context aware handover / migration is supported, via the source network node. In Step 120, the network node receives from the source network node configuration of one or more candidate communication connections and context aware handover / migration execution condition. The context aware handover / migration execution condition may be from the core network. For example, the context aware handover / migration execution condition is based on context information including at least one of the followings: network context, user context, device context, environmental context, and service / application context. In Step 130, the network node determines whether the context aware handover / migration execution condition is satisfied. In Step 140, if the context aware handover / migration execution condition is satisfied for a target communication connection among the one or more candidate communication connections, the network node executes handover / migration to the target communication connection, which belongs to a target network node. For example, the network node may calculate a score for each of the one or more candidate communication connections by weighting context parameters and decide to handover / migrate to the target communication connection when the score of the target communication connection is greater than or equal to a threshold. If the context aware handover / migration execution condition is not satisfied, the network node may maintain communication connection with the source network node. With this method, context-aware handover / migration can be realized, ensuring robust, flexible, and efficient network connectivity.
[0067] In some embodiments, the source network node is a radio access network (RAN) node deployed on a first network, and the target network node is a RAN node deployed on a second network. In some embodiments, the source network node and the target network node are different integrated access and backhaul (IAB) -node distributed units (DUs) connecting to a same IAB donor centralized unit (CU) . In some embodiments, the source network node and the target network node are different IAB-donor-CUs. For example, the IAB-donor-CUs are F1-terminating IAB-donor-CUs. For another example, the IAB-donor-CUs are RRC-terminating IAB-donor-CUs. In some embodiments, the one or more candidate communication connections are cell connections. In some embodiments, the one or more candidate communication connections are F1 connections. In some embodiments, the handover / migration to the target communication connection is executed by one of the followings: user equipment (UE) , IAB-node DU, and IAB-node mobile-termination (MT) .
[0068] Figure 5 is a flowchart of a handover / migration method according to another embodiment of the present application. Referring to Figure 5, the method 200 includes the followings. In Step 210, a network node (e.g., a RAN node, IAB-node DU, or IAB-donor-CU) receives context aware handover / migration information from a core network (e.g., from a network function (NF) such as AMF) . In Step 220, the network node makes context aware handover / migration decision at least based on the context aware handover / migration information. For example, the context aware handover / migration decision may be made based on context information including at least one of the followings: network context, user context, device context, environmental context, and service / application context. The network node may receive an indication from the core network to execute the context aware handover / migration decision. In Step 230, the network node sends to another network node configuration of one or more candidate communication connections and context aware handover / migration execution condition for the network node to handover / migrate to a target communication connection of the one or more candidate communication connections based on the context aware handover / migration execution condition. With this method, context-aware handover / migration can be realized, ensuring robust, flexible, and efficient network connectivity.
[0069] In some embodiments, the context aware handover / migration decision is made based on energy efficiency strategy in consideration of energy consumption of network resource. In some embodiments, the context aware handover / migration decision is made for handover / migration between network slices. In some embodiments, the context aware handover / migration decision is made in consideration of service type. In some embodiments, the context aware handover / migration decision is made based on real-time load information. In some embodiments, the context aware handover / migration decision is made by incorporating historical data to understand long-term trends. In some embodiments, the context aware handover / migration decision is made based on backhaul network conditions.
[0070] Figure 6 is a flowchart of a handover / migration method according to still another embodiment of the present application. Referring to Figure 6, the method 300 includes the followings. In Step 310, a network function (e.g., an application function (AF) ) receives analytics information that is related to handover / migration and is obtained by analyzing context data using a machine learning model. For example, the analytics information may be received from network data analytics function (NWDAF) , and NWDAF analyzes the context data by using the machine learning model. In Step S320, the network function derives context aware handover / migration condition or parameter based on the received analytics information. For example, the context aware handover / migration condition or parameter may be derived from context information including at least one of the followings: network context, user context, device context, environmental context, and service / application context. In Step S330, the network function provisions context aware handover / migration information including the context aware handover / migration condition or parameter, wherein the context aware handover / migration condition or parameter is for being used to make context aware handover / migration decision. For example, the context aware handover / migration information may be provisioned to at least one of the followings: access and management function (AMF) , user data management function (UDM) , and user data repository function (UDR) . With this method, context-aware handover / migration can be realized, ensuring robust, flexible, and efficient network connectivity.
[0071] Please refer to the following descriptions for more details.
[0072] 2.1 Introduction to Context-Aware Handover
[0073] In conventional handover mechanisms, such as Conditional Handover (CHO) , decisions are primarily based on radio signal measurements like Reference Signal Received Power (RSRP) and Reference Signal Received Quality (RSRQ) . The network provides the UE with predefined conditions-such as signal quality thresholds, timing and location, to execute handovers.
[0074] Context-aware handover goes beyond basic signal measurements. It is an advanced mobility management technique where the decision to initiate a handover and the selection of the target network or satellite are based on a comprehensive understanding of multiple contextual parameters. These parameters may include network conditions, user requirements, device capabilities, and environmental factors, among others.
[0075] This application discloses a broader set of context parameters, such as:
[0076] Network Context:
[0077] -Signal Quality: SNR, RSSI, BER.
[0078] -Available Bandwidth: Current network load.
[0079] -Latency and Jitter: Measured delays and variability.
[0080] -Network Topology: Satellite positions, beam coverage areas.
[0081] -Link Stability: Predicted connectivity duration with current and candidate satellites.
[0082] User Context:
[0083] -QoS Requirements: Latency sensitivity, bandwidth needs, reliability.
[0084] -Mobility Patterns: Speed and direction of the UE.
[0085] -User Preferences: Network cost considerations, preferred operators.
[0086] Device Context:
[0087] -Battery Level: Remaining energy capacity.
[0088] -Hardware Capabilities: Supported frequency bands, antenna types.
[0089] -Application Usage: Foreground and background applications.
[0090] Environmental Context:
[0091] -Geographical Location: Urban, rural, maritime, or aerial environments.
[0092] -Weather Conditions: Effects of rain fade on signal propagation.
[0093] -Interference Levels: Obstacles, electromagnetic interference.
[0094] Service / Application Context:
[0095] -Type of Service: Voice calls, video streaming, IoT telemetry.
[0096] -Priority Levels: Emergency services vs. best-effort services.
[0097] -Session Continuity Requirements: Tolerance for service interruptions.
[0098] This multi-dimensional context-aware approach allows 6G networks to make more informed and optimal handover decisions.
[0099] For example, in one embodiment 6G can manage handovers between satellites in different orbits, each with varying characteristics (e.g., latency, coverage, bandwidth) , ensuring seamless connectivity and optimal performance.
[0100] In another embodiment, the Network Data Analytics Function (NWDAF) or a similar entity in 6G could utilize machine learning models to analyze vast amounts of context data and optimize handover decisions. Algorithms could learn from network behavior over time, continuously improving handover efficiency. This context data can then be fed back to the UE, enabling more accurate and responsive handover actions.
[0101] In yet another embodiment, a User and Service-Centric Handover approach introduces service differentiation by tailoring handover decisions based on individual user preferences, application requirements, and service contexts. For instance, handover decisions may prioritize critical communications (e.g., emergency services) over best-effort services (e.g., general web browsing) , thereby ensuring higher performance for high-priority use cases.
[0102] In yet another embodiment, environmental factors could also play a role in handover decisions. Integrating environmental context-such as weather conditions affecting satellite signals (e.g., rain fade) and geographical terrain-into the decision-making process ensures that the network adapts to external conditions to maintain reliable connectivity.
[0103] In yet another embodiment, UAV-assisted handover can facilitate connectivity in scenarios where terrestrial networks are unavailable. For example, a UE located in a desert without connectivity could launch a UAV equipped with Proximity Services (ProSe) . The UAV's UE-to-UE (U2U) or UE-to-Network (U2N) module can establish a link and relay the signal to another node or UE nearby, deployed by a large operator, acts as a relay to route the communication to the service provider’s Radio Access Network (RAN) and then to the ground AMF.
[0104] In yet another embodiment, in multi-orbit satellite networks incorporating e.g., LEO, MEO, GEO satellites, HAPS, UAVs, and more, context-aware handover becomes critical due to the dynamic nature of these networks. Each orbit offers different latency, bandwidth, and coverage characteristics, and satellites move relative to the Earth’s surface. A context-aware approach ensures seamless connectivity and optimal performance by making intelligent handover decisions tailored to the specific needs of each scenario.
[0105] 2.2 The application of context-aware handover strategy
[0106] This application further discloses how to incorporate context-aware handover strategies.
[0107] For example, in one embodiment, energy efficiency strategies factor in the UE's battery level to minimize energy consumption, which is especially important for IoT devices and wearables. By optimizing handover decisions to reduce unnecessary network resource utilization, networks contribute to greener operations.
[0108] In the other embodiment, network slicing integration allows context-aware handover to utilize network slicing technology, applying different handover policies for different slices to cater to specific service requirements, such as enhanced Mobile Broadband (eMBB) or Ultra-Reliable Low-Latency Communications (URLLC) . This enables handovers not only between access nodes but also between network slices based on context, enhancing service delivery.
[0109] In another embodiment, handling diverse mobility scenarios is another important aspect. Context-aware handover can develop specialized mechanisms for UEs in high-speed transport scenarios, such as trains or airplanes, where rapid cell transitions occur. In densely populated areas with small cell deployments, predicting user paths can reduce handover frequency, enhancing user experience and network efficiency.
[0110] In yet another embodiment, load balancing and congestion management can be achieved by including real-time load information in context parameters, preventing handovers to congested cells or networks and thereby maintaining service quality.
[0111] In yet another embodiment, enhanced predictive analytics, incorporating historical data to understand long-term trends like seasonal variations in network usage, can help optimize handover policies accordingly.
[0112] In yet another embodiment, expanding environmental context considerations allows for disaster awareness by incorporating data about natural disasters or large-scale events that might affect network availability, enabling proactive handover to maintain connectivity. Monitoring the operational status of network infrastructure, such as base stations affected by power outages, informs handover decisions, and enhances network resilience.
[0113] In yet another embodiment, backhaul network considerations are also critical. Including backhaul network conditions in context parameters can prevent bottlenecks, which is especially important for IAB nodes and satellite links. Handover decisions can be adjusted based on the latency characteristics of backhaul connections to meet specific service requirements.
[0114] By integrating these strategies, context-aware handover in 6G networks can provide robust, efficient, and seamless connectivity, adapting to a wide range of scenarios and user needs without relying solely on basic signal measurements.
[0115] 2.3 Context Processing
[0116] In one embodiment, predefined conditions can be utilized to trigger handovers based on specific context thresholds. For example, a threshold of 5QI=1 can prompt a handover from GEO satellite connectivity to an available LEO satellite to prevent service degradation. These predefined conditions help avoid unnecessary cell searches and camping processes, which is particularly beneficial for devices in satellite networks that require extended periods for cell discovery.
[0117] These predefined conditions can be communicated from the core network (CN) to the RAN node, IAB node, or a network function (NF) within 5G or 6G systems. This enables the RAN or IAB node to optimize handover strategies and make more efficient decisions.
[0118] In another embodiment, a utility function could be employed to trigger handovers based on the context information detailed in Section 2.1. The utility function would calculate a score for each candidate network by weighing the various context parameters. A threshold-either predefined by the operator or adaptively determined by an algorithm-can be used to trigger the UE to initiate the context-aware handover procedures described in Section 2.4.
[0119] In yet another embodiment, a machine learning model could be applied to predict the optimal handover decision based on historical data. For example, the source gNB could receive an indication from a network function (NF) in the 5G or 6G network to execute a context-aware handover decision. This NF would derive information from the machine learning model, which is provided either by the 5G or 6G network or a third party, utilizing various context parameters outlined in Section 2.1.
[0120] 2.4 Procedures
[0121] This section discloses four scenarios, including gNB onboard NTN platform with the application of context-aware handover support in Section 2.4.1, mobile IAB node onboard satellite with context-aware handover in Section 2.4.2, IAB donor onboard satellite with the application of Context Aware Migration for Mobile IAB-DU in Section 2.4.3, and IAB donor onboard satellite with the application of Context Aware Migration for Mobile IAB-MT in Section 2.4.4. It is important to note that these are not exhaustive variations. The principles and mechanisms of context aware handover or context aware migration can be applied for handovers or migrations between instances deployed on any TN or NTN platforms. Similarly, the principles and mechanisms of IAB onboard satellite can facilitate handover, handoff, switchover, or migration across multi-orbit networks, multi-layer networks, or instances deployed at various altitudes to facilitate.
[0122] 2.4.1 gNB on board NTN platforms with context-aware handover support
[0123] Figure 7 illustrates an architecture where gNB / eNB, an NG-RAN node, or a 6G RAN node, or other radio access network technology is deployed on an NTN platform, e.g. LEO, MEO, GEO, LAPS or HAPS. UE initially established connectivity to communicate with core network via the RAN node deployed on the first TN or NTN network. Later on, UE determines that the pre-defined context aware conditions (e.g. QoS) are met, and execute handover to the RAN node deployed on the second TN or NTN network.
[0124] Figure 8 shows the call flow for this example where the context aware handover can be used to support UE to handover from the source gNB on GEO to Target gNB on LEO based on one or multiple conditions in Section 2.1, with the application of the strategy in Section 2.2, to evaluate the context and conditions as described in Section 2.3 to initiate the handover execution.
[0125] In steps 0a-0d, AF request containing information about context-aware handover conditions in Section 2.1 is created. AF validates the received information and derives the context aware parameters. AF may use subscribed NWDAF analytics information to determine context aware parameters or conditions. The request to provision the context aware handover information into the system (e.g. 5G core, 5G-Acore or 6G core) , and expose such information to NF, e.g. AMF
[0126] For example, UE may be required to handover from a GEO to LEO to support low latency IMS call. AF may generate proper parameters or conditions, e.g. 5QI value so that when UE makes such a call, the handover from GEO satellite to LEO satellite can be executed.
[0127] The context aware handover information can be provisioned into the data repository and data management functions in a system (e.g. UDM / UDR in 5G / 5G-Advance, or similar functions in 6G) . The information is also exposed to other NFs in such a system, e.g. AMF.
[0128] User Data (UD) may indicate the support of Context Aware Handover.
[0129] During registration, UE may indicate to the NF (e.g. AMF or SMF) that the context aware handover is supported.
[0130] In step 2, the context-aware handover execution conditions are provided to the source gNB from one or multiple 5G NF (s) , e.g. AMF or SMF, or one or multiple 6G NF (s) .
[0131] In step3, the Source gNB configures the UE measurement procedures and the UE reports according to the measurement configuration.
[0132] In step 4, based on the MeasurementReport and Radio Resource Management (RRM) information, source gNB makes context aware handover decision, and starts the handover preparation.
[0133] The source gNB requests Context Aware Handover for candidate cells belong to one or more candidate gNBs. A Context Aware Handover request message is sent for each candidate cell.
[0134] Admission Control may be performed by the target gNB.
[0135] The candidate gNB (s) sends Context Aware Handover response including the configuration of the Context Aware Handover candidate cells to the source gNB. The Context Aware Handover response message is sent to each candidate cell.
[0136] In step 5, the source gNB sends Context Aware Handover command to the UE using procedures, e.g. RRC Reconfiguration, or other 5G or 6G procedures. The Context Aware Handover command contains the configuration of Context Aware Handover candidate cell (s) and Context Aware Handover execution condition (s) .
[0137] In step 6, the UE maintains the connection with the source gNB after receiving Context Aware Handover configuration and starts evaluating the one or multiple context aware handover execution conditions for the candidate cell (s) as described in Section 2.1, with the application of the strategies as described in Section 2.2 and trigger the handover execution when these conditions are met based on the context processing methods described in Section 2.3.
[0138] In step 7, UE detach from the old cell and synchronize to the new cell and complete RRC Hanover completion steps as described in clause 9.2.3.4.2-1 of TS 38.300.
[0139] 2.4.2 Mobile IAB node onboard satellite with context-aware handover
[0140] In the other embodiment, mobile IAB node is onboard satellite as illustrated in Figure 9 where IAB nodes are deployed on NTN platforms. And IAB-donor is deployed on the ground. UE evaluates context-aware handover and determine whether to initiate a handover based on the context conditions.
[0141] Figure 10 shows the call flow for this scenario.
[0142] In steps 0a-0d, AF request containing information about context-aware handover conditions in Section 2.1 is created. AF validates the received information and derives the context aware parameters. AF may use subscribed NWDAF analytics information to determine context aware parameters or conditions. The request to provision the context aware handover information into the system (e.g. 5G core, 5G-Acore or 6G core) , and expose such information to one or multiple 5G NF, e.g. AMF, or one or multiple 6G NF. UE may indicate the support of the Context Aware Handover.
[0143] For example, UE may be required to handover from a GEO to LEO to support low latency IMS call. AF may generate proper parameters or conditions, e.g. 5QI value so that when UE makes such a call, the handover from GEO satellite to LEO satellite can be executed.
[0144] The context aware handover information can be provisioned into the data repository and data management functions in a system (e.g. UDM / UDR in 5G / 5G-Advance, or similar functions in 6G) . The information is also exposed to other NFs in such a system, e.g. AMF in 5G or one or multiple NF (s) in 6G.
[0145] In step 1, context aware information is sent to IAB-donor CU.
[0146] In step 2, Measure report from UE is sent to source Mobile IAB-node DU on GEO, and forwarded to IAB donor CU.
[0147] In step 3, the IAB donor CU makes context aware handover decision.
[0148] In steps 4a-4b, the IAB donor CU send message to the candidate IAB-node DU (s) to create UE context and set up one or more data bearers. The message is sent for each candidate cell and includes information for handover preparation.
[0149] The candidate IAB-node DU (s) responds to the IAB-donor CU with a message including the target cell ID that was requested from the IAB-donor CU. The message is sent for each requested candidate cell.
[0150] In step 5, the IAB donor CU send context-aware handover command to the source IAB-node DU. The Context Aware Handover command contains the configuration of context-ware handover candidate DUs and execution conditions, and the source IAB node DU forwards the message containing the Context aware handover command to the UE. The source IAB node DU responds to donor CU messages indicating that the context aware handover command has been sent to UE.
[0151] In steps 6-8, UE maintains the connection with the source IAB-node DU after receiving the context-aware handover configuration and starts to evaluate the context-aware handover execution conditions for the candidate cell (s) .
[0152] If at least one context-aware candidate cell satisfies the corresponding context-aware handover execution condition, the UE detaches form the source IAB node DU, applies the stored corresponding configuration for the selected candidate cell, synchronizes to that candidate cell, and completes the handover.
[0153] 2.4.3 IAB donor onboard satellite with the application of Context Aware Migration for Mobile IAB-DU
[0154] In-flight connectivity for commercial or military aircraft could initially rely on GEO satellites at cruising altitude, where constant coverage is more important than latency. As the aircraft descends or approaches regions with LEO coverage, it could hand off to LEO donors to provide faster, more responsive connectivity, especially during high-traffic periods like landing or in-flight entertainment.
[0155] In Figure 11, a Mobile IAB node is deployed e.g. on an aircraft. All UEs in this aircraft access network through the Mobile IAB node. The context aware handover mechanisms can be applied on the Mobile IAB-DU migration in this case to allow all UEs accessing this Mobile IAB node to handover e.g. from a path via source F1-terminating donor CU on GEO to a path via target F1-terminating donor CU on LEO.
[0156] Unlike scenarios in Section 2.4.1 and Section 2.4.2, F1-terminating IAB donor CU is onboard satellite, while the Mobile IAB node is equipped on an aircraft to provide service for the UEs inside the aircraft. In this case, as UE is connected to the IAB node DU, UE does not initiate context aware handover. However, the context aware handover principle can be applied to DU in Mobile IAB node to initiate migration from a source F1-terminating IAB donor onboard satellite to a target F1-terminating IAB donor onboard satellite.
[0157] The F1-terminating IAB donor could be onboard on any NTN platforms, e.g. LEO, GEO, HAPS, etc. Deployment of IAB donor on LEO satellites could improve access in isolated regions (e.g., islands, mountainous regions, or disaster zones) . As LEO satellites are constantly moving across the sky, which could lead to frequent handoffs between satellites. This might cause challenges for the IAB donor which relies on stable connections to backhaul links. However, modern LEO constellations inter-satellite links (ISLs) usually operate laser communications technology to mitigate this, ensuring seamless connectivity.
[0158] In addition to the in-flight connectivity scenario, there could be numerous other potential applications for the IAB donor onboard satellite architecture depicted in Figure 11. For example, it is likely the mobile IAB node equipped on ships or offshore platforms that travel over long distances may start with GEO satellite backhaul due to its wide coverage. As the ship moves into a region with denser LEO satellite coverage (e.g. near coastal areas or certain maritime zones) , it could hand off to a LEO donor to take advantage of lower latency and potentially higher bandwidth.
[0159] Emergency response vehicles or mobile units in remote areas (e.g. disaster recovery zones or temporary medical facilities) could initially connect to a GEO satellite to establish communication. However, as the response unit moves or satellite conditions change, switching to a LEO network could enhance real-time communications and data transfer.
[0160] A high-speed train or a long-haul truck that starts in a remote area with only GEO satellite coverage may eventually move into urban or semi-urban regions where LEO satellite constellations provide better performance.
[0161] Figure 12 shows call flow for the architecture illustrated in Figure 11.
[0162] In step 0, Core Network NF obtains context-aware handover information for IAB-MT through means, e.g. from AF, NWDAF, or other NFs.
[0163] In step 1, NF expose the Context Aware Handover / Migration information to Source F1-terminating IAB-donor CU.
[0164] In step 2, the source F1-terminating IAB-donor-CU makes migration decision.
[0165] In step 3, now that source logical DU and target logical DU are in the same Mobile IAB-node, the target logical DU knows the target F1-terminating IAB-donor CU information.
[0166] The target logical DU send message to the candidate F1-terminating IAB-donor-CU (s) to create one or multiple TNL and F1 connections.
[0167] The candidate target F1-terminating IAB-donor-CU responds to the target logical DU with a message including the configurations of these one or multiple TNL and F1 connections for migration preparation.
[0168] In step 4, OAM or Source F1-terminating IAB-donor-CU sends Context Aware Handover / Migration command to the mobile IAB-node (source logical DU) . The command contains configuration of the context-aware handover / migration candidate Transport Network Layer (TNL) and F1 connections, and execution conditions.
[0169] In step 5, Source logical DU maintains the connection with the source F1-terminating IAB-donor CU and starts to evaluate the context-aware migration execution conditions for the candidate TNL and F1 connections toward the target F1-terminating IAB-donor-CU.
[0170] In step 6, if at least one candidate F1-terminating IAB donor CU satisfies the corresponding context-aware migration execution conditions, the source F1-terminating IAB-donor-CU hands over the UE from a source cell served by the source logical mobile IAB-DU to a target cell served by the target logical mobile IAB-DU. The target F1-terminating IAB-donor-CU initiates traffic migration towards the RRC-terminating IAB-donor-CU for offloading the UE’s traffic during this step.
[0171] 2.4.4 IAB donor onboard satellite with the application of Context Aware Migration for Mobile IAB-MT
[0172] In Figure 13, the context aware handover mechanisms can be applied on the Mobile IAB-MT handover from a source RRC-terminating IAB-donor-CU deployed on a TN or NTN platform to target RRC-terminating IAB-donor-CU deployed on the same type of or a different type of TN or NTN platforms.
[0173] Figure 14 shows the procedures for Mobile IAB-MT handover with the application of Context Aware Handover.
[0174] In step 0, the core Network NF (s) obtains context-aware handover information for IAB-MT through means, e.g. from AF, NWDAF, or other NFs.
[0175] In step 1, the NF (s) expose the Context Aware Handover information to Source RRC-terminating IAB-donor CU.
[0176] In step 2, the source RRC-terminating IAB-donor-CU decides to handover the IAB-MT, based on MeasurementReport and RRM information.
[0177] In step 3, the source RRC-terminating IAB-donor CU requests Context Aware Handover for one or multiple candidate Target RRC-terminating IAB-donor-CU. Admission Control may be performed by the target RRC-terminating IAB-donor CU. If admitted, the candidate RRC-terminating IAB-donor-CU sends Context Aware Handover response including the configuration of the Context Aware Handover candidate cell (s) to the source RRC-terminating IAB-donor CU.
[0178] In step 4, the source RRC-terminating IAB-donor-CU sends Context Aware Handover command containing configuration of context-aware handover candidate cells and execution conditions. Mobile IAB-node MT confirms the reception of the command.
[0179] In step 5, the IAB-node MT maintains the connection with the source RRC-terminating IAB-donor-CU.
[0180] The IAB-MT evaluates the Context Aware Handover execution conditions for the candidate cells.
[0181] In step 6, if at least one context aware handover candidate cell satisfies the corresponding context aware handover execution condition, the IAB-MT detaches from the source RRC-terminating IAB-donor-CU, applies the stored corresponding configuration for the selected candidate cell, synchronizes to that candidate cell, and completes the handover.
[0182] In summary, the key benefits of this application include,
[0183] -Seamless Connectivity: Reduced interruptions during handover.
[0184] -Optimized Performance: Better alignment of network capabilities with user needs.
[0185] -Resource Efficiency: Improved utilization of network infrastructure.
[0186] The embodiment of the present application further provides a communication device. The communication device includes a processor, configured to call and run program instructions stored in a memory, to execute corresponding processes implemented in each of the methods of the embodiments of the present application. For brevity, details will not be described herein again.
[0187] The embodiment of the present application further provides a computer readable storage medium for storing a computer program. The computer readable storage medium enables a computer to execute corresponding processes implemented in each of the methods of the embodiments of the present application. For brevity, details will not be described herein again.
[0188] The embodiment of the present application further provides a computer program product including computer program instructions. The computer program product enables a computer to execute corresponding processes implemented in each of the methods of the embodiments of the present application. For brevity, details will not be described herein again.
[0189] The embodiment of the present application further provides a computer program. The computer program enables a computer to execute corresponding processes implemented in each of the methods of the embodiments of the present application. For brevity, details will not be described herein again.
[0190] Those of skill in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
[0191] Further, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
[0192] The methods, sequences and / or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
[0193] It should be understood that any embodiments disclosed herein as being “non-transitory” do not exclude any physical storage medium, but rather exclude only the interpretation that the medium can be construed as a transitory propagating signal.
[0194] The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.
[0195] Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and / or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.
[0196] Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’ , ‘an’ , ‘first’ , ‘second’ , etc. do not preclude a plurality.
[0197] Above all, while the preferred embodiments of the present application have been illustrated and described in detail, various modifications and alterations can be made by persons of ordinary skill in the art. The embodiment of the present application is therefore described in an illustrative but not restrictive sense. It is intended that the present application should not be limited to the particular forms as illustrated, and that all modifications and alterations which maintain the spirit and realm of the present application are within the scope as defined in the appended claims.
Claims
1.A handover / migration method, comprising:establishing connectivity to communicate with a core network via a source network node;receiving from the source network node configuration of one or more candidate communication connections and context aware handover / migration execution condition;determining whether the context aware handover / migration execution condition is satisfied;if the context aware handover / migration execution condition is satisfied for a target communication connection among the one or more candidate communication connections, executing handover / migration to the target communication connection, which belongs to a target network node.2.The method of claim 1, further comprising:if the context aware handover / migration execution condition is not satisfied, maintaining communication connection with the source network node.3.The method of claim 1, further comprising:indicating to the core network that context aware handover / migration is supported.4.The method of claim 1, wherein the context aware handover / migration execution condition is from the core network.5.The method of claim 1, further comprising:calculating a score for each of the one or more candidate communication connections by weighting context parameters;deciding to handover / migrate to the target communication connection when the score of the target communication connection is greater than or equal to a threshold.6.The method of claim 1, wherein the context aware handover / migration execution condition is based on context information comprising at least one of the followings: network context, user context, device context, environmental context, and service / application context.7.The method of claim 1, wherein the network context comprises at least one of the followings: signal quality, available bandwidth, latency and jitter, network topology, and link stability.8.The method of claim 1, wherein the user context comprises at least one of the followings: quality of service (QoS) requirements, mobility patterns, and user preferences.9.The method of claim 1, wherein the device context comprises at least one of the followings: battery level, hardware capabilities, and application usage.10.The method of claim 1, wherein the environmental context comprises at least one of the followings: geographical location, weather conditions, and interference levels.11.The method of claim 1, wherein the service / application context comprises at least one of the followings: type of service, priority levels, and session continuity requirements.12.The method of claim 1, wherein the source network node is a radio access network (RAN) node deployed on a first network, and the target network node is a RAN node deployed on a second network.13.The method of claim 1, wherein the source network node and the target network node are different integrated access and backhaul (IAB) -node distributed units (DUs) connecting to a same IAB donor centralized unit (CU) .14.The method of claim 1, wherein the source network node and the target network node are different IAB-donor-CUs.15.The method of claim 14, wherein the IAB-donor-CUs are F1-terminating IAB-donor-CUs.16.The method of claim 14, wherein the IAB-donor-CUs are RRC-terminating IAB-donor-CUs.17.The method of claim 1, wherein the one or more candidate communication connections are cell connections.18.The method of claim 1, wherein the one or more candidate communication connections are F1 connections.19.The method of claim 1, wherein the handover / migration to the target communication connection is executed by one of the followings: user equipment (UE) , IAB-node DU, and IAB-node mobile-termination (MT) .20.A handover / migration method, comprising:receiving context aware handover / migration information from a core network;making context aware handover / migration decision at least based on the context aware handover / migration information;sending to a network node configuration of one or more candidate communication connections and context aware handover / migration execution condition for the network node to handover / migrate to a target communication connection of the one or more candidate communication connections based on the context aware handover / migration execution condition.21.The method of claim 20, wherein the context aware handover / migration decision is made based on context information comprising at least one of the followings: network context, user context, device context, environmental context, and service / application context.22.The method of claim 20, wherein the context aware handover / migration decision is made based on energy efficiency strategy in consideration of energy consumption of network resource.23.The method of claim 20, wherein the context aware handover / migration decision is made for handover / migration between network slices.24.The method of claim 20, wherein the context aware handover / migration decision is made in consideration of service type.25.The method of claim 20, wherein the context aware handover / migration decision is made based on real-time load information.26.The method of claim 20, wherein the context aware handover / migration decision is made by incorporating historical data to understand long-term trends.27.The method of claim 20, wherein the context aware handover / migration decision is made based on backhaul network conditions.28.The method of claim 20, further comprising:receive an indication from the core network to execute the context aware handover / migration decision.29.A handover / migration method, comprising:receiving analytics information that is related to handover / migration and is obtained by analyzing context data using a machine learning model;deriving context aware handover / migration condition or parameter based on the received analytics information;provisioning context aware handover / migration information comprising the context aware handover / migration condition or parameter, wherein the context aware handover / migration condition or parameter is for being used to make context aware handover / migration decision.30.The method of claim 29, wherein the context aware handover / migration condition or parameter is derived from context information comprising at least one of the followings: network context, user context, device context, environmental context, and service / application context.31.The method of claim 29, wherein the analytics information is received from network data analytics function (NWDAF) .32.The method of claim 29, wherein the context aware handover / migration information is provisioned to at least one of the followings: access and management function (AMF) , user data management function (UDM) , and user data repository function (UDR) .33.A communication device, comprising a processor, configured to call and run program instructions stored in a memory, to execute the method of any of claims 1 to 19.34.A communication device, comprising a processor, configured to call and run program instructions stored in a memory, to execute the method of any of claims 20 to 28.35.A communication device, comprising a processor, configured to call and run program instructions stored in a memory, to execute the method of any of claims 29 to 32.36.A non-transitory machine-readable storage medium having stored thereon instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 32.37.A chip, comprising:a processor, configured to call and run a computer program stored in a memory, to cause a device in which the chip is installed to execute the method of any one of claims 1 to 32.38.A computer readable storage medium, in which a computer program is stored, wherein the computer program causes a computer to execute the method of any one of claims 1 to 32.39.A computer program product, comprising a computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 32.40.A computer program, wherein the computer program causes a computer to execute the method of any one of claims 1 to 32.