Service experience enhancement via digital twin based communication

Abstract

Systems, methods, and apparatus for wireless communication are described. The methods improve the service experience in the 6th generation (6G) wireless communication. An example method includes transmitting, by a wireless device, a digital twin (DT) service request related information. The method further includes receiving, by the wireless device and in response to the DT service request related information, a DT service response related information. Another example method includes receiving, by a wireless device, a digital twin (DT) service performance evaluation query related information. The method further includes transmitting, by the wireless device and based on the DT service performance evaluation query related information, a DT service performance evaluation result report.

Description

SERVICE EXPERIENCE ENHANCEMENT 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-A wireless 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 is related to the 6th generation (6G) wireless communication digital twin (DT) technologies. In some embodiments, a user equipment (UE) has a DT capability and can perform local DT operations. In some embodiments, the UE sends DT service requests to a network (NW) device for performing DT services via a radio resource control (RRC) procedure. Upon request, the UE can also send DT service performance evaluation result reports. The disclosed methods, among other benefits, improve the service experience.

[0005] A first example wireless communication method includes transmitting, by a wireless device, a digital twin (DT) service request related information. The method further includes receiving, by the wireless device and in response to the DT service request related information, a DT service response related information.

[0006] A second example wireless communication method includes transmitting, by a wireless device, a digital twin (DT) service request. The method further includes receiving, by the wireless device and based on the DT service request, an outcome of a completed DT service.

[0007] A third example wireless communication method includes performing, by a wireless device with a digital twin (DT) capability, a local DT operation.

[0008] A fourth example wireless communication method includes receiving, by a network device, a digital twin (DT) service request related information. The method further includes performing, by the network device and based on the DT service request related information, a DT service.

[0009] A fifth example wireless communication method includes receiving, by a wireless device, a digital twin (DT) service performance evaluation query related information. The method further includes transmitting, by the wireless device and based on the DT service performance evaluation query related information, a DT service performance evaluation result report.

[0010] A sixth example wireless communication method includes receiving, by a network device, a physical wireless service request. The method further includes executing, by the network device, the physical wireless service request in parallel with an ongoing digital twin (DT) service in an overlapping time frame.

[0011] 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.

[0012] 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.

[0013] 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.

[0014] 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

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

[0016] FIG. 2 illustrates an example split RAN communication system.

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

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

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

[0020] FIG. 6 is an example flowchart for transmitting a DT service request related information.

[0021] FIG. 7 is an example flowchart for transmitting a DT service request.

[0022] FIG. 8 is an example flowchart for performing a local DT operation.

[0023] FIG. 9 is an example flowchart for performing a DT service.

[0024] FIG. 10 is an example flowchart for transmitting a DT service performance evaluation result report.

[0025] FIG. 11 is an example flowchart for executing a physical wireless service request in parallel with an ongoing DT service.

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

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

[0028] 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.

[0029] I. Introduction

[0030] The present patent document discloses methods of performing DT operations or DT services. The disclosed methods, among other benefits, improve the service experience.

