Mobility strategy pre-verification via digital-twin-based communication

Abstract

Systems, methods, and apparatus for wireless communication are described. The methods, among other benefits, improve the handover efficiency and consequently a user's mobility experience. An example method includes determining, by a network device and based on one or more digital twin (DT) operations or services, one or more mobility strategies. The method further includes triggering or executing, by the network device and based on the one or more mobility strategies, a handover operation. Another example method includes transmitting, by a network device, a digital twin (DT) service request for determining one or more mobility strategies associated with a handover operation. The method further includes receiving, by the network device and in response to the DT service request, a DT service response.

Description

MOBILITY STRATEGY PRE-VERIFICATION VIA DIGITAL-TWIN-BASED COMMUNICATIONTECHNICAL FIELD

[0001] This patent document is directed generally to wireless communications.BACKGROUND

[0002] Mobile telecommunication technologies are moving the world toward an increasingly connected and networked society. In comparison with the existing wireless networks, next-generation systems and wireless communication techniques will need to support a much wider range of use-case characteristics and provide a more complex and sophisticated range of access requirements and flexibilities.

[0003] Long-Term Evolution (LTE) is a standard for wireless communication for mobile devices and data terminals developed by 3rd Generation Partnership Project (3GPP) . LTE Advanced (LTE-A) is a wireless communication standard that enhances the LTE standard. The 5th generation of wireless system, known as 5G, and the 6th generation of wireless system, known as 6G, advance the LTE and LTE-Awireless standards and are committed to supporting higher data rates, large number of connections, ultra-low latency, high reliability, and other emerging business needs.SUMMARY

[0004] The present patent document discloses methods to pre-verify a handover strategy using digital twin (DT) technology. A serving network (NW) device with a DT capability can perform local DT operations. Alternatively, the serving NW device can request a target NW device to perform DT services. In some embodiments, multiple DT operations or services can be performed based on multiple cells or network devices in a target cell set. In some embodiments, multiple DT operations or services can be performed based on multiple possible future tracks of a wireless device. In some embodiments, the pre-verification is in parallel with a physical handover. If a DT service request is rejected, the serving NW device can trigger another handover strategy pre-verification. If the target NW device does not respond within a waiting time T, the serving NW device can initiate a physical handover. The disclosed methods, among other benefits, improve the handover efficiency and consequently a user’s mobility experience.

[0005] A first example wireless communication method includes determining, by a network device and based on one or more digital twin (DT) operations or services, one or more mobility strategies. The method further includes triggering or executing, by the network device and based on the one or more mobility strategies, a handover operation.

[0006] A second example wireless communication method includes transmitting, by a network device, a digital twin (DT) service request for determining one or more mobility strategies associated with a handover operation. The method further includes receiving, by the network device and in response to the DT service request, a DT service response.

[0007] A third example wireless communication method includes receiving, by a wireless device, a digital twin (DT) service response related information associated with one or more mobility strategies. The method further includes transmitting, by the wireless device and after performing a handover operation associated with a mobility strategy of the one or more mobility strategies, a DT service performance evaluation result.

[0008] A fourth example wireless communication method includes triggering or executing, by a network device and in parallel with one or more digital twin (DT) operations or services in an overlapping time frame, a physical handover operation, where the one or more DT operations or services are for determining one or more mobility strategies.

[0009] Note that where the patent document discloses a method of transmitting an information by a first device to a second device, it will be understood that a method of receiving the information by the second device from the first device is also disclosed. Similarly, where a method of receiving a message by a first device from a second device is disclosed, it will be understood that the message is transmitted by the second device to the first device.

[0010] In yet another example embodiment, a device that is configured or operable to perform the above-described methods is disclosed. The device includes at least one processor configured to implement the above-described methods.

[0011] In yet another example embodiment, the above-described methods are embodied in the form of processor-executable code and stored in a non-transitory computer-readable storage medium. The code included in the computer readable storage medium when executed by a processor, causes the processor to implement the methods described in this patent document.

[0012] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 illustrates an example non-split radio access network (RAN) .

[0014] FIG. 2 illustrates an example split RAN.

[0015] FIG. 3 illustrates an example digital twin (DT) system.

[0016] FIG. 4 illustrates an example wireless system without a DT capability.

[0017] FIG. 5 illustrates an example wireless system with a DT capability.

[0018] FIG. 6 illustrates an example DT service procedure.

[0019] FIG. 7 illustrates an example DT service outcome reporting procedure.

[0020] FIG. 8 illustrates an example DT service performance evaluation procedure.

[0021] FIG. 9 illustrates an example handover strategy pre-verification procedure.

[0022] FIG. 10 illustrates an example handover strategy pre-verification procedure based on a track prediction.

[0023] FIG. 11 illustrates an example handover strategy pre-verification procedure in parallel with a physical handover.

[0024] FIG. 12 illustrates an example handover strategy pre-verification procedure if a first DT service is rejected.

[0025] FIG. 13 illustrates an example handover strategy pre-verification procedure if a target network (NW) device does not respond.

[0026] FIG. 14 is an example flowchart for determining a mobility strategy based on a DT operation or service.

[0027] FIG. 15 is an example flowchart for a DT service procedure.

[0028] FIG. 16 is an example flowchart for a DT service performance evaluation procedure.

[0029] FIG. 17 is an example flowchart for triggering a physical handover in parallel with a DT operation or service.

[0030] FIG. 18 illustrates an example block diagram of a hardware platform that may be a part of a network device or a wireless device.

[0031] FIG. 19 illustrates example wireless communication including a Base Station (BS) and User Equipments (UEs) based on some implementations of the disclosed technology.DETAILED DESCRIPTION

[0032] The example headings for the various sections below are used to facilitate the understanding of the disclosed subject matter and do not limit the scope of the claimed subject matter in any way. Accordingly, one or more features of one example section can be combined with one or more features of another example section. Furthermore, 5G and 6G terminology is used for the sake of clarity of explanation, but the techniques disclosed in the present document are not limited to 5G and 6G technology only and may be used in wireless systems that implemented other protocols, e.g., ambient-IoT.

[0033] I. Introduction

[0034] The present patent document discloses methods to pre-verify a handover strategy using digital twin (DT) technology. The disclosed methods, among other benefits, improve the handover efficiency and consequently a user’s mobility experience.

