Adjusting wakeup time across uplink and downlink of multiple protocols

Abstract

Various embodiments include a method implemented in a user equipment (UE) for synchronizing resource timing of at least two wireless protocols. The UE may obtain communication timing information of a user device, transmit the communication timing information of the user device to a network node, and configure a first resource timing of an uplink or a downlink between the UE and the user device based on the communication timing information. The UE may request a configuration of a second resource timing for another uplink or downlink between the UE and the network node based on the communication timing information. Sending communication timing information may include requesting a discontinuous reception (DRX) configuration adjustment that causes a discontinuous reception (DRX) period of the UE to at least partially coincide with a target wake time (TWT) of the user device. Configuring a first resource timing may include adjusting a timing of the TWT based on a DRX configuration of the user device.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 815,263, filed on July 27, 2022; the entire contents of which are hereby incorporated by reference. Background Art

[0003] Long Term Evolution (LTE), Fifth Generation (5G) New Radio (NR), and other communication technologies enable improved communication and data services. One such service is Augmented Reality (AR) or Extended Reality (XR), which require low latency and high bandwidth for real-time processing. Some of this data bandwidth may be allocated to other transport networks, such as a Wireless Local Area Network (WLAN), which may be a Wi-Fi network with a connection to the Internet. However, non-5G communication networks may operate at different times and cause user devices to transmit and receive all the time, resulting in lower battery and energy performance. Summary of the invention

[0004] Aspects include systems and methods performed by a user equipment (UE) for improving wireless communications by enabling synchronization of communication windows between protocols and / or between portions of downlink and uplink communication chains. Aspects may include: obtaining communication timing information of the user device, sending the communication timing information of the user device to a network node; and

[0005] A first resource timing of an uplink or a downlink between the UE and the user device is configured based on the communication timing information. Some aspects may also include requesting configuration of a second resource timing of another uplink or a downlink between the UE and the network node based on the communication timing information. In some aspects, sending the communication timing information may also include requesting that the network node adjust a discontinuous reception (DRX) configuration so that the DRX cycle of the UE and the target wake-up time (TWT) of the user device at least partially overlap.

[0006] In some aspects, configuring the first resource timing may also include adjusting the timing of a target wake time (TWT) for the user device based on a discontinuous reception (DRX) configuration. In some aspects, adjusting the timing of the TWT includes setting a TWT interval and a TWT start based on a DRX cycle and a DRX offset of the UE, respectively, wherein the DRX cycle and the DRX offset are configured by the network node. In some aspects, adjusting the timing of the TWT includes setting a TWT minimum wake-up duration based on jitter of arrival times of periodic data services received by the UE.

[0007] In some aspects, configuring the first resource timing may also include: adjusting the timing of the target wake-up time (TWT) for downlink traffic from the UE to the user device based on the discontinuous reception (DRX) configuration of the UE, the physical downlink shared channel (PDSCH) traffic mode between the UE and the network node, or the semi-persistent scheduling of the network node. In some aspects, configuring the first resource timing may also include: adjusting the timing of at least one of a bandwidth physical uplink shared channel (PUSCH), a configuration grant of the network node based on the TWT of the user device, or an auxiliary message from the user device for uplink traffic from the user device to the UE. Some aspects may also include: the UE actively sending the SR before receiving data from the user device by considering one or both of the delay of the scheduling request (SR) for the PUSCH or the delay of the buffer status report (BSR).

[0008] In some aspects, configuring the first resource timing may also include sending the communication timing information, and may also include: generating one or more auxiliary data messages including the communication timing information of the user device via a cross-layer application programming interface (API) on the UE, and sending the one or more auxiliary data messages to the network node. In some aspects, configuring the first resource timing may also include: adjusting the timing of the target wake-up time (TWT) of the user device to at least partially overlap with the DRX cycle of the UE based on the discontinuous reception (DRX) configuration of the UE received from the network node. In some aspects, configuring the first resource timing may also include: adjusting the timing of the target wake-up time (TWT) of the user device based on downlink traffic from the network node. In some aspects, configuring the first resource timing may also include requesting that the physical uplink shared channel (PUSCH) resources of the UE be adjusted to at least partially overlap with the TWT of the user device based on the communication timing information.

[0009] Some aspects may also include receiving data generation timing, wherein configuring the first resource timing may include: sending a request to the network node to adjust the physical uplink shared channel (PUSCH) resources of the UE based on the data generation timing, or sending a request to the network node to adjust the data generation timing.

[0010] In some aspects, configuring the first resource timing may also include one or both of the following: adjusting the timing of the uplink from the user device to the UE to at least partially overlap with another uplink from the UE to the network node based on the communication timing information, or adjusting the timing of the downlink from the UE to the user device to at least partially overlap with another downlink from the network node to the UE based on the communication timing information.

[0011] Other aspects include a UE having a processor configured to perform one or more operations of any of the methods outlined above. Other aspects include a processing device for use in a UE, the processing device being configured with processor-executable instructions to perform the operations of any of the methods outlined above. Other aspects include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the UE to perform the operations of any of the methods outlined above. Other aspects include a UE having a component for performing the functions of any of the methods outlined above. Other aspects include a system-on-chip for use in a UE, the system-on-chip comprising a processor configured to perform one or more operations of any of the methods outlined above.

[0012] Other aspects include methods for synchronizing resource timing of at least two wireless protocols executed by a processor of a network node. Such aspects may include receiving one or more auxiliary data messages from a user equipment (UE), the one or more auxiliary data messages including communication timing information of a user device connected to the UE, configuring the resource timing of the network node based on the communication timing information, and notifying the UE of adjusted PUSCH resources. In some aspects, configuring the resource timing of the network node based on the communication timing information may include: adjusting a physical uplink shared channel (PUSCH) resource allocated to the UE to at least partially coincide with a target wake-up time (TWT) of the user device, the timing of the TWT being included in the communication timing information. In some aspects, configuring the resource timing of the network node based on the communication timing information may include: adjusting a physical uplink shared channel (PUSCH) resource allocated to the UE based on the communication timing information, wherein the communication timing information is related to data generation timing at the user device.

[0013] Other aspects include a network node having a processor configured to perform one or more operations of any of the methods outlined above. Other aspects include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a processor of the network node to perform the operations of any of the methods outlined above. Other aspects include a network node having components for performing the functionality of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0015] Figure 1A is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.

[0016] Figure 1B is a system block diagram illustrating an example communication system suitable for implementing any of the various embodiments.

[0017] Figure 1C is a system block diagram illustrating an example decomposed base station architecture suitable for implementing any of the various embodiments.

[0018] Figure 2A is a transmission downlink timing block diagram illustrating example communication timing in accordance with various embodiments.

[0019] Figure 2B is a transmit uplink timing block diagram illustrating example communication timing in accordance with various embodiments.

[0020] Figure 3A is a system block diagram illustrating a process for wireless communication suitable for implementing various embodiments.

[0021] Figure 3B is a system block diagram illustrating a process for wireless communication suitable for implementing various embodiments.

[0022] Figure 4A is a system block diagram illustrating a process for wireless communication suitable for implementing various embodiments.

[0023] Figure 4B is a system block diagram illustrating a process for wireless communication suitable for implementing various embodiments.

[0024] Figure 5A is a system block diagram illustrating a process suitable for implementing wireless communications of various embodiments.

[0025] Figure 5Bis a system block diagram illustrating a process for wireless communication suitable for implementing various embodiments.

[0026] Fig. 6A is a block diagram illustrating computing devices in a network suitable for implementing various embodiments.

[0027] Figure 6B is a block diagram illustrating computing devices in a network suitable for implementing various embodiments.

[0028] Figure 7 is a transmission downlink timing block diagram illustrating example communication timing in accordance with various embodiments.

[0029] Figure 8 is a process flow diagram illustrating an example process suitable for implementing various embodiments.

[0030] Fig.9A is a process flow diagram illustrating an example process suitable for implementing various embodiments.

[0031] Fig. 9B is a process flow diagram illustrating an example process suitable for implementing some embodiments.

[0032] Fig. 10A is a transmit uplink timing block diagram illustrating example communication timing in accordance with some embodiments.

[0033] Fig. 10B is a transmit uplink timing block diagram illustrating example communication timing in accordance with some embodiments.

[0034] Fig.11 is a process flow diagram illustrating an example process suitable for implementing some embodiments.

[0035] Fig.12 is a process flow diagram illustrating an example process suitable for implementing some embodiments.

[0036] Fig.13 is a component block diagram of an example of smart glasses suitable for use with various embodiments.

[0037] Fig.14 is a component block diagram of a UE suitable for use with various embodiments.

[0038] Fig.15 is a component block diagram of a connected processor suitable for implementing various embodiments.

[0039] Fig.16 is a component block diagram of a network device suitable for use with various embodiments. DETAILED DESCRIPTION

[0040] Various embodiments and implementations are described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0041] Various embodiments include systems and methods for synchronizing wake-up times or ON times of multiple wireless communication protocols for wireless user equipment (UE). According to various aspects, a UE may establish a communication link between a network node and a user device, such as extended reality (XR) glasses. The XR glasses may utilize a backend server for graphics processing and other power-intensive tasks. The UE may be connected as a bridge between the XR / AR glasses and a cellular network connected to an extended reality computing server. The XR glasses may include a Wi-Fi link and a separate cellular link to the UE. The systems and methods of various embodiments provide synchronization of these various communication links so as to reduce the ON time of the transceiver in the XR glasses, thereby saving power in the UE.

[0042] Various embodiments improve wireless communications by enabling synchronization of communication windows between protocols and / or between portions of a downlink / uplink chain, where different portions of a downlink / uplink chain may be different protocols. Various aspects of the present disclosure improve wireless communications by providing an enhanced messaging process that notifies devices along an uplink / downlink path of preferred timing and communication windows.

[0043] The term "user equipment" (UE) is used herein to refer to any or all of the following: wireless communication devices, wireless appliances, cellular phones, smart phones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, multimedia Internet-enabled cellular phones, wireless router devices, medical devices and equipment, biometric sensors / devices, wearable devices (including smart watches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings and smart bracelets)), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices (including smart meters / sensors), industrial manufacturing equipment, large and small machines and appliances for home or business use, wireless communication elements within autonomous and semi-autonomous vehicles, wireless devices fixed to or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices that include memory, wireless communication components, and programmable processors.

[0044] The term "user device" is generally used herein to refer to a device that can communicate with a UE to receive downlink signals and send uplink signals according to various embodiments and implementations. Various embodiments are particularly useful for AR glasses, which are a type of user device. Therefore, in the following embodiments, the terms "user device" and "AR glasses" may be used interchangeably.

[0045] The term "system on chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources or processors integrated on a single substrate. A single SOC may contain circuits for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general or special-purpose processors (digital signal processors, modem processors, video processors, etc.), memory blocks (such as ROM, RAM, flash memory, etc.), and resources (such as timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.

[0046] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores, or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs coupled together via high-speed communication circuits and packaged in close proximity (such as on a single motherboard or in a single wireless device). The proximity of the SOCs facilitates high-speed communication and the sharing of memory and resources.

[0047] As used herein, the terms "network", "system", "wireless network", "cellular network", and "wireless communication network" may interchangeably refer to a portion or all of an operator's wireless network associated with a wireless device and / or a subscription on a wireless device. The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA), time division multiple access (TDMA), FDMA, orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), and other networks. In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support at least one radio access technology that may operate on one or more frequencies or frequency ranges. For example, a CDMA network may implement Universal Terrestrial Radio Access (UTRA) (including Wideband Code Division Multiple Access (WCDMA) standards), CDMA2000 (including IS-2000, IS-95, and / or IS-856 standards), and the like. In another example, a TDMA network may implement Enhanced Data Rates for Global System for Mobile Communications (GSM) Evolution (EDGE). In another example, the OFDMA network may implement Evolved UTRA (E-UTRA) (including the LTE standard), Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDM®, etc. Reference may be made to a wireless network using the LTE standard, and thus the terms "Evolved Universal Terrestrial Radio Access," "E-UTRAN," and "eNodeB" may also be used interchangeably herein to refer to a wireless network. However, these references are provided as examples only and are not intended to exclude wireless networks using other communication standards. For example, although various third generation (3G) systems, fourth generation (4G) systems, and fifth generation (5G) systems are discussed herein, these systems are referenced only as examples, and the next generation system (e.g., sixth generation (6G) or higher generation system) may be substituted in various examples.