[0031] 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 Operations, Administration and Maintenance (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 in the future. The 6th generation (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 be 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., the 3rd Generation Partnership Project (3GPP) standardized manner. Among all benefits and gains achievable from various DTN operations, continuous enhancement of mobile user’s applications / communication service 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 service experiences.

[0032] The following paragraph describes 3GPP user equipment (UE) in single connectivity (SC) .

[0033] The International Mobile Telecommunications (IMT) wireless communication systems (such as 5th generation new radio (5G-NR) specified by 3GPP) are shown in FIG. 1 and FIG. 2. FIG. 1 shows the non-split RAN case. FIG. 2 shows the split RAN case. The Core Network (CN) consists of various types of control plane (CP) nodes or entities, e.g., 5G Access and Mobility Management Function (AMF)  / Session Management Function (SMF) , and user plane (UP) node or entity, e.g., 5G user plane function (UPF) . In the radio access network (RAN) non-split case on the left side, the RAN node, e.g., 5G aggregated gNodeB (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 on the right side, the RAN node, e.g., 5G dis-aggregated gNB consists of control unit (CU) -CP node, CU- UP node and Distributed Unit (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 application (APP) and Web services etc. outside. For both CP and UP planes, they have their own interface and protocol stack and normally span from CN domain to RAN network and then to UE.

[0034] The following paragraphs describe DTN technology and capability.

[0035] The basic principles of the DTN technology applied in a wireless system are as follows. Based on the DTN task input of a 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 the "physical object" for future development or evolution) 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, and continuously drives the “digital twin entity” to evolve towards and approach the expected target status of the “digital planning entity” . With the 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 or devices, and in foreseeing various internal causal relationships inside the 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 the 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.

[0036] The basic functional modules for DT system are shown in FIG. 3. The “Application Function” and “Communication Function” etc. can be the requesting entity for a 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 and pre-verification of something requested ahead.

[0037] The following paragraphs describe wireless system with DT capability.

[0038] With the advanced DTN technology integrated into a future 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 service experiences can be enhanced based on simulation and pre-verification operations with 6G DT capability.

[0039] FIG. 4 shows an architecture of the wireless system without DT capability. As shown in FIG. 4, in a wireless system without DT capability, all communication service behaviors of a UE or a network (NW) node are based on real physical event requirements, and later on real physical event occurs in the physical world. Therefore, regardless of whether radio signal transceiving or protocol data packet transmission or application data packet transmission in air interface, all of them are conducted in the real and physical world, accordingly the resources such as time, space, frequency, RF power, and computing power are consumed physically for those application and communication services.

[0040] FIG. 5 shows an architecture of the wireless system with DT capability. As shown in FIG. 5, the DT system (as shown in FIG. 3) is introduced into the UE and NW node, 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, regardless of whether radio signal transceiving or protocol data packet transmission or application  data packet transmission in air interface, all of them can be conducted in virtual digital world, accordingly only the computing power for DTN operations is consumed physically for those application and communication services.

[0041] The following paragraph describes benefits and gains from DTN operations.

[0042] In the dynamic radio environment, the mobile user’s service experience is often influenced or degraded by lots of factors, such as user behaviors, radio conditions, and wireless network resources etc. In the physical run time with the wireless system today, the pending user service experience of particular application / communication service are not predictable or cannot be pre-verified in advance, hence upon event triggering, the mobile user usually has to go ahead with its own service intention regardless of the potential outcomes. In the physical run time with the wireless system with DT capability, the pending user service experience of particular application / communication service 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 services, e.g., not always going ahead immediately taking into account of potential outcomes. With DTN operation assistance, the mobile user may form into more cautious and rational behaviors. The more cautious and rational behaviors of mobile user shall not only save the resources of wireless system by optimal usage (not wasting resources on bad / worse service outcomes) , but also enhance the user’s service experiences in field.

[0043] The following paragraphs give some basic definitions.

[0044] "physical world" : the objective real world where the physical wireless system and services are deployed and running.

[0045] "physical object" : the various tangible and intangible things in physical world.

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

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

[0048] "digital planning entity" : digital planned / expected target status of the "physical object" for future development or evolution in the digital world.

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

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

[0051] The following points are methods and devices for enhancing the mobile user’s service experiences via DTN.

[0052] 1: UE is capable of DT (Digital Twin) , so it has a “DT system” inside and can perform local DT operations or send DT service requests to the NW node for performing DT operations instead.

[0053] 1-1: UE may trigger one or multiple times of DT operations or DT services for the expected real physical wireless service before executing it physically in physical world.

[0054] 1-2: UE may trigger multiple DT operations or DT services in parallel for different real physical wireless services.

[0055] 1-3: Based on the outcomes of DT operation or DT service conducted by DT system, UE may decide when and how to trigger / execute the expected real physical wireless service physically in physical world. Though the outcome of DT operation or DT service indicates that the service pre-verified is not well supported or the user experience will be poor after initiated, the UE can also initiate physical services as required.

[0056] 1-4: UE may trigger / execute the expected real physical wireless service physically, before receiving the outcomes of DT operation or DT service conducted by DT system.

[0057] 1-5: UE may report / feedback the DT performance evaluation result of DT service to the NW node.

[0058] 2: In the DT service execution process, UE shall execute the RRC procedures containing the DT service execution related information.

[0059] 2-1: In the uplink DT service messages, the DT service execution related information may include such as: “DT service request indicator for DT service” , “DT service type” , “DT service id” , “UE wireless service profile for DT modelling and planning” , “DT service assistance info for DT modelling and planning” .

[0060] 2-2: In the downlink DT service messages, the DT service response related information may include such as “DT service response indicator for DT service” , “DT service id” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” .

[0061] 3: In the DT service performance evaluation result report process, UE shall execute the RRC procedures containing the DT service performance evaluation related information.

[0062] 3-1: In the uplink DT service performance evaluation result report messages, the DT service performance evaluation related information includes such as: “Excellent / Good / Bad level judgement indicator” , “Yes / No or x%for enhancing mobile user’s service experiences” .

[0063] 3-2: Based on the DT service performance evaluation result, the NW node may adjust / optimize its detailed handling of DT service execution in the future.

[0064] 4: UE may trigger / execute the expected real physical wireless service physically, in parallel with ongoing DT services in the overlapping time frame.

[0065] 4-1: NW may execute the requested real physical wireless service physically, in parallel with ongoing DT operations in the overlapping time frame.

[0066] II. Embodiment 1

[0067] Embodiment 1 describes how UE triggers NW for XR service performance pre-verification.

[0068] Assuming the mobile user wants to initiate an XR service. In traditional communication systems, when there is a user service demand from the NW side, a downlink paging message Paging will be sent, triggering the UE (or the user terminally actively triggering) to RACH process, and then UE enters the "RRC_CONNECTED state" for communication service interaction and user data transmission. From the mobile user's perspective, except roughly perceiving the current coverage quality of the serving cell through the "4 / 5G signal strength quality grid" displayed on the mobile phone screen, mobile users cannot know or predict the eventual quality / experience of mobile services in the future, as depending on NW resources’ status and physical operations. Therefore, for high-profile services like "XR" that requires high performance guarantee and consumes lots of resources, the challenges for NW how to bear them are still quite significant. Launching such high-profile services recklessly or self-willed when the network environment, resources, etc. are temporarily in bad state, may result in a poor XR service experience for users and even further deteriorate the NW’s situation. Such physical service execution not only consumes resources such as air interfaces, computing power, and energy consumption, but also leads to a degradation of user experience expectation.

[0069] In the future, with the assistance of DTN, before the mobile user triggers the XR services, the NW will provide reference advice and indicative references through "DTN based service performance pre-verification" , so that the XR service can be triggered more reasonably  and appropriately, e.g., at the right time and places. As a result, the physical resources consumed on the network and UE are utilized to meet the maximal values, making user easier to achieve good service experience.

[0070] This embodiment 1 considers that the UE triggers the NW to perform the DTN based pre-verification firstly before physically initiating the XR service in physical world. In such case, the mobile user is willing to wait some while before triggering the XR service physically.

[0071] The following paragraphs describe the implementation steps.

[0072] Step 101: The application function of UE initiates a DTN based pre-verification service request for certain XR service to its own local DT system and provides necessary XR service profile information. After receiving the request, the DT system of UE generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID = 0001" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T that the user is willing to endure and hold off the physical service, i.e. the NW must execute and complete the "DTN based pre-verification" and work out the pre-verification result within the waiting time T) .

[0073] Step 102: The communication function of the UE sends Message1 (containing the DT service execution related information generated in Step 101) to the NW node through the RRC procedure. The forms of Message1 include but are not limited to: reusing existing RRC messages (e.g., MSG3 or MSG5 in 4-step Random Access Procedure, MSG A in 2-step Random Access Procedure, UEAssistanceInformation message, UEAssistanceInformation message) and using newly defined dedicated RRC messages.

[0074] Step 103: The communication function of the NW node 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.

[0075] Step 104: The DT system of the NW node 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 the above admission control of DT service, the DT system of the NW 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.

[0076] Step 105: The communication function of the NW node sends Message2 to the communication function of the UE through the RRC procedure, which contains the DT service response related information generated in Step 104. Since the DT service request is accepted, UE can behave according to the instructions in the Message2, e.g., wait for a while during DTN based simulation and performance pre-verification in NW. The forms of Message2 include but are not limited to: reusing existing RRC messages (e.g., MSG2 or MSG4 in 4-step Random Access Procedure, MSG B in 2-step Random Access Procedure, DLInformationTransfer message) and using newly defined dedicated RRC messages.

[0077] Step 106: The DT service of the NW node simulates and pre-verifies the performance of XR services 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 DT service response related information may include “DT service id = 0001” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0078] Step 107: The communication function of the NW node 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 106, so that UE can understand the network condition and its support situation for XR services. The forms of Message3 include but are not limited to: reusing existing messages (e.g., DLInformationTransfer message) and using newly defined dedicated messages.

[0079] Step 108: UE parses the content of Message3 and, based on the information in Message3, decides to immediately start or delay initiating the physical XR service. In case of starting immediately, UE can configure the physical XR service request according to the configuration parameters recommended in Message3.

[0080] III. Embodiment 2

[0081] Embodiment 2 describes how UE triggers NW for XR service performance pre-verification once more after the first DT service request is rejected.

[0082] In the same background as Embodiment 1, this embodiment 2 considers that the UE triggers the NW to perform the DTN based pre-verification firstly before physically initiating the XR service in physical world. In such case, the mobile user is willing to await some while before triggering the XR service physically.

[0083] The following paragraphs describe the implementation steps.

[0084] Step 201: The application function of UE initiates a DTN based pre-verification service request for certain XR service to its own local DT system and provides necessary XR service profile information. After receiving the request, the DT system of UE generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID =0001" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T that the user is willing to endure and hold off the physical service, i.e. the NW must execute and complete the "DTN based pre-verification" and work out the pre-verification result within the waiting time T) .

[0085] Step 202: The communication function of the UE sends Message1 (containing the DT service execution related information generated in Step 201) to the NW node through the RRC procedure. The forms of Message1 include but are not limited to: reusing existing RRC messages and using newly defined dedicated RRC messages.

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

[0087] Step 204: The DT system of the NW node 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 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" , 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.

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

[0089] Step 206: UE 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 XR service profile information. The DT system of UE generates another DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID = 0002" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" .

[0090] Step 207: The communication function of the UE sends Message3 (containing new DT service execution related information generated in Step 206) to the NW node through the RRC procedure. The forms of Message3 include but are not limited to: reusing existing RRC messages and using newly defined dedicated RRC messages.

[0091] Step 208: Similar to Step 204, The DT system of the NW node 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 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.

[0092] Step 209: The communication function of the NW node sends Message4 to the communication function of the UE through the RRC procedure, which contains the DT service response related information generated in Step 207. Since the DT service request is accepted, UE can behave according to the instructions in the Message4, e.g., wait for a while during DTN based simulation and performance pre-verification in NW.

[0093] Step 210: The DT service of the NW node simulates and pre-verifies the performance of XR services 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 DT service response related information may include “DT service id = 0002” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0094] Step 211: The communication function of the NW node sends Message5 to the communication function of the UE through the RRC procedure, and the message contains the DT service response related information generated in Step 209, so that UE can understand the network  condition and its support situation for XR services. The forms of Message5 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0095] Step 212: UE parses the content of Message5 and, based on the information in Message5, decides to immediately start or delay initiating the physical XR service. In case of starting immediately, UE can configure the physical XR service request according to the configuration parameters recommended in Message3.