[0035] Currently, the system level simulation and service performance / experience pre-verification based on DT (digital twin) technologies are mainly used in non-real-time technical fields such as wireless network planning, optimization of various OAM issues, and other system high level aspects. The current DTN (Digital Twin Network) paradigm presents the characteristics of “offline simulation / execution” + “external mounting DT  capability” for its deployment and operation, so it is not deeply integrated / coupled with the logical architecture and service workflows of wireless communication system. The applicability, benefit, performance gain, and operation efficiency with DTN still need to be extended and improved. The 6G wireless communication system aims to natively support / integrate the DTN technologies and applications, and the logical architecture, node functions, and service workflows of the 6G initial system version are supposed to equipped with DT capability and to support various kinds of system level simulations and service performance / experience pre-verification via DTN driven by real physical data (i.e., presenting the characteristics of “inline simulation / execution” + “internal / native mounting DT capability” ) , and furthermore the 6G wireless communication system can by itself “manage and control internally” various DTN operations in, e.g., 3GPP standardized manner. Among all benefits and gains achievable from various DTN operations, continuous enhancement of mobile user’s applications / communication mobility experience in the system run time is always pursued and targeted. Therefore, methods and devices with internal DT capability and potential 3GPP standardization impacts are required for natively applying DTN technologies in 6G wireless system, in order to enhance the mobile user’s mobility experiences.

[0036] The below paragraph describes the background for 3GPP UE in Single Connectivity (SC) .

[0037] In the IMT wireless communication systems (such as 5G-NR specified by 3GPP) as shown in FIG. 1 and FIG. 2, the Core Network (CN) consists of various types of control plane (CP) nodes or entities, e.g., 5G AMF / SMF, and user plane (UP) node or entity, e.g., 5G UPF. In the RAN non-split case in FIG. 1, the RAN node, e.g., 5G aggregated gNB consists of CP part and UP part together, and then terminates on UE via radio link (RL) in the air. In the RAN split case in FIG. 2, the RAN node, e.g., 5G dis-aggregated gNB consists of CU-CP node, CU-UP node and DU node or entities, and then terminates on UE via RL in the air. The CP part or node is responsible for generating, processing and transferring control signaling, e.g., for (re) configuring and monitoring nodes. The UP part or node is responsible for processing and transferring user UP data, e.g., normally associated with mobile APP and Web services etc. outside. For both CP and UP plane, they have their own interface &protocol stack and normally span from CN domain to RAN network and then to UE.

[0038] The below paragraphs describe the background for DTN technology and capability.

[0039] The basic principles of the DTN technology applied in wireless system are as follows. Based on the DTN task input of specific user (e.g., mobile user or wireless network OAM personnel) , real-time data collection from physical world and digital modeling in digital world are performed for specific “physical object” in the wireless system to create the corresponding “digital twin entity” (digital mapping / representative of the “physical object” with mirrored behaviors / characteristics) . Furthermore, based on the “digital planning entity” (digital planned / expected target status of “physical object” ) created by user’s evolution intention or “physical object’s ” own evolution demand, the DT system implements a specific-level simulation strategy and execution operation, so continuously drives the “digital twin entity” to evolve towards and approach the expected target status of the “digital planning entity. ” With above process, the DTN user can predict and pre-verify the causal relationship between the objective trend, direction, status, conditions, path, and effect with the “physical object” to some extent. Therefore, the DTN technology can assist various network users in predicting required conditions for development or change of network nodes, and in foreseeing various internal causal relationships inside wireless  system (if such relatively strong inevitable probability, regularity, and deterministic causal relationship indeed exist objectively) , hence the network users can more quickly identify and locate a network problem and figure out optimal solutions and their performance effects with different conditions. With DTN technology, unnecessary practical trial in physical world, or error and extra resource cost caused by implementation of wrong or sub-optimal solutions in physical world can be avoided as much as possible. In the DTN, there are also negative impacts due to incomplete / non-real time data collection, inaccurate DT modeling, dynamic environment changes and irregular / randomized interference, hence the benefit and gain of DTN for wireless networks are not 100%absolute and deterministic, and they are also affected by the limited resources and conditions of wireless system. Although the results of “prediction and pre-verification” and “optimal solution” via DTN are not 100%true and trustworthy, they can still be used as good tactical references to improve or optimize wireless network through multiple rounds of “closed-loop iteration, ” so as to achieve more reliable and trustworthy gains.

[0040] The basic functional modules for a DT system is shown in FIG. 3. The “Application Function” and “Communication Function” etc. can be the requesting entity for particular DT service. The DT system receives the “DT service request” from the applications / communication entity, and sends back the “DT service response” after DT service admission control; then the DT system performs the requested simulation and pre-verification operation based on DT service related data exchanged with applications / communication entity. Finally, the DT system sends the “DT service outcomes” to the applications / communication entity. The applications / communication entity obtains the DT service outcomes, i.e., prediction of something requested ahead.

[0041] The below paragraphs describe a wireless system with a DT capability.

[0042] With the advanced DTN technology integrated into a wireless system, the logic architecture, feature functions, service flows, and various performances of the 6G wireless system will be affected in standardized sense and further enhanced. From 6G mobile users’ perspective, their application and communication mobility experiences can be enhanced based on simulation and pre-verification operations with 6G DT capability.

[0043] As shown in FIG. 4, in a wireless system without a DT capability, all communication service behaviors of a UE or a NW node are based on real physical event requirements, and later on real physical event occurs in physical world.

[0044] As shown in FIG. 5, the DT system (as shown in FIG. 3) is introduced into NW nodes (includes UE) , hence they can provide the simulation and pre-verification for the requested DT service from internal or external application / communication function entities. With the DT capability, some application / communication service behaviors of a UE or a NW node can be simulated based on virtual digital event requirements, and real physical event does not occur in first time, but the virtual digital event occurs firstly for performance prediction and pre-verification. Therefore, no matter whether the handover / addition / deletion of the serving cell is to be applied for particular served UE, it can be performed in the virtual digital world firstly to avoid unnecessary or improper mobility strategy execution in the physical world.

[0045] The paragraph below describes the benefits and gains from DTN operations.

[0046] In the dynamic radio environment, the mobile user’s mobility experience is often influenced or degraded by lots of factors, such as user behaviors, radio conditions and mobility strategy, etc. In the physical run time with a current wireless system, the pending user mobility experience of particular mobility strategy are not predictable or cannot be pre-verified in advance, hence upon it triggering, the mobile user usually has to go ahead regardless of the potential outcomes. In the physical run time with a wireless system with DT capability, the pending user mobility experience of particular mobility strategy are predictable and can be pre-verified to some extent (though not 100%true) in advance, hence the mobile user may have more tactical choices before conducting the strategies, e.g., not always going ahead immediately but taking into account of potential outcomes. With DTN operation assistance, the mobile user and NW node may form into more cautious and rational behaviors for mobility handling. The more cautious and rational behaviors of mobile user and NW node shall not only save the resources of wireless system by optimal usage (not executing the improper mobility strategy leading to bad mobility handling for UE) , but also enhance the user’s mobility experiences in field.

[0047] Some basic definitions are given as follows:

[0048] “physical world” : the objective real world where the physical wireless system and services are deployed and running.

[0049] “physical object” : the various tangible and intangible things in physical world.

[0050] “digital world” : the artificial virtual world where the DTN system and services are deployed and running.