[0048] Augmented reality (AR) or extended reality (XR) technologies are expected to be the next frontier in media by adding, extending, or overlaying additional features and information on the world we perceive around us. Because augmented reality or extended reality is added to the user experience as part of the real world, these technologies necessarily include real-time aspects. In addition, AR and XR media can be primarily audio-visual. Currently, the real-time projection of audio-visual overlays and information onto the lens through which the real world is viewed requires a lot of computer processing and power. Therefore, battery resource requirements on portable augmented reality or extended reality user devices are high or need to be conserved. In some embodiments, computing tasks associated with AR and XR media processing are performed in one or more cloud resources, where the processed media is transmitted to VR / XR glasses in order to save battery power on the UE and / or VR / XR glasses.

[0049] In applications where computation and rendering processing is transferred to an external server, the bandwidth and latency of the communication link between the portable user device and the backend server may become a bottleneck for the application. In addition, despite outsourcing such processing to an external server, battery resources may still be an important consideration. Therefore, the efficiency of the communication link between the portable user device and the backend server remains important. The systems and processes disclosed herein can improve the efficiency of the communication link in multiple aspects including power usage and bandwidth allocation.

[0050] In some embodiments, the portable user device that provides an extended reality experience may be augmented reality (AR) glasses. AR glasses may project or display one or more graphics on their lenses and may emit sounds from their frames or temples. AR glasses may also allow the user to look through the lenses to view the real world while the graphics are displayed on the lenses. In order to properly align the displayed graphics with the real world seen through the lenses, the AR glasses record or monitor the user's posture, orientation, eye direction, and movement. In order to support the rendering process that matches the user's field of view, an external server may require the user's posture, orientation, eye direction, or movement before starting the calculation. Therefore, in embodiments where the extended reality processing is transmitted to an external server, the timing between the upload of the posture information and the download of the completed rendering may have specific latency requirements. The systems and processes of various embodiments can reduce the latency within this loop.

[0051] Figure 1A1 is a system diagram illustrating an example communication system 100 that provides a communication link between AR glasses 140 and XR server 110. As described above, AR glasses 140 may require additional processing to be performed on XR server 110, and accordingly, XR server 110 may require gesture information from AR glasses 140. Thus, example communication system 100 may include uplink channels and downlink channels or uplink resources and downlink resources. One or more of the links or connections within example communication system 100 may be wireless or wired. Figure 1A The devices shown in are merely examples and may be other computing devices or communication devices.

[0052] As shown, the AR glasses 140 can be connected to a user equipment (UE) 150 via a Wi-Fi link 145, and the UE 150 can be connected to a network node 120 via a radio link 125, and the network node 120 can connect the link 120 to the XR server 110. The wireless link 125 can be provided by a 5G new radio (NR) network or any other appropriate network (such as a long-term evolution (LTE) network or a next-generation network). Therefore, references to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting. The communication system 100 can be a heterogeneous network that includes peer links, relay links, and one or more links to a network node (e.g., network node 120). The XR server 110 can be set on the back end and connected to the network node 120 via a backhaul link or other network link. In Figure 1C The various connections in the 5G radio system are described in more detail in .

[0053] In the example communication system 100, the AR glasses 140 may include a Wi-Fi transceiver to connect to a user equipment (UE) 150 and other Wi-Fi resources, wherein the Wi-Fi transceiver sends and receives signals via uplinks and downlinks defined by one of the Wi-Fi standard protocols. The UE 150 may include a Wi-Fi transceiver for communicating with the AR glasses 140 and a 5G transceiver for communicating with the network node 120. The radio link 125 may be a cellular wireless link defined by a 5G standard protocol or other suitable protocol.

[0054] Figure 1B is a system diagram illustrating an example communication system 101 that provides a communication link between the AR glasses 140 and the XR server 110. Figure 1BIn the example communication system 101 shown, the AR glasses 140 can be connected to one or more UEs 150 via a Wi-Fi link 145, and connected to the network node 120 via a radio link 147, which can be a cellular wireless link defined by a 5G standard protocol or other suitable protocol. The UE 150 can be connected to the network node via a radio link 125 in parallel with the radio link 147. That is, the radio link 147 and the radio link 125 can share bandwidth resources. In addition, the Wi-Fi link 145 can be replaced or assisted by a peer 5G side link connection, which can share resources with the radio links 125 and 147. Therefore, in the example communication system 101, the AR glasses 140 can be connected to the XR server 110 via a radio link 147 and / or a Wi-Fi link 145. The AR glasses 140 may include a Wi-Fi transceiver and a radio (5G) transceiver.

[0055] The communication system 100 or 101 may include a plurality of network nodes 120 and other network entities, such as base stations and other UEs. A network node is an entity that communicates with a UE and may be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next generation Node B (gNodeB or gNB), etc.

[0056] In various communication network implementations or architectures, the network node may be implemented as an aggregated base station, a decomposed base station, an integrated access and backhaul (IAB) node, a relay node, a side link node, etc., such as a virtualized radio access network (vRAN) or an open radio access network (O-RAN). In addition, in various communication network implementations or architectures, the network device (or network entity) may be implemented in an aggregated or integrated base station architecture or alternatively in a decomposed base station architecture, and may include one or more of a centralized unit (CU), a distributed unit (DU), a radio unit (RU), a near real-time (RT) RAN intelligent controller (RIC), or a non-real-time RIC. Each network device can provide communication coverage for a specific geographic area. In 3GPP, the term "cell" may refer to a coverage area of ​​a network device, a network device subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used.

[0057] The network node 120 may provide communication coverage for a macro cell, a pico cell, a femto cell, another type of cell, or a combination thereof. A macro cell may cover a relatively large geographic area (e.g., a radius of several kilometers) and may allow unrestricted access by a UE with a service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by a UE with a service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by a UE associated with the femto cell (e.g., a UE in a closed subscriber group (CSG)). A network node of a macro cell may be referred to as a macro node or a macro base station. A network node of a pico cell may be referred to as a pico node or a pico base station. A network node of a femto cell may be referred to as a femto node, a femto base station, a home node, or a home network device. The terms "network device", "network node", "eNB", "base station", "NR BS", "gNB", "TRP", "AP", "Node B", "5G NB", and "cell" may be used interchangeably herein.

[0058] In some examples, the cell may not be stationary, and the geographic area of ​​the cell may move depending on the location of the network device. In some examples, the network nodes may be interconnected to each other and to one or more other network devices (e.g., base stations or network nodes (not illustrated)) in the communication system 100 through various types of backhaul interfaces (such as direct physical connections, virtual networks, or combinations thereof) using any suitable transport network.

[0059] The network node 120 may communicate with a backend server (e.g., XR server 110) via a wired or wireless communication link (e.g., link 121). The UE 150 may communicate with the network node 120 via a wireless communication link 125. The wired communication link (e.g., link 121) for the backend may use various wired networks (such as Ethernet, TV cable, telephone communication, optical fiber, and other forms of physical network connections), which may use one or more wired communication protocols, such as Ethernet, point-to-point protocol, high-level data link control (HDLC), high-level data communication control protocol (ADCCP), and transmission control protocol / Internet protocol (TCP / IP).

[0060] The communication system 100 may also include a relay station, which may receive a transmission of data from an upstream station (e.g., a network node or UE) and send a transmission of data to a downstream station (e.g., a UE or a network node). A relay station may also be a UE that is capable of relaying transmissions for other UEs. A network controller may be coupled to a group of network nodes and may provide coordination and control for these network nodes. The network controller may communicate with a network subject via a backhaul, midhaul, and / or fronthaul. The network nodes may also communicate with each other directly or indirectly, for example, via a wireless or wired backhaul.

[0061] The communication system 100 or 101 may be a heterogeneous network including different types of network devices (e.g., macro network devices, pico network devices, femto network devices, relay network devices, etc.). These different types of network devices may have different transmit power levels, different coverage areas, and different effects on interference in the communication system 100. For example, a macro node may have a high transmit power level (e.g., 5 to 40 watts), while a pico network device, a femto network device, and a relay network device may have a lower transmit power level (e.g., 0.1 to 2 watts). UEs (e.g., UE 150) may be dispersed throughout the communication system 100, and each UE may be stationary or mobile. UEs may also be referred to as access terminals, terminals, mobile stations, subscriber units, user stations, wireless devices, etc.

[0062] A wireless communication link (e.g., radio link 125 or radio link 147) may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication link may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication link include 3GPP LTE, 3G, 4G, 5G (such as NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that may be used in one or more of the various wireless communication links within the communication system 100 include medium-range protocols (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE)).

[0063] Generally, any number of communication systems and any number of wireless networks can be deployed in a given geographic area. Each communication system and wireless network can support a specific radio access technology (RAT) and can operate on one or more frequencies. RAT can also be referred to as radio technology, air interface, etc. Frequency can also be referred to as carrier, frequency channel, etc. Each frequency can support a single RAT in a given geographic area to avoid interference between communication systems of different RATs. In some cases, 4G / LTE and / or 5G / NR RAT networks can be deployed. For example, a 5G non-standalone (NSA) network can utilize both 4G / LTE RAT on the 4G / LTE RAN side of a 5GNSA network and 5G / NR RAT on the 5G / NR RAN side of a 5G NSA network. Both 4G / LTE RAN and 5G / NR RAN can be connected to each other and to a 4G / LTE core network (e.g., an evolved packet core (EPC) network) in a 5G NSA network. Other example network configurations may include a 5G standalone (SA) network, in which a 5G / NR RAN is connected to a 5G core network.

[0064] The deployment of a communication system (such as a 5G NR system) can be arranged in a variety of ways with various components or constituent parts. In a 5G NR system or network, a network node, a network entity, a mobility element of a network, a radio access network (RAN) node, a core network node, a network element, or a network device (such as a base station (BS) or one or more units (or components) performing base station functions) can be implemented in an aggregated or decomposed architecture. For example, a base station (such as a Node B (NB), an evolved NB (eNB), an NR BS, a 5G NB, an access point (AP), a transmit receive point (TRP), or a cell, etc.) can be implemented as an aggregated base station (also called a standalone BS or a monolithic BS) or a decomposed base station.

[0065] An aggregated base station may be configured to utilize a radio protocol stack that is physically or logically integrated within a single RAN node. A decomposed base station may be configured to utilize a protocol stack that is physically or logically distributed between two or more units, such as one or more central or centralized units (CUs), one or more distributed units (DUs), or one or more radio units (RUs). In some aspects, a CU may be implemented within a RAN node, and one or more DUs may be co-located with the CU, or alternatively, may be geographically or virtually distributed in one or more other RAN nodes. A DU may be implemented to communicate with one or more RUs. Each of the CU, DU, and RU may also be implemented as a virtual unit, referred to as a virtual central unit (VCU), a virtual distributed unit (VDU), or a virtual radio unit (VRU).

[0066] Base station type operations or network designs may take into account the aggregated nature of base station functionality. For example, a decomposed base station may be utilized in an integrated access backhaul (IAB) network, an open radio access network (O-RAN (such as a network configuration sponsored by the O-RAN Alliance)), or a virtualized radio access network (vRAN, also known as a cloud radio access network (C-RAN)). Decomposition may include distributing functionality across two or more units at multiple physical locations, as well as virtually assigning functionality to at least one unit, which may enable flexibility in network design. Individual units of a decomposed base station or decomposed RAN architecture may be configured for wired or wireless communication with at least one other unit.

[0067] Figure 1C is a system block diagram illustrating an example decomposed base station 160 architecture suitable for implementing any of the various embodiments. Figure 1A , Figure 1B and Figure 1C , the decomposed base station 160 architecture may include one or more central units (CU) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more decomposed base station units (such as a near real-time (near RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (non-RT) RIC 168 associated with a service management and orchestration (SMO) architecture 166, or both). The CU 162 may communicate with one or more distributed units (DU) 170 via corresponding mid-haul links (such as an F1 interface). The DU 170 may communicate with one or more radio units (RU) 172 via corresponding fronthaul links. The RU 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some embodiments, a UE 120 may be served by multiple RUs 172 simultaneously.

[0068] Each unit (i.e., CU 162, DU 170, RU 172) and near-RT RIC 164, non-RT RIC 168, and SMO architecture 166 may include one or more interfaces or be coupled to one or more interfaces configured to receive or send signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units or an associated processor or controller that provides instructions to the communication interface of the unit may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface that is configured to receive signals or send signals to one or more other units via a wired transmission medium. Additionally, a unit may include a wireless interface that is configured to receive signals from one or more of the other units or send signals to one or more of the other units or simultaneously receive and send signals via a wireless transmission medium, and the wireless interface may include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver).

[0069] In some aspects, CU 162 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to transmit signals with other control functions hosted by CU 162. CU162 may be configured to handle user plane functions (i.e., central unit-user plane (CU-UP)), control plane functions (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some embodiments, CU 162 may be logically divided into one or more CU-UP units and one or more CU-CP units. The CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as an E1 interface when implemented in an O-RAN configuration). CU 162 may be implemented to communicate with DU 170 as needed for network control and signaling.