[0096] IV. Embodiment 3

[0097] Embodiment 3 describes how UE triggers NW for XR service performance pre-verification in parallel with physical XR service.

[0098] In the same background as Embodiment 1, UE may trigger / execute the expected physical wireless service physically, in parallel with ongoing DT services in the overlapping time frame. This may be because user is unwilling to wait some while before triggering the XR service physically, or the NW node cannot notify UE of the DT service results within the waiting time T that the user is willing to endure and hold off the physical service, or for other reasons. This embodiment 3 considers that a mobile user must initiate the XR service in real time, the UE can trigger the NW node to perform the DTN based pre-verification in parallel with physical XR service. In this case, the mobile user is unwilling to wait some while before triggering the XR service physically.

[0099] The following paragraphs describe the implementation steps.

[0100] Step 301: The application function of the UE generates physical service execution related information. Meanwhile, the application function of UE initiates a DTN based pre-verification service request for certain XR service to its own local DT system and provides necessary XR service profile information. After receiving the request, the DT system of UE generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID = 0001" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T that the user is willing to endure and hold off the physical service, i.e. the NW must execute and complete the "DTN based pre-verification" and work out the pre-verification result within the waiting time T. )

[0101] Step 302: The communication function of the UE sends Message1 (containing both physical service execution related information and DT service execution related information  generated in Step 301) to the NW node through the RRC procedure. The forms of Message1 include but are not limited to: reusing existing RRC messages and using newly defined dedicated RRC messages.