[0051] “digital twin entity” : digital mapping / representative of the "physical object" with mirrored behaviors / characteristics in digital world.

[0052] “digital planning entity” : digital planned / expected target status of "physical object" in digital world.

[0053] “DT operation” : including various simulations and pre-verification for certain function / performance / experience aspects of wireless services.

[0054] “DT service” : asking for certain DT operation as kind of service from the requesting entity.

[0055] Note that NW node is equivalent to NW device.

[0056] Before specific embodiments are describes, the following points are to be highlighted for enhancing the mobile user’s mobility experiences (i.e., essential part of user QoE) via DTN.

[0057] 1: The current serving NW node of UE is capable of DT (Digital Twin) , so it has “DT system” inside and can perform local DT operation or send DT service request to another NW node for performing DT operation instead.

[0058] 1-1: The current serving NW node may trigger one or multiple times of DT operation or DT service for the pre-verification of mobility strategies while deciding to perform certain mobility strategy and corresponding actions (e.g., intra / inter system redirection, HO, CA, DC as specified in 3GPP, etc. ) . This patent shall focus on the handover case.

[0059] 1-2: After the current serving cell makes a handover decision and determines the potential target cell, the current serving NW node may trigger multiple DT operations or DT services of multiple different target NW nodes in parallel, if the potential target cell set includes cells from different NW nodes. The current serving NW node may trigger pre-verification of mobility strategies with different potential target cells in one DT service, if there are multiple potential target cells in that target NW node. The current serving NW node may trigger multiple DT operations or DT services in parallel for different mobility strategies.

[0060] 1-3: If the current serving NW node initiates pre-verification based on UE track prediction, and there is more than one possible future track of UE, or NW node needs to execute mobility strategies for multiple times at a future time, the target NW node may perform multiple DT operations or DT services for mobility strategy for one DT service request.

[0061] 1-4: Based on the outcomes of DT operation or DT service conducted by DT system in the target NW node (s) , the current serving NW node may decide whether and when to perform certain mobility strategy, i.e., handover to which potential target cell (s) . Though the outcome of DT operation or DT service from the target NW node indicates that the result of certain handover action is not satisfactory, the current serving NW node can still continue to execute the mobility strategy as decided.

[0062] 1-5: The current serving NW node may also trigger / execute the handover action before receiving the outcomes of DT operation or DT service conducted by DT system in the target NW node (s) .

[0063] 2:In the DT service execution process, the NW node (s) shall send and receive the messages via Xn (between RAN nodes) or NG (between RAN node and CN node) alike interfaces, containing the DT service execution related information.

[0064] 2-1: In messages sent by current serving NW node to target NW node, the DT service execution related information may include such as:

[0065] “DT service request indicator” ;

[0066] “DT service identification information” : may include DT service id, etc.

[0067] “DT service type” ;

[0068] “DT service assistance info for DT modelling and planning” : may include UE measurement report, HandoverRequest information (may include ProtocolIEs, GUAMI, targetCellGlobalID, UEContextInfo, Handover Reason indicator, etc. ) , UE mobility strategy information, time period during which the DT service should pre-verify, the waiting time T that the request initiator can endure, etc.

[0069] “DT service report related information” : indicators of the parameters (e.g., key indicators of pre-verification, time range of pre-verification) to be included, report mode (who and when to report) ;

[0070] “DT service priority” .

[0071] 2-2: In messages sent by target NW node to current serving NW node, the DT service response related information may include such as:

[0072] “DT service response indicator for DT service” : indicates the acceptation or rejection of the request;

[0073] “DT service identification information” : DT service id, etc.

[0074] “DT service type” ;

[0075] “DT service rejection Reason indicator” ;

[0076] “DT service report identification information” ;

[0077] “DT service report” : may include UE ID , target cell ID, “DT modelling and planning outcomes” , “DT service outcomes of DT simulation and pre-verification” (may include simulation results of key indicators) , time / time range of pre-verification, etc.

[0078] 3:UE is capable of DT (Digital Twin) , so it has “DT system” inside. It can parse the DT service response related information and / or report / feedback the DT performance evaluation result of DT service to the target NW node conducted DT operation or DT service after handover action.

[0079] 3-1: UE can receive DT service response information from the current serving NW node or the target NW node, learn about the network conditions, and perform proper handover operations.

[0080] 3-2: If UE handovers to a target NW node ever conducting DT operation or DT service for it, UE can send DT service performance evaluation related information to that target NW node through the RRC procedure (s) . The DT service performance evaluation related information includes such as:

[0081] “DT service performance evaluation indicator” ;

[0082] “DT service identification information” : DT service id, etc.

[0083] “DT service type” ;

[0084] “UE identification information” : identifies the UE that completes the evaluation.

[0085] “Excellent / Good / Bad level judgement indicator” ;

[0086] “Yes / No or x%for enhancing user’s experiences related to mobility” .

[0087] 3-3: Based on the DT service performance evaluation result, the target NW node ever conducting DT operation or DT service may adjust / optimize its detailed handling of DT service execution at a future time.

[0088] 4: The current serving NW node may trigger / execute the handover action physically, in parallel to ongoing DT services in the overlapping time frame.

[0089] 4-1: The target NW node may execute the handover action triggered by the current serving NW node physically, in parallel to ongoing DT operations in the overlapping time frame.

[0090] FIG. 6 shows the DT service request, response, and DT service outcome reporting procedure related to point 2 and point 3-1. DT service outcome report may: 1) Report to the current serving NW node for reference,  and let the current serving NW node decide whether to notify UE; 2) Directly notify UE (after UE accesses the target NW node) ; 3) No feedback.

[0091] FIG. 7 shows the procedure related to point 4 and point 1-5, taking HO as an example. The current service NW node may: The current serving NW node may be: 1) . Makes physical handover decisions in accordance with the DT service report sent by the target NW node. 2) . Makes physical handover decisions and requests before receiving a DT service outcome report. Other possible handovers, such as CHO and LTM, are similar, except that UE evaluation and cell selection may be added, or the access procedure may be different.

[0092] FIG. 8 shows DT service performance evaluation procedure related to point 3-2, taking HO as an example. After accessing the target NW node, UE can feedback its DT service performance evaluation to the target NW node.

[0093] II. Embodiment 1

[0094] Embodiment 1 describes current serving NW node triggering target NW node for handover strategy pre-verification.

[0095] The below paragraphs describe the background.

[0096] Assuming a multi-mode UE is moving. In traditional communication systems, when the information reported by UE displays the signal quality of the current serving cell is degraded, the serving NW node should execute mobility strategy, e.g., cell handover, to cope. When the UE is in a heterogeneous coverage environment (multi-type RAT, multi-frequency multi-cell overlapping coverage, macro-micro intra-frequency coordination) , there may be multiple potential target cells, the current serving NW node should select the best target cell (set) in time. In a manner without assistance of a digital twin technology, e.g., the serving NW node uses current signal quality and strength of the potential target cells as references, it cannot guarantee the service quality of the UE after the UE accesses the target NW node.