[0070] DU 170 may correspond to a logical unit including one or more base station functions for controlling the operation of one or more RU 172. In some aspects, DU 170 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) at least in part according to a functional partitioning such as those defined by the Third Generation Partnership Project (3GPP). In some aspects, DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to transmit signals with other layers (and modules) hosted by DU 170 or with control functions hosted by CU 162.

[0071] The lower layer functions may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DUs 170 may correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transform (FFT), inverse FFT (iFFT), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on functional partitioning (such as lower layer functional partitioning). In such an architecture, the RUs 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some embodiments, real-time and non-real-time aspects of control and user plane communications with the RUs 172 may be controlled by the corresponding DUs 170. In some scenarios, this configuration may enable the DUs 170 and CUs 162 to be implemented in a cloud-based RAN architecture (such as a vRAN architecture).

[0072] The SMO architecture 166 may be configured to support RAN deployment and provisioning of non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO architecture 166 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface such as an O1 interface. For virtualized network elements, the SMO architecture 166 may be configured to interact with a cloud computing platform such as an open cloud (O-cloud) 176 to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface such as an O2 interface. Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some embodiments, the SMO architecture 166 may communicate with hardware aspects of the 4G RAN (such as an open eNB (O-eNB) 174) via an O1 interface. Additionally, in some embodiments, the SMO architecture 166 may communicate directly with one or more RUs 172 via an O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166 .

[0073] The non-RT RIC 168 may be configured to include logic functions that implement non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 may be coupled to or in communication with the near-RT RIC 164 (such as via an A1 interface). The near-RT RIC 164 may be configured to include logic functions that implement near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface that connects one or more CUs 162, one or more DUs 170, or both, and O-eNBs to the near-RT RIC 164 (such as via an E2 interface).

[0074] In some embodiments, in order to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. Such information may be used by the near-RT RIC 164 and may be received from a non-network data source or from a network function at the SMO architecture 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to adjust RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through the SMO architecture 166 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).

[0075] Figure 2A is a communication timing diagram of a downlink from the network node 120 to a user device (such as AR glasses 140). Figure 1A-Figure 2A , the data transmitted in the downlink may originate from the XR server 110 or other remote resources. The connection between the network node 120 and the UE 150 may be a radio channel, and may be a physical downlink shared channel (PDSCH) or a similar downlink shared channel (e.g., LTE downlink shared channel - DL-SCH). The connection between the UE 150 and the AR glasses 140 may be a Wi-Fi channel. The UE 150 may operate as a bridge between the two channels and resources, receiving the downlink 210 on the radio channel and sending the downlink 211 on the Wi-Fi channel. Any mismatch in timing between the downlink 210 and the downlink 211 may be buffered in a memory on the UE 150 as a buffering delay 215. The downlink 210 may be sent according to the resource allocation of the radio channel, and the downlink 211 may be sent according to the target wake-up time (TWT) of the Wi-Fi channel assigned to the AR glasses 140.

[0076] TWT can define a TWT window by a TWT start time and a TWT interval. In some embodiments, the TWT interval and the TWT start can be set based on the UE's discontinuous reception (DRX) cycle and DRX offset, respectively, which can be configured by a network node (such as a gNB). In some embodiments, the TWT minimum wake-up duration can be set based on the jitter of the arrival time of periodic data services received by the UE.

[0077] The allocation of PDSCH resources can be controlled by the Physical Downlink Control Channel (PDCCH), which can grant time slots for download to each UE sharing the PDSCH resources. The PDCCH can carry downlink control information (DCI). Figure 2A In the example of , the PDSCH channel is divided into resource blocks, which can be symbols or time slots. The channel can include download blocks (D), upload blocks (U), and start blocks (S). Resource blocks (e.g., time slots, frames, symbols) can be defined according to a 5G protocol or a similar radio network protocol. The TWT window for communication between the UE 150 and the AR glasses 140 can be defined by a Wi-Fi protocol (e.g., IEEE802.11ax, Wi-Fi 6 / 6e) and can be a negotiated period allocated by the UE 150 or the AR glasses 140 or their transceivers. Various aspects of the timing can be implemented via a transceiver and one or more processors executing computer-readable instructions.

[0078] Figure 2B is a communication timing diagram of the uplink from the AR glasses 140 to the network node 120. Figure 1A-Figure 2B , the data transmitted in the uplink may originate from the AR glasses 140 or a component thereof (e.g., an imager, an inertial measurement unit, a clock). The connection between the AR glasses 140 and the UE 150 may be a Wi-Fi channel. The connection between the UE 150 and the network node 120 may be a radio channel, and may be a physical uplink shared channel (PUSCH) or a similar uplink shared channel (e.g., an LTE downlink shared channel - UL-SCH). The UE 150 may operate as a bridge between the two channels and resources, receiving the uplink 220 on the Wi-Fi channel and sending uplink data to the network node 120 on the radio channel. Any mismatch in timing between the uplink 220 and a subsequent uplink 222 transmission on a radio channel (e.g., radio link 125) may be buffered in a memory on the UE 150 as a buffering delay 221. The uplink 220 may be sent according to a target wake-up time (TWT) assigned to the Wi-Fi channel of the AR glasses 140.

[0079] The allocation of physical uplink shared channel (PUSCH) resources may be controlled by a physical uplink control channel (PUCCH), which may grant time slots for upload to the network node 120 delivering the PUSCH resources. The PUCCH may carry uplink control information (UCI). Figure 2BIn the example of , the PUSCH channel is divided into resource blocks, which may be symbols or time slots. The channel may include download blocks (D), upload blocks (U), and start blocks (S). Resource blocks (e.g., time slots, frames, symbols) may be defined according to a 5G protocol or a similar radio network protocol. The TWT window for communication between the UE 150 and the AR glasses 140 may be defined by a Wi-Fi protocol (e.g., IEEE 802.11ax, Wi-Fi 6 / 6e) and may be a negotiated period allocated by the UE 150 or the AR glasses 140 or their transceivers. Various aspects of the timing may be implemented via a transceiver and one or more processors executing computer-readable instructions.

[0080] Configuration of resources on the radio channel may be accomplished using radio resource control (RRC) messages from one or more UEs 150 requesting time slots or resources from the network node 120. In addition, the UE 150 may send a time sensitive communication assistance information (TSCAI) message to the network node 120 to assist the network node 120 in allocating resources appropriately. Figure 2B As shown, in order for UE 150 to receive a granted time slot (or a portion thereof), UE 150 may first send a scheduling request (SR) in an uplink period to request some resources in a future period (dynamic grant process). In the future period, UE 150 may send a buffer status report (BSR) indicating the amount of data to be sent and requesting resources for doing so. Finally, UE 150 may be granted upload resources during which the buffered data may be uploaded or sent. This scheduling process may introduce latency that may be too long for AR / XR purposes. Figure 2A and Figure 2B The buffering delays 215 and 221 shown in are example delays and may be larger or smaller depending on resource requirements. In some embodiments, the granted upload time slots may be pre-configured or scheduled by the network node 120 as part of the PUSCH scheduling.

[0081] For Wi-Fi link 145, power saving operations can be based on a target wake-up time (TWT). To initialize TWT, the user device can perform a TWT setup with the access point and receive a confirmation. Subsequently, according to the scheduled TWT start, the TWT period will continue to the TWT wake-up duration. In the context of extended reality, posture information related to the orientation of the user device can be first sent to the access point and ultimately to the server. The server (e.g., XR server 110) can generate video, overlays, or other audio-visuals, and can send data back to the user device during the TWT wake-up duration. After the TWT wake-up duration, the UE can turn off the Wi-Fi transmitter and suspend Wi-Fi transmission and / or reception during the OFF period. The OFF period together with the ON period (TWT) can be defined as a TWT interval. For example, the TWT interval can be 20ms, with an ON time of 10-11 ms. When the user device is disconnected, the TWT schedule can be canceled and the resource release access point.

[0082] In some instances, the user device may have a minimum TWT wake-up duration so that the device will remain awake to receive downlink signals even if the device itself has nothing to send. Peer devices may be notified of the minimum TWT wake-up duration so that they can schedule transmissions to the user device during that period. For example, tracking frames from the AR glasses 140 may be aggregated for upload and sent with gesture information at the beginning of the TWT, or may be sent after downloading a video from a server at the end of the TWT. Download or downlink transmission opportunities may begin within the TWT wake-up duration.

[0083] Wi-Fi TWT scheduling allows the AR glasses 140 to enter sleep mode with a deterministic on-off duty cycle, making the availability of the transceiver predictable. For example, downlink traffic can be sent only within the TWT window, and if the downlink signals arrive outside the TWT window, they must be buffered somewhere until the next TWT window. In other words, the TWT window involves reception (Rx) just as the DRX mode involves reception. For upload traffic, the Wi-Fi transceiver can transmit whenever it is available. However, this does come with additional power costs. Therefore, for applications that use Wi-Fi regularly, power savings can be found by synchronizing or aligning the processing for uploads with the TWT window. Similarly, aligning uplink and downlink traffic to have the same frequency and phase results in power savings because the transceiver can complete both at the same time in the same TWT window.

[0084] In general, the systems and processes disclosed herein involve coordination and information sharing across protocols (e.g., wireless protocols—Wi-Fi, 5G) and across devices. In various embodiments, the coordination may be performed by a cross-layer application programmable interface (API) that may control or notify one or more layers of the 5G protocol on one or more devices, and may control or notify one or more layers of the Wi-Fi protocol on one or more devices. For example, the cross-layer API may be configured to operate on the AR glasses 140 and the UE 150. In various embodiments, coordination may be performed via enhanced messaging throughout the architecture, or by inserting additional information into resource requests and timing negotiations to notify devices in the architecture of the timing constraints of other devices (e.g., TWT windows, gesture generation, etc.). Thus, 5G and Wi-Fi resources may be aligned for various links in the architecture.

[0085] For downlink traffic, the TWT scheduling timing (e.g., start, interval) of the Wi-Fi link 145 can be aligned / scheduled based on the DRX cycle configuration, the PDSCH burst traffic mode, or the semi-persistent scheduling (SPS) of the radio link 125 (e.g., 5G resources). For example, the TWT interval can be set based on the DRX cycle, or the TWT start can be set based on the DRX offset. For uplink traffic, the PUSCH resource timing (e.g., pre-scheduled, configured grant, dynamic grant) of the radio link 125 can be aligned / scheduled based on the uplink traffic timing (e.g., posture, camera, application) or TWT window timing (e.g., start, interval, minimum duration) in the Wi-Fi link 145. For example, the configured grant periodicity of the radio link 125 can be set based on the TWT interval, or the configured grant offset can be set based on the TWT start. As part of this coordination, different clocks in different protocols (e.g., 5G, Wi-Fi, AP) can be synchronized, or clock drift between them can be compensated by a cross-layer API. The cross-layer API may be hosted on UE 150 as UE 150 accesses radio link 125 and Wi-Fi link 145 .

[0086] Figure 3A is a network flow diagram illustrating a phone-to-glasses split augmented reality architecture 300 . Figure 3B is a component block diagram illustrating the information flow between various components in a phone-to-glasses split augmented reality system. Figure 1A-Figure 3B, in the consumer augmented reality space, a phone-to-glasses (P2G) architecture involves a system in which a phone relays extended reality traffic between an XR server 110 and AR glasses 140 using 5G and Wi-Fi links. For example, the AR glasses 140 shown only require Wi-Fi conductivity, which can reduce product size, weight, cost, and power consumption. The phone can provide better 5G connectivity through its larger form factor and antenna size than the AR glasses. Additionally, the AR glasses can help save power in long-distance scenarios because long segments of uplink traffic will be handled by the phone. Therefore, the phone-to-glasses architecture can combine two separate wireless protocols to achieve better results.

[0087] This phone-to-glasses architecture with separate protocols may have resource timing in 5G and Wi-Fi resources that is not aligned or operates without coordination. In part, the system disclosed herein provides processes and components for such coordination. For example, a key power saving feature of 5G communications is the discontinuous reception (DRX) cycle, which turns the reception and decoding cycles of the 5G transceiver on and off in order to save power. Similarly, in the Wi-Fi communication protocol, a device may be assigned a target wake-up time (TWT) during which the device can transmit and receive. When a 5G device or a Wi-Fi device is in a power saving mode, an uplink or downlink to or through the device may not be possible. When one of the uplinks or downlinks in the chain of the architecture is not possible or delayed, delays and degraded services occur.