[0102] Step 303: NW node parse and response the physical service request contained in Message1, configure corresponding resources, then transmit the service data to UE. UE execute the physical XR service.

[0103] Step 304: The communication function of the NW node 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.

[0104] Step 305: The DT system of the NW node 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 the above admission control of DT service, the DT system of the NW 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. 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.

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

[0106] Step 307: The DT service of the NW node simulates and pre-verifies the performance of XR services 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 DT service response related information may include “DT service id = 0001” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0107] Step 308: The communication function of the NW node 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.

[0108] Step 309: UE parses the content of Message3 and, based on the information in Message3, UE can understand the network condition and the possible quality of XR service in future. UE can modify its own XR service configuration according to the configuration recommendation provided in Message3.

[0109] V. Embodiment 4

[0110] Embodiment 4 describes how UE triggers NW for XR service performance pre-verification, then evaluate the DT service performance.

[0111] In the same background as Embodiment 1, this embodiment 4 considers that the UE triggers the NW to perform the DTN based pre-verification firstly before physically initiating the XR service in physical world, but there is overlapping time frame. After NW node notify UE of the DT service performance evaluation related information, UE can evaluate the performance effects of DT service, and report DT service performance evaluation related information to NW node.

[0112] The following paragraphs describe the implementation steps.

[0113] Step 401: The application function of UE initiates a DTN based pre-verification service request for certain XR service to its own local DT system and provides necessary XR service profile information. After receiving the request, the DT system of UE generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID = 0001" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" (may indicate the waiting time T that the user is willing to endure and hold off the physical service, i.e. the NW must execute and complete the "DTN based pre-verification" and work out the pre-verification result within the waiting time T) .

[0114] Step 402: The communication function of the UE sends Message1 (containing the DT service execution related information generated in step 101) to the NW node through the RRC procedure. The forms of Message1 include but are not limited to: reusing existing RRC messages and using newly defined dedicated RRC messages.

[0115] Step 403: The communication function of the NW node identifies that the message1 contains information related to DTN service requests, so sends it to its own DT system for content parsing and subsequent processing.

[0116] Step 404: The DT system of the NW node 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 the above admission control of DT service, the DT system of the NW 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.

[0117] Step 405: The communication function of the NW node sends Message2 to the communication function of the UE through the RRC procedure, which contains the DT service response related information generated in Step 404. Since the DT service request is accepted, UE can behave according to the instructions in the Message2, e.g., wait for a while during DTN based simulation and performance pre-verification in NW.