[0097] With the assistance of DTN, before the serving NW node executes the handover action, the target NW node can provide references and advice through “DTN based service performance pre-verification” , so that the current serving NW node and the UE can know the performance of UE after accessing to that target NW node. As results, the current serving NW node can make more reasonable decisions to guarantee the QoS of the UE.

[0098] This embodiment 1 considers that when the current serving NW node determines to hand over to a cell (or cells) of another NW node, it initiates a DTN based pre-verification request to the target NW node before physically initiating the handover request to that NW node. In such case, the current serving NW node is willing to await some while before executing the mobility strategy physically.

[0099] The below paragraphs describe the implementation steps.

[0100] Step 101: UE sends measurement report to the current serving NW node (hereinafter referred to as the NW node1) , and NW node1 makes a handover decision and determines the potential target cell (set) , including servercellId, PCI, SSBID, SSB RSRP / RSRQ, etc. of the target serving cell (s) . The communication  function of NW node1 initiates a DTN based pre-verification service request for certain handover decision to its local DT system and provides necessary information related to physical handover action, such as handover reasons, targetCellID, UEAMBR, UESecurityCapabilities, SecurityInformation, etc. After receiving the request, the DT system of NW node1 generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = mobility strategy pre-verification" , "DT service ID = 0001" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T, UE measurement report, HandoverRequest information, etc. ) .

[0101] Step 102: The communication function of the NW node1 sends Message1 (containing the DT service execution related information generated in Step 101) to the target NW node (hereinafter referred to as the NW node2) through the Xn or NG interface. The forms of Message1 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0102] Step 103: The communication function of the NW node2 identifies that the Message1 contains information related to DT service requests, so sends it to its own DT system for content parsing and subsequent processing.

[0103] Step 104: The DT system of the NW node2 parses and analyzes the received DT service request, e.g., checking whether the pre-verification service is within its supported service scope, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = Yes" , "DT service ID = 0001" , etc.

[0104] Step 105: The communication function of the NW node2 sends Message2 to the communication function of the NW node1 via Xn or NG interface, which contains the DT service response related information generated in Step 104. The forms of Message2 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0105] Step 106: The DT service of the NW node2 simulates and pre-verifies the performance after the UE is accessed through local DT operations (may take several seconds or has to be completed within the T-time indicated by NW node1) . The performance evaluation indicators may include future data transmission (average / guaranteed) rate, transmission delay, link robustness, and energy consumption of UE, future load changes of the NW node2, etc. The evaluation indicators may be provided by NW node1 or NW node2, or both. NW node2 generates DT service response related information, which may include “DT service id = 0001” , “DT service report identification information” , “DT service report” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0106] Step 107: The communication function of the NW node2 sends Message3 to the communication function of the NW node1 via Xn or NG interface, and the message contains the DT service response related information generated in Step 106, so that NW node1 can understand the network condition and the performance of UE after executing corresponding handover action. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0107] Step 108: NW node1 parses the content of Message3 and, based on the information in Message3, decides to whether and when to perform handover action to the target cell (s) . In case of handover to the target cell of NW node2, NW node1 can initiate the physical handover request.

[0108] Step109: NW node1 can send Message4 to UE through the RRC procedure, notifying UE of the decision and performance of the mobility strategy. Message4 may include the DT service response related information. The forms of Message 4 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0109] III. Embodiment 2

[0110] Embodiment 2 describes current serving NW node triggering target NW node for handover strategy pre-verification based on track prediction.

[0111] The below paragraph describes the background.

[0112] In the background similar to Embodiment 1, the current serving NW node can predict the future track of the UE in accordance with the UE context information and its measurement report, and optimize mobility strategy (e.g., intra / inter system redirection, HO, CA, DC, etc. ) based on the future track. For example, when it is predicted that the signal quality of the UE may degrade at a future time, cell handover or other mobility optimization-related operations are prepared in advance. This embodiment 2 considers that if the serving NW node believes that handover to a cell (or cells) of another NW node may be necessary at a future time, it initiates a DTN based pre-verification request to that target NW node. According to the verification report, the current serving NW node can instruct the UE to hand over to the proper cell at a proper time, or notify UE of the execution condition for triggering CHO. In this way, when the UE moves to the corresponding location, cell handover can be triggered in time, avoiding the QoS degradation or interruption of service.

[0113] The below paragraphs describe the implementation steps.

[0114] Step 201: UE sends measurement report to the current serving NW node (hereinafter referred to as the NW node1) , and NW node1 makes a handover decision and determines the potential target cell (set) , including servercellId, PCI, SSBID, SSB RSRP / RSRQ, etc. of the target serving cell (s) . The communication function of NW node1 initiates a DTN based pre-verification service request for certain mobility strategy to its local DT system and provides necessary information, such as handover reasons, UEAMBR, UESecurityCapabilities, SecurityInformation, etc. After receiving the request, the DT system of NW node1 generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = Mobility strategy pre-verification" , "DT service ID = 0001" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T, UE measurement report, HandoverRequest information, etc. ) .

[0115] Step 202: The communication function of the NW node1 sends Message1 (containing the DT service execution related information generated in Step 201) to the target NW node (hereinafter referred to as the NW node2) through the Xn or NG interface. The forms of Message1 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0116] Step 203: The communication function of the NW node2 identifies that the Message1 contains information related to DT service requests, so sends it to its own DT system for content parsing and subsequent processing.

[0117] Step 204: The DT system of the NW node2 parses and analyzes the received DT service request, e.g., checking whether the pre-verification service is within its supported service scope, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = Yes" , "DT service ID = 0001" , etc.

[0118] Step 205: The communication function of the NW node2 sends Message2 to the communication function of the NW node1 via Xn or NG interface, which contains the DT service response related information generated in Step 204. The forms of Message2 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0119] Step 206: The DT service of the NW node2 simulates and pre-verifies the performance of UE after accessed through local DT operations (may take several seconds or has to be completed within the T-time indicated by NW node1) . The performance evaluation indicators may include future data transmission (average / guaranteed) rate, transmission delay, link robustness, and energy consumption of UE, future load changes of the NW node2, etc. The evaluation indicators may be provided by NW node1 or NW node2, or both. The NW node2 performs pre-verification for each possible track, each possible target cell, and each possible handover provided by the NW node1. then generates DT service response related information, which may include “DT service id = 0001” , “DT service report identification information” , “DT service report” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0120] Step 207: The communication function of the NW node2 sends Message 3 to the communication function of the NW node1 via Xn or NG interface, and the message contains the DT service response related information generated in Step 206, so that NW node1 can understand the network condition and the performance of UE after executing corresponding mobility strategy. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0121] Step 208: NW node1 parses the content of Message3 and, based on the information in Message3, decides to whether and when to perform certain mobility strategy to the potential target cell (s) . In case of connecting to the target cell of NW node2, NW node1 can initiate the physical handover request to NW node2 if the preset conditions are met, e.g., the UE reaches the preset location, the signal quality decreases to the preset threshold.