[0088] exist Figure 3A and Figure 3B In the example shown, timing coordination is driven by the XR server 110. That is, after initialization between the extended reality application on the AR glasses 140 and the XR processing application on the XR server 110, the server 110 can drive the timing of data upload, download, rendering, and other aspects of the AR experience on the glasses. Figure 3A In the DRX cycle, the XR server 110 may send a server data timing 310 to the network node 120. The network node 120 may use the timing information to configure the DRX period for the UE 150. The network node 120 may notify the UE 150 of the new DRX timing via a radio resource control (RRC) message 320 or via the PDCCH / PUCCH of the radio link 125. The UE 150 may be ready to receive data from the XR server 110 when the data has been processed. Based on the DRX cycle, the UE 150 may establish or negotiate a TWT timing 330 for the AR glasses 140. Figure 3B Various example processes in this coordination are illustrated in more detail in .

[0089] The AR application 340 may be adapted to split processing between the XR server 110 and the AR glasses 140. Upon startup, the AR application 340 will make contact with the XR server 110, where the initial contact may be via Figure 3A The XR server 110 may determine a traffic offset or a burst traffic offset for the media generated at the XR server 110, but may be uncoordinated. The XR server 110 may determine a traffic offset or a burst traffic offset for the media generated at the XR server 110. The network node 120 or the core network 180 may determine the burst traffic offset. The traffic offset or the burst traffic offset may be determined so that traffic from the XR server 110 is scheduled to be sent when transmission resources (e.g., 5G and Wi-Fi) are available. The burst traffic offset calculated at the XR server 110 may be sent to the network node 120 via a timing message 350 and to the UE 150 to notify and drive resource allocation in the communication chain. Thus, the XR server 110 may initialize and direct resource allocation within the network 300 based on the graphics rendering timing and the traffic offset.

[0090] The XR server 110 may send or confirm a burst traffic offset or a burst traffic arrival time to the network node 120. The transmission, confirmation, or negotiation of the traffic offset may be performed via an enhanced TSCAI message exchanged between the XR server 110 and the network node 120. Based on the burst traffic offset (e.g., server data timing 310), the network node 120 may reconfigure or adjust the DRX configuration or radio resources via RRC reconfiguration 320. The RRC reconfiguration 320 configures the radio resources of the radio link 125. The RRC reconfiguration 320 or enhanced TSCAI message may notify the UE 150 of the transmission timing carrying the XR data. The UE 150 may negotiate or establish a Wi-Fi TWT schedule based on the radio resources (e.g., DRX cycle) allocated by the RRC reconfiguration 320. That is, the UE 150 may drive the Wi-Fi scheduling and timing of the AR glasses 140 based on the server timing.

[0091] UE 150 may include an API 353 that may communicate with a radio modem 357 and a Wi-Fi modem 359a on UE 150. API 353 may determine or receive any information from the radio modem 357 and convert or relay the information across one or more layers and across protocols (e.g., 5G, Wi-Fi). Wi-Fi modem 359a may receive a suggested or proposed TWT timing 330 for a TWT window and notify the corresponding Wi-Fi modem 359b of AR glasses 140 of such timing. AR glasses 140 may also operate (execute) at least a portion of API 353 to manage timing alignment and offset with its counterpart in UE 150. API 353 in one or more user devices (e.g., UE 150, AR glasses 140) may be connected via various modems and transceivers to align or synchronize operations (e.g., device data transfer).

[0092] The UE 150 may align or schedule the TWT to coincide with a DRX connection period (e.g., transceiver on) or other DRX parameters (e.g., cycle, offset, configuration). The UE 150 (e.g., cellular phone) or an API 353 on the UE 150 or AR glasses 140 may set or establish the TWT timing 330 under the control of the UE 150. Based on the aligned TWT and DRX, the AR glasses may upload gesture information 360 based on the TWT. For example, the gesture 360 ​​may be uploaded at the beginning of the TWT so that the AR glasses 140 have the remainder of the TWT period to wait for XR data from the XR server 110. The UE 150 or an API 353 on the UE 150 or AR glasses 140 may set or establish the TWT timing 330 under the control of the UE 150 so that the TWT is aligned or coincident with the XR downlink traffic pattern. Timing control or negotiation between UE 150 and AR glasses 140 may be performed based on the timing synchronization function (TSF) of the Wi-Fi protocol and the exchange of TSF messages. When UE 150 or AR glasses 140 detects that the TWT window has drifted beyond a threshold relative to the DRX cycle or XR downlink or other radio resources, UE 150 may periodically update the TWT timing.

[0093] The alignment between the XR server 110 generating the data and the receipt of the data at the UE 150 during the DRX connection period may deteriorate after establishment (although the API 353 on the UE 150 synchronizes various clocks as previously described). Therefore, the UE 150 may periodically send UE assistance information (UAI) to the network node 120 to actively request PUSCH / PDSCH resources for posture information 360. The network node 120 may perform granting or pre-scheduling of configuration of radio resources for the UE 150 based on the request and / or based on the server data timing 310 (e.g., timing message 350). The active request of the UE 150 may be sent via a synchronization signal block (SSB) or a tracking reference signal (TRS) or other channel scheduling signal. The XR server 110 may continue to set the timing (at least at the network node 120) based on its audiovisual rendering schedule and related bursty traffic (e.g., bursty traffic offset).

[0094] Figure 4A A network architecture 400 according to an embodiment is illustrated. Figure 1A-Figure 4A , the phone-to-glasses timing may be driven or set based on the data generation of the AR glasses, so that the timing control flows upstream to the XR server 110. The AR glasses 140 may set or schedule one or more target wake times (TWTs) for themselves and the Wi-Fi link 145, and may notify the UE 150 of the TWT timing 330. The UE 150 may request resources or notify the network node 120 that expected data will be uploaded during the TWT of the AR glasses 140. The network node 120 may communicate this data timing information (e.g., data timing 420) to the XR server 110 via the link 121 (e.g., a backhaul link). Based on this expected data timing, the XR server 110 may set a rendering schedule, or may similarly notify downstream devices (e.g., UE 150, AR glasses) when processing of the uploaded data will be completed.

[0095] Figure 4B This process illustrates the radio and Wi-Fi timing being set by a user device (eg, AR glasses 140). Figure 1A-Figure 4B, the AR glasses 140 may generate gesture information 360 at a given time or according to a given schedule. The AR glasses 140 may set a TWT start time for its Wi-Fi modem 359b to coincide with the generation of the gesture information 360. As the TWT period shifts relative to the gesture generation 360 (or vice versa), the AR glasses may continue to drive, set, or reset the TWT start time (or other TWT parameters). The API 353 may negotiate the TWT timing 330 or be notified of the TWT timing 330 and may ensure that the Wi-Fi modems 359a and 359b have the TWT timing 330. The API 353 may also notify the radio modem 357 of the TWT timing 330. The API 353 or the UE 150 may generate a request to the XR server 110 for an optimal rendering start time (e.g., data timing 420) for the audiovisual rendering corresponding to the gesture information 360. The API 353 may calculate an offset or expected delay between the start of the TWT or the gesture upload to the UE and the arrival of the gesture information at the XR server 110. That is, the optimal rendering time may be based on the pose information generation timing or the TWT start time and may be offset from these timings due to transmission delays.

[0096] In addition to notifying the XR server 110 of the optimal rendering time, the UE 150 may also send a DRX request 455 or UE assistance information, etc., which requests to update the DRX cycle (or PUSCH resource allocation) of the UE 150 to an RRC reconfiguration that coincides with the TWT timing 330. That is, the UE 150 may notify the XR server 110 of the optimal rendering or gesture processing time, and may notify the network node 120 of the optimal DRX connection timing based on the information from the AR glasses 140. The network node 120 may send an RRC reconfiguration 470 with updated radio resources based on the UE assistance information.

[0097] Figure 5A A network architecture 500 according to an embodiment is illustrated. Figure 5A , the phone to glasses timing can be driven or set based on the AR glasses 140 so that the timing control flows upstream to the XR server 110, similar to Figure 4A-4B Here, the AR glasses 140 may send TWT timing 330 to the UE 150, and the UE 150 may send data timing 420 in the form of a message or request to the network node 120. The network node 120 may relay the information or message of the data timing 420 to the XR server 110. In this case, the key timing factor is one or more TWT parameters used at the AR glasses 140 to determine the upstream timing.

[0098] Figure 5BThis process is illustrated in which a user device (eg, AR glasses 140 ) sets the radio and Wi-Fi timing based on a target wake time (TWT). Figure 1A-Figure 5B , the TWT period (e.g., TWT start) can be set by the UE 150 or the AR glasses 140 and can be set based on broader network resource availability (e.g., mesh network, channel sharing). The AR glasses 140 can set the posture information generation time to coincide with the start of the TWT period. Since posture generation can only involve measurement, the process can have more flexible timing constraints than network communication. The UE 150 can request or notify the XR server 110 of the optimal rendering time based on the TWT start time and the expected posture information timing. The request may include a request or timing information (e.g., offset) about when the rendered audio-visual information is optimally sent to the network node 120 and the UE 150. The UE 150 can request from the network node 120 the optimal DRX offset (or other DRX parameters) and PUSCH / PDSCH resources corresponding to the expected audio-visual transmission time or posture information upload timing. The request can be performed via a UE assistance information (UAI) message. The network node 120 can send RRC reconfiguration based on the UAI message to adjust the network resources so that DRX, PUSCH or PDSCH corresponds to the downlink of audio-visual data or the uplink of gesture information. Therefore, the local TWT of the AR glasses (user device) can drive the overall end-to-end timing of the network architecture 500.

[0099] Fig. 6A is a component block diagram illustrating a system 600 configured to generate gesture information and coordinate transmission with an extended reality server (eg, XR server 110) of an AR device according to various embodiments. Figure 1A-Figure 6A , the system 600 may include a computing device 602 configured to communicate with one or more UEs 150 or other computing devices via a local wireless connection (e.g., Wi-Fi 145, Bluetooth, Ant, etc.) or other near field communication (NFC) technology. The computing device 602 may also be configured to communicate with an external resource (e.g., an XR server 110) via a wireless connection 147a / 147b to a wireless communication network 608 (e.g., a cellular wireless communication network). The wireless connection 147a may be a radio link to a micro cell 606, which may be connected to the communication network 608 via a backhaul or mid-haul 630. The wireless connection 147b may be a radio link to a gNB 604, which may be connected to the communication network 608 via a backhaul or mid-haul 632. The communication network may be connected to the XR server 110 via a link 121 (e.g., optical fiber).

[0100] Computing device 602 may include one or more processors 610, electronic storage 612, one or more sensors 614, a transceiver 616 (eg, a wireless transceiver), and other components. Computing device 602 may include communication links or ports to enable information to be exchanged with a network and / or other computing platforms. Fig. 6A The illustration of computing device 602 in is not intended to be limiting. Computing device 602 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to computing device 602.

[0101] Electronic storage 612 may include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage 612 may include one or both of a system storage device that is provided integrally (i.e., substantially non-removable) with computing device 602 and / or a removable storage device that is removably connected to computing device 602 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 612 may include one or more of an optically readable storage medium (e.g., an optical disk, etc.), a magnetically readable storage medium (e.g., a magnetic tape, a magnetic hard drive, a floppy disk drive, etc.), a charge-based storage medium (e.g., an EEPROM, a RAM, etc.), a solid-state storage medium (e.g., a flash drive, etc.), and / or other electronically readable storage medium. Electronic storage 612 may include one or more virtual storage resources (e.g., a cloud storage device, a virtual private network, and / or other virtual storage resources). Electronic storage 612 may store software algorithms, information determined by processor 610 , information received from computing device 602 , information received from UE 150 , external resources (eg, XR server 110 ), and / or other information that enables computing device 602 to function as described herein.

[0102] Processor 610 may include one or more local processors (such as Fig.13 and 15 ), which may be configured to provide information processing capabilities in computing device 602. Thus, processor 610 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other means for electronically processing information. Although processor(s) 602 may be configured to provide information processing capabilities in computing device 602, the processor 610 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other means for electronically processing information. Fig. 6A 610 is shown as a single entity, but this is for illustrative purposes only. In some embodiments, processor 610 may include multiple processing units. These processing units may be physically located within the same device, or processor 610 may represent processing functions of multiple devices operating in coordination.

[0103] The computing device 602 may be configured by machine-readable instructions 620, which may include one or more instruction modules. The instruction modules may include computer program components. Specifically, the instruction modules may include one or more of a sensor data component 622, an extended reality engine 624, a transmission timing component 626, a timing API 628, and / or other instruction modules. Together, these components (e.g., 622-628) may provide an augmented reality experience via the AR glasses 140, as well as Fig.13 shown.