[0118] Step 406: The DT service of the NW node simulates and pre-verifies the performance of XR services 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 DT service response related information may include “DT service id” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” , etc.. If the pre-verification fails, DT service response related information may include corresponding error information.

[0119] Step 407: The communication function of the NW node 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 406, so that UE can understand the network condition and its support situation for XR services. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0120] Step 408: UE parses the content of Message3 and, based on the information in Message3, decides to immediately start or delay initiating the physical XR service. In case of starting immediately, UE can configure the physical XR service request according to the configuration parameters recommended in Message3.

[0121] Step 409: After UE starting the physical XR service, UE can evaluate the real performance of DT service, and generate the DT service performance evaluation related information, which may include information such as: “Excellent / Good / Bad level judgement indicator” , “Yes / No or x%for enhancing mobile user’s service experiences” .

[0122] Step 410: The communication function of UE sends Message4 to the communication function of the NW node through the RRC procedure, and the message contains the DT service performance evaluation related information generated in Step 409. Based on Message4, the NW node may adjust its execution of DT service and optimize performance of the pre-verification in future.

[0123] VI. Embodiment 5

[0124] Embodiment 5 describes how UE triggers NW for physical XR service if the NW node does not notify UE of the DT service response related information within the waiting time T.

[0125] In the same background as Embodiment 1, this embodiment 5 considers that the mobile user triggers the NW to perform the DTN based pre-verification firstly before physically initiating the XR service in physical world, and is willing to await time T before triggering the XR service physically. But NW node cannot notify UE of the DT service response related information within waiting time T. This may be because the NW node cannot complete the pre-verification within waiting time T, or the NW node cannot notify UE in time, or for other reasons. In such cases, UE can trigger / execute the expected physical XR service directly.

[0126] The following paragraphs describe the implementation steps.

[0127] Step 501: The application function of UE initiates a DTN based pre-verification service request for certain XR service to its own local DT system and provides necessary XR service profile information. After receiving the request, the DT system of UE generates corresponding DT service execution related information, which may include "DT service request indicator for DT service" , "DT service type = performance pre-verification" , "DT service ID = 0001" , "UE wireless service profile for DT modeling and planning = XR service profile" , "DT service assistance information for DT modeling and planning" (includes the waiting time T that the user is willing to endure and hold off the physical service, i.e. the NW must execute and complete the "DTN based pre-verification" and work out the pre-verification result within the waiting time T. )

[0128] Step 502: The communication function of the UE sends Message1 (containing DT service execution related information generated in Step 501) to the NW node through the RRC procedure. The forms of Message1 include but are not limited to: reusing existing RRC messages and using newly defined dedicated RRC messages.

[0129] Step 503: The communication function of the NW node 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.

[0130] Step 504: The DT system of the NW node 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 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 / No" , "DT service ID = 0001" , etc. If its DT system cannot work out the requested pre-verification result in waiting time T, it may reject the request.

[0131] Step 505: The communication function of the NW node sends Message2 to the communication function of the UE through the RRC procedure, 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.

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

[0133] Step 507: The DT service of the NW node simulates and pre-verifies the performance of XR service 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 DT service response related information may include “DT service id = 0001” , “DT modelling and planning outcomes for UE wireless service” , “DT service outcomes of DT simulation and pre-verification” , etc. If the pre-verification fails, DT service response related information may include corresponding error information.

[0134] Step 508: If UE fails to receive the DT service response related information within waiting time T, the application function of the UE can initiate physical XR service immediately. The whole procedure may be terminated. Or, UE can initiate physical XR service immediately in parallel with the DTN based XR service performance pre-verification, and the DT service of the NW node will continue executing the pre-verification and notify UE of the DT service response related information.

[0135] Step 509: The communication function of the NW node 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. The forms of Message3 include but are not limited to: reusing existing messages and using newly defined dedicated messages.

[0136] Step 510: UE parses the content of Message3 and, based on the information in Message3, UE can understand the network condition and the possible quality of XR service in future. UE can modify its own XR service configuration according to the configuration recommendation provided in Message3.

[0137] FIG. 6 is an example flowchart for transmitting a DT service request related information. Operation 602 includes transmitting, by a wireless device, a digital twin (DT) service request related information. Operation 604 includes receiving, by the wireless device and in response to the DT service request related information, a DT service response related information. 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.

[0138] In some embodiments, the DT service request related information corresponds to a DT network (DTN) based simulation or pre-verification service request, and the DT service request related information includes at least one of the following: a DT service request indicator for a DT service; a DT service type; a DT service identifier (ID) ; a DT service priority; a user equipment (UE) wireless service profile for a DT modeling or planning; or a DT service assistance information for a DT modeling or planning.

[0139] In some embodiments, the DT service request related information is transmitted and the DT service response related information is received through a radio resource control (RRC) procedure in an air interface.