[0122] Step 209: NW node1 can send Message4 to UE through the RRC procedures, notifying UE of the decision and performance of the mobility strategy. Message4 may include the DT service response related information. The forms of Message4 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0123] Step 210: If UE executes the mobility strategy and accesses to the cell (s) of NW node2, UE can evaluate the real performance of DT service, and generate the DT service performance evaluation related information, which may include information such as: “DT service id” , “Excellent / Good / Bad level judgement indicator” , “Yes / No or x%for enhancing mobile user’s mobility experiences” .

[0124] Step 211: The communication function of UE sends Message5 to the communication function of the NW node2 through the RRC procedure, and the message contains the DT service performance evaluation related information generated in Step 210. Based on Message5, NW node2 may adjust its execution of DT service and optimize performance of the pre-verification at a future time.

[0125] IV. Embodiment 3

[0126] Embodiment 3 describes current serving NW node triggering a more suitable NW node for handover strategy pre-verification in parallel to physical handover.

[0127] The below paragraph describes the background.

[0128] In the same background as Embodiment 1, in some cases, there may be reasons for the current serving NW node triggering / executing the handover action physically, in parallel to ongoing DT services in the overlapping time frame. This can be because the current serving NW node is unwilling to await some while, or the target NW node cannot notify current serving NW node of the outcomes within the waiting time T that the current serving NW node is willing to endure, or for other reasons. This embodiment 3 considers that the current serving NW node initiates a DTN based pre-verification request to that target NW node in parallel to instructing the UE to hand over to the better serving cell.

[0129] The below paragraphs describe the implementation steps.

[0130] Step 301: UE sends measurement report to the current serving NW node (hereinafter referred to as the NW node1) , and NW node1 determines that there are cells more suitable for the UE. Therefore, NW node1 makes a handover decision and determines the target cell (set) , including servercellId, PCI, SSBID, SSB RSRP / RSRQ, etc. of the target serving cell (s) . The communication function of NW node1 initiates a DTN based pre-verification service request for certain target cell (s) to its local DT system and provides necessary information, such as handover reasons, UEAMBR, UESecurityCapabilities, SecurityInformation, etc. After receiving the request, the DT system of NW node1 generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = Mobility strategy pre-verification" , "DT service ID = 0001" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T, UE measurement report, HandoverRequest information, future track (s) of UE, etc. ) .

[0131] Step 302: The communication function of the NW node1 sends Message1 (containing the DT service execution related information generated in Step 301) to the target NW node (hereinafter referred to as the NW node2) through the Xn or NG interface. The forms of Message1 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0132] Step 303: The NW node1 sends handover request to NW node2 and sends an RRCConnectionRelease message to the UE, carrying the target cell information of the NW node2. The UE performs random access to the target cell in accordance with the information.

[0133] Step 304: The communication function of the NW node2 identifies that the Message1 contains information related to DT service request, so sends it to its own DT system for content parsing and subsequent processing.

[0134] Step 305: The DT system of the NW node2 parses and analyzes the received DT service request, e.g., checking whether the performance pre-verification service is within its supported business scope, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = Yes" , "DT service ID = 0001" , etc.

[0135] Step 306: After UE handover to NW node 2, the communication function of the NW node2 sends Message2 to the communication function of the UE through the RRC procedure, which contains the DT service response related information generated in Step 305. The forms of Message2 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0136] Step 307: The DT service of the NW node2 simulates and pre-verifies the performance of UE after handover through local DT operations (may take several seconds or has to be completed within the T-time indicated by NW node2) , and generates DT service response related information. The performance evaluation indicators may include the changes of data transmission (average / guaranteed) rate, transmission delay, link robustness, and energy consumption of UE, load changes of the NW node2, etc. The evaluation indicators may be provided by NW node1 or NW node2, or both. The DT service response related information may include “DT service id = 0001” , “DT service report identification information” , “DT service report” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0137] Step 308: The communication function of the NW node2 sends Message3 to the communication function of the UE through the RRC procedure, and the message contains the DT service response related information generated in Step 307. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0138] Step 309: UE parses the content of Message3 and, based on the information in Message3, UE can understand the network condition and the possible QoS at a future time.

[0139] V. Embodiment 4

[0140] Embodiment 4 describes current serving NW node triggering target NW node for handover strategy pre-verification once more after the first DT service request is rejected.

[0141] The below paragraph describes the background.

[0142] In the same background as Embodiment 1, in some cases, there may be rejection of DT services. But the current serving NW node can (modify and) continue to initiate DT services multiple times after being rejected. This embodiment 4 considers that the current serving NW node initiates a DTN based pre-verification request to the target NW node once more after the first DT service request is rejected.

[0143] The below paragraphs describe the implementation steps.

[0144] Step 401: UE sends measurement report to the current serving NW node (hereinafter referred to as the NW node1) , and NW node1 makes a handover decision and determines the target cell (set) , including servercellId, PCI, SSBID, SSB RSRP / RSRQ, etc. of the target serving cell (s) . The communication function of NW node1 initiates a DTN based pre-verification service request for certain target cell (s) to its local DT system and provides necessary information. After receiving the request, the DT system of NW node1 generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = Mobility strategy pre-verification" , "DT service ID = 0001" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T, UE measurement report, HandoverRequest information, etc. ) .

[0145] Step 402: The communication function of the NW node1 sends Message1 (containing the DT service execution related information generated in Step 401) to the target NW node (hereinafter referred to as the NW node2) through the Xn or NG interface. The forms of Message1 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0146] Step 403: The communication function of the NW node2 identifies that the Message1 contains information related to DT service request, so sends it to its own DT system for content parsing and subsequent processing.

[0147] Step 404: The DT system of the NW node2 parses and analyzes the received DT service request, e.g., checking whether the performance pre-verification service is within its supported business scope, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = No" , "DT service ID = 0001" , “DT service rejection Reason indicator” , etc. Since the DT service request is rejected, the DT service response related information include the reason for the rejection, e.g., the format of DT service execution related information is incorrect, the DT service execution related information contains incorrect parameters, or the request exceeds the capability of the NW node.

[0148] Step 405: The communication function of the NW node2 sends Message2 to the communication function of the NW node1 via Xn or NG interface, which contains the DT service response related information generated in Step 404. The forms of Message2 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0149] Step 406: NW node1 makes corresponding adjustments based on the given reason after receiving Message2, and then sends another DT service request to its own local DT system with necessary mobility strategy information. The DT system of NW node2 generates another DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = Mobility strategy pre-verification" , "DT service ID = 0002" , "DT service assistance information for DT modeling and planning" may indicate the waiting time T, UE measurement report, HandoverRequest information, etc. ) .