[0104] The sensor data component 622 can be connected to one or more sensors 614 to detect orientation, distance, inertia, movement, direction, and other posture information. Ranging sensor information can come from one or more cameras, lidar, radar, sonar, laser, wireless signaling (e.g., Wi-Fi ranging), ultrasonic, and / or other ranging systems. Cameras and lidars using computer vision can detect the position and angular orientation of surfaces, as well as identify objects. Inertial and orientation information can be detected by an inertial measurement unit (IMU) including an accelerometer, gravimeter, and magnetometer. Direction, orientation, and movement can be detected by a global positioning satellite (GPS) system, etc. Other posture information and eye tracking data can be captured by a camera and inferred or calculated from the camera data via one or more computer models.

[0105] As a non-limiting example, the processor 610 of the computing device 602 can receive sensor data directly from an onboard sensor (such as sensor(s) 614), and / or use one or more transceivers (e.g., 1324) to detect available wireless connections (e.g., Wi-Fi, Bluetooth, cellular, etc.) and obtain sensor information from remote sensors. In addition, the sensor data component 622 can be configured to determine whether the detected communication link is available to the UE 150 or other remote computing device (e.g., by measuring signal strength).

[0106] The extended reality (XR) engine 624 may include one or more audiovisual rendering processes to render graphics and sounds for the XR / AR experience provided by the device. The XR engine 624 may, for example, present an icon indicating that further information corresponding to a real-world object being viewed by the user via the AR glasses 140 is available. The XR engine 624 may, for example, generate and play animal sounds corresponding to animals being viewed in a zoo through the AR glasses 140.

[0107] As a non-limiting example, the processor 610 of the computing device 602 can render AR / XR audiovisual information on the processor, and / or use one or more transceivers (e.g., 1324) to manage and obtain the rendered audiovisual data from the remote computing resource (e.g., XR server 110) based on local information (e.g., gestures) to provide to the user. The XR engine 624 can include the application 340 and can initiate contact with the XR server 110 and remotely operate one or more processes of the XR engine 624 on the XR server 110.

[0108] The transmission timing component 626 can measure the delay on one or more links (e.g., 100, 200, 300, 400, 500) of the network based on the acknowledgement / negative acknowledgement (ACK / NACK) timing, response delay or time stamp. The transmission timing component 626 can use the delay or round trip time to determine the offset of one or more links (e.g., Wi-Fi link 145) or the optimal timing of data transmission (e.g., bursty traffic). The transmission timing component 626 can measure the drift of one or more clocks of the devices (e.g., UE 150) in the chain based on the received time stamp or timing synchronization function (TSF). The transmission timing component 626 can propose updates to the scheduling or alignment to the timing API 628 or one or more devices (e.g., UE 150) based on the clock drift or offset.

[0109] As a non-limiting example, the processor 610 of the computing device 602 can calculate the timing difference via the transmission timing component 626 on the processor, and / or obtain ACK / NACK information and timestamps from a remote computing resource (e.g., XR server 110) or another external network device using one or more transceivers (e.g., 1324).

[0110] The timing API 628 of the computing device 602 (e.g., AR glasses 140) can form a connection with a corresponding API at a UE or network device (e.g., UE 150) and can exchange messages including timing information with the corresponding API. The timing API 628 can negotiate one or more TWT periods or TWT schedules with a corresponding API in a Wi-Fi network and another device on the network (e.g., a mesh network). The timing API 628 can receive timing information from the transmission timing component 626 and coordinate changes to network resources of external devices based on the received timing information.

[0111] As a non-limiting example, the processor 610 of the computing device 602 may execute the timing API 628 on the processor and / or a corresponding API for connecting to a UE (e.g., UE 150) or other external network device using one or more transceivers (e.g., 1324). The processor 610 of the computing device 602 may execute the timing API 628 to provide an available interface for coordinating with one or more external devices and one or more Wi-Fi resource controllers.

[0112] Figure 6B is a component block diagram illustrating a system 650 configured to coordinate and convert transmissions between an AR device and a communication network according to various embodiments. Figure 1A-Figure 6B , the system 650 may include a computing device 603 configured to communicate with one or more AR glasses 140 or other computing devices via a local wireless connection (e.g., Wi-Fi 145, Bluetooth, Ant, etc.) or other NFC communication technology. The computing device 603 may also be configured to communicate with an external resource (e.g., XR server 110) via a wireless connection 125a / 125b to a wireless communication network 608 (such as a cellular wireless communication network). The wireless connection 125b may be a radio link to a picocell 606, which may be connected to the communication network 608 via a backhaul or mid-haul 630. The wireless connection 125a may be a radio link to a gNB 604, which may be connected to the communication network 608 via a backhaul or mid-haul 632. The communication network 608 may be connected to the XR server 110 via a link 121 (e.g., optical fiber).

[0113] Computing device 603 may include one or more processors 617, electronic storage 611, one or more sensors 613, transceiver 615 (eg, wireless transceiver), and other components. Computing device 603 may include communication links or ports to enable information to be exchanged with a network and / or other computing platforms. Figure 6B The illustration of computing device 603 in is not intended to be limiting. Computing device 603 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to computing device 603.

[0114] Electronic storage 611 may include non-transitory storage media that electronically stores information. The electronic storage media of electronic storage 611 may include system storage provided integrally with computing device 603 (i.e., substantially non-removable) and / or one or both of removable storage devices that are removably connected to computing device 603 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 611 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy disk drive, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. Electronic storage 611 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage 611 may store software algorithms, information determined by processor 617 , information received from computing device 603 , information received from AR glasses 140 , external resources (e.g., XR server 110 ), and / or other information that enables computing device 603 to function as described herein.

[0115] Processor 617 may include one or more local processors (such as Fig.14 and Fig.15 ), which may be configured to provide information processing capabilities in computing device 603. Thus, processor(s) 617 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other means for electronically processing information. Although processor 603 may be configured to provide information processing capabilities in computing device 603, processor(s) 617 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other means for electronically processing information. Figure 6B 617 is shown as a single entity, but this is for illustrative purposes only. In some embodiments, processor 617 may include multiple processing units. These processing units may be physically located within the same device, or (multiple) processors 617 may represent processing functions of multiple devices operating in coordination.

[0116] The computing device 603 may be configured by machine-readable instructions 623, which may include one or more instruction modules. The instruction modules may include computer program components. Specifically, the instruction modules may include one or more of a sensor data component 641, a buffer management component 643, a transmission timing component 647, a timing API 645, a protocol conversion component 649, and / or other instruction components. Together, these components (e.g., 641 to 649) of the computing device 603 may provide a synchronization relay for an augmented reality device.

[0117] Sensor data component 641 may be connected to one or more sensors 613, including a global positioning system (GPS) component, an IMU, a time of flight (TOF) or round trip time (RRT) sensor, and other sensors. Sensor data component 641 may include processes for collecting data from sensor 613 and may store the data on electronic storage device 611.

[0118] As a non-limiting example, the processor 617 of the computing device 603 can operate the sensor data component 641 on the processor and / or use one or more transceivers (e.g., 1466) to connect to remote sensors or other external network devices. The processor 617 of the computing device 603 can execute the sensor data component 641 to obtain timing, location, and quality of service measurements of the local device and one or more external devices.

[0119] Buffer management component 643 retains or manages one or more blocks of memory of electronic storage device 611. Buffer management component 643 can record the delay of data stored therein (e.g., buffer delay 215) and can reorder or classify the data stored therein for optimal transmission timing and quality of service. Buffer management component 643 can be connected to local Wi-Fi transceiver, local wireless transceiver, timing API 645, protocol conversion component 649 and other components. Buffer management component 643 can operate a buffer as part of electronic storage device 611 to receive uplink or downlink data and store it at least until the corresponding transmission window on the next link begins.

[0120] As a non-limiting example, the processor 617 of the computing device 603 can operate a buffer management component 643 on the processor and / or offload data in the buffer to a remote resource, destination device, or other external network device using one or more transceivers (e.g., 1466). The processor 617 of the computing device 603 can execute the buffer management component 643 to manage the storage of data received at one transceiver and not yet ready to be transmitted or retransmitted on another transceiver.

[0121] The timing API 645 of the computing device 603 can form a connection with a corresponding API at an AR device or a network device, and can exchange messages including timing information with the corresponding API. The timing API 645 can negotiate one or more TWT periods or TWT schedules with a corresponding API in a Wi-Fi network and another device on the network (e.g., a mesh network). The timing API 645 can negotiate one or more DRX periods or configured grant slots with the wireless network via a wireless modem. The timing API 645 can receive timing information from a transmission timing component 647 and coordinate changes to network resources of external devices based on the received timing information.

[0122] As a non-limiting example, the processor 617 of the computing device 602 may execute the timing API 645 on the processor and / or a corresponding API for connecting an AR device or other external network device using one or more transceivers (e.g., 1466). The processor 617 of the computing device 603 may execute the timing API 645 to provide an available interface for coordinating with one or more external devices, one or more Wi-Fi resource controllers, and one or more radio resource controllers.

[0123] The transmission timing component 647 can measure the delay on one or more links (e.g., 100, 200, 300, 400, 500) of the network based on the confirmation / negative confirmation (ACK / NACK) timing, response delay or timestamp. The transmission timing component 647 can use the delay or round trip time to determine the offset of one or more links (e.g., Wi-Fi link 145) or the optimal timing of data transmission (e.g., bursty traffic). The transmission timing component 647 can measure the drift of one or more clocks of devices in the chain (e.g., AR glasses 140) based on the received timestamp, TSF message, SSB / TRS message, or TSCAI message. The transmission timing component 647 can propose updates to the scheduling or alignment to the timing API 645 or one or more devices (e.g., AR glasses 140) based on the clock drift or offset.

[0124] As a non-limiting example, the processor 617 of the computing device 603 can calculate the timing difference via the transmit timing component 647 on the processor, and / or obtain ACK / NACK information and timestamp from a remote computing resource (e.g., XR server 110) or another external network device using one or more transceivers (e.g., 1466).

[0125] The protocol conversion component 649 can unpack one or more layers of a first protocol (e.g., Wi-Fi) and repack the underlying data with layers of a second protocol (e.g., 5G). The protocol conversion component 649 can convert or wrap packets from one protocol into a compatible format of another protocol, or can repack the payload of one or more packets for transmission. The protocol conversion component 649 can perform other packet relay operations to ensure seamless transfer of data from a wireless transmission protocol (e.g., 5G) to a Wi-Fi transmission protocol (e.g., 802.11ax).

[0126] As a non-limiting example, the processor 617 of the computing device 603 may execute the protocol conversion component 649 on the processor and / or use one or more transceivers (eg, 1466) to relay the converted data.

[0127] Figure 7 FIG. 1 illustrates a timing diagram of network resources of various network links in an aligned configuration according to an embodiment. Figure 1A-Figure 7 , Figure 7The timing diagram in FIG. 1 may involve a downlink of a video frame or audio-visual data from the XR server 110 through the network node 120 to the UE 150 and to a user device in the form of the AR glasses 140 for display. The downlink 210 signal or data from the XR server 110 may be aligned with the DRX offset 703 such that the DRX cycle 701 is at the DRX connected time 702. The downlink 210 signal or data from the XR server 110 may be timed to coincide with the DRX connected time 702 of the PDSCH instead of the DRX idle time 704. Upon receiving the downlink 210 by the network node 120, the network node 120 may perform various channel or data preparation procedures during the preparation time 705 prior to transmission to the UE 150. The UE 150 may use the preparation time 705 to receive a first packet (e.g., a channel status report) from the gNB and may store or buffer the data for a buffer time 707 until the AR glasses 140 are ready to receive in the TWT (e.g., after the gesture information is uploaded). If the data rate of the Wi-Fi link is faster than the 5G link, the AR glasses using the Wi-Fi link do not need to wake up until a sufficient amount of data is buffered in the UE. Therefore, the buffer time 707 can allow the Wi-Fi transceiver of the AR glasses to remain in sleep mode for a longer time, thereby saving power. In addition, the buffer time 707 can include a glasses-to-phone offset within the TWT of the AR glasses 140 (as shown by the reverse arrow), which corresponds to the upload period of the posture information when the posture information is transmitted before the TWT. Once the AR glasses 140 are ready to receive in the TWT window, the UE 150 can send a downlink 211 to the AR glasses 140. As shown in the next DRX connection time 702, the process can be repeated. Alignment can be performed by the AR glasses 140 aligning the TWT with the DRX offset 703 or other parameters plus the preparation time 705 and the buffer time 707.

