Method, apparatus and system for supporting coordinated transmission for cooperating user equipment (UE) - Patents.com

Abstract

In one method, a first WTRU of a WTRU group receives configuration information indicating WTRU IDs for one or more WTRUs in the WTRU group, one or more configured grants (CGs) associated with the one or more WTRUs, and a threshold value. The method may further include, conditional on the first WTRU determining that respective timing information associated with each WTRU of the one or more WTRUs exceeds the threshold value, determining a respective preferred CG for each WTRU, and indicating the respective preferred CG and WTRU ID of the respective WTRU to a network.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Patent Application No. 63 / 309,150, filed February 11, 2022, U.S. Patent Application No. 63 / 335,019, filed April 26, 2022, U.S. Patent Application No. 63 / 394,854, filed August 3, 2022, and U.S. Patent Application No. 63 / 410,757, filed September 28, 2022. The contents of these earlier-filed applications are hereby incorporated by reference in their entirety for all purposes.

[0002] FIELD OF THEINVENTION FIELD OF THE DISCLOSURE The embodiments disclosed herein relate generally to wireless communications, such as methods, apparatus, architectures and systems for supporting coordinated transmission for cooperating UEs. [Background technology]

[0003] Extended Reality (XR) may refer to different types of immersive experiences, such as Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), as well as realities interpolated between them. VR is a rendered version of a delivered visual and audio scene. The rendering may be designed to mimic as naturally as possible the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world to the observer or user as the observer or user moves within limits defined by the application. AR may be when the user is provided with additional information or artificially generated items and / or content overlaid on the user's current environment. MR may be an advanced form of AR, where some virtual elements may be inserted into a physical scene, for example, with the purpose of providing the illusion that these elements are part of the real scene. XR may refer to (e.g., associated with) a combined real and virtual (e.g., all real and virtual) environment and human-machine interaction generated by computer technology and wearables. An XR application may be supported by one or more devices, nodes, and / or user equipment (UE). Summary of the Invention

[0004] One embodiment may be directed to a method that may be performed by a first WTRU (e.g., an anchor UE) of a WTRU group. The method may include receiving configuration information indicating a WTRU ID for one or more WTRUs in the WTRU group, one or more configured grants (CGs) associated with the one or more WTRUs, and / or a threshold. The method may further include determining that respective timing information associated with each WTRU of the one or more WTRUs exceeds a threshold, determining and / or selecting a respective CG for the respective WTRU, and indicating the selected respective CG and WTRU ID for the respective WTRU to the network.

[0005] One embodiment may be directed to a WTRU including at least one processor and at least one transceiver. The transceiver may be configured to receive configuration information indicating a WTRU ID for one or more WTRUs in a WTRU group, one or more configured grants (CGs) associated with the one or more WTRUs, and / or a threshold. Conditional on respective timing information associated with a respective WTRU of the one or more WTRUs being determined to exceed a threshold, the processor may be configured to determine and / or select a respective CG for the respective WTRU, and the transceiver may be configured to indicate the selected respective CG and WTRU ID of the respective WTRU to a network. [Brief description of the drawings]

[0006] A more detailed understanding may be had from the following detailed description, taken by way of example in conjunction with the accompanying drawings, in which: Figures in the specification are examples; thus, the drawings and detailed description should not be considered as limiting, as other equally effective examples are possible and likely. Moreover, like reference numerals in the figures may refer to like elements. [Figure 1A] FIG. 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] FIG. 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1D is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, according to one embodiment. [Diagram 2] FIG. 2 is a diagram illustrating a set of UEs (eg, UE A and UE B) that form at least a portion of a cooperating UE group that participates in a cooperative operation, according to one embodiment. [Diagram 3] FIG. 3 is a diagram illustrating cooperative transmission in a cooperating UE group including an anchor UE and a cooperating UE according to one embodiment. [Figure 4A] FIG. 4A is a diagram illustrating cooperative transmission in a cooperating UE group including an anchor UE and a cooperating UE according to one embodiment. [Figure 4B] FIG. 4B is a flow diagram illustrating a method for coordinated transmission in a group of cooperating UEs, according to one embodiment. [Diagram 5] FIG. 5 is a flow chart illustrating a method for cooperative transmission in a group of cooperating UEs, according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of certain embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components and circuits may not be described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with embodiments and other examples explicitly, implicitly and / or inherently (collectively "provided") herein. Although various embodiments are described and / or claimed herein in which apparatus, systems, devices, etc. and / or any elements thereof perform operations, processes, algorithms, functions, etc. and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any elements thereof are configured to perform any operations, processes, algorithms, functions, etc. and / or any portions thereof.

[0008] Exemplary Communication Systems or Networks for the Implementation of Exemplary Embodiments The methods, apparatus, and systems provided herein are well suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with reference to Figures 1A-1D, in which various elements of a network may utilize, execute, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus, and systems provided herein.

[0009] 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communications system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0010] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals, and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (loT) devices, watches or other wearable, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating in commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d, and / or any other WTRUs mentioned or described herein may be referred to interchangeably as a UE.

[0011] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), Node-B, eNodeB (end), Home Node B (HNB), Home eNode B (HeNB), gNB, NR Node B, site controller, Access Point (AP), wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0012] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell, for example, using beamforming to transmit and / or receive signals in a desired spatial direction.

[0013] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0014] More specifically, as noted above, the communications system 100 may be a multiple access system, but may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a and the WTRUs 102a, 102b, 102c in the RAN 104 / 113 may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0015] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

[0016] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to and from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0019] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as an office, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.11, to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology, such as IEEE 802.15, to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0020] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as, for example, different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high level security functions such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may use the same RAT as the RANs 104 / 113 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802 wireless technology.

[0023] Figure 1B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0024] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0025] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0026] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0027] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as, for example, NR and IEEE 802.11.

[0028] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

[0029] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0030] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location determination method while remaining consistent with an embodiment.

[0031] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0032] The processor 118 of the WTRU 102 may be in operative communication with various peripherals 138 including, for example, one or more accelerometers, one or more gyroscopes, a USB port, other communications interfaces / ports, a display, and / or any of other visual / audio indicators to implement the representative embodiments disclosed herein.

[0033] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0034] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As mentioned above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also communicate with the CN 106.

[0035] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with an embodiment. The eNodeBs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, the eNodeB 160a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0036] Each of the eNodeBs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the UL and / or DL. As shown in FIG 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0037] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0038] The MME 162 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0039] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during inter-eNodeB handovers, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0040] The SGW 164 may be connected to a PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0041] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0042] Although the WTRU is depicted in FIGS. 1A-1D as a wireless terminal, in certain representative embodiments, it is contemplated that such a terminal may use a wired communications interface (e.g., temporarily or permanently) with the communications network.

[0043] In an exemplary embodiment, the other network 112 may be a WLAN.

[0044] A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to the STA may arrive through the AP and be delivered to the STA. Traffic originating from the STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) the source STA and the destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad-hoc" communication mode.

[0045] When using an 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0046] A High Throughput (HT) STA may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

[0047] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining multiple contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed and the combined data may be transmitted to the Medium Access Control (MAC).

[0048] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have limited capabilities, including certain capabilities, for example, support for (e.g., support only for) certain and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0049] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be configured and / or limited by the STAs among all STAs operating in the BSS that support the smallest bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration may depend on the status of the primary channel. For example, if the primary channel is active due to a STA (that only supports the 1 MHz mode of operation) transmitting to the AP, the entire available frequency band may be considered active even though most of the frequency band may remain dormant and available.

[0050] In the United States, the available frequency bands that can be used by 802.11ah are 902MHz to 928MHz. In South Korea, the available frequency bands are 917.5MHz to 923.5MHz. In Japan, the available frequency bands are 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0051] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may use NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0052] The RAN 113 may include gNBs 180a, 180b, 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to transmit and / or receive signals to the gNBs 180a, 180b, 180c. Thus, the gNB 180a may transmit and / or receive wireless signals to and from the WTRU 102a, for example, using multiple antennas. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0053] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

[0054] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to a gNB 180a, 180b, 180c while also communicating with and connecting to another RAN, such as an eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0055] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface. Any of the terms "gNB", "network entity", "base station", and / or "access point" may be used interchangeably.

[0056] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0057] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different Protocol Data Unit (PDU) sessions having different requirements), selection of the SMFs 183a, 183b for registration, management of registration areas, termination of Non-Access Stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency communication (URLLC) access, services relying on enhanced mobile (e.g., enhanced mobile broad band (eMBB)) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0058] The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN 115 via an N11 interface. The SMFs 183a, 183b may also be connected to the UPFs 184a, 184b in the CN 115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure the routing of traffic through the UPFs 184a, 184b. The SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0059] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0060] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0061] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0062] The emulation device may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in the communication network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may use terrestrial wireless communication to implement the tests.

[0063] The one or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0064] In certain representative embodiments, methods, apparatus, and / or systems may be implemented to support coordinated transmission / reception for one or more UEs in a cooperating user equipment (UE) group.

[0065] In certain representative embodiments, one or more identifiers (IDs) may be implemented to associate UEs in a cooperating UE group.

[0066] In certain representative embodiments, the UE may send information and / or instructions to a network entity (NE), network (NW), and / or gNB associated with one or more actions (e.g., extended reality (XR) actions).

[0067] In certain representative embodiments, the UE may send higher / application layer information to itself and to NEs, NWs, and / or gNBs associated with cooperating UEs and / or cooperating UE groups.

[0068] In certain representative embodiments, the UE may send information and / or instructions to the NE / NW / gNB and / or other UEs (e.g., in a cooperating group) to, for example, enable periodic / dynamic allocation of resources within a cooperating UE group.

[0069] In certain representative embodiments, the UE may receive information and / or instructions from the NE / NW / gNB and / or other UEs (e.g., in a cooperating group) to, for example, enable periodic / dynamic allocation of resources within a cooperating UE group.

[0070] In certain representative embodiments, a UE may perform actions / behaviors associated with cooperative transmission / reception within a cooperating UE group.

[0071] In certain representative embodiments, the UE may determine information and / or instructions to be sent on the uplink (UL) based on information or instructions received on the downlink (DL).

[0072] In certain representative embodiments, the UE may receive, for example, from the gNB / NW, configuration regarding permissible changes to resource grant configurations for itself and member UEs that the UE may make and / or activate without instructions to the gNB / NW. The UE may receive, for example, from the gNB / NW, corresponding thresholds for implementing permissible changes. The UE may notify the gNB / NW if the change exceeds what the gNB / NW has configured as an "permissible change."

[0073] Exemplary Procedures for Supporting Cooperative Transmission, for example In certain representative embodiments, a UE, e.g., an anchor UE, may be configured to receive configuration information from a gNB. The configuration information may include the IDs of one or more UEs within a cooperating UE group (e.g., the Uu link and SL IDs of the anchor UE and member UEs), default parameters of configured grants (CGs) associated with each UE within the group (e.g., start offsets), time thresholds T1 and T2, and / or any allowable changes to the CG configuration (e.g., the maximum duration allowed to time-shift the occasion of CG resources). In one embodiment, the anchor UE may be configured to receive, from a higher layer, data and UE traffic association information (e.g., an association flag) between the anchor UE and member UEs. According to one embodiment, the anchor UE may be configured to determine UL jitter (δ) for the anchor UE and member UEs based on data arrival, default parameters of the UE's CG resources (e.g., start offsets), and / or traffic association information (e.g., traffic association information between the anchor UE and member UEs). In one embodiment, the anchor UE may be configured to determine whether to use the default CG configuration, a shifted CG, or request a new CG for itself and the member UEs based on the value of the jitter. For example, if δ < T1, the anchor UE may determine to transmit UL data using CG resources with default parameters. If T1 < δ < T2, the anchor UE may determine to transmit data in UL using time-shifted CG resources. If δ > T2, the anchor UE may transmit an indication to the gNB to request resources for the anchor UE and member UEs and determine to transmit data in UL using the received resources. According to certain embodiments, the anchor UE may be further configured to transmit the next data in UL using CG resources with default parameters.

[0074] For example, an exemplary procedure (e.g., an implementation example) using an anchor UE to coordinate cooperative UE group schedulingIn a particular representative embodiment, the anchor UE may receive upper / application layer information about the XR experience (e.g., expected periodicity of traffic, average expected jitter associated with the XR experience, and / or other XR parameters, among others). The anchor UE may send assistance information to the gNB / NE associated with the upper / application layer information. The anchor UE may receive the assistance information from the gNB / NE, where the assistance information may include at least one of: (1) configuration / configuration information (e.g., in / for a radio resource control (RRC) associated with a cooperating UE group) (e.g., UE ID); (2) one or more pre-configured sets of resource grants for each UE, at least one of which is activated (e.g., one or more configured grant (CG) sets may be activated); and / or (3) an overall threshold T that may trigger a change in one or more resource grant allocations. The anchor UE may receive an indication of an event from the application and a duration of the event (e.g., an expected time window). The anchor UE may receive data from the application. The anchor UE may determine an absolute time difference (δ) resulting from the event based on the arrival time of data from the application (e.g., timestamp or other time indication) and the resource grant configuration (e.g., CG configuration) of the first and second UEs (e.g., UE A and UE B). For example, if δ<threshold T, the anchor UE may send data using the activated resource grant. As another example, if δ>threshold T, the anchor UE may select the most appropriate resource grant configuration for itself and UE B by taking δ into account (e.g., based on δ). The anchor UE may send an indication / information to the gNB / NE on behalf of UE B to select a different resource grant configuration from a preconfigured list for UE A and for the duration of the event. The anchor UE may send an indication / information to the gNB / NE on behalf of UE B to select a different resource grant configuration from a preconfigured list for UE B.In certain representative embodiments, the anchor UE may send an indication / information to UE B (e.g., via a sidelink (SL) transmission / direct communication) to signal, for example, an adjustment of the resource grant allocation cycle. In certain representative embodiments, the gNB / NE may send a wake-up signal (WUS) to indicate the change. The anchor UE may receive from the gNB / NE either (1) a resource grant confirmation for UE B and / or (2) a resource grant activation for UE A.

[0075] Exemplary Procedures for Using Cooperative UEs to Support Coordination of a Group of Cooperative UEs In certain representative embodiments, the cooperating UE may receive configuration / configuration information from the NE / gNB. The configuration information may include or indicate (1) one or more sets of resource grants, (2) one or more activated sets / resource grants, and / or (3) one or more monitoring occasions (e.g., start and / or duration of the monitoring occasions, e.g., one or more time-related values ​​(e.g., associated with a timer) for defining the one or more monitoring occasions). The cooperating UE may receive data from the application. The cooperating UE may receive data from the application at a first time t A and may start a timer associated with the activated resource grant (eg, initiate a time expiration operation based on a time value).

[0076] Upon expiration of the timer (e.g., the end of the expiration operation), a second time t BAt (e.g., as shown in FIG. 3), the UE may start monitoring the DL (e.g., physical downlink control channel (PDCCH) transmissions). Conditional or if the UE receives an indication / information from the NE / NW / gNB to change the resource grant from the NE / gNB, the UE may switch from the initial set or pre-configured resource grant to another. Conditional or if the UE does not receive a DCI, the UE may restart the timer (e.g., restart expiration operation) for the monitoring occasion.

[0077] The term extended reality (XR) is an umbrella term for different types of immersive experiences, including virtual reality (VR), augmented reality (AR), and mixed reality (MR), as well as realities interpolated between them. Virtual reality (VR) may refer to a rendered version of a delivered visual and / or audio scene. The rendering may be designed to mimic as naturally as possible the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world to the observer or user as the observer or user moves within limits defined by the application. Augmented reality (AR) may be when the user is provided with additional information or artificially generated items and / or content overlaid on the user's current environment. Mixed reality (MR) may be an advanced form of AR where some virtual elements may be inserted into a physical scene, for example, with the purpose of providing the illusion that these elements are part of the real scene. XR may refer to (e.g., associated with) a combined real and virtual (e.g., all real and virtual) environment and human-machine interaction generated by computer technology and wearables.

[0078] The concept of immersion in the context of XR applications / services refers to providing the feeling of being surrounded by the virtual environment, as well as being physically and spatially located within it. The level of virtualization can range from partial sensory input to fully immersive multi-sensory input leading to a virtual reality that is virtually indistinguishable from actual reality.

[0079] XR devices may typically be associated with the ability to provide various degrees of spatial tracking. XR devices may be equipped with various sensors, e.g., monocular / stereo / depth cameras, radio beacons, GPS, and / or inertial sensors, among others, to enable spatial tracking. Such spatial tracking may be performed at different levels, e.g., 3 Degrees of Freedom (DoF) (rotational movement along X, Y, and Z axes), 6DoF (rotational and / or translational movement along X, Y, and Z axes). Such spatial tracking may result in some form of interaction to experience virtual content. A user may act within and / or interact with components within the extended reality. For example, actions and / or interactions may include, among others, movement, gesture, and / or gaze tracking. Spatial tracking may be an enabler for immersive XR experiences. For example, some form of head and / or movement tracking may ensure that simulated visual and audio components from the user's perspective are updated to match the user's movements. Inaccurate and / or delayed spatial tracking may result in discomfort and / or a feeling of motion sickness for the user.

[0080] A UE may correspond to any XR device / node, which may appear in various form factors. A typical UE (e.g., an XR UE) may include, but is not limited to, any of the following: (1) one or more Head Mounted Displays (HMDs), (2) optical see-through glasses and camera see-through HMDs for AR and MR, (3) one or more mobile devices with position tracking, (4) cameras, and / or (5) wearables, among others. Additionally or alternatively, several different types of XR UEs may be implemented based on XR device capabilities / operations to use or include, for example, any of: (1) one or more displays, (2) one or more cameras, (3) one or more sensors, (4) sensor processing, (5) wireless connectivity, (6) XR / media processing, and / or (7) one or more power sources provided by any of: (i) one or more devices, (ii) one or more wearables, (iii) one or more actuators, (iv) one or more controllers, and / or (v) one or more accessories, among others.