[0140] In some embodiments, the DT service request related information is parsed or processed by a DT system on a network device, where parsing or processing the DT service request related information includes at least one of the following: checking whether a DT network (DTN) based simulation or pre-verification service is within a supported business scope or a DT network (DTN) capability of the network device; determining a priority of a DTN based simulation or pre-verification service request; or preparing a resource set for executing a requested DT service or DT operation.

[0141] In some embodiments, the DT service response related information is received after a DT system of a network device determines to accept an associated DT service request.

[0142] In some embodiments, the DT service response related information instructs the wireless device to hold off on an associated physical wireless service during a DT network (DTN) based simulation or pre-verification service on a network device.

[0143] In some embodiments, the method further includes determining, by the wireless device and based on the DT service response related information, whether to delay initiating a physical wireless service or start initiating a physical wireless service according to a policy or a configuration parameter recommended by a network device.

[0144] In some embodiments, the method further includes parsing or processing, by the wireless device, the DT service response related information, where the wireless device understands a network condition or a possible quality of a physical wireless service at a future time based on a parsed or processed DT service response related information.

[0145] In some embodiments, the DT service response related information includes at least one of the following: a DT service response indicator for a DT service; a DT service identifier (ID) ; a DT modeling or planning outcome for a user equipment (UE) wireless service; a DT service outcome of a DT network (DTN) based simulation or pre-verification service; an error information if a DTN based simulation or pre-verification service fails; or a reason for rejecting a DT service request.

[0146] In some embodiments, the reason for rejecting the DT service request includes at least one of the following: a format of the DT service request related information is incorrect; the DT service request related information contains an incorrect parameter; or the DT service request exceeds a business scope or a DTN capability of a network device.

[0147] In some embodiments, the method further includes transmitting, by the wireless device and based on the reason for rejecting the DT service request, an adjusted or updated DT service request including an adjusted or updated DT service request related information.

[0148] In some embodiments, the method further includes transmitting, by the wireless device, a physical wireless service execution related information. In some embodiments, the method further includes triggering or executing, by the wireless device and based on the physical wireless service execution related information, a physical wireless service in parallel with an ongoing DT service corresponding to the DT service request related information in an overlapping time frame.

[0149] In some embodiments, triggering or executing the physical wireless service is based on a determination that a user is unwilling to wait for a period of time before the physical wireless service is triggered, a network device is unable to complete a DT network (DTN) based simulation  or pre-verification service within a predetermined waiting time, or a network device is unable to notify the wireless device of a DT service outcome within the predetermined waiting time.

[0150] FIG. 7 is an example flowchart for transmitting a DT service request. Operation 702 includes transmitting, by a wireless device, a digital twin (DT) service request. Operation 704 includes receiving, by the wireless device and based on the DT service request, an outcome of a completed DT service. 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.

[0151] In some embodiments, the method further includes receiving, by the wireless device and based on the DT service request, additional DT service outcomes periodically beyond a predetermined waiting time. In some embodiments, based on a single DT service request, the network device can notify the UE of DT service updated outcomes multiple times, e.g., as periodical notifications with updated outcomes, so that the UE can continue to know more updated simulation and pre-verification results beyond the waiting time T.

[0152] FIG. 8 is an example flowchart for performing a local DT operation. Operation 802 includes performing, by a wireless device with a digital twin (DT) capability, a local DT 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.

[0153] In some embodiments, the wireless device triggers one or more DT operations or DT services for an expected physical wireless service before executing the expected physical wireless service.

[0154] In some embodiments, the wireless device triggers multiple DT operations or DT services in parallel for different physical wireless services.

[0155] In some embodiments, the method further includes determining, by the wireless device and based on an outcome of a DT operation or DT service, whether, when, or how to trigger or execute an expected physical wireless service.

[0156] In some embodiments, the method further includes initiating, by the wireless device, the expected physical wireless service, despite that the outcome of the DT operation or DT service indicates that a pre-verified wireless service is not well supported, or a user experience will be poor after initiating the expected physical wireless service at an immediate time.

[0157] In some embodiments, the method further includes triggering or executing, by the wireless device and before receiving an outcome of a DT operation or DT service, an expected physical wireless service.

[0158] In some embodiments, the method further includes transmitting, by the wireless device, a DT service performance evaluation result report.

[0159] FIG. 9 is an example flowchart for performing a DT service. Operation 902 includes receiving, by a network device, a digital twin (DT) service request related information. Operation 904 includes performing, by the network device and based on the DT service request related information, a DT service. 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.

[0160] In some embodiments, the DT service request related information is received in an uplink DT service message, and the DT service request related information includes at least one of the following: a DT service request indicator for a DT service; a DT service type; a DT service identifier (ID) ; a DT service priority; a user equipment (UE) wireless service profile for a DT modeling or planning; or a DT service assistance information for a DT modeling or planning.