[0128] Figure 8 is a process flow diagram illustrating an example method 800 for adjusting communication resources of a device. Figure 1A-Figure 8 In block 802, UE 150 (or its processor / transceiver) may obtain communication timing information of a user device (e.g., AR glasses 140). Means for performing the operations of block 802 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0129] In block 804, UE 150 (or its processor / transceiver) may send communication timing information of the user device to a network node (e.g., network node 120). Means for performing the operations of block 804 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0130] In block 806, UE 150 (or its processor / transceiver) may configure a first resource timing for an uplink or a downlink between the UE and the network node based on the communication timing information. Means for performing the operations of block 806 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or an external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0131] Fig.9A is a process flow diagram illustrating an example method 910 for adjusting communication resources so that they coincide. Figure 1A-Figure 9A , after the operation in box 804 of method 800, UE 150 (or its processor / transceiver) may configure the first resource timing of the uplink or downlink between the UE and the network node based on the communication timing information by adjusting the timing of the TWT of the user device to at least partially overlap with the DRX cycle of the UE based on the DRX configuration for the UE received from the network node in box 901. In some embodiments, adjusting the timing of the TWT of the user device in box 902 may include setting the TWT interval and the TWT start based on the DRX cycle and DRX offset of the UE, respectively. The DRX cycle and the DRX offset may be configured by the network node. In some embodiments, adjusting the timing of the TWT of the user device in box 902 may include setting the TWT minimum wake-up duration based on the jitter of the arrival time of the periodic data service received by the UE. Means for performing the operations of block 902 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0132] As part of the operations in method 910, the UE 150 may align the TWT scheduling with the DRX parameters via a cross-layer API. The network node 120 may configure the optimal DRX parameters for the UE 150 via an RRC message. The UE 150 may obtain or read the DRX parameters via the cross-layer API. The UE 150 may convert the DRX timing to the Wi-Fi timing (e.g., including delays and offsets). The cross-layer API or the UE 150 may request adjustments to the TWT scheduling based on the calculated Wi-Fi timing. For example, the TWT interval may be set to the DRX cycle. If the TWT interval is not aligned with the data delivery rhythm of the XR server 110, the drift may be accumulated and compensated at a certain threshold. For example, the TWT minimum wake-up duration may be set to be greater than the jitter of the service arrival measured on the Wi-Fi link 145. The TWT start time may be set to the DRX offset plus the preparation time plus the storage time (optimal buffer time) and minus the glasses to phone offset (see Figure 7 ). The preparation time (e.g., preparation time 705) may include time for processing data before actual transmission (e.g., sounding resource signal transmission, channel state information reference signal, scheduling delay, etc.). The Wi-Fi layer of UE 150 may be instructed by the cross-layer API to set the TWT time or schedule based on the DRX parameters. The XR layer or cross-layer API of the AR glasses may receive or read the TWT schedule from the UE 150 and may generate uplink posture information at the TWT start time.

[0133] Fig. 9B is a process flow diagram illustrating an example method 920 for adjusting TWT timing of a device. Figure 1A-Figure 9B, after the operation in box 804 of method 800, in box 904, UE 150 (or its processor / transceiver) may configure the first resource timing of the uplink or downlink between the UE and the network node based on the communication timing information by adjusting the timing of the TWT of the user device based on the downlink traffic from the network node. In some embodiments, configuring the first resource timing in box 904 may also include: adjusting the timing of at least one of a bandwidth physical uplink shared channel (PUSCH), a configuration grant of the network node based on the TWT of the user device, or an auxiliary message from the user device for the uplink traffic from the user device to the UE. In some embodiments, configuring the first resource timing in box 904 may also include the UE actively sending a scheduling request (SR) for the PUSCH before receiving data from the user device by considering one or both of the delay of the SR or the delay of the buffer status report (BSR). Means for performing the operations of block 904 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0134] As part of method 920, UE 150 may configure TWT scheduling based on a downlink XR data service pattern. For example, if the DRX parameters are not configured by the network node 120, the UE 150 may learn the XR service pattern and may align the TWT scheduling with the XR service arrival time via a cross-layer API. The XR application may be initialized (e.g., the AR application 340), and the network node may not configure the DRX parameters for the UE. The UE may estimate the XR service pattern of the downlink service timing (e.g., via artificial intelligence learning or machine learning), including the XR service period, the XR service arrival time offset at the UE, and the XR service arrival time jitter. One or more of these patterns may be recorded by the XR server and sent to the UE. The UE may request the XR service pattern from the network node. The UE may convert the XR service pattern timing to Wi-Fi timing, including the TWT interval being set to coincide with the DRX period, the TWT start being set to coincide with the XR service arrival offset at the UE minus the optimal buffer time, or the TWT minimum wake-up duration being set to extend further than the jitter of the XR service arrival time. The UE can request to set the TWT timing of the AR glasses via a cross-layer API based on the DRX timing or the service timing. The UE can set the TWT scheduling or TWT timing, and the AR glasses can read or receive the TWT scheduling and can generate attitude information for the uplink at the TWT start time.

[0135] Fig. 10A FIG. 1 illustrates a timing diagram of network resources of various network links in an aligned configuration according to an embodiment. Figures 1A-10A , Fig. 10A The timing diagram in FIG. 1 involves a sequence from a pair of AR glasses 140 to the UE 150 and to the network node 120 and the XR server 110 (see Figure 3A , Figure 4A , Figure 5A ) of data. For example, uplink 220 may carry posture information (P) or a camera image. UE 150 may estimate time 1002 as the time required to complete the SR request and the BSR request and obtain a granted time slot for uploading in the PUSCH channel. UE 150 may send the SR and BSR before the uplink 220 arrives. After the uplink 220 has arrived, the UE 150 may briefly buffer (B) the data before sending it over the radio channel in the granted time slot as uplink 222.

[0136] Fig. 10B FIG. 1 illustrates a timing diagram of network resources of various network links in an aligned configuration according to an embodiment. Figure 1A-Figure 10B , Fig. 10B The timing diagram in FIG. 1 involves a sequence from a pair of AR glasses 140 to the UE 150 and to the network node 120 and the XR server 110 (see Figure 3A , Figure 4A , Figure 5A ) in an uplink of data. The AR glasses 140 may indicate the service timing of the uplink data to the UE 150, including the service volume, service timing offset, and service cycle. The UE 150 may estimate the estimated time 1004 required to complete the SR, BSR and receive the granted time slot (U) of the PUSCH resource. The UE 150 may send the SR and BSR before the uplink 220 has arrived at the UE 150. The UE 150 may upload data via the uplink 222 after the relay delay (B) at the UE 150. Accordingly, the TWT may be aligned based on the service generation time at the AR glasses 140 and based on the estimated time 1004.

[0137] Fig.11 is a process flow diagram illustrating an example method 1100 for adjusting PUSCH resources.

[0138] refer to Figure 1A-Figure 11, after the operations in block 804 of method 800, in block 1102, UE 150 (or its processor / transceiver) may configure first resource timing of an uplink or downlink between the UE and a network node based on the communication timing information by sending a request for adjusting a PUSCH resource of the UE based on the communication timing information to at least partially coincide with a TWT of the user device. The means for performing the operations of block 1102 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or an external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0139] As part of method 1100, UE 150 may request configuration of PUSCH resource scheduling based on TWT scheduling. For example, UE 150 may request radio resources that coincide with receiving an upload or uplink packet from Wi-Fi link 145. The active request for aligned PUSCH resources by UE 150 may reduce overall relay latency. AR glasses 140 may set gesture generation timing at the TWT start time, and UE 150 may actively reserve PUSCH resources that coincide with the TWT timing. UE 150 may set the TWT scheduling by, for example, setting the TWT start time to the DRX offset plus the preparation time plus the buffer time minus the glasses to phone (G2P) offset. AR glasses may receive or read the TWT schedule via a cross-layer API and set the gesture generation timing to the TWT start time. UE 150 may request allocation of PUSCH resources based on glasses request or timing. PUSCH resource timing may be scheduled based on the TWT start plus the G2P offset. For example, UE 150 may request allocation via a grant (CG) PUSCH for configuration or a pre-scheduled UE assistance information (UAI) message to align the time slot grant with the optimal uplink timing. UE 150 may send SR and BSR in advance based on the service information from AR glasses 140 so that the granted PUSCH resources are aligned with the uplink timing (TWT timing) after a delay estimated from the SR, BSR, and CG.

[0140] Fig.12 is a process flow diagram illustrating an example method 1200 for adjusting XR data generation timing in accordance with some embodiments.

[0141] refer to Figure 1A-Figure 12, after the operations in block 804 of method 800, in block 1202, UE 150 (or its processor / transceiver) may receive a data generation timing. Means for performing the operations of block 1202 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source (e.g., a remote system or an external resource (e.g., XR server 110)) using a transceiver (e.g., 1324, 1466) and related components.

[0142] In block 1204, UE 150 (or its processor / transceiver) may configure first resource timing of uplink or downlink between UE and network node based on communication timing information by sending a request to adjust PUSCH resources of UE based on data generation timing or a request to adjust data generation timing to the network node. Means for performing the operations of block 1204 may include a processor (e.g., 1322, 1425, 1502, 1504, 1552) coupled to a memory (e.g., 611, 612, 1413) or coupled from a remote source using a transceiver (e.g., 1324, 1466) and related components, such as a remote system or external resource (e.g., XR server 110).

[0143] As part of the method 1200, the XR generation timing of the XR server 110 may be adjusted based on congestion in the uplink or downlink of the Wi-Fi link 145 between the user device (AR glasses) and the UE. The UE 150 or the AR glasses 140 may detect congestion on the Wi-Fi channel. The UE 150 or the AR glasses 140 may send a request to the XR server 110 via the radio uplink to adjust the data generation timing at the XR server 110. The UE 150 may specify a specific time delay in the request to the server. The XR server 110 may receive the request and move the XR data generation, thereby moving the XR service timing. The XR server 110 may update the XR service timing to the network node 120 via a TSCAI message. The network node 120 may update the configuration of the UE (e.g., DRX) based on the rescheduled service timing in the TSCAI message. Based on the DRX configuration or XR service mode of the UE, the UE 150 may update the TWT scheduling of the AR glasses 140 to reduce channel congestion.

[0144] As part of process 1200, UE 150 may request an adjustment of PUSCH resources based on data generation delays at the user device (AR glasses). For example, the uplink traffic cycle may not match the downlink traffic cycle (100hz for gestures and 60hz for XR data), or the server specifies gesture capture timing to minimize motion-to-rendering delays, or the AR glasses have a camera that requires uplink traffic that has a different offset than the gesture uplink traffic. The AR glasses 140 may notify UE 150 of the uplink traffic timing, and UE 150 may request PUSCH resources to correspond to the uplink traffic. UE 150 may set the TWT scheduling of the AR glasses and UE 150 to coincide with the uplink. Since the uplink traffic may not be sent at the TWT start time, the scheduled TWT start time may not need to include a G2P offset. Accordingly, the TWT start time may be set to coincide with the DRX offset time plus the preparation time plus the buffer time. The AR glasses 140 can adjust or determine the uplink traffic (data) generation timing based on the TWT start time received via the cross-layer API. Data generation can be scheduled to fit within the TWT window or can be scheduled to be uploaded in another TWT window (different from the TWT used for gesture upload). The AR glasses can send uplink traffic to the UE 150 via the Wi-fi link 145. The AR glasses can send information about the uplink traffic volume or the uplink traffic timing offset to the start of the TWT to the UE. If the periodicity of the uplink does not match the downlink periodicity, the AR glasses can indicate the uplink periodicity to the UE. If the Wi-Fi link 145 or the AR glasses 140 does not specify the uplink traffic mode, the UE 150 can learn the uplink traffic mode of the Wi-Fi link 145 (e.g., via machine learning or artificial intelligence). The UE 150 can convert the wi-Fi uplink timing to the radio clock timing (e.g., the 5G system clock). The UE 150 may proactively request allocation of PUSCH resources based on a request or information (or learned information) from the AR glasses. The requested PUSCH timing may be timed based on the timing offset to the start of the TWT plus the G2P offset.