[0150] Step 407: The communication function of the NW node2 sends Message3 (containing new DT service execution related information generated in Step 406) to the NW node2 via Xn or NG interface. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0151] Step 408: Similar to Step 404, The DT system of the NW node2 parses and analyzes the received DT service request, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = Yes" , "DT service ID = 0002" , etc.

[0152] Step 409: The communication function of the NW node2 sends Message4 to the communication function of the NW node1 via Xn or NG interface, which contains the DT service response related information generated in Step 408. The forms of Message4 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0153] Step 410: The DT service of the NW node simulates and pre-verifies the performance of UE after accessed through local DT operations (may take several seconds or has to be completed within the T-time indicated by UE) , and generates DT service response related information. The performance evaluation indicators may include the changes of data transmission (average / guaranteed) rate, transmission delay, link robustness, and energy consumption of UE, load changes of the NW node2, etc. The evaluation indicators may be provided by NW node1 or NW node2, or both. The DT service response related information may include “DT service id” , “DT service report identification information” , “DT service report” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0154] Step 411: The communication function of the NW node2 sends Message5 to the communication function of the NW node1 via Xn or NG interface, and the message contains the DT service response related information generated in Step 410, so that NW node1 can understand the network condition and the performance of UE after executing corresponding mobility strategy. The forms of Message5 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0155] Step 412: NW node1 parses the content of Message5 and, based on the information in Message5, decides to whether and when to perform handover action to the target cell (s) . In case of handover to the target cell of NW node2, NW node1 can initiate the physical handover request.

[0156] Step 413: After handover to the target cell of NW node2, UE can evaluate the real performance of DT service, and generate the DT service performance evaluation related information, which may include information such as: “DT service id” , “Excellent / Good / Bad level judgement indicator” , “Yes / No or x%for enhancing mobile user’s mobility experiences” .

[0157] Step 414: The communication function of UE sends Message6 to the communication function of the NW node2 through the RRC procedure, and the message contains the DT service performance evaluation related information generated in Step 413. Based on Message6, the NW node2 may adjust its execution of DT service and optimize performance of the pre-verification at a future time.

[0158] VI. Embodiment 5

[0159] Embodiment 5 describes current serving NW node triggering target NW node for physical handover if the target NW node does not response within the waiting time T.

[0160] The below paragraph describes the background.

[0161] In the same background as Embodiment 1, this embodiment 5 considers that when the current serving NW node determines to hand over to a cell (or cells) of another NW node, it initiates a DTN based pre-verification request to the target NW node before physically initiating the handover request to that NW node, and is willing to await time T. But the target cannot response within time T. This may be because the target NW node cannot complete the pre-verification within time T, or the target NW node cannot send response messages in time, or for other reasons.

[0162] The below paragraphs describe the implementation steps.

[0163] Step 501: UE sends measurement report to the current serving NW node (hereinafter referred to as the NW node1) , and NW node1 makes a handover decision and determines the potential target cell (set) , including servercellId, PCI, SSBID, SSB RSRP / RSRQ, etc. of the target serving cell (s) . The communication function of NW node1 initiates a DTN based pre-verification service request for certain handover to its local DT system and provides necessary information, such as handover reasons, UEAMBR, UESecurityCapabilities, SecurityInformation, etc. After receiving the request, the DT system of NW node1 generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = Mobility strategy pre-verification" , "DT service ID = 0001" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T, UE measurement report, HandoverRequest information, etc. ) .

[0164] Step 502: The communication function of the NW node1 sends Message1 (containing the DT service execution related information generated in Step 501) to the target NW node (hereinafter referred to as the NW node2) through the Xn or NG interface. The forms of Message1 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0165] Step 503: The communication function of the NW node2 identifies that the Message1 contains information related to DT service requests, so sends it to its own DT system for content parsing and subsequent processing.

[0166] Step 504: The DT system of the NW node2 parses and analyzes the received DT service request, e.g., checking whether the pre-verification service is within its supported service scope, and determines the priority of the pre-verification request. Based on above admission control of DT service, the DT system of the NW node2 decides whether to accept the DT service request and sends the relevant response information to its local communication function. The DT service response related information may include "DT service response indicator for DT service = Yes" , "DT service ID = 0001" , etc. If its DT system cannot work out the requested pre-verification in time T, it may reject the request.

[0167] Step 505: The communication function of the NW node2 sends Message2 to the communication function of the NW node1 via Xn or NG interface, which contains the DT service response related information generated in Step 504. The forms of Message2 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0168] Step 506: If the DT service request is accepted, NW node1 can behave according to the instructions in the Message2, e.g., wait for a while during DTN simulation and performance pre-verification in NW node2. If the DT service is rejected, NW node1 identifies the reason for rejection as failure of NW node2 to complete the DT pre-verification within time T. NW node1 initiates physical handover action immediately. The whole procedure is terminated.

[0169] Step 507: The DT service of the NW node2 simulates and pre-verifies the performance after the UE is accessed through local DT operations (may take several seconds or has to be completed within the T-time indicated by NW node1) . The performance evaluation indicators may include future data transmission (average / guaranteed) rate, transmission delay, link robustness, and energy consumption of UE, future load changes of the NW node2, etc. The evaluation indicators may be provided by UE, NW node1 or NW node2, or the mixed. NW node2 generates DT service response related information, which may include “DT service id =0001” , “DT service report identification information” , “DT service report” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0170] Step 508: If NW node2 fails to receive the DT service response related information within time T, it can initiate physical handover action immediately. The whole procedure may be terminated. Or, the DT service of the NW node2 can continue executing the pre-verification and notify UE of the DT service response related information in parallel to UE executing physical handover action.

[0171] Step 509: If NW node2 complete the pre-verification out of the waiting time T, and UE has accessed, the communication function of the NW node2 sends Message3 to the communication function of the UE through the RRC procedure, and the message contains the DT service response related information generated in Step 507, so that UE can understand the network condition and its future performance. The forms of Message 3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0172] FIG. 14 is an example flowchart for determining a mobility strategy based on a DT operation or service. Operation 1402 includes determining, by a network device and based on one or more digital twin (DT) operations or services, one or more mobility strategies. Operation 1404 includes triggering or executing, by the network device and based on the one or more mobility strategies, a handover operation. In some embodiments, the method can be implemented according to Embodiments 1-5. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0173] In some embodiments, at least one of the following applies: the network device has a DT capability, and the one or more DT operations are performed locally by the network device; or the network device sends one or more DT service requests to another network device, the one or more DT services are performed by the other network device, and one or more outcomes of the one or more DT services are sent back to the network device.