[0161] In some embodiments, the method further includes transmitting, by the network device, a downlink DT service message including a DT service response related information, where the DT service response related information includes at least one of the following: a DT service response indicator for a DT service; a DT service identifier (ID) ; a DT modeling or planning outcome for a user equipment (UE) wireless service; a DT service outcome of a DT network (DTN) based simulation or pre-verification service; an error information if a DTN based simulation or pre-verification service fails; or a reason for rejecting a DT service request.

[0162] FIG. 10 is an example flowchart for transmitting a DT service performance evaluation result report. Operation 1002 includes receiving, by a wireless device, a digital twin (DT) service performance evaluation query related information. Operation 1004 includes transmitting, by the wireless device and based on the DT service performance evaluation query related information, a DT service performance evaluation result report. 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.

[0163] In some embodiments, the DT service performance evaluation query related information is received in a downlink DT service performance evaluation query message, the DT service performance evaluation result report is transmitted in an uplink DT service performance  evaluation result report message, and the DT service performance evaluation result report includes at least one of the following: an excellent, good, average, or bad level judgement indicator for enhancing a user service experience with an associated DT service; a yes or satisfied versus no or unsatisfied indicator for enhancing a user service experience with an associated DT service; or a percentage level indicator for enhancing a user service experience with an associated DT service.

[0164] In some embodiments, a DT service or operation is adjusted, updated, or optimized based on the DT service performance evaluation result report.

[0165] FIG. 11 is an example flowchart for executing a physical wireless service request in parallel with an ongoing DT service. Operation 1102 includes receiving, by a network device, a physical wireless service request. Operation 1104 includes executing, by the network device, the physical wireless service request in parallel with an ongoing digital twin (DT) service in an overlapping time frame. 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.

[0166] FIG. 12 shows an example block diagram of a hardware platform 1200 that may be a part of a network device (e.g., a base station (BS) , a transmission and reception point (TRP) , or a radio access network (RAN) ) or a wireless device (e.g., a user equipment (UE) ) . The hardware platform 1200 includes at least one processor 1210 and a memory 1205 having instructions stored thereupon. The instructions upon execution by the processor 1210 configure the hardware platform 1200 to perform the operations described in FIGS. 1-11 and in the various embodiments described in this patent document. The transmitter 1215 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 1220 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 1200.

[0167] The implementations as discussed above will apply to a wireless communication. FIG. 13 shows an example of a wireless communication system (e.g., a 6G, 5G, or NR cellular network) that includes a base station 1320 and one or more user equipment (UE) 1311, 1312, and 1313. 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 1331, 1332, 1333) , which then enables subsequent communication (e.g., shown in the direction from the network to the UEs, sometimes called downlink direction, shown by arrows 1341, 1342, 1343) from the BS  to the UEs. In some embodiments, the BS sends information to the UEs (sometimes called downlink direction, as depicted by arrows 1341, 1342, 1343) , 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 1331, 1332, 1333) 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 1320 depicted in FIG. 13.