[0145] Various embodiments (including the above reference Figure 8 , Fig.9A , Fig. 9B , Fig.11 and Fig.12 The embodiments discussed herein can be implemented on a variety of wearable devices, examples of which are shown in FIG. Fig.13 In the figure, it is shown in the form of AR glasses 140. Figure 1A-Figure 13As shown, the AR glasses 140 can operate like traditional glasses, but with enhanced computer features and sensors, such as a built-in camera 1335 and a heads-up display or AR features on or near the lens 1331. As with any glasses, the smart glasses can include a frame 1302 coupled to temples 1304, which fit beside the wearer's head and behind the ears. The frame 1302 holds the lenses 1331 in place in front of the wearer's eyes when the nose pads 1306 on the bridge 1308 rest on the wearer's nose.

[0146] In some embodiments, the AR glasses 140 may include an image rendering device 1314 (e.g., an image projector) that may be embedded in one or both temples 1304 of the frame 1302 and configured to project an image onto an optical lens 1331. In some embodiments, the image rendering device 1314 may include a light emitting diode (LED) module, an optical channel, a homogenizing lens, an optical display, a folding mirror, or other components of a known projector or head-mounted display. In some embodiments (e.g., those embodiments in which the image rendering device 1314 is not included or used), the optical lens 1331 may be or may include a see-through or partially see-through electronic display. In some embodiments, the optical lens 1331 includes an image generating element, such as a see-through organic light emitting diode (OLED) display element or a liquid crystal on silicon (LCOS) display element. In some embodiments, the optical lens 1331 may include independent left-eye and right-eye display elements. In some embodiments, the optical lens 1331 may include or operate as a light guide for transmitting light from the display element to the wearer's eyes.

[0147] The AR glasses 140 may include a plurality of external sensors that may be configured to obtain information about the wearer's actions and external conditions, which may be used to sense images, sounds, muscle movements, and other phenomena that may be used to detect when the wearer interacts with the described virtual user interface. In some embodiments, the AR glasses 140 may include a camera 1335 configured to image an object in front of the wearer in a still image or video stream, which may be transmitted to another computing device (e.g., UE 150 or XR server 110) for analysis. In addition, the AR glasses 140 may include a lidar sensor 1340 or other ranging device. In some embodiments, the AR glasses 140 may include a microphone 1310 that is positioned and configured to record sounds near the wearer. In some embodiments, multiple microphones may be positioned in different locations on the frame 1302 (such as on the distal end of the temple 1304 near the jaw) to record sounds made when the user taps a selected object on the hand, etc. In some embodiments, the AR glasses 140 may include a pressure sensor (such as on the nose pad 1306) configured to sense facial motion to calibrate distance measurements. In some embodiments, the AR glasses 140 may include other sensors (e.g., a thermometer, a heart rate monitor, a body temperature sensor, a pulse oximeter, etc.) for collecting information about the environment and / or user conditions, which may be used to identify user interactions with the virtual user interface.

[0148] The processing system 1312 may include a processing and communication SOC 1502, 1504, which may include one or more processors, one or more of which may be configured with processor-executable instructions to perform the operations of various embodiments. The processing and communication SOC 1502, 1504 may be coupled to internal sensors 1320, internal memory 1322, and communication circuits 1324, which are coupled to one or more antennas 1326 for establishing a wireless data link with an external computing device (e.g., UE 150), such as via a Bluetooth or Wi-Fi link. The processing and communication SOC 1502, 1504 may also be coupled to a sensor interface circuit 1328, which is configured to control and receive data from the camera 1335, the microphone 1310, and other sensors located on the frame 1302.

[0149] Internal sensors 1320 may include an IMU including an electronic gyroscope, accelerometer, and magnetic compass configured to measure movement and orientation of the wearer's head. Internal sensors 1320 may also include a magnetometer, an altimeter, an odometer, and an atmospheric pressure sensor, as well as other sensors useful for determining the orientation and movement of the AR glasses 140. Such sensors may be useful in various embodiments for detecting head movement, which may be used to adjust the distance measurements described. The processing system 1312 may also include a power source (such as a rechargeable battery 1330) coupled to the SOCs 1502, 1504 and external sensors on the frame 1302.

[0150] Various embodiments (including but not limited to the above reference Figure 1A-Figure 14 The embodiments discussed herein may be implemented on a variety of computing devices, an example of which is Fig.14 150 in the form of a mobile computing device (e.g., UE 150). As described herein, the processor that executes the embodiment method may be in a computing device 604 that is separate from the distance sensor (e.g., LiDAR) and / or the display (e.g., AR glasses 140). Figure 1A-Figure 15 , the mobile computing device 604 may include a first SoC 1502 (e.g., SoC-CPU) coupled to a second SoC 1504 (e.g., a SoC with 5G capabilities). The first and / or second SOCs 1502, 1504 may be coupled to internal memory 1413, 1425, a display 1415, and a speaker 1414. Additionally, the UE 150 may include one or more antennas 1404 for sending and receiving electromagnetic radiation, which may be connected to one or more wireless transceivers 1466 (e.g., wireless data links and / or cellular transceivers, etc.) coupled to one or more processors in the first and / or second SOCs 1502, 1504. The UE 150 may also include a menu selection button or rocker switch 1420 for receiving user input.

[0151] The UE 150 may additionally include a sound coding / decoding (CODEC) circuit 1410 that digitizes the sound received from the microphone into a data packet suitable for wireless transmission and decodes the received sound data packet to generate an analog signal, which is provided to the speaker to generate sound. In addition, one or more of the processors in the first and / or second SOC 1502, 1504, the wireless transceiver 1466, and the CODEC circuit 1410 may include a digital signal processor (DSP) circuit (not shown separately).

[0152] Fig.15is a component block diagram illustrating an example computing and wireless modem system 1500 suitable for implementing any of the various embodiments. The various embodiments may be implemented on a variety of single-processor and multi-processor computer systems, including a system on a chip (SOC) or a system in a package (SIP).

[0153] refer to Figure 1A-Figure 15 , the illustrated example computing system 1500 (which may be a SIP in some embodiments) includes two SOCs 1502, 1504 coupled to a clock 1506, a voltage regulator 1508, an output device 1568, and a wireless transceiver 1566, which is configured to send and receive wireless communications to and from a UE (e.g., 150) or a network device (e.g., 120) via an antenna (not shown). In some embodiments, the first SOC 1502 may operate as a central processing unit (CPU) of the UE, which executes instructions of a software application by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions. In some embodiments, the second SOC 1504 may operate as a special-purpose processing unit. For example, the second SOC 1504 may operate as a dedicated 5G processing unit responsible for managing high capacity, high speed (such as 5 Gbps) and / or very high frequency short wavelength (such as 28 GHz millimeter wave spectrum) communications.

[0154] The first SOC 1502 may include a digital signal processor (DSP) 1510, a modem processor 1512, a graphics processor 1514, an application processor 1516, one or more coprocessors 1518 (such as a vector coprocessor) connected to one or more processors, memory 1520, custom circuits 1522, system components and resources 1524, an interconnect / bus module 1526, one or more temperature sensors 1530, a thermal management unit 1532, and a thermal power envelope (TPE) component 1534. The second SOC 1504 may include a 5G modem processor 1552, a power management unit 1554, an interconnect / bus module 1564, multiple millimeter wave transceivers 1556, memory 1558, and various additional processors 1560 (e.g., an application processor, a packet processor, etc.).

[0155] Each processor 1510, 1512, 1514, 1516, 1518, 1552, 1560 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SOC 1502 may include a processor that executes a first type of operating system (such as FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (such as MICROSOFT WINDOWS 10). In addition, any one or all of the processors 1510, 1512, 1514, 1516, 1518, 1552, 1560 may be included as part of a processor cluster architecture (such as a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).

[0156] The first SOC 1502 and the second SOC 1504 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other dedicated operations (such as decoding data packets and processing encoded audio and video signals for rendering in a web browser). For example, the system components and resources 1524 of the first SOC 1502 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients running on the UE. The system components and resources 1524 and / or custom circuits 1522 may also include circuits for interfacing with peripheral devices (such as cameras, electronic displays, wireless communication devices, external memory chips, etc.).

[0157] The first SOC 1502 and the second SOC 1504 can communicate via an interconnect / bus module 1550. Various processors 1510, 1512, 1514, 1516, 1518 can be interconnected to one or more memory elements 1520, system components and resources 1524, custom circuits 1522, and thermal management units 1532 via interconnect / bus modules 1526. Similarly, processor 1552 can be interconnected to power management units 1554, millimeter wave transceivers 1556, memory 1558, and various additional processors 1560 via interconnect / bus modules 1564. Interconnect / bus modules 1526, 1550, 1564 can include reconfigurable logic gate arrays and / or implement bus architectures (such as CoreConnect, AMBA, etc.). Communications can be provided by advanced interconnects (such as high-performance on-chip networks (NoCs)).

[0158] The first and / or second SOC 1502, 1504 may also include input / output modules (not illustrated) for communicating with resources external to the SOC, such as a clock 1506 and a voltage regulator 1508. Resources external to the SOC, such as a clock 1506, a voltage regulator 1508, may be shared by two or more of the internal SOC processors / cores.

[0159] In addition to the example SIP 1500 discussed above, some embodiments may be implemented in a variety of computing systems that may include a single processor, multiple processors, multi-core processors, or any combination thereof.

[0160] Various embodiments (including but not limited to the above reference Figure 1A-Figure 16 The embodiments discussed herein may be implemented on a variety of computing devices, an example of which is Fig.16 It is shown in the form of a server. Figure 1A-Figure 16 , the network computing device 1600 (e.g., XR server 110) may include a processor 1601 coupled to a volatile memory 1602 and a large capacity non-volatile memory (such as a disk drive 1603). The network computing device 1600 may also include a peripheral memory access device such as a floppy disk drive, a compact disk (CD), or a digital video disk (DVD) drive 1606 coupled to the processor 1601. The network computing device 1600 may also include a network access port 1604 (or interface) coupled to the processor 1601 for establishing a data connection with a network (such as the Internet and / or a local area network coupled to other system computers and servers). The network computing device 1600 may include one or more transceivers 1607 for sending and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network computing device 1600 may include additional access ports such as USB, Firewire, Thunderbolt, etc. for coupling to peripheral devices, external memory, or other devices.

[0161] The processors of UE 150 and network device 1600 may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that may be configured by software instructions (applications) to perform various functions (including the functions of some embodiments described below). In some wireless devices, multiple processors may be provided, such as one processor within SOC 1504 dedicated to wireless communication functions and one processor within SOC 1502 dedicated to running other applications. Software applications may be stored in memory 611, 612 before they are accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.

[0162] The various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one example embodiment. For example, Figure 8 , Fig.9A , Fig. 9B , Fig.11 and Fig.12 One or more operations of the methods and operations may be replaced or combined with Figure 8 , Fig.9A , Fig. 9B , Fig.11 and Fig.12 A combination of one or more operations of methods and operations.

[0163] Implementation examples are described in the following paragraphs. Although some of the following implementation examples are described according to example methods, additional example implementations may include: the example methods discussed in the following paragraphs are implemented by a UE, the UE includes a processor, the processor is configured with processor-executable instructions to perform the operations of the methods of the following implementation examples; the example methods discussed in the following paragraphs are implemented by a UE, the UE includes a component for performing the functions of the methods of the following implementation examples; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the UE to perform the operations of the methods of the following implementation examples.

[0164] Example 1. A method for synchronizing resource timing of at least two wireless protocols, performed by a processor of a user equipment (UE), the method comprising: obtaining communication timing information of a user device; sending the communication timing information of the user device to a network node; and configuring a first resource timing of an uplink or downlink between the UE and the user device based on the communication timing information.

[0165] Example 2. The method according to Example 1 also includes requesting configuration of a second resource timing of another uplink or downlink between the UE and the network node based on the communication timing information.

[0166] Example 3. A method according to any one of Examples 1 or 2, wherein sending the communication timing information further includes: requesting the network node to adjust the discontinuous reception (DRX) configuration so that the DRX cycle of the UE and the target wake-up time (TWT) of the user device at least partially overlap.

[0167] Example 4. A method according to any one of Examples 1-3, wherein configuring the first resource timing further comprises: adjusting the timing of a target wake time (TWT) for the user device based on a discontinuous reception (DRX) configuration.

[0168] Example 5. A method according to Example 4, wherein adjusting the timing of the TWT includes: setting the TWT interval and the TWT start based on the DRX cycle and the DRX offset of the UE, respectively, wherein the DRX cycle and the DRX offset are configured by the network node.

[0169] Example 6. A method according to Example 4, wherein adjusting the timing of the TWT includes setting a TWT minimum wake-up duration based on jitter in arrival time of periodic data services received by the UE.

[0170] Example 7. A method according to any one of Examples 1-6, wherein configuring the first resource timing further includes: adjusting the timing of a target wake-up time (TWT) for a downlink service from the UE to the user device based on a discontinuous reception (DRX) configuration of the UE, a physical downlink shared channel (PDSCH) service mode between the UE and the network node, or a semi-permanent scheduling of the network node; or.

[0171] Example 8. A method according to any one of Examples 1-7, wherein configuring the first resource timing further includes: adjusting the timing of at least one of a bandwidth PUSCH, a configuration grant of the network node based on the TWT of the user device, or an auxiliary message from the user device for the uplink service from the user device to the UE.

[0172] Example 9. A method according to any one of Examples 1-8, wherein sending the communication timing information further includes: generating one or more auxiliary data messages including the communication timing information of the user device via a cross-layer application programming interface (API) on the UE; and sending the one or more auxiliary data messages to the network node.

[0173] Example 10. A method according to any one of Examples 1-9, wherein configuring the first resource timing further includes: based on the DRX configuration for the UE received from the network node, adjusting the timing of the TWT of the user device to at least partially overlap with the DRX cycle of the UE.

[0174] Example 11. A method according to any one of Examples 1-10, wherein configuring the first resource timing also includes adjusting the timing of the TWT of the user device based on downlink traffic from the network node.

[0175] Example 12. A method according to any one of Examples 1-11, wherein configuring the first resource timing further comprises: based on the communication timing information, requesting that the PUSCH resources of the UE be adjusted to at least partially overlap with the TWT of the user device.

[0176] Example 13. The method according to any one of Examples 1-12 further includes receiving data generation timing, wherein configuring the first resource timing also includes sending a request to the network node to adjust the physical uplink shared channel (PUSCH) resources of the UE based on the data generation timing or sending a request to the network node to adjust the data generation timing.

[0177] Example 14. A method according to any one of Examples 1-13, wherein configuring the first resource timing also includes adjusting the timing of the uplink from the user device to the UE to at least partially overlap with another uplink from the UE to the network node based on the communication timing information.

[0178] Example 15. A method according to any one of Examples 1-14, wherein configuring the first resource timing also includes adjusting the timing of the downlink from the UE to the user device to at least partially overlap with another downlink from the network node to the UE based on the communication timing information.

[0179] Other implementation examples are described in the following paragraphs. Although some of the following implementation examples are described according to example methods, other example implementations may include: the example methods discussed in the following paragraphs are implemented in a network node of a cellular wireless communication network, wherein the network node includes a processor configured with processor-executable instructions to perform the operations of the methods of the following implementation examples; the example methods discussed in the following paragraphs are implemented by the network node, which includes: a component for performing the functions of the methods of the following implementation examples; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the network node to perform the operations of the methods of the following implementation examples.

[0180] Example 16. A method for synchronizing resource timing of at least two wireless protocols, performed by a processor of a network node, the method comprising: receiving one or more auxiliary data messages including communication timing information of a user device connected to the UE from a user equipment (UE); and configuring the resource timing of the network node based on the communication timing information.

[0181] Example 17. A method according to Example 15, wherein configuring the resource timing also includes: adjusting the physical uplink shared channel (PUSCH) resources allocated to the UE to at least partially overlap with the target wake-up time (TWT) of the user device, the timing of the TWT being included in the communication timing information; and notifying the UE of the adjusted PUSCH resources.

[0182] Example 18. A method according to Example 15, wherein configuring the resource timing also includes: adjusting a physical uplink shared channel (PUSCH) resource allocated to the UE based on the communication timing information, wherein the communication timing information is related to a data generation timing at the user device; and notifying the UE of the adjusted PUSCH resource.

[0183] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities configured to perform specific operations or functions, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be but not limited to a process, a processor, an object, an executable file, an execution thread, a program, or a computer running on a processor. As an example, both an application running on a wireless device and the wireless device can be referred to as a component. One or more components can reside within a process or execution thread, and a component can be located on a processor or core or distributed between two or more processors or cores. In addition, these components can be executed from various non-temporary computer-readable media on which various instructions or data structures are stored. Components can communicate through local or remote procedures, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, or process-related communication methods.

[0184] Many different cellular and mobile communication services and standards are available or expected in the future, all of which can be implemented and benefit from the various embodiments. Such services and standards include, for example, the Third Generation Partnership Project (3GPP), Long Term Evolution (LTE) system, third generation wireless mobile communication technology (3G), fourth generation wireless mobile communication technology (4G), fifth generation wireless mobile communication technology (5G) and next generation 3GPP technology, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) system (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I & II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN). Each of these technologies involves, for example, the transmission and reception of voice, data, signaling and / or content messages. It should be understood that any reference to terminology and / or technical details related to individual telecommunication standards or technologies is for illustrative purposes only and is not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.

[0185] The foregoing method descriptions and process flow charts are provided only as illustrative examples, and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter", "then", "next", etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular form, such as using the article "one", "an", or "the", should not be interpreted as limiting the element to the singular.

[0186] The various illustrative logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been generally described above with respect to their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician may implement the described functionality in different ways for each specific application, but such embodiment decisions should not be interpreted as resulting in a departure from the scope of the claims.

[0187] The hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or executed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.

[0188] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or codes on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operation of the method or algorithm disclosed herein may be embodied in a processor-executable software module or a processor-executable instruction, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. As an example and not limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage smart objects, or any other medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. As used herein, disks and optical disks include compact disks (CDs), laser optical disks, optical optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, wherein disks typically reproduce data magnetically, and optical disks reproduce data optically with lasers. Combinations of the above items are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable storage medium and / or a computer-readable storage medium, which may be incorporated into a computer program product.

[0189] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but should be consistent with the widest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A user equipment (UE), comprising: A first transceiver configured to establish a wireless communication link with a user device; a second transceiver configured to establish a wireless communication link with a network node of the cellular wireless communication network; as well as a processor coupled to the first transceiver and the second transceiver and configured to: Obtaining communication timing information of the user device; sending the communication timing information of the user device to the network node; and A first resource timing of an uplink or a downlink between the UE and the user equipment is configured based on the communication timing information.

2. The UE according to claim 1, wherein: The processor is further configured to request configuration of a second resource timing of another uplink or downlink between the UE and the network node based on the communication timing information.

3. The UE according to claim 1, wherein: The processor is further configured to send the communication timing information by requesting the network node to adjust a discontinuous reception (DRX) configuration so that a DRX cycle of the UE and a target wake time (TWT) of the user equipment at least partially overlap.

4. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by adjusting a timing of a target wake time (TWT) based on a discontinuous reception (DRX) configuration for the user equipment.

5. The UE according to claim 4, wherein: The processor is also configured to adjust the timing of the TWT by setting a TWT interval and a TWT start based on a DRX cycle and a DRX offset of the UE, respectively, wherein the DRX cycle and the DRX offset are configured by the network node.

6. The UE according to claim 4, wherein: The processor is further configured to adjust the timing of the TWT by setting a TWT minimum wake-up duration based on jitter of arrival times of periodic data traffic received by the UE.

7. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by one or both of the following: adjusting a timing of a target wake time (TWT) for downlink traffic from the UE to the user device based on a discontinuous reception (DRX) configuration of the UE, a physical downlink shared channel (PDSCH) traffic pattern between the UE and the network node, or a semi-persistent scheduling of the network node; or For uplink traffic from the user device to the UE, adjust the timing of at least one of a bandwidth physical uplink shared channel (PUSCH), a configuration grant of the network node based on the TWT of the user device, or an auxiliary message from the user device.

8. The UE according to claim 7, wherein: The processor is further configured to proactively send the SR before receiving data from the user equipment by considering one or both of a delay of a scheduling request (SR) or a delay of a buffer status report (BSR) for the PUSCH.

9. The UE according to claim 1, wherein: The processor is further configured to send the communication timing information by performing the following operations: generating, via a cross-layer application programming interface (API) on the UE, one or more assistance data messages including the communication timing information of the user device; as well as The one or more assistance data messages are sent to the network node.

10. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by adjusting a timing of a target wake time (TWT) of the user equipment to at least partially coincide with a DRX cycle of the UE based on a discontinuous reception (DRX) configuration for the UE received from the network node.

11. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by adjusting a timing of a target wake time (TWT) of the user device based on downlink traffic from the network node.

12. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by requesting, based on the communication timing information, that a physical uplink shared channel (PUSCH) resource of the UE be adjusted to at least partially coincide with a TWT of the user device.

13. The UE according to claim 1, wherein: The processor is further configured to: Receive data generation timing; and The first resource timing is configured by sending a request to the network node to adjust a physical uplink shared channel (PUSCH) resource of the UE based on the data generation timing or sending a request to the network node to adjust the data generation timing.

14. The UE according to claim 1, wherein: The processor is further configured to configure the first resource timing by one or both of the following: Based on the communication timing information, adjusting the timing of the uplink from the user device to the UE to at least partially overlap with another uplink from the UE to the network node; or Based on the communication timing information, the timing of the downlink from the UE to the user device is adjusted to at least partially overlap with another downlink from the network node to the UE.

15. A method for synchronizing resource timing of at least two radio protocols, performed by a processor of a user equipment (UE), the method comprising: obtaining communication timing information of a user device; sending the communication timing information of the user device to a network node; as well as A first resource timing of an uplink or a downlink between the UE and the user equipment is configured based on the communication timing information.

16. The method according to claim 15, further comprising: Configuration of a second resource timing of another uplink or downlink between the UE and the network node is requested based on the communication timing information.

17. The method according to claim 15, wherein: Sending the communication timing information further includes: requesting the network node to adjust a discontinuous reception (DRX) configuration so that the DRX cycle of the UE and a target wake-up time (TWT) of the user device at least partially overlap.

18. The method according to claim 15, wherein: Configuring the first resource timing also includes adjusting a timing of a target wake time (TWT) for the user equipment based on a discontinuous reception (DRX) configuration.

19. The method according to claim 18, wherein: Adjusting the timing of the TWT includes setting the TWT interval and the TWT start based on the DRX cycle and the DRX offset of the UE respectively, wherein the DRX cycle and the DRX offset are configured by the network node.

20. The method according to claim 18, wherein: Adjusting the timing of the TWT includes setting a TWT minimum wake-up duration based on jitter in arrival times of periodic data services received by the UE.

21. The method according to claim 15, wherein: Configuring the first resource timing also includes one or both of the following: adjusting a timing of a target wake time (TWT) for downlink traffic from the UE to the user device based on a discontinuous reception (DRX) configuration of the UE, a physical downlink shared channel (PDSCH) traffic pattern between the UE and the network node, or a semi-persistent scheduling of the network node; or For uplink traffic from the user device to the UE, adjust the timing of at least one of a bandwidth physical uplink shared channel (PUSCH), a configuration grant of the network node based on the TWT of the user device, or an auxiliary message from the user device.

22. The method according to claim 21, further comprising: The UE proactively sends the SR before receiving data from the user equipment by considering one or both of a delay of a scheduling request (SR) for the PUSCH or a delay of a buffer status report (BSR).

23. The method according to claim 15, wherein: Sending the communication timing information also includes: generating, via a cross-layer application programming interface (API) on the UE, one or more assistance data messages including the communication timing information of the user equipment; and The one or more assistance data messages are sent to the network node.

24. The method according to claim 15, wherein: Configuring the first resource timing further includes adjusting a timing of a target wake time (TWT) of the user device to at least partially overlap with a DRX cycle of the UE based on a discontinuous reception (DRX) configuration for the UE received from the network node.

25. The method of claim 15, wherein: Configuring the first resource timing also includes adjusting a timing of a target wake time (TWT) of the user device based on downlink traffic from the network node.

26. The method of claim 15, wherein: Configuring the first resource timing also includes requesting, based on the communication timing information, that a physical uplink shared channel (PUSCH) resource of the UE be adjusted to at least partially overlap with the TWT of the user equipment.

27. The method according to claim 15, further comprising receiving data generation timing, in, Configuring the first resource timing further includes: sending a request to the network node for adjusting a physical uplink shared channel (PUSCH) resource of the UE based on the data generation timing, or sending a request to the network node for adjusting the data generation timing.

28. The method of claim 15, wherein: Configuring the first resource timing also includes one or both of the following: Based on the communication timing information, adjusting the timing of the uplink from the user device to the UE to at least partially overlap with another uplink from the UE to the network node; or Based on the communication timing information, the timing of the downlink from the UE to the user device is adjusted to at least partially overlap with another downlink from the network node to the UE.

29. A computing device for use as a network node in a cellular wireless communication network, the computing device comprising: A processor configured with processor-executable instructions to: receiving one or more assistance data messages from a user equipment (UE), the one or more assistance data messages comprising communication timing information of a user device connected to the UE; Configuring the resource timing of the network node based on the communication timing information in any of the following ways: adjusting a physical uplink shared channel (PUSCH) resource allocated to the UE to at least partially coincide with a target wake-up time (TWT) of the user equipment, the timing of the TWT being included in the communication timing information; or adjusting a PUSCH resource allocated to the UE based on the communication timing information, wherein the communication timing information is related to a data generation timing at the user device; and The UE is notified of the adjusted PUSCH resources.

30. A method for synchronizing resource timing of at least two wireless protocols, performed by a processor of a network node, the method comprising: receiving one or more assistance data messages from a user equipment (UE), the one or more assistance data messages comprising communication timing information of a user device connected to the UE; Configuring the resource timing of the network node based on the communication timing information in any of the following ways: adjusting a physical uplink shared channel (PUSCH) resource allocated to the UE to at least partially coincide with a target wake-up time (TWT) of the user equipment, the timing of the TWT being included in the communication timing information; or adjusting a PUSCH resource allocated to the UE based on the communication timing information, wherein the communication timing information is related to a data generation timing at the user device; as well as The UE is notified of the adjusted PUSCH resources.

Images