[0174] In some embodiments, determining the one or more mobility strategies is based on a determination that a target cell set includes one or more cells or network devices, where at least one of the following applies: a pre-verification of the one or more mobility strategies corresponding to the one or more cells or network devices is performed in one DT operation or service; or a pre-verification of one mobility strategy corresponding to one cell or network device is performed in one DT operation or service, and multiple DT operations or services are performed in parallel for multiple cells or network devices.

[0175] In some embodiments, determining the one or more mobility strategies is based on a determination that a wireless device has one or more possible future tracks, where at least one of the following applies: a pre-verification of the one or more mobility strategies corresponding to the one or more possible future tracks is performed in one DT operation or service; or a pre-verification of one mobility strategy corresponding to one possible future track is performed in one DT operation or service, and multiple DT operations or services are performed in parallel for multiple possible future tracks.

[0176] In some embodiments, triggering or executing the handover operation includes selecting, by the network device, a mobility strategy from the one or more mobility strategies to trigger or execute the handover operation with.

[0177] In some embodiments, triggering or executing the handover operation includes determining, by the network device, whether and when to execute a mobility strategy of the one or more mobility strategies.

[0178] In some embodiments, triggering or executing the handover operation includes executing, by the network device, a mobility strategy of the one or more mobility strategies even though an outcome of a DT operation or service corresponding to the mobility strategy indicates that the mobility strategy is not satisfactory.

[0179] In some embodiments, triggering or executing the handover operation includes triggering or executing the handover operation before the network device receives one or more outcomes of the one or more DT operations or services.

[0180] FIG. 15 is an example flowchart for a DT service procedure. Operation 1502 includes transmitting, by a network device, a digital twin (DT) service request for determining one or more mobility strategies  associated with a handover operation. Operation 1504 includes receiving, by the network device and in response to the DT service request, a DT service response. In some embodiments, the method can be implemented according to Embodiments 1-5. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0181] In some embodiments, the DT service request is transmitted and the DT service response is received via at least one of the following: an Xn interface between radio access network (RAN) nodes; or an NG interface between a RAN node and a core network (CN) node.

[0182] In some embodiments, the DT service request includes a DT service execution related information including at least one of the following: a DT service request indicator; a DT service identification (ID) information; a DT service type; a DT service assistance information for DT modeling and planning; a DT service reporting related information; or a DT service priority.

[0183] In some embodiments, the DT service assistance information includes at least one of the following: a user equipment (UE) measurement report; a handover request information; a UE mobility strategy information; a time period during which a DT service should pre-verify a mobility strategy; or a waiting time T after which the DT service request is abandoned.

[0184] In some embodiments, the DT service reporting related information includes at least one of the following: a pre-verification indicator; a time range of a pre-verification; a reporting mode; an information on whom to report to; or an information on when to report.

[0185] In some embodiments, the DT service response includes a DT service response related information including at least one of the following: a DT service response indicator indicating an acceptance or a rejection of the DT service request; a DT service identification (ID) information; a DT service type; a DT service reason for rejection indicator; a DT service report ID information; or a DT service report.

[0186] In some embodiments, the DT service report includes at least one of the following: a DT service identification (ID) information; a DT service type; a DT service report ID information; a user equipment (UE) ID information; a target cell ID information; a DT modeling and planning outcome; a DT service outcome of a DT simulation and pre-verification; a DT service pre-verification configuration; or a time or time range of a pre-verification.

[0187] FIG. 16 is an example flowchart for a DT service performance evaluation procedure. Operation 1602 includes receiving, by a wireless device, a digital twin (DT) service response related information associated with one or more mobility strategies. Operation 1604 includes transmitting, by the wireless device and after performing a handover operation associated with a mobility strategy of the one or more mobility strategies, a DT service performance evaluation result. In some embodiments, the method can be implemented according to Embodiments 1-5. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0188] In some embodiments, the wireless device receives the DT service response related information from a serving network device or a target network device, the wireless device has a DT capability, the wireless  device parses the DT service response related information to determine a network condition, and the wireless device performs the handover operation based on the network condition.

[0189] In some embodiments, the wireless device transmits the DT service performance evaluation result to a target network device through a radio resource control (RRC) procedure, where the DT service performance evaluation result includes a DT service performance evaluation related information including at least one of the following: a DT service performance evaluation indicator; a DT service identification (ID) information; a DT service type; a user equipment (UE) ID information; an excellent, good, average, or bad indicator for enhancing a user service experience with the mobility strategy; a yes or satisfied versus no or unsatisfied indicator for enhancing a user service experience with the mobility strategy; or a percentage indicator for enhancing a user service experience with the mobility strategy.

[0190] In some embodiments, a target network device adjusts or optimizes, based on the DT service performance evaluation result, a future DT service execution.

[0191] FIG. 17 is an example flowchart for triggering a physical handover in parallel with a DT operation or service. Operation 1702 includes triggering or executing, by a network device and in parallel with one or more digital twin (DT) operations or services in an overlapping time frame, a physical handover operation, where the one or more DT operations or services are for determining one or more mobility strategies. In some embodiments, the method can be implemented according to Embodiments 1-5. In some embodiments, performing further steps of the method can be based on a better system performance than a legacy protocol.

[0192] FIG. 18 shows an example block diagram of a hardware platform 1800 that may be a part of a network device (e.g., a base station (BS) , a transmission and reception point (TRP) , a radio access network (RAN) , or a core network (CN) ) or a wireless device (e.g., a user equipment (UE) ) . The hardware platform 1800 includes at least one processor 1810 and a memory 1805 having instructions stored thereupon. The instructions upon execution by the processor 1810 configure the hardware platform 1800 to perform the operations described in FIGS. 1-17 and in the various embodiments described in this patent document. The transmitter 1815 transmits or sends information or data to another device. For example, a network device transmitter can send a message to a user equipment. The receiver 1820 receives information or data transmitted or sent by another device. For example, a user equipment can receive a message from a network device. For example, a UE, a wireless device, or a network device, as described in the present document, may be implemented using the hardware platform 1800.

[0193] The implementations as discussed above will apply to a wireless communication. FIG. 19 shows an example of a wireless communication system (e.g., a 6G, 5G, or NR cellular network) that includes a base station 1920 and one or more user equipment (UE) 1911, 1912, and 1913. In some embodiments, the UEs access the BS (e.g., the network) using a communication link to the network (sometimes called uplink direction, as depicted by dashed arrows 1931, 1932, 1933) , which then enables subsequent communication (e.g., shown in the direction from the network to the UEs, sometimes called downlink direction, shown by arrows 1941, 1942, 1943) from the BS to the UEs. In some embodiments, the BS sends information to the UEs (sometimes called downlink direction, as depicted by arrows 1941, 1942, 1943) , which then enables subsequent communication  (e.g., shown in the direction from the UEs to the BS, sometimes called uplink direction, shown by dashed arrows 1931, 1932, 1933) from the UEs to the BS. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, an Internet of Things (IoT) device, and so on. The UEs described in the present document may be communicatively coupled to the base station 1920 depicted in FIG. 19.