[0168] It will be appreciated by one of skill in the art that the present patent document discloses methods that, among other benefits, improve the user experience. The methods disclosed include performing local DT operations or DT services via a RRC procedure. The methods disclosed further include sending DT service performance evaluation result reports.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] 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:transmitting, by a wireless device, a digital twin (DT) service request related information; andreceiving, by the wireless device and in response to the DT service request related information, a DT service response related information.2.The method of claim 1, wherein the DT service request related information corresponds to a DT network (DTN) based simulation or pre-verification service request, and wherein the DT service request related information comprises at least one of the following:a DT service request indicator for a DT service;a DT service type;a DT service identifier (ID) ;a DT service priority;a user equipment (UE) wireless service profile for a DT modeling or planning; ora DT service assistance information for a DT modeling or planning.3.The method of claim 1 or 2, wherein the DT service request related information is transmitted and the DT service response related information is received through a radio resource control (RRC) procedure in an air interface.4.The method of any of claims 1-3, wherein the DT service request related information is parsed or processed by a DT system on a network device, and wherein parsing or processing the DT service request related information comprises at least one of the following:checking whether a DT network (DTN) based simulation or pre-verification service is within a supported business scope or a DT network (DTN) capability of the network device;determining a priority of a DTN based simulation or pre-verification service request; orpreparing a resource set for executing a requested DT service or DT operation.5.The method of any of claims 1-4, wherein the DT service response related information is received after a DT system of a network device determines to accept an associated DT service request.6.The method of any of claims 1-5, wherein the DT service response related information instructs the wireless device to hold off on an associated physical wireless service during a DT network (DTN) based simulation or pre-verification service on a network device.7.The method of any of claims 1-5, further comprising determining, by the wireless device and based on the DT service response related information, whether to delay initiating a physical wireless service or start initiating a physical wireless service according to a policy or a configuration parameter recommended by a network device.8.The method of any of claims 1-7, further comprising parsing or processing, by the wireless device, the DT service response related information, wherein the wireless device understands a network condition or a possible quality of a physical wireless service at a future time based on a parsed or processed DT service response related information.9.The method of any of claims 1-8, wherein the DT service response related information comprises at least one of the following:a DT service response indicator for a DT service;a DT service identifier (ID) ;a DT modeling or planning outcome for a user equipment (UE) wireless service;a DT service outcome of a DT network (DTN) based simulation or pre-verification service;an error information if a DTN based simulation or pre-verification service fails; ora reason for rejecting a DT service request.10.The method of claim 9, wherein the reason for rejecting the DT service request comprises at least one of the following:a format of the DT service request related information is incorrect;the DT service request related information contains an incorrect parameter; orthe DT service request exceeds a business scope or a DTN capability of a network device.11.The method of claim 9 or 10, further comprising transmitting, by the wireless device and based on the reason for rejecting the DT service request, an adjusted or updated DT service request comprising an adjusted or updated DT service request related information.12.The method of any of claims 1-11, further comprising:transmitting, by the wireless device, a physical wireless service execution related information; andtriggering or executing, by the wireless device and based on the physical wireless service execution related information, a physical wireless service in parallel with an ongoing DT service corresponding to the DT service request related information in an overlapping time frame.13.The method of claim 12, wherein triggering or executing the physical wireless service is based on a determination that a user is unwilling to wait for a period of time before the physical  wireless service is triggered, a network device is unable to complete a DT network (DTN) based simulation or pre-verification service within a predetermined waiting time, or a network device is unable to notify the wireless device of a DT service outcome within the predetermined waiting time.14.A method of wireless communication, comprising:transmitting, by a wireless device, a digital twin (DT) service request; andreceiving, by the wireless device and based on the DT service request, an outcome of a completed DT service.15.The method of claim 14, further comprising receiving, by the wireless device and based on the DT service request, additional DT service outcomes periodically beyond a predetermined waiting time.16.A method of wireless communication, comprising performing, by a wireless device with a digital twin (DT) capability, a local DT operation.17.The method of any of claims 14-16, wherein the wireless device triggers one or more DT operations or DT services for an expected physical wireless service before executing the expected physical wireless service.18.The method of any of claims 14-17, wherein the wireless device triggers multiple DT operations or DT services in parallel for different physical wireless services.19.The method of any of claims 14-18, further comprising determining, by the wireless device and based on an outcome of a DT operation or DT service, whether, when, or how to trigger or execute an expected physical wireless service.20.The method of claim 19, further comprising initiating, by the wireless device, the expected physical wireless service, despite that the outcome of the DT operation or DT service indicates that a pre-verified wireless service is not well supported, or a user experience will be poor after initiating the expected physical wireless service at an immediate time.21.The method of any of claims 14-18, further comprising triggering or executing, by the wireless device and before receiving an outcome of a DT operation or DT service, an expected physical wireless service.22.The method of any of claims 14-21, further comprising transmitting, by the wireless device, a DT service performance evaluation result report.23.A method of wireless communication, comprising:receiving, by a network device, a digital twin (DT) service request related information; andperforming, by the network device and based on the DT service request related information, a DT service.24.The method of claim 23, wherein the DT service request related information is received in an uplink DT service message, and wherein the DT service request related information comprises at least one of the following:a DT service request indicator for a DT service;a DT service type;a DT service identifier (ID) ;a DT service priority;a user equipment (UE) wireless service profile for a DT modeling or planning; ora DT service assistance information for a DT modeling or planning.25.The method of claim 23 or 24, further comprising transmitting, by the network device, a downlink DT service message comprising a DT service response related information, wherein the DT service response related information comprises at least one of the following:a DT service response indicator for a DT service;a DT service identifier (ID) ;a DT modeling or planning outcome for a user equipment (UE) wireless service;a DT service outcome of a DT network (DTN) based simulation or pre-verification service;an error information if a DTN based simulation or pre-verification service fails; ora reason for rejecting a DT service request.26.A method of wireless communication, comprising:receiving, by a wireless device, a digital twin (DT) service performance evaluation query related information; andtransmitting, by the wireless device and based on the DT service performance evaluation query related information, a DT service performance evaluation result report.27.The method of claim 26, wherein the DT service performance evaluation query related information is received in a downlink DT service performance evaluation query message, wherein the DT service performance evaluation result report is transmitted in an uplink DT service performance evaluation result report message, and wherein the DT service performance evaluation result report comprises at least one of the following:an excellent, good, average, or bad level judgement indicator for enhancing a user service experience with an associated DT service;a yes or satisfied versus no or unsatisfied indicator for enhancing a user service experience with an associated DT service; ora percentage level indicator for enhancing a user service experience with an associated DT service.28.The method of claim 26 or 27, wherein a DT service or operation is adjusted, updated, or optimized based on the DT service performance evaluation result report.29.A method of wireless communication, comprising:receiving, by a network device, a physical wireless service request; andexecuting, by the network device, the physical wireless service request in parallel with an ongoing digital twin (DT) service in an overlapping time frame.30.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 29.31.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 29.

Images