[0081] One or more devices / nodes / UEs may be grouped into a cooperating group (e.g., an XR group) to support an application (e.g., either an XR application / service and / or timing / synchronization operation). For example, a procedure may use both network communication and sidelink (e.g., direct UE-to-UE communication) to enable time synchronization between a first UE / device and a second UE / device.

[0082] Representative Traffic Models for XR Applications and Use Cases The first representative virtual reality (VR1) application First, VR1 applications (e.g., immersive 6DoF streaming) can be modeled using service flows applicable to the viewport-dependent streaming architecture. Similar to adaptive streaming (e.g., dynamic adaptive streaming over HTTP, DASH), viewport-dependent streaming can enable dynamic updating of media / video quality based on available bitrates in the network and air interface. In terms of service / traffic flows, the viewport tracking and pose information of the XR device (e.g., for small packet sizes, i.e., <100B) can be sent periodically to the XR server in the UL at a certain data rate (e.g., relatively low data rate) (e.g., 0.5-2Mbits per second (Bps) at 60-500Hz). In response, the XR server may send in DL at a data rate (e.g., a higher data rate) (e.g., 6-18Mbps for 4k omnidirectional and / or Field of View (FoV) area streaming) and / or periodically (e.g., quasi-periodic (e.g., 40 / 60 / 120 frames per second (fps)). For example, the viewport may be adaptively optimized media (e.g., H.264 / 265 video), which may then be rendered on the XR device display.

[0083] For example, the traffic characteristics of a VR1 application may be as follows: For example, for UL pose / viewport information (e.g., including information about 6DoF), the traffic characteristics may be: (i) small size (e.g., constant size <100B) packets, (ii) have a data rate (e.g., low data rate) of about 0.5-2Mbps, (iii) use a single flow, and / or (iv) be periodic (e.g., within a periodic range of 60-500Hz). Additionally or alternatively, in the case of DL, the media / video may include or include viewport-optimized scenes (e.g., high quality viewport-optimized scenes) and media / video for (lower quality) non-viewport scenes. For example, for DL, the traffic characteristics may be: (i) include packets of large size (e.g., variable size with Gaussian distribution or fixed size of 1500 B); (ii) use high data rates of approximately 6-18 Mbps; (iii) have end-to-end (E2E) latency in the range of 50 ms; (iv) use multiple flows (e.g., video flows with different bit rates, 3D media, and / or metadata, among others); and / or (iv) be semi-periodic (e.g., quasi-periodic (e.g., with periodicity as a function of frame rate of 40 / 60 / 120 fps)).

[0084] The second typical virtual reality (VR2) application VR2 applications (e.g., immersive games in spectator mode) may be modeled using service flows that are applicable to a split-rendering architecture. In this case, the XR server may perform pre-rendering and / or encoding of two-dimensional (2D) media / video frames based on pose information sent by the XR device periodically at a first data rate (e.g., a low data rate such as 0.5-2 Mbps at 60-500 Hz). Rendering may be performed (e.g., primarily performed) in the XR server and sent in the DL at a higher data rate (e.g., a rate above a threshold) and / or with some latency (e.g., a low latency of 30-45 Mbps, e.g., between 10-20 ms). The XR device may decompress the received media / video and perform asynchronous time-warping (ATW) to correct the viewport based on the latest pose information. The round trip time (RTT) latency for sending pause information in the UL and receiving pre-rendered media in the DL can range up to 50 ms, but ATW may enable meeting motion-to-photon latency requirements (e.g., less than 20 ms) based on in-device processing.

[0085] For example, the traffic characteristics of VR2 may be as follows: For example, for UL pose / viewport information, the traffic characteristics may be: (i) include packets of small size (e.g., constant size <100B), (ii) have a data rate (e.g., a low data rate of about 0.5-2 Mbps), (iii) use a single flow, and / or (iv) be periodic (e.g., within a periodic range of 60-500 Hz). Additionally or alternatively, in the case of DL, the 3D scene may be provided in a frame buffer. For example, the traffic characteristics may include: (i) large size packets (e.g., having a Gaussian distribution, e.g., in the range of about up to 1500 B or unlimited); (ii) using high data rates of about 30-45 Mbps; (iii) having an RTT latency of about 30 ms (e.g., average or typical) and an RTT maximum of about 50 ms; (iv) using multiple flows (e.g., 3D video / media and / or metadata); and / or (v) being quasi-periodic (e.g., the periodicity may be a function of frame rate of 60 / 90 fps).

[0086] The first representative Augmented Reality 1 (AR1) application An AR1 application (e.g., real-time communication with a store clerk) may be characterized using service flows applicable to a distributed computing architecture. According to the service and / or traffic flows, the XR device may transmit pose information (e.g., 0.5-2 Mbps at 60-500 Hz) and / or video (e.g., 10 Mbps at 10 Hz frame update rate) to the XR server in the UL. The received information may be used by the XR server to generate a scene, which may be converted into a 2D (e.g., video) or 3D media (e.g., 3D object) format along with metadata (e.g., scene description). The compressed media and metadata (e.g., characterized by a Pareto distribution) may be delivered quasi-periodically in the DL at a high data rate (e.g., 30-45 Mbps, 40 / 60 / 120 fps). The XR device may locally generate the AR scene, for example, by overlaying 3D objects onto the 2D video, and render the scene in the device display.

[0087] For example, the traffic characteristics of AR1 can be described as follows: For example, for UL pause / viewport information and / or 2D video stream information, the pause traffic characteristics may be (i) small size packets, (ii) have a data rate (e.g., a low data rate of about 0.5-2 Mbps), and / or (iii) periodic within a range of 60-500 Hz. For example, the video traffic characteristics may be (i) large size packets, (ii) have a data rate (e.g., about 10 Mbps), and / or (iii) periodic (e.g., with an update period of 10 Hz). Additionally or alternatively, for DL ​​2D / 3D pre-rendered media and XR metadata, the traffic characteristics may (i) include large sized packets (e.g., having a Pareto distribution), (ii) use high data rates, e.g., around 30-45 Mbps, (iii) use multiple flows (e.g., 2D / 3D media and / or metadata), and / or (iv) be quasi-periodic (e.g., the periodicity may be a function of frame rate of 60 / 90 fps).

[0088] The second representative augmented reality (AR2) application AR2 applications (e.g., XR conferences and / or AR animated avatar calls) may use services / traffic flows applicable to an XR conversation architecture where two or more XR clients / devices can perform peer-to-peer communication with intermediate media processing in the network. Different types of media that may be supported for AR2 applications based on the type of user expression include 2D+ / RGBD (e.g., 2.7 Mbps), 3D mesh (e.g., 30 Mbps), and / or 3D Video point cloud coding (VPCC), / Geometry-based point cloud compression (GPCC) (e.g., at 5-50 Mbps). In a typical XR traffic flow, an XR client in a device may initiate a call setup procedure, based on which a session control function triggers network-based media processing. The session control function (SMF) may forward the call setup to the second XR client / device and then forward real-time media processing and streaming to both clients with low latency (e.g., E2E latency of about <100 ms). During an XR call, 2D / 3D media, and possibly user pause information, may be transmitted quasi-periodically on the UL and / or DL ​​between XR clients / devices.

[0089] For example, the traffic characteristics of AR2 may be as follows: for UL 2D / 3D media, user pause and / or video, the traffic characteristics may (i) include large size packets, (ii) have a data rate (e.g., a high data rate of about 2.7-50 Mbps), (iii) have a packet delay budget (PDB) of about <150 ms, (iv) use multiple flows (e.g., 2D / 3D media), and / or (v) be quasi-periodic in the range of about 60-500 Hz. Additionally or alternatively, for DL ​​2D / 3D media, user pauses and / or video, the traffic characteristics may (i) include large sized packets (e.g., truncated Gaussian distribution), (ii) have a high data rate of about 2.7-50 Mbps, (iii) have an E2E PDB of about <100 ms, (iv) use multiple flows (e.g., 2D / 3D media), and / or (v) be quasi-periodic (in the range of about 60-500 Hz).

[0090] Representative XR conference applications XR conferencing applications provide an immersive conferencing experience between geographically separated users by representing the users in a 3D volumetric representation (e.g., point cloud or mesh). One or more cameras (with depth perception capabilities) may be placed at each user's location to enable interaction (e.g., seeing, hearing, rotating, zooming in, and / or resizing, among others) with each other's full 3D volumetric representation on their respective headsets / glasses. XR conferencing applications may support simultaneous UL and DL media traffic with media consisting of / including audio, video, and / or 3D objects. Media formats that may be applied to capture users in a 3D volumetric format may include 2D+ / RGBD (>2.7Mbps for one camera and / or>5.4Mbps for two cameras), 3D mesh (~30Mbps), and / or 3D VPCC / GPCC (at about 5-50Mbps). Media processors may be centrally located or distributed at the edge of the network. The service / traffic flows between XR clients / users via the in-network media processors can be expected to be similar to the AR2 and XR conversation use cases. Joining an XR conference session may result in an initial download peak to download the virtual environment and associated media objects in the XR application. Throughout the remainder of the session, data rates may vary depending on the number of users, their upload formats, and / or the refresh rate of the virtual 2D / 3D objects / environments.

[0091] For example, traffic characteristics for an XR conference may be as follows: for example, for UL 2D / 3D media, user pose and / or real-time video, 2D / 3D objects / environments (possibly from a third party), the traffic characteristics may be: (i) contain large size packets, (ii) have a data rate (e.g., a high data rate of about 2.7-50 Mbps), (iii) use multiple flows (e.g., 2D / 3D media), (iv) be quasi-periodic within the range of about 60-500 Hz, and / or (v) be about <10 -3 Additionally or alternatively, for DL ​​2D / 3D media, user pose and / or real-time video, 2D / 3D objects / environments (possibly from a third party), the traffic characteristics may be: (i) containing large size packets, (ii) having a data rate (e.g., a high data rate of about 2.7-50 Mbps), (iii) having an E2E PDB of about <100 ms, (iv) using multiple flows (e.g., 2D / 3D media), (v) being quasi-periodic in the range of about 60-500 Hz, and / or (vi) being about <10 -3 The encoder may have a low PER.

[0092] Representative cloud gaming applications Cloud gaming applications (e.g., 5G online games) mainly rely on an adaptive streaming architecture, where video / media rendered in the network is streamed to a thin client in a device (e.g., a smartphone and / or tablet). In a typical service / traffic flow for cloud gaming, an XR device may send pose information (e.g., 100-250B) regarding a viewport to an XR server in the UL (e.g., at about 0.1-1Mbps and 60-500Hz). The generated viewport-related video / media (e.g., about 1500B) may be encoded / compressed (e.g., via H.264 / 265 video) and sent quasi-periodically by an XR server in the DL (e.g., at about 30-45Mbps, 30 / 50 / 60 / 90 / 120fps, and PER of about 10e-3 or less). The received video / media may be rendered in the XR device upon decoding and processing. The RTT latency to support certain high-end cloud gaming applications (e.g., Category D applications such as photorealistic and / or natural video games) may be determined by the round trip delay (e.g., about 50 ms or less). For other cloud gaming applications (e.g., Categories A, B, or C), the UL PDB may be about 10 ms and the DL streaming PDB may range from about 50 ms to 200 ms.

[0093] For example, the traffic characteristics of cloud gaming are as follows: For example, the traffic characteristics for cloud gaming may be as follows: For example, for UL pause / viewport information, the traffic characteristics may be: (i) include packets of small size (e.g., about 100-250B), (ii) have a data rate (e.g., a low data rate of about 0.1-1 Mbps), (iii) have a PDB of about 10 ms, (iv) use a single flow, and (v) be periodic in the range of about 60-500 Hz. Additionally or alternatively, for a user's DL 2D / 3D media and / or video, the traffic characteristics may (i) include large size packets (e.g., up to about 1500B), (ii) use high data rates, e.g., about 30-45 Mbps, (iii) have a PDB of about 2 ms, (iv) use multi-flows (e.g., 2D / 3D media and / or video), (v) be quasi-periodic (e.g., the periodicity may be a function of frame rate of 30 / 60 / 90 / 120 fps), and / or (vi) have a PER of about 10e-3 or less.

[0094] As disclosed herein, a network may include network entities (NEs) including, for example, one or more base stations (e.g., gNBs, transmission / reception points (TRPs), radio access network (RAN) nodes, and / or access nodes), one or more core network functions (e.g., UPF, SMF, and / or AMF, among others), and one or more application functions (e.g., edge server functions and / or remote server functions, among others). As disclosed herein, a flow may correspond to either a QoS flow or a data flow (e.g., a flow of data or PDUs that may be associated with one or more QoS requirements such as, for example, latency, data rate, and / or reliability, among others).

[0095] As disclosed herein, a transmission configuration may correspond to any of: (1) one or more radio bearers; (2) one or more logical channels; (3) one or more configuration parameters in individual layers in an access stratum (AS) protocol stack (e.g., SDAP, PDCP, RLC, MAC, and / or PHY); (4) one or more parameters associated with logical channel prioritization (LCP) (e.g., priority, prioritized bit rate (PBR), and / or bucket size duration (BSD)); (5) one or more parameters associated with data flow / QoS flow to radio bearer mapping (e.g., parameters in SDAP); (6) one or more carriers; (7) one or more bandwidth parts (BWP); and / or (8) one or more links that may be used to deliver PDUs, for example, in the UL and / or DL ​​directions.

[0096] Multiple UEs / other devices may be associated with the same application / experience. For example, the degree of association may vary depending on application layer and / or access stratum (AS) layer attributes. In certain representative embodiments, cooperating UEs (e.g., each cooperating UE) may handle scheduling cooperatively, for example, to reduce inconsistencies when individual radio resource grants are requested and received.

[0097] In certain representative embodiments, the coordination / cooperation may be handled at a layer below the application layer, for example, to reduce latency and / or overhead.

[0098] For example, providing coordination and / or cooperation at the application layer to the AS layer can guarantee latency (e.g., meet pack delay budget requirements) for a user experience (e.g., an XR experience).

[0099] In certain embodiments, handling the coordination / cooperation at one of the UEs in the UE group may, for example, minimize signaling for one or more experiences. For example, signaling for multiple CG grant (e.g., modification) requests and CSI on individual links may be reduced and / or minimized. Such coordination / cooperation may, for example, enable streamlining transmissions and / or retransmissions in a coordinated manner to increase the reliability of the overall experience.

[0100] A selected set of devices and / or UEs having diverse capabilities and functions operating in cooperation may contribute to an XR experience. In this regard, the following issues are addressed herein: at least (1) how one or more UEs can support cooperation within a cooperating UE group, e.g., to ensure that data transmission and / or reception is handled in an efficient manner, and (2) what are the corresponding actions and / or behaviors of the UEs within the cooperating UE group that are associated with a user experience (e.g., an XR experience).

[0101] FIG. 2 is a diagram illustrating a set of UEs (e.g., UE A and UE B) that may form at least a portion of a cooperating UE group that participates in a cooperative operation (e.g., an “XR experience”).

[0102] FIG. 3 is a diagram illustrating an example of coordinated transmission in a cooperating UE group including an anchor UE (e.g., transmitting traffic such as video traffic), which may leverage traffic knowledge of cooperating UEs (e.g., transmitting other traffic such as haptic traffic) to ensure that appropriate offsets are applied (e.g., in time windows) during data transmission.

[0103] Overview of Collaborative XR A cooperating group or cooperating UE group may comprise or include two or more UEs, with a first UE designated as an anchor UE and a second UE designated as a cooperating UE.

[0104] For example, a UE may be one or more of the following: (1) one or more independent and / or standalone devices or nodes (e.g., XR devices, XR glasses, smart watches); (2) one or more devices that may be user-centric (e.g., each may belong to or be registered with the same user) or non-user-centric (e.g., a device may belong to or be registered with multiple users); (3) one or more UEs that may be linked and / or connected to one or more other UEs, where the association between one or more UEs may be initiated in an application and may permeate other layers of the communication framework (e.g., NAS, PDCP, MAC, etc.); (4) one or more non-standalone devices / nodes. (5) devices / nodes controlled by a network (e.g., a network operator); (6) devices / nodes that may not be directly associated and / or connected to a NE / gNB and that may be candidates and / or options for a cooperating group given certain parameters (e.g., FoV metadata (e.g., size, dimensions, quality, etc. of the FoV) and / or pose information); and / or (7) fixed, static, moving and / or mobile devices or nodes, among others.

[0105] The terms corresponding to any UE, any node, and / or any device may be used interchangeably and may refer to any of the different UE types discussed above.

[0106] An anchor UE, in the context of collaborative XR, may refer to any UE that is involved in performing any one or more of the following: (1) hosting an application function (e.g., an XR application) from which a request for any action (e.g., an XR action) may be received; (2) receiving a request for an action (e.g., an XR action) from an application function located in the network (e.g., in an edge server and / or a remote server); (3) initiating a discovery procedure to determine other UEs / devices / nodes in the cooperating UE group that are in proximity to perform any action (e.g., an XR action); (4) establishing a session (e.g., an XR session, a PDU session, and / or an application session) by sending and / or receiving a request for session establishment, and communicating with RAN functions / nodes (e.g., gNBs), core networks (core (5) an interface connection between the anchor UE and the network (e.g., if supporting a connection to the network, an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB)), (6) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (7) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (8) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (9) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (10) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (11) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (12) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (13) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (14) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (15) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (16) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (17) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (18) an interface connection between the anchor UE and the network (e.g., NE, base station, and / or gNB), (19) an interface connection between the anchor UE and the network (e.g., NE, base station, and (6) coordination (e.g., the anchor UE may support coordination between the anchor UE and one or more cooperating UEs during an event (e.g., an “XR experience”), regardless of the level of association that may exist between the anchor UE and the cooperating UEs for the XR experience. The level of association may remain constant or may change throughout the experience), and / or (7) communication (e.g., provision) to the network (NW) of assistance information for coordinating a cooperating UE group (e.g., timing of transmissions (e.g., expected timing), duration of transmissions, etc., on behalf of the anchor UE and one or more cooperating UEs).

[0107] In the context of cooperative XR, a cooperating UE, which may be interchangeably referred to as a member UE, may refer to any UE that is involved in performing one or more of the following: (1) initiating a discovery procedure to make the UE discoverable (e.g., via a sidelink and / or via a network) and / or receiving a request to perform one or more actions (e.g., an XR action); (2) interfacing (e.g., the interface between a cooperating UE and a network (e.g., a NE / base station and / or a gNB) may be referred to as a secondary Uu link if it supports connection to the network); (3) transmitting information-related activities to the network (e.g., directly to the network, such as a gNB / NE / base station, CN function, and / or application function), and / or indirectly to the anchor UE. (4) receiving information (e.g., RRC configuration information, and / or application configuration information, among others) that may be used to determine one of the actions (e.g., XR action), e.g., possibly with the anchor UE; (5) sending action (e.g., XR action) related messages / reports to the anchor UE and / or the network (e.g., NE), e.g., including pause and / or FoV measurements and estimations over a sidelink interface (e.g., NR sidelink, Bluetooth, and / or WiFi Direct, among others); and / or (6) cooperation (e.g., cooperating UEs may be associated with different cooperating groups and anchor UEs).

[0108] The end-user / XR experience relates to the end-user's overall experience and is derived from the coordinated transmission and / or reception of accurate data to the correct end device in a reliable and timely manner.

[0109] An action (e.g., an XR action) may be split among and / or performed by one or more UEs, and the anchor UE may perform the splitting of the action (e.g., an XR action) and / or collaboration with other UEs in a cooperating UE group to perform the split action. In another example, the same / similar action (e.g., an XR action) may be performed by one or more UEs / nodes associated with a cooperating group, and the actions (e.g., an XR action) may be performed in parallel.

[0110] Although various embodiments are described using XR implementations and operations, the embodiments are not so limited and other implementations are possible as well. Coordinated actions between devices may be implemented, for example, for wearable devices, gaming devices, AR / VR devices, and other IoT devices that may benefit from a coordinated / collaborative control scheme.

[0111] An "event" may result in, for example, a change in the current operating mode, transmission, and / or reception of data that may require or use a change in resource allocation (e.g., changing resource grant allocations, changing the periodicity of configured grants, and / or applying an offset to resource grant allocations, among others), either statically, semi-statically, or dynamically. Examples of when an event or triggering condition may be detected may include any one or more of the following: (1) the anchor UE may receive an indication from application of an expected delay, for example, as a result of jitter in the UL (e.g., as a result of processing delays from a codec in the AR glasses and / or VR headset); (2) the anchor UE may detect the presence of jitter exceeding a threshold (e.g., an allowed delay budget) based on receipt of a previous DL transmission; (3) the anchor UE may receive an indication from an application regarding an experience (e.g., an XR experience) and associated payload (e.g., an increase in resources following an expected scene change that will be known by the application and indicated to the anchor UE), or in other representative embodiments, the experience / payload may be implicitly detected by the anchor UE (e.g., from an increase in data rate). (4) The anchor UE may implicitly or explicitly receive dynamic indications (e.g., regarding data priority / importance and / or spatial / pose information, among others) from one or more cooperating UEs in a cooperating group (e.g., as application type events) and / or from an application, and / or (5) the anchor UE may receive indications from a gNB / NE regarding changes in one or more lower layer parameters (e.g., link quality degradation, coverage holes, and / or cell edges, among others).

[0112] The detection of an event and / or trigger condition may be based on measurements by the UE that the timing of arrival of data from an application is outside an expected arrival window, which may lead to the UE changing the mode of resource grant allocation.

[0113] The terminology for anchor UEs and cooperating UEs is non-limiting example. Other terms may be used interchangeably when referring to an anchor UE (e.g., "central UE," "primary UE," "main UE," "initiating UE," "UE 1," and "UE A," "first UE," among others). Other terms that may be used when referring to cooperating UEs may include "assisting UE," "supporting UE," "secondary UE," "second UE," "UE 2," "UE B," among others.

[0114] Exemplary Procedures for Supporting Cooperative Transmission / Reception for UEs in a Cooperative UE Group The procedures described herein may be performed semi-statically and / or dynamically, one or more times, at the beginning of and / or throughout an experience / action (e.g., an XR experience / XR action).

[0115] Representative ID management procedure for association between UEs An identifier (ID) may be implemented / used to associate UEs in a cooperating UE group. For example, an anchor UE may be associated with one or more cooperating UEs, and the level of such association may vary per experience, action, and / or trigger condition (e.g., XR experience) and / or within the same experience / action or after one trigger condition is met (e.g., XR experience). The association between UEs in a cooperating UE group may be application-initiated and follow the requirements of the application, for example, to provide an experience (e.g., XR experience), and this association may be transparent and / or translated to other layers in the communication framework (e.g., NAS, RRC, SDAP, PDCP, RLC, MAC, and / or PHY layers, or any new layers of the AS protocol stack).

[0116] The initial ID from the application may be retained throughout the layers, or there may be different IDs generated in different layers, and associations may be made between corresponding IDs in each layer. The IDs may remain the same throughout an experience (e.g., an XR experience). The IDs may remain the same from one session (e.g., an XR session) to another, or the IDs may change during and / or between sessions. For example, management and / or storage of IDs between UEs in a cooperating UE group may be performed by (1) the CN, (2) the gNB / NE, (3) the application, and / or (4) the UEs involved in the XR experience.

[0117] The service ID and one or more XR action IDs may be matched. For example, the UE may send one or more IDs including any of the following: (1) application ID, (2) service ID, (3) session ID, (4) UE ID, (5) cooperating group ID, and / or (6) XR action ID (e.g., XR actions supported by the UE and / or requested to be performed by other UEs). In a particular embodiment, the cooperating UE may send an indication when it detects that a service ID / XR action ID in a discovery, request, and / or indication message received from the anchor UE matches a service ID / XR action ID of a service ID and / or XR action ID pre-configured and / or available in the cooperating UE.

[0118] For example, an ID associated with one or more UEs (e.g., a UE ID and / or a Cell Radio Network Temporary Identifier (C-RNTI) in a cooperating UE group and / or an ID associated with a cooperating UE group, e.g., a group RNTI) may be used in any UP / CP procedure (e.g., scheduling), including (1) when transmitting RRC messages, Service Requests (SR) / Buffer Status Reports (BSR), Uplink Control Information (UCI), UL Medium Access Control Control Element (MAC CE), PUCCH transmissions, PUSCH transmissions, UE data and / or assistance data, among others, and / or (2) when receiving RRC signaling / messages, resource grants, configured grants, DCI, DL MAC CE, PDCCH transmissions, and / or PDSCH transmissions, among others.

[0119] According to certain embodiments, matching capabilities and / or procedures may be implemented. For example, a cooperating UE may send an indication when it determines that one or more currently supported capabilities (e.g., XR capabilities and / or connection capabilities) are within the capabilities of the cooperating UE (e.g., to support a match with those indicated by the anchor UE in a discovery / request / indication message).

[0120] Exemplary Procedure for Sending Information Associated with Coordination / UE Actions The UE may send information and / or instructions associated with one or more XR actions to a network (e.g., a NE). In a particular embodiment, the UE may send information to the network, which may be associated with one or more XR actions to be performed by the UE. In a particular example, the UE may send information associated with XR actions to assist a scheduler in the network in scheduling tasks and / or to request network resources on a per-group basis. In another example, the UE may send information to support application awareness functionality in the network, e.g., to enable the network to have awareness of XR actions and / or application attributes / parameters supported by the UE.

[0121] The information may be sent by the UE to the network as, for example, any of (1) assistance information, (2) status information / indication, and / or (3) request / response messages. The UE may send information to the network via, for example, (1) AS layer signaling (e.g., RRC signaling and / or messages using MAC CE and / or over UCI), (2) non-AS (NAS) layer signaling (e.g., PDU session related messages), and / or (3) application layer signaling / messages.

[0122] In an example embodiment, the information sent by a UE (eg, an anchor UE or another UE) may include, for example, any one or more of the following: (1) Identifiers / IDs (e.g., the UE may send one or more IDs including any of an application / service / session ID, a cooperating group ID (e.g., with which the UE may be associated), an ID of another UE / node, and / or an XR action ID (e.g., an XR action supported by the UE and / or requested to be performed by another UE) and / or a data type / message ID (e.g., an ID associated with pause information, FoV information, and / or media / video frame information, among others); (2) pose information (e.g., orientation and / or position (e.g., pose information may be associated with measurements in any spatial dimension, including but not limited to longitude, latitude, altitude, roll, pitch, and / or yaw in one or more coordinate systems (e.g., Cartesian and / or spherical). In one particular example, the pose information sent by the UE may be associated with the orientation and / or position / location of the UE. In other examples, the pose information sent by the UE may be the orientation and / or position / location of another UE / node / device, which may be desired and / or requested by the UE); (3) Capability information associated with connectivity (e.g., information about interfaces that may include some interfaces and / or interface types (e.g., NRUu, NRSL, wiLAN, and / or Bluetooth, among others) supported by the UEs in the cooperating UE group. For example, capability information about interfaces that are supported by the UE and / or may be needed / used by the UE to support any of the XR actions in other UEs may include, among others, any of (i) bandwidth, (ii) number of carriers, (iii) number of transmit antennas, and / or (iv) number of receive antennas, etc.); (4) capability information associated with the XR action (e.g., capability information related to the XR action, including visual sensing and possibly supported by the UE (e.g., a sensor, camera associated with the UE) and / or required / used by the UE to support any of the XR actions in other UEs), which may include any of: (i) FoV resolution (e.g., number of megapixels); (ii) aperture size; (iii) shutter lag; (iv) start-up time; (v) image quality (e.g., min / max range); (vi) zoom lens options; (vii) image stabilization; (viii) exposure settings; (ix) battery life; (x) sound / audio; and / or (xi) merging overlapping frames from different angles (e.g., stitching together frames from individual captures for a panoramic image / video); and / or (5) One or more preferred forwarding configurations (e.g., the UE may send one or more preferred forwarding configurations to the network / NE and / or other UEs / nodes to support any XR actions that may be performed / supported by cooperating UEs and / or another UE / node on behalf of the UE. For example, the one or more forwarding configurations sent by the UE associated with the supported and / or requested UP / CP configurations (e.g., radio bearers, logical channels, and / or links) may include any of the following: (i) Latency requirements (in a first example, the latency requirements may include the latency requirements for IP packets / PD In a second example, the latency requirement may be expressed in terms of a PDB associated with a UP / CP configuration (e.g., a radio bearer, a logical channel, and / or a link), (ii) a data rate requirement (e.g., Mbps), (iii) an application delay budget and / or a frame delay budget associated with a reliability requirement (in one example, the reliability may be expressed in PER. In another example, the reliability may be expressed in terms of a frame error rate and / or an application error rate, (iv) an absolute / relative priority value associated with a UP / CP configuration (e.g., a radio bearer, a logical channel, and / or a link).

[0123] For example, if the network / gNB / NE may be the entity that selects a resource grant configuration (e.g., best resource grant configuration) for the anchor UE and / or one or more cooperating UEs in a cooperating UE group, the UE may send the first two or the first three or the first four preferred QoS configurations to provide options for selection (e.g., best selection) of a resource grant allocation for the UE.

[0124] The UE may potentially send information associated with XR actions and / or cooperating groups to the network / NE based on one or more of the following triggering events / triggering conditions: (1) during connection / session establishment, configuration and / or reconfiguration (e.g., during establishment configuration and / or reconfiguration of an RRC connection, PDU session, application session; (2) when changing and / or updating an XR action (e.g., when a new XR action occurs and / or when releasing an XR action); (3) when receiving higher layer information and / or application information (e.g., when receiving an indication (e.g., from an application function hosted in the UE or hosted in the network) indicating, among other things, a change in XR action and / or forwarding configuration). , (4) upon detecting one or more changes in measurements and / or movement (e.g., when RSRP, RSRQ, and / or RSSI measurements of signals, channels, radio links, and / or carriers, which may be associated with one or more XR actions, among others, go above / below a threshold (e.g., to meet a trigger condition / threshold). As another example, when a pause / positioning measurement (e.g., location information, and / or pause information in 6DoF) goes above / below one or more pause thresholds, and / or (5) upon detecting one or more changes in time / timing attributes (e.g., the UE may send information periodically, aperiodically, and / or when a timer associated with transmitting assistance information is set (e.g., a time period starts) and / or expires (e.g., a time period ends).

[0125] The UE may send higher and / or application layer information to a network / NE / gNB associated with the UE, one or more cooperating UEs, and / or a cooperating UE group.

[0126] The UE may send assistance information to the network / NE / gNB on or through higher layer information and / or through application layer information. The assistance information may include any parameters from the application that may assist the gNB in ​​scheduling tasks for the anchor UE and / or for one or more UEs in the cooperating UE group. Such examples may include, but are not limited to, (1) information about the traffic (e.g., packet size, expected arrival of PDUs, and / or information about groups / clusters / bursts of PDUs), (2) expected periodicity of the traffic, (3) average expected jitter of the traffic, and / or (4) one or more thresholds associated with an XR experience / XR application that may require / use to trigger different resource grant allocation / configuration for the anchor UE and / or one or more cooperating UEs as part of the cooperating UE group.

[0127] A UE may send information and / or instructions to the network and / or one or more other UEs, for example, to enable periodic / dynamic allocation of resources within a cooperating UE group.

[0128] In certain representative embodiments, periodic allocation of resources to one or more UEs in a cooperating UE group (eg, a configured grant type may be used in the UL) may be implemented.

[0129] In various representative embodiments, dynamic allocation of resources to one or more UEs in a cooperating UE group (eg, a dynamic grant type may be used in the UL) may be implemented.

[0130] To enable such embodiments disclosed herein, any of the following may occur: On condition that the network (e.g., NE) selects a resource grant configuration for the anchor UE and / or one or more cooperating UEs and the anchor UE determines that the resource grant configuration is not the most appropriate resource grant configuration for the anchor UE and / or one or more cooperating UEs, the anchor UE may send an instruction to the NE / gNB / base station to change the resource grant configuration. For example, the anchor UE may (i) select a different resource grant configuration from a pre-configured set of resource grant configurations for the anchor UE and / or one or more cooperating UEs, (ii) request the NE / gNB / base station to change / modify / fine-tune the active resource grant configuration for the anchor UE and / or one or more cooperating UEs (e.g., the modification may include, among other things, a different periodicity, a different length, and / or a different traffic volume), and / or (iii) request the NE / gNB / base station to apply an offset (e.g., in subcarriers and / or times / slots / symbols) to the active or next resource grant configuration for the anchor UE and / or one or more cooperating UEs.

[0131] The anchor UE may send an indication (e.g., via direct / sidelink (SL) communication) to one or more cooperating UEs to signal an adjustment of resource grant allocation (e.g., on condition that the anchor UE has selected an alternative resource configuration for one or more cooperating UEs or has changed an active resource configuration for one or more cooperating UEs (e.g., by applying an offset)).

[0132] The anchor UE may send an indication to any cooperating UE in the cooperating UE group to indicate when to listen / monitor DL ​​transmissions (e.g., PDCCH transmissions) via a DL control channel, provided that the anchor UE has requested a change and / or offset to the resource grant allocation for the cooperating UE. The indication may encompass / include more granular information to find / locate / listen / monitor the next transmission (e.g., the anchor UE may indicate a specific frequency range, bandwidth portion, and / or search space set, etc.). The anchor UE may indicate / send a message to the cooperating UE that the NE / gNB / base station (BS) may send a low power signal (e.g., WUS) with information (e.g., all information) required / used for one or more cooperating UEs, and may indicate a window to expect / monitor a low power signal from the NE / gNB / BS.

[0133] In certain representative embodiments, the anchor UE may send and / or may be configured to send periodic indications to one or more cooperating UEs regarding the status of resource grant allocations for the anchor UE and / or one or more cooperating UEs in a cooperating UE group (e.g., the status may be per cooperating UE and / or group status).

[0134] The cooperating UEs may send dynamic and / or periodic indications (e.g., via direct / SL communication) to the anchor UE to request a change in the resource grant configuration of the cooperating UE. The indications may be requests (e.g., simple requests) to review the active resource grant allocation (e.g., the active configured grant configuration, e.g., periodicity and / or bit rate, among others) and / or requests to switch to a different resource grant configuration that may have been pre-approved by the NE / network.

[0135] The anchor UE may dynamically indicate changes in UL traffic requirements based on the cooperating UE groups by sending messages / indications to the NE / gNB / network, and the network may use the received information to modify how it provides UL resources to the anchor UE and the cooperating UE groups.

[0136] In a particular example, the anchor UE may initiate a SR / BSR-based procedure to reserve sufficient UL grant (e.g., PUSCH resources) based on the current data requirements / needs / usage of the cooperating UE group. Various factors may affect the grant size, including, among others, (i) the amount of data to be and / or need to be served in the UL, e.g., FoV of devices in the cooperating UE group, (ii) channel conditions, (iii) link quality, (iv) coverage, (v) power requirements, and / or (vi) location of the UEs in the cooperating UE group. The UE may send a BSR to the NE / gNB / network, which may be a joint BSR based on the requirements of the UEs (e.g., some or all UEs) in the cooperating UE group, or an individual BSR based on each separate cooperating UE in the cooperating UE group (e.g., per UE BSR).

[0137] In certain representative embodiments, changes in logical channel group (LCG) characteristics determined / observed from the anchor UE's perspective may result in a BSR MAC-CE being triggered from the anchor UE, which may occur when there are multiple LCGs with changes in traffic activity duration. For example, a first video may be linked to a particular LCG (LCG "A") and a higher priority video (e.g., with FoV data) may be linked to another higher priority LCG (LCG "B"). LCG "B" may be bursty compared to LCG "A" and sudden availability of data belonging to LCG "B" may trigger a BSR report.

[0138] In certain representative embodiments, if an application in the anchor UE determines / detects / notifies a degradation of a quality metric (e.g., Quality of Experience (QoE) metric), the anchor UE may be triggered to provide a BSR report. The BSR may be triggered from the NE / gNB (e.g., network side) based on feedback from an application server (e.g., XR application server). This trigger may preempt the BSR from the anchor UE (e.g., from the anchor UE side). A network-triggered BSR may result in additional and / or simultaneous triggering of individual BSRs from (one, a subset, or all) UEs / devices in the anchor UE's cooperating group. A triggered BSR may remain active for a certain duration (e.g., based on a timer / counter / time value) or based on when a quality metric (e.g., QoE metric) for an application is satisfactory and / or is restored. This quality metric may be measured (e.g., directly measured) at the anchor UE and / or based on feedback received from the NE / gNB and / or application server (e.g., XR application server).

[0139] In certain representative embodiments, the anchor UE may send a power headroom (PH) report to the gNB / NE / network. The PH report may be triggered by the expiration of a timer (e.g., at the end of a time period), e.g., a periodic reporting timer). This PH report may be triggered when the anchor UE detects a change in the state of power usage / requirements of one of the devices in the cooperating UE group (e.g., based on a path loss change and / or a location change of one of the devices in the cooperating UE group, among others). The reported PH may be based on the worst case PH of the entire set or subset of devices in the cooperating UE group, e.g., to ensure that the resulting bandwidth reservation does not result in a device (e.g., any device) in the set or subset exceeding a maximum allowed transmit power.

[0140] The anchor UE, if configured by the NE / gNB / network, may decide to send additional UL information, e.g., CSI reporting, and / or may send additional UL information. The anchor UE may decide / determine to report CSI if an associated reported buffer status (e.g., determined / established as (i) (a) the entire cooperating UE group, and / or (b) a joint BSR for a subset or all of the devices in the cooperating UE group, and / or (ii) an individual device in the cooperating UE group) is above or below a certain threshold. Such a buffer status may indicate, for example, a larger amount of data to be sent, which may benefit from a more accurate and / or updated CSI report.

[0141] In certain examples, devices (e.g., in a cooperating UE group) may be configured with an additional UL (e.g., a supplementary UL, SUL). The SUL may be added to the UL (sometimes referred to as a normal UL or a non-supplemental UL). The devices may be instructed not to use the SUL (e.g., to use a normal UL instead) or to switch to the SUL under certain scenarios for data transmission in the UL. For example, a non-SUL may be used if the channel conditions experienced by the devices are good (e.g., meet a criterion or exceed a threshold) and / or the bandwidth needs / requirements of the UL data are large (e.g., exceed a criterion or threshold). If the devices in the cooperating UE group, a subset of the devices in the cooperating UE group are power constrained, or all devices in the cooperating UE group (i) experience poor channel conditions, (ii) are power constrained, and / or (iii) do not have high bandwidth requirements (e.g., determined to use less than a threshold size bandwidth), then the UL transmission for this cooperating UE group may be controlled by the NE / gNB on the SUL.

[0142] In some examples, the UE may prefer to use the SUL over non-SUL / normal UL for higher data rates because the SUL may be or generally is at a lower carrier frequency.

[0143] In certain representative embodiments, the anchor UE may have additional information (e.g., that link degradation has improved for the cooperating UE), and the anchor UE may send an indication to indicate / inform the NE / gNB / network of the changed CSI conditions for the cooperating UE.

[0144] Exemplary Procedure for Receiving Information Associated with Coordination / UE Actions The UE may send information and / or indications to the network / other UEs to enable periodic / dynamic allocation of resources within a cooperating UE group.

[0145] In certain representative embodiments, periodic allocation of resources (e.g., configured grants may be sent in the DL for resource allocation in the UL) and / or any configuration information may be sent to UEs in a cooperating UE group.

[0146] In certain representative embodiments, dynamic allocation of resources and / or any configuration information may be sent to UEs in a cooperating UE group.

[0147] To enable such embodiments disclosed herein, any of the following may occur. For example, the anchor UE may receive higher / application layer information about an experience (e.g., an XR experience). The information may be relevant to the anchor UE and / or cooperating UEs that form part of the XR experience and / or may be beneficial to, for example, an XR action. The cooperating UEs may also receive higher / application layer information about the XR experience. The higher / application layer information about the XR experience may include, for example, any of the following parameters for or associated with the anchor UE and / or one or more cooperating UEs: (i) information about the traffic (e.g., information such as (a) packet size, (b) expected arrival of PDUs and / or groups / clusters / bursts of PDUs), (ii) expected periodicity of the traffic, (iii) average expected jitter of the traffic, etc., (iv) one or more thresholds associated with the XR experience / XR application that may require / cause triggering of different resource grant allocation / configuration for the anchor UE and / or one or more cooperating UEs in the cooperating UE group. N thresholds T n (where N is the number of UEs in the cooperating UE group n≧1) may be determined by the application for each UE, in which case the anchor UE may receive one threshold value per UE for the cooperating UE group.

[0148] The anchor UE may receive assistance information from the network / NE / gNB, for example, to enable / facilitate an XR experience. This assistance information may include any of the following. For example, the assistance information may include configuration information (e.g., in RRC signaling) related to the anchor UE and / or the cooperating UE group, and / or a subset or all of the cooperating UEs forming part of the cooperating UE group. The configuration information may be tagged / accompanied by a cooperating UE group ID and / or IDs of individual UEs forming part or all of the cooperating UE group. As another example, the assistance information may include information regarding one or more pre-configured sets of resource grants (e.g., for each UE in the cooperating UE group including the anchor UE), one or more of which may be activated. In a particular embodiment, only a single set of resource grants may be activated. The set of pre-configured resource grants may have been approved / pre-approved by the network (NW) / NE following input from the anchor UE and / or the cooperating UEs (e.g., for each respective UE in the cooperating UE group, e.g., based on expected traffic). The initial selection of the activated resource grant may be based on: (1) the UE receives a resource grant activated by the NE / gNB at the beginning of the XR session based on knowledge of the UE type / class and / or traffic type (e.g., characteristics of the type of traffic such as traffic volume and / or traffic periodicity, among others); (2) the UE receives a resource grant activated by the NE / gNB at the beginning of the XR session based on historical knowledge of resource grants activated in previous time periods for the same type of XR experience; (3) the UE receives a resource grant activated by the gNB at the beginning of the XR session based on one or more indications from the UE (e.g., either an anchor UE or a cooperating UE) regarding traffic information (e.g., traffic periodicity and / or traffic volume, among others).

[0149] In certain representative embodiments, an overall / combined threshold T may trigger a change in resource grant allocation for the anchor UE and / or one or more of the cooperating UEs in the cooperating UE group. In various representative embodiments, in addition to or instead of the overall threshold T, other thresholds may be configured per UE, in which case the anchor UE may receive one threshold per UE for each UE in the cooperating UE group.

[0150] In a particular example, the cooperating UEs may receive assistance information from the NW / gNB / NE, for example, to enable / facilitate an XR experience. This assistance information may include any of the following: For example, the assistance information may include configuration information (e.g., in RRC signaling) related to itself and / or the cooperating UE group, and / or a subset or all of the cooperating UEs forming part of the cooperating UE group. The configuration information may be tagged / accompanied by a cooperating UE group ID and / or IDs of individual UEs forming part or all of the cooperating UE group. As another example, the assistance information may include information regarding one or more pre-configured sets of (e.g., unique) resource grants, one or more of which may be activated. In a particular embodiment, only a single set of resource grants may be activated. The set of pre-configured resource grants may have been approved / pre-approved by the network (NW) / NE following input from the anchor UE and / or the cooperating UE (e.g., for each respective UE in the cooperating UE group, e.g., based on expected traffic). The initial selection of the activated resource grant may be based on: (1) the UE receives a resource grant activated by the NE / gNB at the beginning of the XR session based on knowledge of the UE type / class and / or type of traffic (e.g., characteristics of the type of traffic such as traffic volume and / or traffic periodicity, among others); (2) the UE receives a resource grant activated by the NE / gNB at the beginning of the XR session based on historical knowledge of resource grants activated in previous time periods for the same type of XR experience; (3) the UE receives a resource grant activated by the NE / gNB at the beginning of the XR session based on one or more indications from the UE (either an anchor UE or a cooperating UE) regarding traffic information (e.g., traffic periodicity and / or traffic volume, among others).

[0151] In one embodiment, the cooperating UE may receive a threshold value from the NW that may trigger the cooperating UE to request a change in a resource grant configuration for the cooperating UE.

[0152] The anchor UE may receive an indication of an event from the application and event information (e.g., more details regarding the event (e.g., the duration of the event, a priority associated with the event, a start time of the event, and / or an event type, among others). The event may result in a change in the current operating mode (e.g., a change in resource grant allocation, a change in the periodicity of configured grants, and / or the application of an offset to the resource grant allocation, among others). Various examples of events are disclosed herein, including those related to the collaborative XR portion.

[0153] The anchor UE may receive a resource grant activation for the anchor UE from the NE / gNB / BS, for example, following a request to the NE / gNB / BS to change the resource allocation configuration for the anchor UE. A change in the resource allocation configuration may mean / cause the selection of a different resource allocation configuration or the application of an offset to an ongoing configuration (e.g., an offset to an existing active set of resource allocations).

[0154] The anchor UE may receive resource grant confirmation for one or more UEs in a cooperating UE group at the start of an XR session and / or throughout an XR session and / or following any change in the resource grant configuration of any UE in the cooperating UE group.

[0155] The anchor UE may receive a message and / or an indication from the NE / gNB / NW that its request for a change in resource grant allocation for the anchor UE and / or one or more cooperating UEs in a cooperating UE group may not be allowed (e.g., rejected) or may not be allowed. The message may be accompanied by information indicating one or more alternative scheduling options, for example, (i) a change in resource grant allocation for the anchor UE and / or one or more cooperating UEs may not be allowed for the next / upcoming cycle, but may be allowed in some future cycles, (ii) a change in resource grant allocation for the anchor UE and / or one or more cooperating UEs may not be allowed immediately, but may be allowed in some time period in the future (e.g., in 30 ms), and / or (iii) a change in resource grant allocation for the anchor UE and / or one or more cooperating UEs may not be allowed, but an alternative set of resource grant allocations for the anchor UE and / or one or more cooperating UEs may be allowed.

[0156] In certain representative embodiments, the anchor UE may receive an explicit instruction from the NE / gNB / NW to revert to a default / initially activated mode of resource grant allocation for the anchor UE. The NE / gNB may send the explicit instruction to the anchor UE based on observation of normal traffic conditions / requirements (e.g., based on a determination that traffic conditions / requirements have returned to normal), for example, based on restoration of a quality metric (e.g., QoE) as indicated by an application service (e.g., an XR application service).

[0157] For example, a cooperating UE may receive an explicit instruction from the NE / gNB / NW to revert to its default / initially activated mode of resource grant allocation. The NE / gNB may send the explicit instruction to the cooperating UE based on observation of normal traffic conditions / requirements (e.g., based on a determination that traffic conditions / requirements have returned to normal), for example, based on restoration of quality metrics (e.g., QoE) as indicated by an application service.

[0158] A cooperating UE may receive an indication / message from any anchor UE in a cooperating UE group to indicate when to listen / monitor DL ​​transmissions (e.g., PDCCH transmissions) via a DL control channel, provided that the anchor UE has requested a change and / or offset to the resource grant allocation for the cooperating UE. The indication may encompass or include more granular information to find / locate / listen / monitor the next transmission (e.g., the message / instruction from the anchor UE may include information indicating a particular frequency range, bandwidth portion, and / or search space set, among others). In certain representative embodiments, the message received by the cooperating UE from the anchor UE may include an indication that the NE / gNB / NW may send a low power signal (e.g., WUS) along with information (e.g., all necessary information) for one or more cooperating UEs (e.g., for operating cooperatively) and may indicate a window to expect a low power signal from the NE / gNB / NW.

[0159] The cooperating UEs may receive data from the application. The arrival time of the data at the cooperating UEs may be measured by the cooperating UEs, and an arrival outside the expected time window may trigger an event, which may lead to a request to modify / change the resource allocation configuration.

[0160] The UE may receive dynamic resources from the NE / gNB / NW based on dynamic signaling provided by the anchor UE and the cooperating UE group (e.g., devices associated with the cooperating UE group). Each device / UE in the group may be individually assigned an UL grant for UL data transmission. The NE / gNB may use unique device identifiers (e.g., C-RNTI and / or UE ID, among others) to distinguish between UEs / devices. For example, the NE / gNB may have direct control over which resources are assigned to cooperating UEs in a cooperating UE group, which may be beneficial, for example, in situations where certain applications have low latency requirements. In such cases, the UE may prefer to receive a direct indication of resources from the NE / gNB as opposed to piggybacking its path through the anchor UE. This may have the added benefit of reducing signaling and processing requirements at the anchor UE.

[0161] The cooperating UEs may receive information regarding which set of time and / or frequency resources the UE may use to transmit. The UEs may receive the time domain resource information, for example, via DCI. The cooperating UEs may also be provided with information indicating a delay. This delay may indicate a synchronization delay between the cooperating UEs measured from a PUSCH slot and the length of consecutive symbols assigned to the cooperating UEs for PUSCH by resource grants via DCI. Each UE may be provided with an offset in time and / or frequency resources, for example, to reduce or substantially eliminate the delay. This offset may be indicated in the DCI or provided by the anchor UE.

[0162] An issued UL grant may have an associated timer (time value) that may ensure that a grant received by a cooperating UE is active for a certain duration, for example, based on the timer (e.g., expiration of a period based on the time value). The network may infer the timing based on the BSR received from the UEs in the cooperating UE group. The inferred timing procedure may be beneficial in scenarios where the BSR may indicate a sudden surge in UL data needs, but with associated variability (e.g., jitter) that may imply a need for UL resources that may be available within a certain time window (e.g., time window T, where parameters associated with T may include a start time slot, an end time slot, and a duration / length of T, where the duration / length of T may be measured in number of time slots, symbol duration, SFN, and / or seconds / milliseconds).

[0163] The time that a particular grant is active may depend on some relative time difference or offset based on all or a subset of the UEs in the cooperating UE group. This may be relevant in scenarios where there is some correlation between UEs based on the XR application flows being served, resulting in continuous UL data transmission for a group of UEs. For the example above, in a scenario where one UE receives a grant that is valid for a time window T1, other UEs in the cooperating UE group may be issued a grant that is valid for a time window T2, where T2 may be equal in length / duration to T1 and T2 may have an offset value relative to the starting timeslot of T1, where T1, T2, and the offset value may be expressed in terms of number of timeslots, symbol duration, SFN, and / or seconds / milliseconds, etc. The gNB may use the DCI to provide information indicating a delay (e.g., PUSCH slot delay and / or number of consecutive symbols assigned to each PUSCH) to adapt to / account for the time validity and / or offset duration of the grant, as described above. Correspondingly, the UE may receive an indication from the NE / gNB (e.g., via the DCI).

[0164] The NE / gNB may preemptively allocate more resources than are requested by a set of anchor UEs / cooperating UEs in a cooperating UE group. This may be done, for example, when the NE / gNB anticipates future use / need of UL resources based on network side buffer status for DL ​​and / or information from an application server (e.g., XR application server). In one particular example, the NE / gNB may infer that a sudden burst in DL traffic volume may give rise to additional resource need / use for UL resources based on some level of DL / UL application level symmetry. The NE / gNB may indicate a priority level (e.g., LCG) of the additional resources (e.g., additional resources assigned to an LCG with an associated priority level). The additional resources may be indicated in an issued UL grant for one or more associated devices that may need / use those resources. The anchor UE may receive an indication of extra resources than are requested by the anchor UE and / or one or more cooperating UEs in a cooperating UE group, which the anchor UE may use when planning future resource requirements.

[0165] In certain representative embodiments, the anchor UE may be a UE (e.g., the only UE) in a cooperating UE group that may receive the UL grant. For example, the anchor UE may receive information from the NE / gNB indicating that the anchor UE is the only UE in the cooperating UE group to receive the UL grant.

[0166] In certain representative embodiments, the anchor UE may receive an indication from the NE / gNB that a subset (e.g., only a subset) of UL resources are provided for the anchor UE and / or one or more cooperating UEs. For example, the UE may receive an explicit instruction from the NE / gNB to take a particular action as a result of the indication that only a subset of UL resources are provided. For example, the anchor UE may receive information indicating to prioritize data among some UEs in a cooperating UE group.

[0167] A cooperating UE may receive a partial amount / allocation of UL resources (e.g., only a partial amount of resources) requested by itself or by the anchor UE on behalf of the cooperating UE. The partial allocation of an UL grant may be accompanied by an explicit indication by the NE / gNB, which may include a reason and / or cause code for the partial allocation.

[0168] In certain representative embodiments, the anchor UE may receive an indication from the NE / gNB as to why / cause only partial resources are allowed in the UL. For example, the NE / gNB may not be able to successfully decode a UL transmission from a particular cooperating UE in a cooperating UE group, e.g., due to poor channel quality and / or blocking, among others, and the NE / gNB may decide / decide to reallocate resources later when link quality improves (e.g., when link degradation may be less likely). If the anchor UE has additional information (e.g., that link degradation may no longer be an issue), the anchor UE may send an updated CSI report to the NE / gNB.

[0169] The anchor UE may receive information from the application / NW indicating that there may be overlap / redundancy in data being sent in the UL by one or more cooperating UEs in a cooperating UE group (which may include the anchor UE, for example). Such redundancy may exist, for example, due to common FoV / extended FoV mapping by multiple glass-type UEs in a cooperating UE group. This may be the case for UEs in different cooperating UE groups.

[0170] In certain representative embodiments, the anchor UE may receive information about cooperating UEs from the network. For example, if the anchor UE is processing dynamic indications of buffer status for cooperating UEs or a subset of cooperating UEs in a cooperating UE group, and an event in the cooperating UE triggers the cooperating UE to report the buffer status directly to the NE / gNB, the NE / gNB may indicate this to the anchor UE. Such a trigger may occur, for example, when a sudden increase in UL traffic occurs due to application layer related changes, such as a sudden movement that results in a change in the FoV of the cooperating UE.

[0171] Exemplary Procedures for Enabling Cooperative Transmission / Reception at UEs in a Cooperative UE Group The UE may perform actions and / or behaviors related to coordinated transmission and / or reception in a cooperating UE group based on any one or more of: (1) thresholds; (2) configuration; (3) triggering events / conditions that may arise from any of the following: (i) applications; (ii) AS layer; (iii) conditions / criteria / messages received from the network (e.g., a configuration message that the UE may receive from RRC signaling); and / or (iv) hosted applications (e.g., application functions hosted by the UE).

[0172] The anchor UE may select a resource grant configuration for the anchor UE and one or more cooperating UEs in the cooperating UE group from a set of pre-activated resource grants for the anchor UE and for one or more cooperating UEs in the cooperating UE group based on any of the above-mentioned parameters.

[0173] In certain representative embodiments, the anchor UE may send an instruction to the NE / gNB to change the resource grant configuration, for example, if (1) the NW / NE from which the anchor UE selected a resource grant configuration for the anchor UE and / or one or more cooperating UEs that the anchor UE determines is not a suitable (e.g., most suitable) resource grant configuration for itself and / or one or more cooperating UEs, and / or (2) the selected and / or currently activated resource grant configuration is no longer a suitable (e.g., most suitable) resource grant configuration for the anchor UE and / or one or more cooperating UEs in a cooperating UE group. This procedure may include any of the following: (1) the anchor UE selecting a different resource grant configuration from a pre-configured set of resources for the anchor UE and / or one or more cooperating UEs; (2) the anchor UE requesting the gNB to change / modify / tweak / cancel the active resource grant configuration for the anchor UE and / or one or more cooperating UEs (e.g., using a different periodicity, a different duration, and / or a different traffic volume, among others); (3) the anchor UE requesting the gNB to apply an offset (e.g., in time, frequency, slot, symbol, and / or subcarrier, among others) to the active or next resource grant configuration for the anchor UE and / or one or more cooperating UEs; and / or (4) the anchor UE requesting the addition of a resource grant configuration that was not part of an initially pre-configured set of resource grant configurations for the anchor UE and / or one or more cooperating UEs in the cooperating UE group.

[0174] In certain representative embodiments, the anchor UE may send information (e.g., via direct communication and / or SL communication) to the cooperating UEs indicating an adjustment of the resource grant allocation (e.g., provided that the anchor UE may have selected an alternative resource configuration for the cooperating UE and / or modified an active resource configuration for the cooperating UE, e.g., by applying an offset).

[0175] The anchor UE may send information to cooperating UEs (e.g., any cooperating UEs) in a cooperating UE group indicating when to monitor (e.g., listen to) a DL control channel (e.g., PDCCH transmission), e.g., provided that the anchor UE has requested a change and / or offset to the resource grant allocation for the cooperating UE. The information may also encapsulate / indicate more granular information to find, locate, listen to, and / or monitor the next transmission (e.g., the anchor UE may indicate, among other things, a particular frequency range, bandwidth portion, and / or search space set, etc.). The anchor UE may indicate / send a message to the cooperating UEs that the NE / gNB may send a low power signal (e.g., WUS) along with information (e.g., all information) used / required for one or more cooperating UEs, and may indicate a window to expect a low power signal from the NE / gNB.

[0176] In certain representative embodiments, the anchor UE may be configured to send periodic indications to one or more cooperating UEs regarding the status of resource grant allocations for the anchor UE and / or one or more cooperating UEs in a cooperating UE group.

[0177] In certain representative embodiments, the cooperating UEs may send dynamic and / or periodic indications (e.g., via direct / SL communication) to the anchor UE to request a change in the anchor UE's resource grant configuration. For example, the indication may be (1) a request to review the active resource grant allocation (e.g., active configured grant configuration including, among other things, periodicity and / or bit rate) and / or (2) a request to switch to a different resource grant configuration that may have been pre-approved by the NW / NE.

[0178] For example, the anchor UE may implement a timer and / or counter (e.g., timing or counting operation) that is activated for each cycle in a periodic type resource configuration (e.g., at the activation / start of a new configured grant cycle and / or at the timing of transmitting the first UL grant). The duration of the timer (e.g., a time period associated with a time value) may correspond to the length of the cycle. Upon expiration of the timer and / or time period, the anchor UE may send a status message to one or more cooperating UEs as part of the cooperating UE group to indicate resource grant allocation for one, a subset, or all of the UEs in the cooperating UE group.

[0179] In certain representative embodiments, the cooperating UEs may implement a timer and / or counter (e.g., a timing or counting operation) to determine / know when to wake up. The timer, counter, or time period may start at the start of every resource grant allocation (e.g., at the start of the first configured grant allocation) and may expire either every period or one or more integer multiples of the period. In an illustrative example scenario (see FIG. 3), the timer, counter, or time period may be set to t A It can start with t B Or t C It can end with t A , t B , and t CNote that may be in ms. Upon expiration of the timer, counter, or time period), the cooperating UE may monitor the DL control channel (e.g., PDCCH transmission) to determine and / or learn about any changes in the resource allocation configuration of the cooperating UE (e.g., provided that the anchor UE sent a request to change, e.g., from configured grant 1 to configured grant 2), e.g., as a result of an event detected by the anchor UE for the purpose of aligning / synchronizing transmissions between the anchor UE and the cooperating UE. If the cooperating UE wakes up, e.g., from sleep, from a DL transmission from the NE / gNB before expiration of the timer / counter / time period, the cooperating UE may start monitoring for messages / indications from the NW / NE / gNB on the DL control channel before expiration of the timer / counter / time period.

[0180] A cooperating UE may be configured to wake up periodically (e.g., with a statically or semi-statically defined periodicity) to receive updates regarding the current (e.g., most refreshed / recent) resource grant allocations of one or more cooperating UEs in a cooperating UE group. This periodicity may be configured by the NE / gNB or by the anchor UE and may be granted by the NE / gNB.

[0181] As an example, the anchor UE may receive an explicit instruction from the NE / gNB to revert to a default / previously activated mode of resource grant allocation (e.g., first activated configured grant). The NE / gNB can send the explicit instruction to the anchor UE based on, for example, observing and / or determining that traffic conditions / requirements have returned to normal, for example, based on, among other things, (1) recovery of quality metrics (e.g., QoE), for example, as indicated by an XR application service, and / or (2) recovery of link quality after a previous degradation.

[0182] As another example, the cooperating UE may receive an explicit instruction from the NE / gNB to revert to its default / previously activated mode of resource grant allocation (e.g., first activated configured grant). The NE / gNB can send the explicit instruction to the cooperating UE based on, for example, observing and / or determining that traffic conditions / requirements have returned to normal, for example, based on, among other things, (1) recovery of quality metrics (e.g., QoE), for example, as indicated by an XR application service, and / or (2) recovery of link quality after a previous degradation.

[0183] Provided that the cooperating UE detects a collision / inconsistency between the resource grant allocation selected by the anchor UE and the resource grant allocation selected by the NE / gNB (e.g., through separate indications sent to the cooperating UE from the anchor UE and the NE / gNB, respectively), the cooperating UE may decide and / or make a decision whether to follow the indication from the NE / gNB or, for example, to wake up at both times (e.g., at a time corresponding to a first UL grant indicated by the NE / gNB and at a second time of the first UL grant indicated by the anchor UE). The cooperating UE may also decide to use one or both of the UL grants to send one or more transmissions. In certain embodiments, the cooperating UE may send a message indicating the inconsistency to one or more of the anchor UE or the NE / gNB.

[0184] The cooperating UE may indicate to change (e.g., that it needs to change) the manner of how SR / BSR indications are reported on its behalf by the anchor UE. The cooperating UE may determine, based on some event / condition, that the resource grant and / or resource grant request coming through the anchor UE may be too long. The cooperating UE may decide to send the BSR directly to the NE / gNB in ​​this scenario and send an indication at the same time to the anchor UE to take this into account when the anchor UE makes future SR / BSR requests on behalf of the cooperating UE group. The cooperating UE may recognize a sudden burst of UL traffic due to some trigger at the application layer. The burst may be a short one-off burst that may be inconsistent (non-deterministic) or, alternatively, the burst may be somewhat deterministic and / or periodic in nature. The cooperating UEs may send a BSR request directly to the NE / gNB and / or may indicate a need to send a BSR directly to the network, as opposed to having the anchor UE process the BSR, e.g., to ensure timely adaptation to the resource needs of the cooperating UEs and timely delivery of UL grant information to the cooperating UEs.

[0185] In certain representative embodiments, the cooperating UE may determine that a resource that may be time-limited is reaching the cooperating UE later than a desired time, and the cooperating UE may decide and / or determine to send a BSR request directly to the NE / gNB.

[0186] For example, a change in UL data characteristics (e.g., priority, amount of data, and / or active number of LCGs) and / or an observed / determined increase in buffer volume at a cooperating UE may trigger the cooperating UE to perform a direct BSR transmission to the NE / gNB. The BSR message may be subject to some restrictions, e.g., if the anchor UE has just sent a BSR message for a cooperating UE group, the cooperating UE may (e.g., may need to) wait until the cooperating UE receives a UL grant from the anchor UE or directly from the NE / gNB. A time period or timer (e.g., retxBSR-Timer) may be used to facilitate or determine how long the cooperating UE may need to wait before it can send a direct BSR to the NE / gNB. For example, the cooperating UE may be able (e.g., may only be able) to send a BSR directly on behalf of the cooperating UE upon expiration of the retxBSR-Timer / time period or to modify the BSR reported by the anchor UE, e.g., in conjunction with a periodicBSR-Timer / second time period associated with a periodic BSR that may be configured to ensure that the cooperating UE may provide more or less frequent updated BSRs based on, among other things, (1) the traffic needs of the cooperating UE, (2) changes in the number of LCGs, and / or (3) the priority level of the traffic being served.

[0187] The change in the cooperating UE dynamic indication behavior may be temporary, for example, based on the expiration of some timer / time period / timing action. For example, the timer / time period may be based on (1) an estimate of how long the average fluctuations in traffic may last (based on the type of traffic and / or historical averages) and / or (2) application layer information that is available to the UE.

[0188] The cooperating UE may receive an explicit instruction from the NE / gNB to fall back to the dynamic indication (which may be, for example, anchor UE-based) and / or to return to a default mode. The NE / gNB may provide this instruction when the cooperating UE determines / observes that traffic requirements have returned to normal based on restoration of quality metrics (e.g., QoE) as indicated by an application service (e.g., an XR application service).

[0189] A request for a change in how the anchor UE handles the cooperating UE's dynamic indications and / or resource reservation behavior may be considered as an implicit indication that the cooperating UE is currently going to process a BSR for itself (e.g., all BSRs) and that the anchor UE should take into account the processing of BSRs by the cooperating UEs when providing future BSRs for the cooperating UE group.

[0190] In certain representative embodiments, the anchor UE may receive information about cooperating UEs from the network / NE / gNB. For example, if the anchor UE is processing dynamic indications of buffer status for cooperating UEs or a subset of cooperating UEs in a cooperating UE group, and an event / condition in the cooperating UE triggers the cooperating UE to directly report the buffer status to the NE / gNB, the NE / gNB may indicate the directly reported BSR to the anchor UE. For example, such a trigger may occur when, for example, a sudden increase in UL traffic occurs due to application layer related changes (e.g., a sudden movement resulting in a change in the FoV of the cooperating UE).

[0191] The anchor UE may use the directly reported BSR indication to consider cooperating UEs that are currently reporting their BSRs directly to the NE / gNB and exclude such cooperating UEs from the anchor UE's next BSR reporting for the cooperating UE group. When triggered, the duration for which one or more cooperating UEs may report individual BSRs may be determined by a timing operation / time value / timer, which upon expiration, one or more cooperating UEs may fall back to relying on the anchor UE to report their buffer status.

[0192] In certain examples, cooperating UEs may dynamically indicate BSR directly to the NE / gNB on condition that a change in associated LCG occurs for UL traffic. For example, cooperating UEs may notify and / or determine that a drop in the number of LCGs has occurred, which may indicate a change in priority of traffic requiring service, and may occur when the UE notifies / determines that there is one primary LCG (e.g., for audio) that can benefit from configured grant-based scheduling options. The UE may benefit from providing BSR directly to the NE / gNB so that the NE / gNB may estimate (e.g., best estimate) the RRC configuration (e.g., required RRC configuration, e.g., periodicity of configured grants). The NE / gNB may prioritize and / or facilitate anchor-UE-based joint BSR vs. UE-specific BSR for cooperating UE groups. The NE / gNB may choose to prioritize the BSR provided by the anchor UE when allocating UL grants to UEs in the cooperating UE group, but may revert to individual BSR reporting if the NE / gNB determines / detects a discrepancy between buffer status information / values.

[0193] For example, if the NE / gNB determines, detects, and / or observes that there is a sudden difference and / or a consistent difference (especially based on some time averaging and / or thresholds) between the joint BSR resource measurement value and the sum of all individual BSRs across the cooperating UE group, the NE / gNB may choose to use the individual BSRs when determining an appropriate resource allocation. If this difference falls below a threshold, the NE / gNB can revert to using the joint BSR. In some embodiments, the switch may depend on some timer / time period / timing operation.

[0194] Example of a representative procedure for a UE to receive information regarding acceptable changes that the UE may perform without notifying the NW According to a certain representative embodiment, the UE can receive information regarding "acceptable changes" that the UE can perform and / or activate without an instruction to the gNB / NW. In one embodiment, the UE (e.g., the anchor UE) can be configured to receive from the gNB / NW configuration information regarding "acceptable changes" that can be performed and / or activated without notifying the gNB / NW, and / or other changes beyond the acceptable changes that may need to be indicated to the gNB / NW.

[0195] For example, the UE can be configured to receive one or more time thresholds T1, T2,..., Tn such that, for example, in a UE that receives data from an XR application where a delay δ may exist (as a result of jitter), the UE is configured to perform the following. In one embodiment, if δ < T1, the UE (e.g., the anchor) can be configured to transmit UL data using a CG resource with default parameters (i.e., a CG config activated by default).

[0196] According to one embodiment, when T1 < δ < T2, a UE (e.g., an anchor) may be configured to transmit data in UL using time-shifted CG resources. Such a change may correspond to a configured "permissible change", whereby the UE may not need to notify the gNB / NW about that change before implementing and / or activating it, and / or following activation or implementation. Permissible changes may include, for example, shifting the default CG configuration by a few slots (e.g., 1, 2, 3, 4, ..., K), where K may be considered a sufficiently small number such that the UE (e.g., an anchor) may not need to notify the gNB. In another example, one or more UEs within a UE group (e.g., an anchor UE or a member UE) may each be configured with multiple CG configurations such that a switch from one CG configuration to another for either the anchor UE or the member UE may be considered a "permissible change" by the gNB / NW, and thus the UE (e.g., an anchor) may not need to notify the gNB / NW about the switch. In this example, the UE (e.g., an anchor) may trigger a change in the activated CG config for the member UE as a result of the delay δ.

[0197] In one embodiment, when δ>T2, the UE may be configured to send an indication to the gNB / NW to request new and / or updated resources for the anchor UE and the member UEs. The indication may correspond to any one or more of the following: a change in the activated CG configuration of the anchor UE and / or the member UEs (e.g., a change from one CG configuration to another, a time shift and / or shift by a certain number of occasions and / or slots in the CG configuration of the anchor UE and / or the member UEs (in this case, the number of occasions / slots for the time shift and / or shift may be greater than K so that the change cannot be considered an "acceptable change" and the UE may be required to notify the gNB), a request to activate two or more CG configurations for the anchor UE and / or the member UEs, and / or a request for an additional uplink grant (e.g., a dynamic grant) from the network. The UE (e.g., the anchor) may send a request to the network to request uplink resources for itself and / or the member UEs.

[0198] According to one embodiment, for example, the threshold that the UE may receive from the gNB / NW may correspond to a data volume threshold such that the UE may determine the total amount of data to be transmitted in the UL (i.e., the payload) and evaluate it against the data volume threshold. In one example, the UE may receive one or more data volume thresholds, e.g., V1, V2,..., Vn, etc., from the gNB / NW. As a result, if there is a change Ω in the UL payload to be sent to the gNB / NW, the UE may be configured to evaluate the change in the payload amount against the data volume threshold and perform a corresponding action. In one example, when Ω<V1, the UE (e.g., the anchor UE and the member UEs) may transmit UL data using CG resources with default parameters (i.e., the CG config activated by default). In another example, when Ω>V1, the UE (e.g., the anchor) may send a request to the gNB / NW to request additional resources for itself and / or the member UEs.

[0199] In an exemplary embodiment, there may be more than one CG activated for either the anchor UE or the member UE at any given time. In one exemplary embodiment, the one or more CGs may be specific to an individual member UE. In another exemplary embodiment, the one or more CGs may be on a per UE group basis. The anchor UE may allocate resources in a group CG between itself and the member UEs based on awareness of XR traffic. In an exemplary embodiment, there may be an association between two or more CG configurations among members in a UE group. In one example, activation of a CG configuration for the anchor UE may automatically and / or by default activate a corresponding CG configuration for the member UE. In one example, the association between two or more CG configurations may be 1:1, and in another example, the association may be many:1 and / or 1:many.

[0200] Figures 4A and 4B are diagrams illustrating an example of coordinated transmission in a cooperative UE group including an anchor UE and a cooperating UE according to one embodiment. More specifically, FIG. 4A illustrates an exemplary diagram of a timeline 401 depicting the reception of data and CG configuration at the anchor UE and the reception of data and CG configuration at the cooperating UE, which does not include or consider deviations as a result of jitter. FIG. 4A further depicts an exemplary diagram of a timeline 402 depicting the reception of data and CG configuration at the anchor UE and the reception of data and CG configuration at the cooperating UE while considering deviations as a result of jitter according to a particular embodiment. For example, as illustrated in 402, the anchor UE may be preconfigured or may receive configuration information including one or more time thresholds T1, T2, etc. In one embodiment, when a time threshold is exceeded due to jitter, a change in the resource grant configuration for the anchor UE and / or the member UE may be required and / or necessary. According to one example, the size of the deviation δ may determine the resulting action at the anchor UE. For example, if T1 < δ < T2, the anchor UE may determine a time shift, for example, by a number of seconds / milliseconds and / or the number of occasions, to apply to the transmitted data using default parameters (e.g., CG parameters). However, in one embodiment, if δ > T2, the anchor UE may request a new resource grant configuration from the network or the gNB.

[0201] Although not explicitly illustrated in the example of FIG. 4A, in a further embodiment, the anchor UE may be preconfigured or may receive configuration information including one or more data volume thresholds V1, V2, etc. In this embodiment, if the total amount of data to be sent exceeds the data volume threshold due to the total amount of data to be sent, a change in the resource grant configuration for the anchor UE and / or the member UE may be required and / or necessary. For example, the anchor UE may receive one or more data volume thresholds (e.g., V1, V2,..., Vn, etc.) from the gNB / NW, and as a result, if there is a change Ω in the UL payload to be sent to the gNB / NW, the UE may be configured to evaluate the change in the payload amount with respect to the data volume threshold and perform a corresponding action. In one example, if Ω < V1, the UE (e.g., the anchor UE and the member UE) may be configured to transmit UL data using CG resources with default parameters (i.e., the CG configuration activated by default). In another example, if Ω > V1, the anchor UE may send a request to the gNB / NW for additional or different CG resources (e.g., a larger grant and / or a new offset) for itself and / or the member UE.

[0202] FIG. 4B illustrates an example flow diagram of a method that may be performed, for example, by the anchor UE depicted in FIG. 4A or any other anchor UE discussed herein. As illustrated in the example of FIG. 4B, at 405, the anchor UE may send assistance information, for example regarding XR traffic information, to the gNB. In one embodiment, at 410, the anchor UE may receive the assistance information from the gNB. According to a particular embodiment, the assistance information may include time thresholds T1 and T2, one or more pre-configured sets of resource grants for each UE in the UE group, at least one of which is activated, and / or permissible changes that the anchor UE may make to the resource grant configuration. Thus, in this example, the anchor UE may be pre-configured with one or more time thresholds (e.g., T1, T2, etc.) that, if exceeded due to jitter, may be desirable or necessary to change the resource grant configuration for itself and member UEs.

[0203] As further illustrated in the example of FIG. 4B, at 415, the anchor UE may determine the absolute time difference (δ) resulting from jitter and the corresponding resulting action, which may include applying a time shift by N occasions to the activated CG configuration and / or requesting a new resource grant configuration for the member UE from the gNB. Thus, in some embodiments, the size of the deviation δ may determine the resulting action of the anchor UE. For example, if the deviation δ is greater than T1 but less than T2, the UE may determine the time shift / number of occasions to apply to transmit data using default parameters. As another example, if the deviation δ is greater than T2, the UE may request a new resource configuration. In one embodiment, at 420, the anchor UE may receive a resource grant configuration for the member UE from the gNB.

[0204] Exemplary Procedure for a UE to Determine Information and / or Instructions to be Sent on the UL Based on Instructions Received on the DL In certain representative embodiments, the UE may determine what to send in the UL based on what is received in the DL. The following describes such UE actions / behavior.

[0205] The behavior of the anchor UE in the UL may change with, for example, detected / observed DL signaling and / or traffic received from the NE / gNB. In a particular example, the NE / gNB may switch the mode of DL transmission from dynamic grant-based to DL semi-persistent scheduling (SPS)-based. The mode switch may be triggered by, but may not be limited to, an explicit indication and / or an implicit indication. As an example, an explicit indication may be signaled via a DL channel transmission (e.g., via a PDCCH transmission), while an implicit indication may be indicated by a trigger such as the reception of a DL channel transmission (e.g., a PDCCH transmission) with a BWP indicator (e.g., in switching from an active BWP to a default or smaller BWP) and / or by the expiration of a timer / time period. The switch from dynamic grant-based to SPS-based scheduling may be used by the anchor UE, for example, as an indication to modify the dynamic indication in the UL.

[0206] Activation of SPS in DL may be an indication of higher priority DL traffic, which in turn may require guaranteed symmetric high QoS in the UL direction, which may be associated with the need to change how the anchor UE reports certain dynamic information in the UL (e.g., from joint BSR to individual BSR for better redundancy).

[0207] The anchor UE may adapt the UL data based on detected / observed / determined variations in DL traffic. For example, if the anchor UE detects / observes a sudden higher frequency of DL transmissions, the anchor UE may infer that this change is a result of insufficient or incomplete UL information being transmitted from some subset of devices in the cooperating UE group. The anchor UE may then preemptively attempt to compensate for this effect by providing more frequent UL data updates, such as more frequent pose and orientation information for a spatial and temporal set of FoV (e.g., the most recent spatial and temporal set) and / or more frequent and / or more redundant FoV updates. For example, the anchor UE may infer that a change in the amount of DL traffic may result in a corresponding necessary change in UL transmissions. The anchor UE may then preemptively attempt to request additional resources before needing them. The anchor UE may estimate the additional resources, for example, by calculating how much data it has in RLC and PDCP, and may scale this amount by some additional factor. In certain representative embodiments, the anchor UE may use a historical average and / or maximum value based on recent BSR reports, which may be triggered by the burstiness of DL traffic (e.g., amount) and / or by the duration of this burst in DL. In certain representative embodiments, the request for additional resources may be triggered based on one or more notifications / messages from within the cooperating UE group, for example, when another cooperating UE in the cooperating UE group receives data from an application layer.

[0208] In certain representative embodiments, the anchor UE may modify how it dynamically requests resources on behalf of a cooperating UE group based on certain DL signaling. For example, if the anchor UE determines / notes that dynamic grants issued by the NE / gNB frequently or periodically underestimate the allocated resources (e.g., required resources) for the cooperating UE group, the anchor UE may determine / decide that the BSR reporting for a certain device is inaccurate (e.g., due to link quality degradation and / or outage, among others) and may decide that the anchor UE may take over (e.g., solely take over) the BSR reporting duty for the cooperating UE group.

[0209] A cooperating UE may choose to take a certain action based on DL behavior. For example, a cooperating UE may choose to provide a CSI report if configured to do so, e.g., if the device receives a DL grant either from the anchor UE or directly from the NE / gNB. In certain representative embodiments, if a cooperating UE has not received DL data (e.g., any DL data) for a certain duration (which may be based on some threshold, for example), the device may decide / determine to provide a CSI report, e.g., so that the NE / gNB has accurate CSI information for the device.

[0210] In certain representative embodiments, certain characteristics of the buffer status of one or more UEs in a cooperating UE group may result in CSI reporting being provided to the NE / gNB and / or anchor UE, which may be based, for example, on (1) the size of the buffered data (e.g., the size of the buffer status may use, for example, an absolute size, a time-averaged size, a peak size, and / or a size relationship to some threshold, among others) and / or (2) the relative priority of the UL data (e.g., the number of LCGs).

[0211] Exemplary Procedure for a UE to Assist the Network in Scheduling DL Data Transmission for One or More UEs in a Group In certain representative embodiments, the anchor UE may assist the network in performing scheduling of data transmissions in DL to one or more UEs in a cooperating UE group. The anchor UE may provide such indications or assistance information based on knowledge of one or more factors / parameters including, for example, knowledge of data transmissions and / or receptions by / for UEs in the group, QoS information related to data flows in UL / DL, and certain application / higher layer information. The network may use the assistance information to determine when and how to schedule DL traffic destined for one or more UEs in the cooperating group. For example, the network may use the information / indications to determine whether to send dynamic grants in DCI to the anchor UE (e.g., targeted to the anchor UE or cooperating UEs) and / or directly to the cooperating UEs and / or whether to configure a new SPS, change parameters of a pre-configured SPS, and / or activate / deactivate any of the pre-configured SPSs for that UE.

[0212] In the case of a split rendering scenario where one or more UEs in a group may send data in the UL (e.g., pause / control data, video data) and receive data in the DL (e.g., pre-rendered video, haptic data) that may be associated with the UL data, the anchor UE may be aware of the data expected in the DL for one or more UEs, e.g., based on the data transmitted in the UL. The anchor UE may be aware of the timing of when data may be expected in the DL, e.g., based on RTT latency requirements associated with an application. The anchor UE may also be aware of DL traffic information expected to be received by one or more UEs in the group (e.g., in one or more data flows) based on the UL data transmitted by any of the UEs in the group. Information that may be known by the anchor UE per UE and / or per flow may include any one or more combinations of the following: data type (e.g., I-frame or P / B-frame, haptic data, video data, etc.), priority / importance and / or relative priority / importance of the data type (e.g., I-frame vs. P-frame), PDU payload size (e.g., average, minimum, maximum), number of PDUs per ADU / PDU set, number of data flows per UE, QoS of the data (e.g., PDB or PDU set delay bound, PER or PDU error rate), timing information (e.g., offset timeslot relative to a reference timeslot, time remaining), and / or Uu link measurements of member UEs (e.g., BWP, carrier, RSRP measurements of resource sets configured to member UEs).

[0213] Information (e.g., assistance information), instructions, and / or request messages that may be sent by the anchor UE to the network to assist in scheduling data transmissions in the DL, possibly at different granularities (e.g., per UE and / or per flow), may include any one or more combinations of the following: expected traffic information in the DL, adjustments to resource configuration, data consumption and / or processing delays at the anchor UE / cooperating UEs, prioritization information, data forwarding configurations, channel / link measurements, spatial attributes of the anchor UE / cooperating UEs, power saving configuration information of the anchor UE / cooperating UEs, and / or instructions to fall back to a default configuration.

[0214] For example, the anchor UE may provide information of expected data in DL for one or more UEs. Such traffic information may include any of payload size, data type, number of PDUs per PDU set, any changes to configured traffic parameters (e.g., periodicity, starting offset time slot), and any changes to jitter (e.g., jitter is greater / less than threshold or in / out of range). Such information may be provided, for example, based on data transmitted by either the anchor UE and / or cooperating UEs in UL.

[0215] In one example, the anchor UE may provide information regarding the remaining time or time window (e.g., start / end timeslots, duration) for DL ​​data, including one or more PDUs in one or more data flows, that are expected to be received by the anchor UE and / or cooperating UEs. Such information may be determined by the anchor UE based on tracking the RTT time with a timer, estimating the data type (e.g., I-frame or P / B-frame), number of PDUs per PDU set expected in DL during a given time window, etc.

[0216] As an example, the anchor UE may send an indication / request for a new resource configuration (e.g., SPS configuration, BWP, resource set, beam) and / or update / reconfigure any of the pre-configured resource configurations. In another example, the anchor UE may send a request to activate / deactivate any of the pre-configured resource configurations used for DL ​​reception at the anchor / cooperating UEs. The anchor UE may send an indication (e.g., via SL) to the cooperating UEs to perform reception and / or monitoring of a control channel (e.g., PDCCH) on the resource configuration associated with the member UE requested by the network by the anchor UE.

[0217] In an example where the anchor UE may be provided with information regarding SPS resources configured for cooperating UEs, the anchor UE may send an instruction to the network to change the offset time slot and / or increase / decrease the periodicity associated with the SPS resources for the cooperating UEs when it detects an increase / decrease in the RTT time (e.g., relative to an RTT time threshold) for data transmitted and / or received by the cooperating UEs and / or the anchor UE. Such a scenario may occur when the anchor UE transmits and / or receives data that may be associated with or synchronized with data transmitted and / or received by the cooperating UEs, for example.

[0218] As an example, the anchor UE may send indications / information to the network regarding consumption of data (e.g., in one or more flows) that may have been previously received and / or are expected to be received on the DL at one or more UEs in the cooperating group. Regarding consumption of data, the anchor UE may transmit information regarding any of the following: the rate of data consumption (e.g., the data rate at which the received data is sent to the upper layer / application), the amount of buffer maintained / available at the lower layer (e.g., LCH) and / or upper layer prior to consumption (e.g., number of PDUs, amount of payload relative to a threshold), the expected time to deplete the buffer amount, the expected amount of data rate that should be applied for DL ​​reception to maintain the buffer at the existing / expected level, and an indication of whether the buffer is empty / full (relative to a configured threshold).

[0219] In one example, the anchor UE may send indication / information of processing delays in any of the UEs that may affect receiver availability and / or duration to receive any DL data. Such processing delays in any of the UEs in the cooperating group may be due to i) processing of previous reception of DL data, ii) processing of data for the next transmission, iii) whether the UE may be performing any reception and / or transmission over SL such that any DL reception may not be possible for a certain duration, and iv) whether the UE may be performing channel / link measurements and / or processing of measurements such that any DL reception may not be possible. In some examples, the anchor UE may indicate to the network whether any measurement gap configurations are activated / deactivated in any of the UEs, which may prevent the UE from transmitting and / or receiving on any other channel for the duration of the measurement gap.

[0220] As an example, the anchor UE may send an indication to the network regarding a priority value to be applied when forwarding any of the DL data to one or more UEs in the cooperating group. The priority value may be indicated for any of the following data granularities: per PDU, per ADU / PDU set (e.g., including multiple PDUs), per data type (e.g., I / P / B frames, haptic data), and one or more data / QoS flows. In one example, the anchor UE may send an indication to prioritize DL data transmission to the anchor UE associated with a PDU set carrying P frame data compared to a PDU set carrying I frame data (e.g., the indication may indicate a higher priority value for a PDU set with P frame data compared to a PDU set with I frame data). For example, the anchor UE may send an indication regarding prioritization when indicating any new / updated priority value compared to the default configured priority value associated with the PDU, PDU set, data type, or data flow.

[0221] In another example, the anchor UE may send priority information regarding whether the Uu link or the SL should be used when any of the cooperating UEs may transmit any data / instructions to the network. For example, the anchor UE may send an instruction regarding link prioritization to the network to configure a higher priority for sending any data / instructions indirectly from the cooperating UE to the anchor via the SL compared to the priority value for sending the data / instructions directly via the Uu link. The network may configure link-related priority values ​​in the cooperating UEs to use and / or allocate resources (e.g., for the Uu link or the SL), for example, based on the configured priority values.

[0222] As an example, the anchor UE may be aware of one or more preferred data forwarding configurations for the member UEs to support any of the XR actions. This may include both CP and / or UP configurations (e.g., radio bearers, logical channels, links, etc.), and may include latency requirements, data rate requirements, reliability requirements, and / or absolute / relative priority requirements. In an example, the latency requirements for the member UEs may be expressed in terms of PDBs associated with IP packets / PDUs. In another example, the latency requirements may be expressed in terms of application delay budgets and / or frame delay budgets associated with frames (e.g., video / media frames). Similarly, in the case of reliability, in an example, the reliability requirements for the member UEs may be expressed in terms of packet error rates. In another example, they may be expressed in frame error rates or application error rates. In such a case, the anchor UE may inform the network about the forwarding configurations according to the preferences of the associated member UEs. The anchor UE may also perform translation between requirements expressed in different terms according to different member UE preferences in the group when coordinating downlink transmissions.

[0223] As an example, the anchor UE may send information / reports related to channel / link measurements made by any of the UEs in the cooperating group. The channel measurements sent by the anchor UE may include, for example, measurements performed by any of the UEs in the group on links / beams / channels associated via the Uu link (e.g., RSRP measurements) and / or SL (e.g., RSRP, Channel Busy Ratio (CBR) measurements).

[0224] In an example where one or more UEs in a cooperating UE group may be configured with a measurement threshold (e.g., an RSRP threshold), the anchor UE may send an indication when measurements made by the anchor UE or a cooperating UE on an associated channel are higher / lower than the measurement threshold (e.g., when measurements of a cooperating UE may be sent to the anchor UE via SL).

[0225] In another example, the anchor UE may send information / reports about any positioning measurements (e.g., PRS) and / or positioning RS transmissions (e.g., Sounding Reference Signals for positioning, SRSp) currently being performed or expected to be performed by any of the UEs in the group. Such information may be used by the network, for example, to determine if any prioritization may be done when scheduling data in the DL.

[0226] As an example, the anchor UE may send instructions to the network related to the movement / mobility (e.g., speed, direction) and / or spatial attributes (e.g., location, antenna orientation, UE viewport direction) of any of the UEs in the cooperating UE group. The anchor UE may send information regarding existing or expected changes to any of the UE's movement and / or spatial attributes (e.g., time slots when such changes may be expected at the UE). Such information regarding the movement / spatial attributes may be used by the network to determine, for example, how to schedule any of the resources, resource sets, or beams that may be used to send data to the UE in the DL.

[0227] As an example, the anchor UE may provide information related to any changes that may be performed by the anchor UE and / or cooperating UEs to any of the configured power saving schemes (e.g., CDRX / DRX configuration, PDCCH monitoring). Such changes may possibly include changes that may be performed autonomously and / or temporarily by any of the UEs in the UE group (e.g., the base station may not be aware of the changes), e.g., based on data transmitted in the UL and / or data expected to be received in the DL. An indication of information regarding the power saving schemes used by the UEs in the cooperating group may enable the network to schedule any of the DL receptions by the UEs by taking into account the QoS of the data (e.g., data rate and / or latency for receiving PDUs / PDU sets) and / or by achieving power savings at the UEs.

[0228] In one example, when the anchor UE decides to transition from using a power saving configuration (e.g., the anchor UE uses a CDRX configuration in which the anchor UE may receive data only during ON / active duration timeslots) to not using a power saving configuration (e.g., the anchor UE may receive UP data during all / any timeslots) or vice versa, the anchor UE may send an indication to the network informing the network of the transition. Similarly, the anchor UE may send an indication of such a transition to the network when it receives an indication of such a transition from a member UE (e.g., via SL) and / or detects such an expected transition (e.g., based on an indication from a higher layer / application).

[0229] In one example, the anchor UE may send an indication when either the anchor UE and / or the cooperating UEs change or expect to change (e.g., in any next duration / window) one or more of the power saving parameters, including those of the CDRX configuration (e.g., ON / active duration, inactivity timer duration, cycle duration) or PDCCH monitoring behavior (e.g., search space used for monitoring, core set / BWP used for monitoring).

[0230] As an example, the anchor UE may send an indication as to whether / when any of the UEs in the cooperating group may fall back and / or transition to using a default configuration. In one example, one or more cooperating UEs may be configured to monitor the PDCCH in a default search space and an alternative search space. In this case, the default search space may be intended to receive DCI associated with sparse resources (e.g., for low data rates or low periodicity DL reception), and the alternative search space may be intended to receive DCI for dense resources (e.g., for high data rates or high periodicity DL reception). An anchor UE that may recognize that a cooperating UE may switch from an alternative search space to a default search space may send an indication to the network indicating that the cooperating UE may switch to the default search space, possibly due to recognizing an expected data change in the DL. For example, a similar indication may be sent by the anchor UE to indicate that the UEs in the group may switch from an alternative CDRX configuration to the default configuration.

[0231] The anchor UE may send any of the above indications, assistance information, and / or requests to the network, for example, via RRC signaling (e.g., RRC reconfiguration request, RRC resume request), MAC CE, or UCI. The anchor UE may send any of the indications or assistance information periodically or based on detection of one or more triggering events / conditions. For example, trigger events that may be detected by the anchor UE to send any of the above indications / information may include a combination of one or more of the following: a change in data transmitted in the UL from UEs in the group (e.g., data type changes from I-frame to P / B-frame) and / or QoS applied when transmitting data in the UL (e.g., LCH parameters / priorities used when transmitting data in the UL change); detection / estimation of expected data in the DL of one or more flows of UEs in the group; a change in channel / link measurement (e.g., RSRP value of measurements made by cooperating UEs on CSI-RS associated with a configured resource set goes above / below a threshold); a change in movement / mobility (e.g., increase / decrease in speed or change in direction) or spatial attributes (e.g., change in location, antenna orientation, viewport direction) of one or more UEs in the group; and / or based on a timer / periodicity (e.g., the anchor UE may send an indication when a timer is started, e.g., when it detects an event, and / or when it expires. The anchor UE may possibly send the indication periodically based on a configured periodicity, e.g., using configured CG resources).

[0232] In one example, any of the above information, instructions, and / or requests that may be sent by the anchor UE may be sent directly to the network by one or more cooperating UEs, in some cases. Such direct instructions to the network may be sent by the cooperating UEs, in some cases, upon satisfying one or more trigger conditions detected by the cooperating UEs when processing the cooperation in the cooperating group. For example, conditions that may be monitored to make a decision on whether to send a direct instruction to the network or an indirect instruction via the anchor UE may include any one or more of the following: a comparison of latency (e.g., between direct and indirect transmissions, possibly considering whether ongoing resources are available or new resources may be required), a priority / importance of the data associated with the instruction, a priority value configured for the direct link (e.g., Uu link) and / or an indirect link (e.g., via SL), availability / priority of resources for transmitting data directly (on the Uu link using available CG) or indirectly (via SL using Mode 1 / Mode 2), and / or a measurement of the link state (e.g., Uu link state and / or SL state).

[0233] In one example, in any of the scenarios in which the anchor UE may send any indication / information to the network that may affect DL data reception at the anchor UE and / or one or more cooperating UEs, the anchor UE may also send corresponding indication / information to the cooperating UEs (e.g., via SL). Such indications may be sent, for example, via unicast, multicast (e.g., to multiple UEs in a UE group), or broadcast transmission to one or more UEs in a cooperating UE group. Such indications to the UEs in the group may, for example, indicate any changes to be made to the configurations applied for receiving either an existing or upcoming DL transmission.

[0234] Exemplary Procedure for a UE to Assist Other Co-Operating UEs in Receiving DL Data In one embodiment, the anchor UE may assist one or more cooperating UEs in being aware of upcoming DL scheduling so that data reception can be performed efficiently. Information and / or instructions that may be provided by the anchor UE to one or more cooperating UEs in the group may include any one or more of the following: resource configuration information, reception configuration, data / QoS related information, prioritization information, channel / link measurements, and / or instructions to fall back to a default configuration.

[0235] As an example, the instructions may include timing information on when to perform PDCCH monitoring for DL ​​data reception (e.g., start / stop offset time slots, duration / window). The instructions from the anchor UE may include, for example, the search space to be used (e.g., whether to use a sparse or dense search space for PDCCH monitoring).

[0236] The instruction may include configuration information (e.g., ID of the SPS configuration to use) and / or changes to parameters (e.g., starting offset timeslot, periodicity) associated with the SPS configuration for receiving periodic DL data. Such resource configuration information may be determined by the anchor UE based on data sent in the UL, for example.

[0237] In one example, the indication from the anchor UE may indicate whether to monitor the PDCCH for DCI or to use a pre-configured SPS to receive DL data.

[0238] As an example, the indication from the anchor UE may indicate which links, carriers, BWPs, and / or antenna ports to monitor for receiving control signaling or data in the DL.

[0239] In one example, the instructions may include an AS layer (eg, DRB, SRB) and / or NAS layer configuration to be used to receive and / or process DL data.

[0240] As an example, the indication from the anchor UE may indicate data / QoS related information for data expected in DL by the cooperating UEs. Such information may include, for example, any of the following: data type (e.g., I / P / B frame data), number of PDUs per PDU set, number of QoS / data flows, and QoS of the data (e.g., PDB / PDU set delay bound, PER / PDU set error rate, data rate).

[0241] In one example, the anchor UE may assist the member UE in converting from a common data forwarding configuration from the network to the member UE's preferred data forwarding configuration (e.g., reliability requirements may be expressed in terms of packet error rate in the network and application error rate at the member UE).

[0242] In one example, the anchor UE may indicate whether to receive data in a DL transmission over any configured resource set / BWP / channel / link (e.g., for a certain duration) or to drop reception. The cooperating UE may decide to enter a sleep mode (e.g., when configured in CDRX) upon receiving an indication to possibly drop data reception.

[0243] As an example, the indication from the anchor UE may indicate priority values ​​associated with reception of data (e.g., PDU set, QoS / data flow), resource configuration to apply (e.g., SPS configuration, dynamic grant configuration), configured interface to apply (e.g., Uu link, SL), and / or measurement configuration (e.g., RRM / CSI-RS measurements). The cooperating UEs may use the prioritization information received from the anchor UE to determine how to prioritize reception of DL data.

[0244] As an example, an indication from the anchor UE may indicate whether to perform CSI-RS measurements on the configured resource set. Such an indication may be sent by the anchor UE based on its own measurements (e.g., the measured RSRP on its own resource set is above / below a threshold).

[0245] In one example, the anchor UE may send an indication to the cooperating UEs to transmit a CSI report to the network. Such an indication may possibly be sent by the anchor UE based on detection of a change to a DL grant received by the anchor UE, e.g., by inferring a degradation in channel quality for the anchor UE and / or the cooperating UE from the change in the DL grant.

[0246] As an example, the indication from the anchor UE may indicate a fallback to a default configuration, including a default resource configuration (eg, a default SPS configuration), default PDCCH monitoring parameters / behavior (eg, default / initial BWP).

[0247] The anchor UE may send any of the above indications, information, and / or requests to one or more of the cooperating UEs, for example, via PC5-RRC signaling, SL MAC CE, or SCI (e.g., via the SL interface). Such indications may be sent to one or more UEs over the SL via unicast, multicast, or broadcast transmission. The anchor UE may send any of the indications / information periodically or upon detection of one or more triggering events / conditions, for example, similar to the triggering events described above for sending the indications / information to the network.

[0248] Exemplary Procedure for Using the Sidelink Interface in Cooperative Transmission / Reception In some embodiments, a WTRU may connect with one or more WTRUs in a cooperating WTRU group using a sidelink interface. From a connectivity perspective, leveraging the sidelink interface of one or more WTRUs involved in an XR experience for data transmission may reduce the load on the Uu link.

[0249] Bringing the coordination point locally to the anchor WTRU and communicating with other WTRUs in the vicinity using sidelinks may also enable fast and efficient discovery, connectivity, coordination, scheduling, data transmission, and data reception between multiple WTRUs that form part of one common XR application / service / experience, which may be located in the vicinity (e.g., within a set radius / perimeter measured in meters) of the anchor WTRU.

[0250] The coordination described herein may include any procedures, functions, and operations at one or more layers (e.g., access / RAN layer, NAS layer, application layer) that involve one or more WTRUs that may be associated with a common application / service (e.g., an XR application). For example, procedures and / or functions that may be performed cooperatively between WTRUs (and possibly coordinated by an anchor WTRU) may include discovery, WTRU selection, configuration, resource scheduling, power saving, link management (both SL and respective Uu link interfaces), etc. The sidelink interface may facilitate dynamically supported coordination between WTRUs in a WTRU group to ensure continuity of a user's immersive experience based on locally available information such as pause and (extended) FoV.

[0251] In an example embodiment, coordinated transmission for cooperating WTRUs over a sidelink interface may involve the use of one or more criteria similar to and / or overlapping with the criteria for coordinated transmission for cooperating WTRUs over a Uu interface. In one example, a WTRU may be able to perform coordinated transmission among multiple WTRUs when radio conditions (e.g., RSRP measurements) and load conditions (e.g., CBR measurements) over the SL interface and / or SL resource pool are below / above one or more configured thresholds (e.g., SL RSRP threshold, CDRX threshold).

[0252] Use of Sidelink Interface for Cooperative Transmission Once a sidelink is established between one or more WTRUs, either through solicitation or discovery, messages / indications / reports related to "XR actions" may be exchanged between the anchor WTRU and the cooperating WTRUs, including pause information and / or measurements / estimates related to FoV / extended FoV. Exchanges over the sidelink may also relate to measurements / estimates of radio link interfaces associated with any WTRU in the cooperating WTRU group (e.g., channel / load conditions on the sidelink channels). In an example embodiment, the cooperating WTRUs may send an indication when the quality / load of a channel used by the WTRUs (e.g., to perform one or more "XR actions") meets certain measurement criteria, such as RSRP / RSRQ / RRSI measurements of the channel (over the SL interface) and / or Channel Busy Ratio (CBR) of the channel over the SL interface going above / below respective thresholds and / or remaining above / below respective thresholds for a certain duration.

[0253] The exchange over the sidelink may include connection capabilities over the sidelink interface, e.g., number of carriers, bandwidth, WTRU antenna configuration, number of Tx / Rx antennas, transmission configurations supported over the sidelink interface, etc. In one example, such an exchange may be initiated by the anchor WTRU sending a request to the cooperating WTRU inquiring about connection capabilities over the sidelink interface. In another example, the capability exchange over the sidelink may include application layer information such as spatial capabilities of the WTRU (e.g., equipped with a camera, microphone, etc.) for evaluating potential engagement in one or more “XR actions.”

[0254] The sidelink interface may also be used to send user plane data and related status reports associated with one or more “XR actions” between two or more WTRUs in a WTRU group. Examples may include signaling or initiation or completion of an XR action and / or milestones of an XR action.

[0255] Mode 1 and Mode 2 Sidelink Transmission Cooperative transmission over the sidelink interface may be performed by Mode 1 and / or Mode 2. When operating in Mode 1, at least one WTRU in the WTRU group is within the coverage of the cell / gNB. Radio resources on the sidelink may be allocated from a carrier / bandwidth dedicated to communication on the sidelink or from a carrier / bandwidth sharing resources between SL link and Uu link communication. The sidelink radio resources may be configured such that Mode 1 and Mode 2 may share a resource pool or may use separate resource pools. In a cooperative WTRU group scenario, both Mode 1 and Mode 2 resource allocation techniques may be used, for example, to transmit data and / or control indications / messages between the anchor WTRU and the member WTRUs. A transmitting WTRU (e.g., anchor WTRU or member WTRU) may be configured to use Mode 1, Mode 2, or both simultaneously when performing SL transmissions to a receiving WTRU.

[0256] Although pool sharing may result in efficient use of resources, it may be prone to contention and subsequent contention resolution and thus may introduce additional delays in transmission. In some cases, the delay incurred from contention resolution may be tolerable such that the QoS requirements for XR traffic are still met. However, in other cases, contention resolution may adversely affect QoS. Thus, a WTRU may be configured with both Mode 1 and Mode 2 sidelink transmissions regardless of whether the WTRU may be in network coverage or not, whereby the WTRU may be able to evaluate which mode may be more appropriate (e.g., based on recognition of traffic from the XR application to be transmitted) and send an indication to the network (e.g., in the UCI) to inform the network of the selected operation mode so that the network can provision / allocate radio resources accordingly.

[0257] When configured with both Mode 1 and Mode 2, the WTRU may select Mode 1 for transmission of more important traffic with higher reliability. In one example, the WTRU may select Mode 1 and / or Mode 2 transmission based on the QoS marking of the data in its buffer. In another example, the WTRU may receive an indication of the importance of the data from its XR application, which may be indicated to the WTRU at different levels of granularity (e.g., per frame, and / or per group of frames, and / or per PDU set, and / or per group of PDU sets, etc.). Based on the indication from the application, the WTRU may evaluate whether the data is important enough (e.g., has an importance level above a preconfigured threshold sent by the gNB and / or a QoS marking above a certain rating). If the WTRU deems the data important enough to require a more reliable transmission method, the WTRU may select Mode 1 SL to have access to dedicated resources for transmission. Conversely, if the WTRU determines (based on thresholds from the network and instructions from the XR application in the WTRU) that the data is less important, the WTRU may select Mode 2 SL for transmission.

[0258] To enable the WTRU to evaluate which mode to use, the WTRU may receive different thresholds from the gNB. The thresholds may relate to Key Performance Indicators (KPIs) / parameters, such as quality of data, reliability for sending data, delay requirement for submitting data, etc. Each parameter may have one threshold or multiple (e.g., lower and upper) thresholds. In one example, the gNB may send one delay budget threshold to the anchor WTRU. When the anchor WTRU has data to transmit to a member WTRU over the sidelink, the anchor WTRU may evaluate the delay requirement of the data in its buffer (which may be received from the XR application that generates the data) against the delay budget threshold provided by the gNB. If the delay requirement of the data in its buffer exceeds the delay budget threshold, the WTRU may determine that the data may not need to be transmitted to the member WTRU within the strict latency requirement, and therefore additional delay due to any contention resolution may be acceptable. As a result, the WTRU may select Mode 2SL transmission. In another example, the WTRU may receive a threshold for QoS marking levels from the network. The WTRU may be configured to evaluate the QoS of the data in its buffer against a QoS threshold from the network. If the data QoS (on a PDU basis or on a PDU set basis or on a group of PDU sets basis or on a frame basis or on a group of frames basis) exceeds the QoS threshold from the network, the WTRU may determine that the data is critical and may need to be transmitted over dedicated resources, and therefore may select Mode 1 SL transmission to send the data to member WTRUs.

[0259] A WTRU (e.g., an anchor WTRU or a member WTRU) may also determine the sidelink transmission mode based on the type of frame to be transmitted. In one example, the WTRU may determine that I-frames may be transmitted via Mode 1 while P-frames may be transmitted via Mode 2. The WTRU may choose to always send I-frames via Mode 1 and P-frames via Mode 2, or only in some scenarios. In one example, such scenarios may be based on the coding scheme used. For example, if I-frames and P-frames are coded in separate flows (e.g., Group of Picture (GOP)-based coding scheme), the WTRU may always select Mode 1 for I-frame transmissions and Mode 2 for P-frame transmissions. On the other hand, if I-frames and P-frames are coded in the same flow (e.g., slice-based coding scheme), the WTRU may not want to separate I-frames from P-frames and therefore may select the sidelink transmission mode based on other parameters (e.g., frame importance or per-frame delay budget as mentioned above).

[0260] To enable the SL transmission mode on a frame type basis, the WTRU may need to know the type of frame generated by the XR application. The WTRU may receive an indication of the frame type (e.g., in the frame's header) and / or encoding type that may indicate to the WTRU that all frames / PDUs / PDU sets transmitted on a flow are of one frame type. The transmitting WTRU may proactively send an indication to the receiving WTRU of the type of transmission and the time and resources (e.g., carrier, BWP) on which the transmission should be monitored to avoid the receiving WTRU having to perform blind decoding.

[0261] Since requesting resources per TB (Transport Block) may introduce delays, Mode 1 may include a grant scheduling option configured to reduce delays by pre-allocating SL resources. In this scheme, the network may allocate a set of SL resources to the WTRU for transmitting several TBs. The anchor WTRU may send an indication / message (e.g., via RRC signaling) to the gNB on behalf of the member WTRUs with WTRU assistance information indicating information about expected SL traffic, e.g., TB periodicity, TB maximum size, QoS information, etc. The QoS information may include parameters / KPIs such as latency and / or reliability required by the TBs and their priorities. This information may be used by the gNB to create, configure, and assign to the member WTRUs a CG that meets the requirements of the SL traffic. The gNB may send an indication directly to the member WTRUs and / or to the anchor WTRU, which may then relay the information to the member WTRUs, to indicate the parameters of the new CG (e.g., CG index, time-frequency allocation, periodicity of the allocated SL resources, etc.).

[0262] Representative Procedures for Supporting Cooperative Transmission FIG. 5 is a flow chart illustrating an exemplary method according to one embodiment. For example, FIG. 5 may illustrate a method for supporting coordinated transmission for a group of UEs or WTRUs. In some embodiments, the method of FIG. 5 may be implemented, for example, by a WTRU. According to one embodiment, a WTRU that performs the method of FIG. 5 may be a first WTRU, e.g., an anchor WTRU, of a WTRU group that includes two or more WTRUs. In other exemplary embodiments, the method of FIG. 5 may be performed by other network nodes, entities, or elements.

[0263] According to some embodiments, the method may include, at 510, receiving configuration information from a network (e.g., a base station or gNB). For example, the configuration information may include or indicate WTRU identifiers (IDs) for one or more WTRUs in a WTRU group, one or more configured grants (CGs) associated with one or more WTRUs in the WTRU group, and a threshold. In one embodiment, the threshold may correspond to a jitter threshold or a time threshold corresponding to how much delay (e.g., a maximum amount of delay) can be tolerated by an application as a result of jitter. According to further embodiments, the threshold may correspond to a data volume threshold, which may correspond to an amount of data (e.g., a maximum amount of data) that can be tolerated in a given period of time.

[0264] In one embodiment, the method may optionally include receiving data from one or more applications, at 520. For example, the application may be, but is not limited to, an XR application, a VR application, or an AR application.

[0265] Based on a time at which the first WTRU receives data from the application for each WTRU in the WTRU group, the method may include determining respective timing information associated with actual reception of the data from the application and expected reception of the data. For example, the timing information may include a time difference between actual reception of the data from the application and expected reception of the data from the application. Additionally or alternatively, if the threshold corresponds to a data amount threshold, the method may optionally include determining an amount of data received within a certain time period.

[0266] It should be noted that in some embodiments, the "time" discussed herein, at least with reference to FIG. 5 (e.g., with reference to the time the first WTRU receives the data), may be a indicated time that corresponds to or may be measured in, for example, an absolute time, a relative time, a number of time slots, a symbol (e.g., a symbol duration), seconds, or milliseconds, etc.

[0267] According to one embodiment, the method may include determining whether the respective timing information exceeds a threshold, at 540. If it is determined that the respective timing information does not exceed the threshold, at 540, the method may include determining to transmit the data using a default CG configuration, at 550.

[0268] If the respective timing information is determined to exceed a threshold at 540, then based on the determined respective timing information, the method may include determining and / or selecting at least one respective CG from the one or more CGs for each WTRU in the WTRU group at 560. Additionally or alternatively, in an embodiment, if an amount of data received in a certain time period exceeds a threshold, the method may optionally include determining and / or selecting at least one respective CG (e.g., a change in resource grant configuration, such as a larger grant and / or a new offset) from the one or more CGs for each WTRU in the WTRU group based on the data amount threshold. For example, the determined and / or selected respective CG may include a preferred CG that would be preferred and / or requested by each WTRU in the group, or may be a preferred CG.

[0269] The method may then include, at 570, indicating the determined and / or selected at least one respective CG (e.g., a preferred CG) and the associated WTRU ID of the respective WTRU to a network (e.g., a base station or a gNB). For example, the preferred CG may be a CG requested by the WTRU from the network. In one embodiment, indicating 570 may include indicating the selected at least one respective CG (e.g., a preferred CG) using either RRC signaling, MAC CE, or UCI.

[0270] In one embodiment, the method may optionally include receiving, from the network, a resource grant determination based on the determination and / or the selected at least one respective CG (e.g., a preferred CG) for each WTRU in the WTRU group.

[0271] conclusion (1) "3 rd "3GPP TR 26.928, V16.1.0, December 2020," (2) 3GPP TR 28.928-Technical Specification Group Services and System Aspects; Extended Reality (XR) in 5G (Release 16) (V16.0.0), and (3) 3GPP TS 38.300-NR and NG-RAN Overall Description Stage 2 (V16.1.1), each of which is incorporated by reference in its entirety into this specification.

[0272] The systems and methods for processing data according to the exemplary embodiments may be performed by one or more processors executing sequences of instructions contained in a memory device. Such instructions may be read into the memory device from another computer-readable medium, such as a secondary data storage device. Execution of the sequences of instructions contained in the memory device causes the processor to operate, for example, as described above. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions to implement the invention. Such software may be executed on a processor housed remotely in a robotic assistance / apparatus (RAA) and / or another mobile device. In the latter case, data may be transferred, wired or wirelessly, between the RAA or other mobile device including the sensor and a remote device including a processor executing software to perform scale estimation and compensation as described above. According to other exemplary embodiments, some of the processing described above with respect to localization may be performed in the device including the sensor / camera, and the remainder of the processing may be performed in the second device after receiving partially processed data from the device including the sensor / camera.

[0273] Although the features and elements are described above in certain combinations, one skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in the WTRU 102, UE, terminal, base station, RNC, or any host computer.

[0274] Further, in the above-described embodiments, processing platforms, computing systems, controllers, and other devices including processors are described. These devices may include at least one central processing unit ("Central Processing Unit (CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to operations and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such operations and operations or instructions may be referred to as being "executed," "computer executed," or "CPU executed."

[0275] Those skilled in the art will appreciate that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals, and maintains the data bits in memory locations of a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be appreciated that representative embodiments are not limited to the above-mentioned platforms or CPUs, and that other platforms and CPUs may support the provided methods.

[0276] The data bits may also be maintained on a computer readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory ("RAM")) or non-volatile (e.g., read only memory ("ROM")) mass storage system readable by a CPU. The computer readable medium may include computer readable medium that resides exclusively on a processing system, or that is distributed, cooperative, or interconnected among multiple interconnected processing systems, which may be local or remote to a processing system. It will be understood that representative embodiments are not limited to the above-mentioned memories, and that other platforms and memories may support the described methods. It will be understood that representative embodiments are not limited to the above-mentioned platforms or CPUs, and that other platforms and CPUs may support the provided methods.

[0277] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0278] There is little distinction between hardware and software implementations of aspects of the system. The use of hardware or software is generally (though not always, in certain circumstances the choice between hardware and software may be significant) a design choice that implies a trade-off between cost versus efficiency. There may be a variety of vehicles (e.g., hardware, software, and / or firmware) on which the processes and / or systems and / or other techniques described herein may be affected, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0279] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. To the extent that such block diagrams, flow charts, and / or examples include one or more functions and / or operations, those skilled in the art will appreciate that each function and / or operation in such block diagrams, flow charts, or examples may be individually and / or collectively implemented by a wide variety of hardware, software, firmware, or substantially any combination thereof. Suitable processors include, by way of example, general purpose processors, special purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application specific integrated circuits (ASICs), application specific standard products (ASSPs), field programmable gate array (FPGA) circuits, any other type of integrated circuit (IC), and / or state machines.

[0280] The present disclosure is not limited in terms of the specific embodiments described in this application, which are intended as illustrations of various aspects. As will be apparent to those skilled in the art, many modifications and variations may be made without departing from the spirit and scope of the present invention. No element, operation, or instruction used in the description of this application should be construed as critical or essential to the present invention unless expressly set forth as such. In addition to those enumerated herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that the present disclosure is not limited to a particular method or system.

[0281] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, when referred to herein, "station" and its abbreviation "STA", "user equipment" and its abbreviation "UE" may mean or include (i) a wireless transmit and / or receive unit (WTRU) such as the described infrastructure, (ii) any of several embodiments of a WTRU such as the described infrastructure, (iii) a wireless and / or wired (e.g., tethered) device configured with some or all of the structure and functionality of a WTRU such as the described infrastructure, among others, (iii) a wireless and / or wired device configured with less than all of the structure and functionality of a WTRU such as the described infrastructure, or (iv) the like. Details of an exemplary WTRU that may represent any UE enumerated herein are provided below with respect to Figures 1A-1D.

[0282] In certain representative embodiments, some portions of the subject matter described herein may be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in whole or in part in an integrated circuit as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. In addition, those skilled in the art will recognize that the mechanisms of the subject matter described herein may be distributed as program products in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0283] The subject matter described herein may in some cases illustrate different components that are included within or connected to different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality may be achieved. Thus, any two components combined herein to achieve a particular functionality may be viewed as being "associated with" one another such that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated may be considered to be "operably connected" or "operably coupled" to one another to achieve the desired functionality, and any two components that can be associated in this way may be considered to be "operably couplable" to one another to achieve the desired functionality. Examples of operably connectable include, but are not limited to, physically interoperable and / or physically interacting components, and / or wirelessly interoperable and / or wirelessly interacting components, and / or logically interoperable and / or logically interacting components.

[0284] With respect to the use of substantially any plural and / or singular term herein, those of skill in the art may convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. For purposes of clarity, various singular / plural permutations may be expressly set forth herein.

[0285] In general, those skilled in the art will understand that the terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," and the term "includes" should be interpreted as "includes but is not limited to"). Those skilled in the art will further understand that where a specific number of recitations of the introduced claims are intended, such intent is expressly set forth in the claims, and in the absence of such recitation, no such intent exists. For example, where only one item is intended, the term "single" or similar language may be used. To aid in understanding, the following appended claims and / or the description herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as meaning that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim that includes such an introduced claim recitation to an embodiment that includes only one such recitation, even if the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations.In addition, even if a particular number of recitations in an introduced claim is explicitly recited, those of skill in the art will recognize that such recitation should be interpreted to mean at least the recitation number (e.g., the simple recitation "two recitations" without other qualifiers means at least two recitations, or more than two recitations). Furthermore, when a term similar to "such as at least one of A, B, and C" is used, such a structure is generally intended as a person of skill in the art would understand the term (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). When a notation similar to "such as at least one of A, B, or C" is used, such structure is generally intended as the skilled artisan would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of" followed by a list of items and / or a list of categories of items is intended to include "any of," "any combination of," "any more than one of," and / or "any more than one combination of" the items and / or categories of items, individually or in combination with other items and / or other categories of items.Further, as used herein, the term "set" or "group" is intended to include any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero.

[0286] Additionally, when features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual members or subgroups of members of the Markush group.

[0287] As will be understood by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein also encompass all possible subranges and combinations of subranges thereof. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, a middle third, an upper third, etc. Also, as will be understood by those skilled in the art, all words such as "up to," "at least," "greater than," "less than" and the like refer to ranges that include the recited numbers and that can be subsequently broken down into subranges as discussed above. Finally, as will be understood by those skilled in the art, a range includes each individual member. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so on.

[0288] Moreover, the claims should not be read as limited to the provided order or to the provided elements unless specifically so recited. In addition, the use of the term "means for" in any claim is intended to appeal to 35 U.S.C. ...

[0289] A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit / receive unit (WTRU), user equipment (UE), terminal, base station, mobility management entity (MME) or evolved packet core (EPC), or any host computer. The WTRU may be used in conjunction with other components, such as, for example, hardware and / or software implemented modules, such as a Software Defined Radio (SDR), a camera, a video camera module, a video phone, a speaker phone, a vibration device, a speaker, a microphone, a television transceiver, a hands-free headset, a keyboard, a Bluetooth module, a frequency modulation (FM) radio unit, a near field communication (NFC) module, a liquid crystal display (LCD) display unit, an organic light emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and / or a wireless local area network (WLAN) or an Ultra Wide Band (UWB) module.

[0290] Throughout this disclosure, those skilled in the art will appreciate that certain representative embodiments may be used in the alternative or in combination with other representative embodiments.

[0291] In addition, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable storage medium as instructions for execution by a computer or processor to perform the operations described above. Examples of non-transitory computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method performed by a first wireless transmit / receive unit (WTRU) of a group of WTRUs, comprising: receiving configuration information from a network indicating WTRU identifiers (IDs) for one or more WTRUs in the WTRU group, one or more configured grants (CGs) associated with the one or more WTRUs in the WTRU group, and a threshold value; determining respective timing information associated with actual and expected reception of the data from the application based on a time at which the first WTRU receives data from the application for each WTRU in the WTRU group; determining that the respective timing information exceeds the threshold; selecting at least one respective CG from the one or more CGs for the respective WTRU in the WTRU group based on the determined respective timing information; indicating the at least one selected respective CG and an associated WTRU ID of the respective WTRU to the network.

2. The method of claim 1 , wherein the indicating comprises indicating the selected at least one respective CG using any of RRC signaling, MAC CE, or UCI.

3. The method of claim 1 or 2, further comprising receiving, from the network, a resource grant determination based on the selected at least one respective CG for the respective WTRU in the WTRU group.

4. A method according to any preceding claim, wherein said timing information comprises a time difference between actual receipt of said data from said application and expected receipt of said data.

5. The method of any one of claims 1 to 4, further comprising receiving the data from the application.

6. The method of any one of claims 1 to 5, wherein the WTRU group includes at least one second WTRU.

7. The method of any one of claims 1 to 6, wherein the group of WTRUs comprises a group of cooperating WTRUs configured to support or associated with the application.

8. The method of any one of claims 1 to 7, wherein the threshold comprises a value corresponding to an amount of delay that can be tolerated due to jitter.

9. The method of any one of claims 1 to 8, wherein the application comprises an extended reality (XR) application.

10. The method of any one of claims 1 to 9, wherein the first WTRU comprises an anchor WTRU.

11. A method according to any preceding claim, wherein the at least one selected respective CG comprises a preferred CG requested from the network.

12. A first wireless transmit / receive unit (WTRU) of a group of WTRUs, the first WTRU comprising: a processor; and a transceiver operably coupled to the processor; The transceiver is configured to receive configuration information from a network indicating WTRU identifiers (IDs) for one or more WTRUs in the WTRU group, one or more configured grants (CGs) associated with the one or more WTRUs in the WTRU group, and a threshold value; The processor, determining respective timing information associated with actual and expected reception of the data from the application based on a time at which the first WTRU receives data from an application for each WTRU in the WTRU group; determining that the respective timing information exceeds the threshold; configured to select, for the respective WTRU in the WTRU group, at least one respective CG from the one or more CGs based on the determined respective timing information; The WTRU, wherein the transceiver is configured to indicate to the network the at least one respective CG selected and an associated WTRU ID of the respective WTRU.

13. The WTRU of claim 12 , wherein the transceiver is configured to indicate the selected at least one respective CG using either RRC signaling, a MAC CE, or a UCI.

14. The WTRU of claim 12 or 13, wherein the transceiver is configured to receive from the network a resource grant determination based on the selected at least one respective CG for the respective WTRU in the WTRU group.

15. The WTRU of any one of claims 12 to 14, wherein the timing information comprises a time difference between actual receipt of the data from the application and expected receipt of the data.

16. The WTRU of any one of claims 12 to 15, wherein the transceiver is configured to receive the data from the application.

17. The WTRU of any one of claims 12 to 16, wherein the WTRU group comprises a cooperating WTRU group configured to support or associated with the application.

18. The WTRU of any one of claims 12 to 17, wherein the threshold comprises a value corresponding to an amount of delay that can be tolerated due to jitter.

19. The WTRU of any one of claims 12 to 18, wherein the WTRU group includes at least one second WTRU.

20. The WTRU of any one of claims 12 to 19, wherein the application includes an extended reality (XR) application.

21. The WTRU of any one of claims 12 to 20, wherein the first WTRU comprises an anchor WTRU.

22. The WTRU of any one of claims 12 to 21, wherein the at least one selected respective CG comprises a preferred CG requested by the network.

23. A computer readable medium having stored thereon program instructions for carrying out the method of any one of claims 1 to 11.

Images