[0194] It will be appreciated by one of skill in the art that the present patent document discloses methods that, among other benefits, improve the handover efficiency and consequently a user’s mobility experience. The methods disclosed include pre-verifying a handover strategy using digital twin (DT) technology. A serving network (NW) device with a DT capability can perform local DT operations. Alternatively, the serving NW device can request a target NW device to perform DT services. In some embodiments, multiple DT operations or services can be performed based on multiple cells or network devices in a target cell set. In some embodiments, multiple DT operations or services can be performed based on multiple possible future tracks of a wireless device. In some embodiments, the pre-verification is in parallel with a physical handover. If a DT service request is rejected, the serving NW device can trigger another handover strategy pre-verification. If the target NW device does not respond within a waiting time T, the serving NW device can initiate a physical handover.

[0195] Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM) , Random Access Memory (RAM) , compact discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0196] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware, or firmware. The connectivity between the modules and / or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.

[0197] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0198] Only a few implementations and examples are described, and other implementations, enhancements and variations can be made based on what is described and illustrated in this patent document.

Claims

1.A method of wireless communication, comprising:determining, by a network device and based on one or more digital twin (DT) operations or services, one or more mobility strategies; andtriggering or executing, by the network device and based on the one or more mobility strategies, a handover operation.2.The method of claim 1, wherein at least one of the following applies:the network device has a DT capability, and the one or more DT operations are performed locally by the network device; orthe network device sends one or more DT service requests to another network device, the one or more DT services are performed by the other network device, and one or more outcomes of the one or more DT services are sent back to the network device.3.The method of claim 1 or 2, wherein determining the one or more mobility strategies is based on a determination that a target cell set includes one or more cells or network devices, and wherein at least one of the following applies:a pre-verification of the one or more mobility strategies corresponding to the one or more cells or network devices is performed in one DT operation or service; ora pre-verification of one mobility strategy corresponding to one cell or network device is performed in one DT operation or service, and multiple DT operations or services are performed in parallel for multiple cells or network devices.4.The method of any of claims 1-3, wherein determining the one or more mobility strategies is based on a determination that a wireless device has one or more possible future tracks, and wherein at least one of the following applies:a pre-verification of the one or more mobility strategies corresponding to the one or more possible future tracks is performed in one DT operation or service; ora pre-verification of one mobility strategy corresponding to one possible future track is performed in one DT operation or service, and multiple DT operations or services are performed in parallel for multiple possible future tracks.5.The method of any of claims 1-4, wherein triggering or executing the handover operation comprises selecting, by the network device, a mobility strategy from the one or more mobility strategies to trigger or execute the handover operation with.6.The method of any of claims 1-5, wherein triggering or executing the handover operation comprises determining, by the network device, whether and when to execute a mobility strategy of the one or more mobility strategies.7.The method of any of claims 1-6, wherein triggering or executing the handover operation comprises  executing, by the network device, a mobility strategy of the one or more mobility strategies even though an outcome of a DT operation or service corresponding to the mobility strategy indicates that the mobility strategy is not satisfactory.8.The method of any of claims 1-7, wherein triggering or executing the handover operation comprises triggering or executing the handover operation before the network device receives one or more outcomes of the one or more DT operations or services.9.A method of wireless communication, comprising:transmitting, by a network device, a digital twin (DT) service request for determining one or more mobility strategies associated with a handover operation; andreceiving, by the network device and in response to the DT service request, a DT service response.10.The method of claim 9, wherein the DT service request is transmitted and the DT service response is received via at least one of the following:an Xn interface between radio access network (RAN) nodes; oran NG interface between a RAN node and a core network (CN) node.11.The method of claim 9 or 10, wherein the DT service request comprises a DT service execution related information comprising at least one of the following:a DT service request indicator;a DT service identification (ID) information;a DT service type;a DT service assistance information for DT modeling and planning;a DT service reporting related information; ora DT service priority.12.The method of claim 11, wherein the DT service assistance information comprises at least one of the following:a user equipment (UE) measurement report;a handover request information;a UE mobility strategy information;a time period during which a DT service should pre-verify a mobility strategy; ora waiting time T after which the DT service request is abandoned.13.The method of claim 11, wherein the DT service reporting related information comprises at least one of the following:a pre-verification indicator;a time range of a pre-verification;a reporting mode;an information on whom to report to; oran information on when to report.14.The method of any of claims 9-13, wherein the DT service response comprises a DT service response related information comprising at least one of the following:a DT service response indicator indicating an acceptance or a rejection of the DT service request;a DT service identification (ID) information;a DT service type;a DT service reason for rejection indicator;a DT service report ID information; ora DT service report.15.The method of claim 14, wherein the DT service report comprises at least one of the following:a DT service identification (ID) information;a DT service type;a DT service report ID information;a user equipment (UE) ID information;a target cell ID information;a DT modeling and planning outcome;a DT service outcome of a DT simulation and pre-verification;a DT service pre-verification configuration; ora time or time range of a pre-verification.16.A method of wireless communication, comprising:receiving, by a wireless device, a digital twin (DT) service response related information associated with one or more mobility strategies; andtransmitting, by the wireless device and after performing a handover operation associated with a mobility strategy of the one or more mobility strategies, a DT service performance evaluation result.17.The method of claim 16, wherein the wireless device receives the DT service response related information from a serving network device or a target network device, wherein the wireless device has a DT capability, wherein the wireless device parses the DT service response related information to determine a network condition, and wherein the wireless device performs the handover operation based on the network condition.18.The method of claim 16 or 17, wherein the wireless device transmits the DT service performance evaluation result to a target network device through a radio resource control (RRC) procedure, and wherein the DT service performance evaluation result comprises a DT service performance evaluation related information comprising at least one of the following:a DT service performance evaluation indicator;a DT service identification (ID) information;a DT service type;a user equipment (UE) ID information;an excellent, good, average, or bad indicator for enhancing a user service experience with the mobility strategy;a yes or satisfied versus no or unsatisfied indicator for enhancing a user service experience with the mobility strategy; ora percentage indicator for enhancing a user service experience with the mobility strategy.19.The method of any of claims 16-18, wherein a target network device adjusts or optimizes, based on the DT service performance evaluation result, a future DT service execution.20.A method of wireless communication, comprising:triggering or executing, by a network device and in parallel with one or more digital twin (DT) operations or services in an overlapping time frame, a physical handover operation, wherein the one or more DT operations or services are for determining one or more mobility strategies.21.An apparatus for wireless communication, comprising a processor, wherein the processor is configured to implement a method recited in any one or more of claims 1 to 20.22.A computer readable program storage medium having code stored thereon, the code, when executed by a processor, causing the processor to implement a method recited in any one or more of claims 1 to 20.

Images