New radio (NR) augmented reality (XR)-method for ensuring round-trip delay of XR traffic

Abstract

A method performed by a wireless transmit / receive unit (WTRU) may include: receiving configuration information from a base station; receiving one or more uplink protocol data units (PDUs) from the application layer; determining a buffer delay for transmitting the one or more uplink PDUs in a resource associated with a configuration grant (CG) physical uplink shared channel (PUSCH) occasion; and transmitting an indication of a time offset for a time window under conditions that the buffer delay is greater than a delay threshold and there is no available resources associated with a semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) occasion within the time window. The method may also include transmitting the one or more uplink PDUs to the base station in a CG PUSCH occasion.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 396,016, filed on August 8, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] Extended reality (XR) may refer to various types of immersive experiences, including but not limited to: virtual reality (VR), augmented reality (AR), mixed reality (MR), and realities interpolated therein. VR is a rendered version of a delivered visual and auditory scene. The rendering may be designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimulation of the real world to the observer or user as naturally as possible as they move within the limits defined by the application. In AR, additional information or artificially generated items or content are provided to the user superimposed on their current environment. MR is an advanced form of AR in which some virtual elements may be inserted into the physical scene, aiming to provide the illusion that these elements are part of the real scene. XR may include all real and virtual combined environments, as well as human-computer interactions generated by computer technology and wearable devices.

[0004] In the context of XR applications and services, immersion can refer to the feeling of being surrounded by a virtual environment and providing a sense of being physically and spatially located in the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in a virtual reality that is virtually indistinguishable from actual reality.

[0005] XR devices may generally be associated with the ability to provide various degrees of spatial tracking. XR devices may be equipped with various sensors for implementing spatial tracking, such as monocular / stereo / depth cameras, radio beacons, GPS, and inertial sensors. Spatial tracking may be performed at different levels (e.g., 3 degrees of freedom (DoF) (i.e., rotational motion along the X, Y, and Z axes), 6 DoF (i.e., rotational motion and / or translational motion along the X, Y, and Z axes)). Spatial tracking may result in experiencing some form of interaction with virtual content. Users may perform actions in and / or interact with components within the extended reality. For example, actions and / or interactions may involve movement, gestures, and / or eye tracking. Spatial tracking is an important enabler for immersive XR experiences. For example, some form of head and / or motion tracking may ensure that the visual and audio components of the simulation from the user's perspective are updated to be consistent with the user's movements. Inaccurate and / or delayed spatial tracking may cause the user to feel uncomfortable and / or motion sickness. Summary of the invention

[0006] A method performed by a wireless transmit / receive unit (WTRU) may include: receiving configuration information from a base station; receiving one or more uplink protocol data units (PDUs) from an application layer; determining a buffer delay for sending the one or more uplink PDUs in resources associated with a configuration grant (CG) physical uplink shared channel (PUSCH) opportunity; and sending an indication of a time offset for the time window if the buffer delay is greater than a delay threshold and there are no available resources associated with a semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) opportunity within the time window. The method may also include: sending the one or more uplink PDUs to the base station in a CG PUSCH opportunity.

[0007] The configuration information may include at least one time offset in the time offset associated with the start of the time window. The configuration information may include the delay threshold. The configuration information may include one or more starting offsets associated with the time window. The configuration information includes a CG configuration and an SPS configuration. The CG PUSCH opportunity in the CG configuration may be time-aligned in the time window. The SPS PDSCH opportunity in the SPS configuration may be time-aligned in the time window. The time window may be a round-trip time (RTT) window. The indication may be sent in uplink control information (UCI). BRIEF DESCRIPTION OF THE DRAWINGS

[0008] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

[0009] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0010] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0011] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0012] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0013] Figure 2is a diagram illustrating an example of an interactive and segmented rendering scene;

[0014] Figure 3 is a diagram illustrating an example of a WTRU determining an alignment between a UL resource configuration and a DL resource configuration to satisfy an RTT delay; and

[0015] Figure 4 is a diagram illustrating an example of a WTRU determining timing for DL ​​reception to compensate for a higher than expected delay in the arrival of a PDU for UL transmission; and

[0016] Figure 5 is a flow chart illustrating an exemplary process performed by a WTRU. DETAILED DESCRIPTION

[0017] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ 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 discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0018] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the 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 (STA)) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0019] 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, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an evolved Node B (eNB), a Home Node B, a Home evolved Node B, a Next Generation Node B (such as a gNode B (gNB)), a New Radio (NR) Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0021] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over 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).

[0022] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), that may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication 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 (UL) Packet Access (HSUPA).

[0023] In an 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0024] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology (such as NR radio access) that may establish the air interface 116 using NR.

[0025] In an 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 together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0026] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies 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), and GSM EDGE (GERAN).

[0027] Figure 1AThe base station 114b in the 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 local area, such as a business location, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. 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 an 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 utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0028] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 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 described in detail in the specification, the CN 106 may be configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 and / or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] The CN 106 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 that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks 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 employ the same RAT as the RAN 104 or a different RAT.

[0030] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0031] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, 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 appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0032] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of 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), any other type of integrated circuit (IC), state machine, etc. The processor 118 may perform signal decoding, 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 Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0033] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV, or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0034] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, 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.

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

[0036] The processor 118 of the WTRU 102 may be coupled to and may receive user input 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 a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a 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, and a secure digital (SD) memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0038] The processor 118 may also be coupled to the 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 the 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 received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0039] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules 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 video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices and activity trackers, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and a humidity sensor, etc.

[0040] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0041] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

[0043] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

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

[0045] The MME 162 may be connected to each of the evolved Node-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

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

[0047] The SGW 164 may be connected to the 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.

[0048] 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 may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks and / or wireless networks owned and / or operated by other service providers.

[0049] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0050] In a representative embodiment, the other network 112 may be a WLAN.

[0051] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0052] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP may send beacons 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 dynamically set width. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (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.

[0053] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0054] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

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

[0056] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. 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 set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (which only supports a 1MHz operating mode) is transmitting to the AP, all available bands may be considered busy even if most of the available bands remain idle.

[0057] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0058] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0059] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 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 one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0060] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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 transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0061] 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 while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use 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 an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle 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 eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0062] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, interworking between DC, NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b and routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0063] Figure 1D The illustrated CN 106 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although the aforementioned elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0064] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 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.

[0065] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 106 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 106 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy implementation and QoS, and providing DL data notifications. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0066] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the 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 UPF 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 DL packets, and providing mobility anchoring, etc.

[0067] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the DNs 185a, 185b via the UPFs 184a, 184b via the N3 interfaces to the UPFs 184a, 184b and the N6 interfaces between the UPFs 184a, 184b and the local DNs 185a, 185b.

[0068] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a to 102d, base station 114a to 114b, evolved Node B 160a to 160c, MME 162, SGW 164, PGW 166, gNB180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0069] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. A simulation device may be directly coupled to another device for the purpose of testing and / or performing tests using over-the-air wireless communications.

[0070] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0071] The following abbreviations and acronyms appear in this document:

[0072] 6DOF 6 Degrees of Freedom

[0073] ACK

[0074] ADU Application Data Unit

[0075] AF Application Function

[0076] AR Augmented Reality

[0077] AS Access Layer

[0078] AT Note

[0079] BWP Bandwidth Part

[0080] BSR Buffer Status Report

[0081] CSI Channel State Information

[0082] CG Configuration Authorization

[0083] DG Dynamic Authorization

[0084] DL Downlink

[0085] DMRS Dedicated Demodulation Reference Signal

[0086] FDD Frequency Division Duplex

[0087] FoV

[0088] gNB gNodeB

[0089] FPS Frames per second

[0090] HARQ Hybrid Automatic Repeat Request

[0091] iBLER initial block error rate

[0092] LCP Logic Control Prioritization

[0093] LCH Logical Channel

[0094] MAC Media Access Control

[0095] MCS modulation and coding scheme

[0096] MT Mobile Termination

[0097] MTP Movement to Photons

[0098] NAS Non-Access Stratum

[0099] NACK Negative Acknowledgement

[0100] NW Network

[0101] PDB Packet Delay Budget

[0102] PDCCH Physical Downlink Control Channel

[0103] PDCP Packet Data Convergence Protocol

[0104] PDU Packet Data Unit

[0105] PER Packet Error Rate

[0106] PHY Physical Layer

[0107] PSG Power Saving Gain

[0108] PSR Grouping Power

[0109] PUCCH Physical Uplink Control Channel

[0110] PUSCH Physical Uplink Shared Channel

[0111] PDSCH Physical Downlink Shared Channel

[0112] QoE Quality of Experience

[0113] RLC Radio Link Control

[0114] RTT Round Trip Time

[0115] SDAP Service Data Adaptation Protocol

[0116] SR Scheduling Request

[0117] STD Standard Deviation

[0118] TDD Time Division Duplex

[0119] TE Terminal Equipment

[0120] TRP Send / Receive Point

[0121] UE User Equipment

[0122] UL Uplink

[0123] UPF User Plane Function

[0124] VR Virtual Reality

[0125] WTRU Wireless Transmit / Receive Unit

[0126] XR

[0127] An XR WTRU may correspond to any XR device and / or node. An XR WTRU may include a head-mounted display (HMD), optical see-through glasses and cameras for AR and MR, a see-through HMD, a mobile device with position tracking and a camera, and / or a wearable device. In addition, several different types of XR WTRUs are envisioned based on the functionality of an XR device, which includes a display, camera, sensor, sensor processing, wireless connectivity, XR / media processing, and / or power provided by one or more devices, wearable devices, actuators, controllers, and / or accessories. One or more XR WTRUs may be grouped into collaborative XR groups for supporting XR applications, experiences, and / or services.

[0128] In XR services and applications such as AR, VR, and cloud gaming, traffic may consist of data and PDUs that may be associated with an Application Data Unit (ADU) or a PDU Set. In XR services, PDUs belonging to a PDU Set may be associated with different spatial locations in a frame. For example, multiple PDUs in a PDU Set sent in the UL and / or received in the DL may carry data associated with FoV spatial locations in a frame. Similarly, other PDUs in a PDU Set may carry non-FoV spatial locations in a frame.

[0129] Figure 2 is a diagram illustrating an interactive and segmented rendering scene. Figure 2As shown, in an interactive and split rendering scenario, the XR WTRU 202 may send a set of PDUs (e.g., consisting of pose, gesture, video data) in one or more streams in UL 208a to the base station 204, and may receive an associated set of PDUs (video, audio, haptics) in different streams in DL 208b from the base station 204. Specifically, the set of PDUs received in DL 208b in response to the set of PDUs sent in UL 208a is expected to be within a strict RTT delay to ensure high QoE. The base station 204 may then receive and send data using the UPF / AF 206.

[0130] In XR services, RTT latency may be related to motion-to-photon (MTP) latency, which corresponds to the delay between the user's movement and the change in the device display reflecting the user's movement. The interdependencies and associations between PDUs in a set of PDUs sent in the UL and received in the DL may result in different challenges for ensuring that QoS in terms of RTT latency is met. In addition, a set of PDUs sent in the UL in one or more associated flows may be expected to be received by an application server (in the UL) and / or a WTRU (in the DL) within a synchronization time window.

[0131] Different PDUs in a PDU set may contribute to different user experiences and may be associated with different spatial and / or temporal importance values. RTT latency is typically measured from an application in a WTRU or server to another application in a different WTRU (e.g., between a UL PDU set and an associated DL PDU set). This association between the UL and DL PDU sets may not be visible to the base station. If scheduling of resources is performed without coordination and awareness of the association between UL data and DL data, it may be challenging to ensure that the RTT latency is achievable. Any fluctuations in RTT latency may adversely affect the QoE achievable at the WTRU. Because the WTRU may have visibility into the UL data and DL data and the PDU set (assuming that the WTRU is the source and destination of the data), a solution that utilizes a combination of lower layer mechanisms and application layer mechanisms at the WTRU to maintain QoE may be beneficial.

[0132] One problem to be solved in order to ensure a stable RTT and perform some adaptation when there may be changes in the RTT is how to efficiently handle data transmission in scenarios with variable traffic patterns in the UL and / or DL ​​and ensure predictable RTT delays.

[0133] In the embodiments described herein, the network may include any of a base station (e.g., gNB, TRP, RAN node, access node), a core network function (e.g., AMF), and an application function (e.g., edge server function, remote server function).

[0134] As described in embodiments herein, a flow may correspond to any of the following: a QoS flow or a data flow (e.g., a data flow consisting of one or more PDUs or sets of PDUs), which may be associated with one or more QoS requirements (e.g., latency, data rate, reliability, RTT latency). Different flows (which may originate from a common application and / or be intended for a common destination WTRU or group of associated WTRUs) may be referred to as associated flows or related flows.

[0135] In the embodiments described herein, the forwarding configuration may correspond to any of the following: radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs)), logical channels (LCHs), logical channel groups (LCGs), configuration parameters in various layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, other new protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), BWP, carriers, radio links / interfaces (Uu links, SLs), and radio resources (e.g., a collection of one or more frequency / time / space resources such as time slots, subcarriers, or beams). Radio resources may also be associated with configuration grants (CGs), dynamic grants (DGs), and / or any other resource grants or unauthorized resources.

[0136] In the embodiments described herein, the mapping configuration may correspond to any of the following: parameters and / or configurations associated with mapping from one or more application data (e.g., ADU) flows, QoS flows (e.g., associated or non-associated) to one or more radio bearers, SDAP, PDCP, LCH, carriers or component carriers (e.g., CC in a CA configuration), BWP, and radio links / interfaces (e.g., Uu link or side link), which can be used to deliver PDUs in the UL direction and / or DL ​​direction.

[0137] In the embodiments described herein, XR application-aware data transmission / reception or XR application-aware QoS processing may correspond to PDU sets or ADU processing. A PDU set (e.g., a media unit, a video frame) may include one or more PDUs. A PDU set may be associated with PDU set level QoS requirements (e.g., data rate, latency, error rate, reliability), which may apply to one or more or all PDUs associated with the PDU set. Different PDUs in a PDU set may be associated with respective PDU level QoS requirements. Such associations and interdependencies may be visible to the AS layer (e.g., with an association ID) and / or processed by the AS layer with association awareness during data transmission in the UL and / or data reception in the DL.

[0138] In the embodiments described herein, XR application-aware data transmission / reception or XR application-aware QoS processing may correspond to application / high-level importance / priority. Different PDUs in a PDU set or all PDUs in a PDU set may be associated with different application / high-level importance / priority values. Such high-level importance values ​​may correspond to spatial importance (e.g., the spatial position of a video frame carrying data by a PDU / PDU set, where a PDU or PDU set carrying a FoV spatial position may have a higher spatial importance than a non-FoV spatial position) or temporal importance (e.g., the temporal sequence of video frames carrying data by a PDU / PDU set, where a PDU or PDU set carrying a basic video frame such as an I frame may have a higher temporal importance than a differential video frame such as a P frame or a B frame). During data transmission and reception, such importance values ​​may be visible to the AS layer (e.g., with an associated ID / tag / indication), possibly implemented by application awareness.

[0139] In the embodiments described herein, XR application-aware data transmission / reception or XR application-aware QoS processing may correspond to QoS flow processing. The PDUs and / or PDU sets of an application may be encoded by the application and delivered by the application to the WTRU (in the UL) or the network (in the DL) via one or more QoS flows or data flows. At this point, different QoS flows carrying PDUs or PDU sets associated with the XR application may be visible to the AS layer (e.g., with an association ID) and / or processed at the AS layer, where the association is perceived during data transmission and reception.

[0140] Throughout the embodiments described herein, the WTRU actions that may be associated with application actions and / or AS layer actions for ensuring and / or supporting differentiated QoS may correspond to any of the following:

[0141] WTRU actions that may be associated with application actions and / or AS layer actions for ensuring and / or supporting differentiated QoS may correspond to determining metadata for an application (e.g., an XR application). For example, determining metadata may involve determining any of FoV / visual perimeter, 2D / 3D size, edges, spatial attributes, and / or FoV boundaries based on measurements of any spatial dimension, including but not limited to longitude, latitude, altitude, depth, roll, pitch, and / or yaw in one or more coordinate systems (e.g., Cartesian coordinate system, spherical coordinate system). Determining metadata may involve determining the quality of the FoV content, including whether the FoV content is of high quality (in the case of images, the FoV content may be quantified and evaluated by the image resolution (e.g., number of megapixel density)). Determining metadata may also involve determining the importance and / or priority of the FoV content. Importance may be associated with the spatial importance and / or temporal importance of the content / data. The spatial and / or temporal importance values ​​may indicate an absolute or relative importance associated with the FoV content. Spatial importance may be associated with one or more segments / tiles / slices / positions of the FoV in the spatial dimension. Temporal importance may be associated with one or more frames / subframes of the FoV in the temporal dimension.

[0142] WTRU actions that may be associated with application actions and / or AS layer actions for ensuring and / or supporting differentiated QoS may correspond to determining and / or generating application content. For example, determining application content may involve determining and / or capturing one or more 2D / 3D images and / or video frames associated with a FoV boundary, perimeter, and / or edge (e.g., defined by a WTRU or node for itself and / or on behalf of another WTRU or node based on FoV metadata). For FoV content mapping, the WTRU may use visual sensors (e.g., 2D / 3D cameras, lidar), RF sensors (e.g., RF transceivers, RADAR), and / or audio sensors (e.g., sonar) to determine images and / or video frames. Here, mapping of FoV may also be referred to as sensing of FoV content or capturing of FoV content. For example, determining application content may also include recording / capturing audio frames as part of a real environment or as part of an overlapping sound channel / audio file, where the audio file originates from a source outside the current real environment being mapped.

[0143] WTRU actions that may be associated with application actions and / or AS layer actions for ensuring and / or supporting differentiated QoS may correspond to performing measurements and reporting. For example, the WTRU may measure the posture (e.g., 6DoD / 3DoD orientation, location, position), rate of motion, and / or rate of movement of a user, a WTRU, and / or other objects (e.g., virtual objects or real objects) with which the user may interact. The WTRU may transmit and / or report posture measurement results to the network periodically or upon detecting an event trigger (e.g., a change in posture measurement above / below a threshold). For example, the WTRU may measure one or more of one or more reference signals (e.g., SSB, CSI-SR, PRS, sidelink RS), GNSS signals, unlicensed carriers, ultra-wideband signals, LIDAR signals, visual signals, etc. In another example, the WTRU may measure a radio link interface (e.g., Uu link, SL) associated with the WTRU. For example, a WTRU may trigger the transmission and / or measurement of a reference signal in one or more other WTRUs (eg, via a Uu link and / or a side link). The WTRU may send a measurement report to the network and / or to another WTRU.

[0144] WTRU actions that may be associated with application actions and / or AS layer actions for ensuring / supporting differentiated QoS may correspond to processing and / or forwarding data and / or PDUs or PDU sets and processing QoS associated with the PDUs or PDU sets. For example, the data may include any of media / image / video frames, sensor data, and / or measurement data (e.g., posture measurement results, link / channel measurement results) determined by the WTRU, which may be used to support application / service / network requests associated with the WTRU. For example, the WTRU may transmit data to or receive data from one or more destinations, the one or more destinations including a RAN node (e.g., a gNB), a CN function / entity, an application function (e.g., hosted in the WTRU or in the network). For example, the WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more forwarding configurations during transmission / reception.

[0145] The WTRU actions that may be associated with application actions and / or AS layer actions for ensuring and / or supporting differentiated QoS may correspond to processing and / or forwarding of information related to connectivity with the network and / or other WTRUs. Processing and / or forwarding of information related to connectivity with the network and / or other WTRUs may include, for example, sending capability information to the network, including the ability to support one or more service flows with different XR service patterns (e.g., periodic / aperiodic, PDU sets with variable payload sizes), the ability to perform application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements), and the ability to detect changes in service patterns. Processing and / or forwarding of information related to connectivity with the network and / or other WTRUs may also include sending inter-WTRU coordination capability information to the network, including the ability to support one or more interfaces, the ability to coordinate and / or interact with other WTRUs (e.g., via SL interfaces), which may or may not be co-located with the WTRU. Processing and / or forwarding of information related to connectivity with the network and / or other WTRUs may include receiving configuration information, including receiving RRC configuration from the gNB and / or receiving NAS layer configuration from the CN. The processing and / or forwarding of information related to the connectivity of the network and / or other WTRUs may include transmitting and / or receiving assistance data to and from the network associated with services, QoS, scheduling to support UL / DL transmissions. The processing and / or forwarding of information related to the connectivity of the network and / or other WTRUs may include transmitting requests for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

[0146] In one embodiment, the WTRU may be configured to flexibly update the mapping configuration and / or forwarding configuration, as well as the protocol stack including any new layer in the SDAP, PDCP, RLC, MAC, PHY and / or AS layers based on the detection of one or more configured trigger conditions.

[0147] A mapping configuration may be used to map PDUs and / or PDU sets with the same or different QoS requirements and / or characteristics received in one or more QoS flows to one or more forwarding configurations. Different forwarding configurations may be configured to implement and / or enforce different QoS when sending a PDU or a PDU set. In one example, a mapping configuration (e.g., at an SDAP) may be used to map PDUs in a PDU set received from an application in one or more QoS flows to one or more forwarding configurations (e.g., DRBs with a common / different PDCP entity). Forwarding configurations may be associated and / or grouped to implement and / or ensure PDU set level QoS. At the time of mapping, the configuration (e.g., priority, PDB) in the forwarding configuration used to implement / implement PDU level and / or PDU set level QoS may be applied to the PDU or PDU set in the buffer associated with the forwarding configuration.

[0148] The PDUs in different PDU sets to be received from the application in different QoS flows may have different expected QoS to be met during transmission. Based on the determination of the expected QoS of the PDU or PDU set received or to be received in the QoS flow, the WTRU may apply certain mappings and buffer and / or queue management mechanisms at one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC) so that the expected QoS of the PDU may be met during transmission and / or when received at the network. A similar approach may be applied when the WTRU expects to receive any PDU / PDU set in the DL from the network.

[0149] To meet the QoS requirements of a PDU or a set of PDUs, different layers in the forwarding configuration may be configured with different configuration parameters. For example, such configuration parameters may include support for AM / UM in RLC, LCP rules / restrictions at MAC and associated LCH parameters (e.g., PBR, BSD, priority), and the number of HARQ transmissions. To meet the QoS requirements, certain parameters may be configured in the PDCP (e.g., sequence number size, ROCH) and SDAP (e.g., mapping between QFI and radio bearers) sublayers.

[0150] Hereinafter, the term expected QoS may be used to refer to the expected margin of a particular QoS metric (e.g., latency, data rate, reliability) before a PDU or a set of PDUs arrives or when a PDU or a set of PDUs is received at the WTRU (e.g., the QoS to be achieved and / or implemented when transmitting). The expected QoS may correspond to a duration that may be used at the WTRU to forward the PDU on the Uu link. The expected QoS may also correspond to a time-to-live (TTL) (e.g., the maximum time available for processing and delivery) for different PDUs in a single PDU or a set of PDUs. In this case, the expected QoS may be determined based on indications and / or markings in the PDU (e.g., QFI, timestamp, and / or PDU set ID in the PDU header) and / or based on the use of a timer that may be set when receiving the PDU or a set of PDUs and reset / stopped when the configured duration expires. Similar mechanisms (e.g., based on indications / markers and / or timers) may be applied to change between different mapping and / or forwarding configurations to ensure the expected QoS.

[0151] In some examples, the expected QoS / TTL may be stricter or more relaxed than the default QoS metric associated with a PDU or set of PDUs. For example, if a PDU arrives late at the WTRU or the importance value of the PDU is indicated as high (e.g., above a threshold), experiencing more delay and jitter at the application layer (e.g., due to the encoder), the expected latency to be met by the PDU on the Uu link will be lower than the default PDB typically used to transmit the PDU. Alternatively, if the PDU arrives early or the importance value of the PDU is low (e.g., below a threshold), the expected latency on the Uu link may be considered more relaxed than the PDB typically used to transmit such PDUs.

[0152] The expected QoS may change dynamically based on the QoS experienced during reception and / or importance / priority indications, where for a fixed QoS (e.g., PBR, PDB), an increase and / or decrease in expected QoS prior to reception may translate into a decrease and / or increase in expected QoS on the Uu link.

[0153] In one embodiment, the WTRU may be configured to perform a 1:1, N:1, or N:M mapping from one or more QoS flows to one or more forwarding configurations to enable flexible utilization of radio bearers and resources while satisfying the QoS of a PDU or a set of PDUs.

[0154] In one embodiment, the WTRU may be configured to support and ensure that data transmission consisting of a PDU or a set of PDUs in one or more flows in UL and / or DL ​​is performed within the RTT delay value. The WTRU may support data transmission within the RTT delay and / or assist the network in ensuring the RTT during transmission based on any of the following: configuration, triggering events, conditions / criteria received from the network and / or application.

[0155] The WTRU may be configured with one or more conditions and / or configurations associated with the processing / operation of data / PDU or a set of PDUs to be sent to or received from the network. Such conditions and / or configurations may relate to or may reflect an expected QoS to be achieved during the transmission of the data / PDU or a set of PDUs to the network (e.g., in UL) or reception at the WTRU (e.g., in DL), meeting the RTT, or a change in such expected QoS.

[0156] When operating in a WTRU-based and / or WTRU-assisted mode associated with handling traffic / QoS during data transmission, the WTRU may support one or more procedures or functions for ensuring RTT. When ensuring RTT, the different modes for WTRU operation may include: (1) a WTRU-based mode and / or (2) a WTRU-assisted mode.

[0157] In WTRU-based mode, the WTRU may select and / or determine one or more configurations, parameters, and / or mechanisms to meet QoS requirements associated with XR application-aware data transmission and / or reception (e.g., in UL, DL, RTT) based on assistance information and / or configuration information received from the network. An example of configuration information received from the network is QoS rules that the WTRU uses to determine the QFI value associated with the data packet. The QoS rules may be received from the network in a PDU Session Establishment Response or a PDU Session Modification Command.

[0158] In WTRU-assisted mode, the WTRU may assist the network in selecting and / or determining one or more configurations, parameters, and / or mechanisms to meet QoS requirements associated with XR application-aware data transmission / reception (e.g., in UL, DL, RTT). Assistance may include providing assistance information and / or preferred configuration information to the network (e.g., preferred parameters to be supported in mapping / forwarding configurations). For example, the WTRU may provide such assistance information to the network in a PDU Session Establishment Request or a PDU Session Modification Request.

[0159] The WTRU may perform any of the following actions based on such conditions, configurations, and / or operating modes as described herein:

[0160] In one embodiment, based on the conditions / configurations / operations described herein, the WTRU may perform mapping of PDUs in a set of PDUs in one or more QoS flows to one or more resources or forwarding configurations. Resource configuration may include configuring authorized resources and / or dynamically granting resources. Such mapping may be performed based on the use of one or more configured mapping configurations (e.g., determining mapping configuration parameters, dynamic activation and / or deactivation) and other conditions, thresholds, and / or configurations described herein.

[0161] In one embodiment, based on the conditions, configurations, and / or operations described herein, the WTRU may determine and / or select a set of resources or forwarding configurations and / or parameters of resources and / or forwarding configurations to use for transmitting the PDUs in the set of PDUs. Such determination and / or selection may be performed based on the use of one or more configured forwarding configurations, associated parameters, and other conditions and / or thresholds and / or configurations described herein.

[0162] In one embodiment, the WTRU may transmit information associated with supporting XR / application awareness and / or QoS processing (e.g., association of PDUs with PDU sets, association between UL PDU sets and DL PDU sets, RTT latency) to the network, which may be used to enable the network to understand WTRU actions (e.g., transmission / reception of UP and CP data associated with XR services) and / or applications and / or QoS configurations / parameters supported by the WTRU.

[0163] Information associated with XR / application awareness may be transmitted by the WTRU to the network as at least one or more of the following message types: auxiliary information; preferred configuration information (e.g., preferred forwarding and / or resource configuration / parameters to be applied in UL / DL); status information and / or indications (e.g., associated with any AS layer in the AS layer); measurement / status reports (e.g., WTRU posture information, channel / link measurement results, buffer occupancy measurement results); and / or request and / or response messages.

[0164] The WTRU may transmit information periodically (e.g., using one or more configured periodicity values), periodically / dynamically (e.g., upon detection of a triggering event and / or condition as described herein), as an update message (e.g., upon detection of a change in previously transmitted information), and / or in a semi-persistent manner (e.g., transmitted at a periodicity value within a time window and / or duration). The WTRU may switch between a first periodicity value and a second periodicity value to transmit information, which may be based on the type of event detected (e.g., change in RTT). In another example, the WTRU may switch between periodically and aperiodically transmitting information based on whether any change and / or amount of change is determined in the transmitted / reported information.

[0165] The WTRU may transmit information and / or indications to the network via any of the following: RRC signaling and / or messages (e.g., via SRB1, SRB2, SRB3, SRB4); control PDUs associated with any AS layer in the AS layer (e.g., SDAP control PDU, PDCP control PDU); UL MAC CE (e.g., BSR, preemptive BSR, flexible BSR, which can be extended / adjusted by transmitting subsequent indications, possibly without canceling earlier BSRs); UCI (e.g., SR, feedback, ACK / NACK, CSI); PUCCH; PUSCH; non-AS (NAS) layer signaling (e.g., PDU session-related messages); application layer signaling / messages.

[0166] When the information and / or indication is transmitted to the network in a NAS message such as a PDU Session Establishment Request or a PDU Session Modification Request, the information / indication may be received by the SMF and used by the SMF to derive QoS rules and / or QoS profile for the PDU session. The SMF may also consider the PCC rules received from the PCF when deriving the QoS rules and QoS profile for the PDU session. The SMF may then forward the QoS rules to the WTRU in a PDU Session Establishment Response or a PDU Session Modification Command. The SMF may then forward the QoS profile to the base station in an N2 message. The QoS profile may be enhanced to include the information described below so that the network can better understand the applications / QoS configurations / parameters supported by the WTRU.

[0167] The information transmitted by the WTRU to the network may include identifiers and / or IDs. For example, the WTRU may transmit one or more IDs and / or indices, including any of the following: an ID associated with an application (e.g., application ID, service ID, session ID, application configuration ID); a group ID (e.g., associated with a group of QoS flows, a group of forwarding configurations, a group of devices / WTRUs); an ID of a single QoS flow, mapping configuration, forwarding configuration; a data type, a message ID (e.g., a PDU set ID, a PDU ID, an ID associated with pose information, FoV information, media / video frame information); and / or an association ID (e.g., an ID or sequence number indicating an association between one or more UL PDUs or PDU sets / streams and one or more DL PDUs or PDU sets / streams).

[0168] The information transmitted by the WTRU to the network may include the priority of the applications supported by the WTRU. For example, the WTRU may transmit the IDs of the supported applications and / or information about the relative and / or absolute priority values ​​associated with the supported applications.

[0169] The information transmitted by the WTRU to the network may include data flows associated with the applications. For example, the WTRU may transmit numbers and / or IDs associated with the data and / or QoS flows supported by each application. The WTRU may also transmit information about relative / absolute priority values ​​associated with the data and / or QoS flows of different applications supported.

[0170] The information transmitted by the WTRU to the network may include the devices associated with the application. For example, the WTRU may transmit the number of supported devices and / or associated IDs, and / or the association of devices for each application.

[0171] The information transmitted by the WTRU to the network may include data / traffic types associated with data flows per application. For example, the WTRU may transmit information about different data / QoS flows associated with an application, where the data types may include video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, haptic data, pose and / or positioning data, and / or audio data.

[0172] The information transmitted by the WTRU to the network may include traffic characteristics and / or parameters of data and / or services associated with data, QoS flows, and / or PDU sets per application. For example, the WTRU may transmit information about traffic characteristics and / or patterns of different data and / or QoS flows associated with an application, including whether the data is periodic, aperiodic, semi-persistent, quasi-periodic, etc. The traffic characteristics may include one or more periodicity values ​​for the flow.

[0173] For example, the WTRU may transmit information about the number of PDUs expected per PDU set in one or more flows per application. The information about the number of PDUs per PDU set may also include statistical and / or distribution information, such as average, minimum, maximum, and / or standard deviation values. The information related to the PDU set may include the size of the PDU set (e.g., total payload, number of PDUs in the PDU set), an indication of the start / first PDU and / or end / last PDU of the PDU set, and an indication of the association / dependency of the PDUs in the PDU set (e.g., ID of the PDU set, importance / priority value).

[0174] For example, the WTRU may transmit jitter related information in the UL and / or in the DL.Such jitter information, which may be transmitted on a per-flow, per-PDU-set, or per-PDU basis, may include a range, an average, a maximum, and a minimum value.

[0175] For example, the WTRU may transmit an indication upon detecting any change in the UL / DL traffic pattern (eg, change in periodicity, change in average payload size, change in jitter range).

[0176] For example, the WTRU may transmit information in the UL and / or DL ​​regarding traffic pattern predictions for upcoming data (eg, timing, size, importance of data to be received, uncertainty of the prediction, and / or confidence level).

[0177] In one example, the WTRU may transmit information regarding whether a PDU and / or a set of PDUs sent in the UL may be followed by ACK / NACK feedback indications, which the WTRU may expect to receive from the application layer (e.g., TCP, RTP) and / or lower layers (e.g., ARQ, HARQ) within a time window / duration after the UL transmission.

[0178] Similarly, the WTRU may transmit information about whether a PDU and / or a set of PDUs received in the DL may be followed by ACK / NACK feedback indications, and the WTRU may expect to send these ACK / NACK feedback indications to the application layer (e.g., TCP, RTP) and / or lower layers (e.g., ARQ, HARQ) within a time window / duration after the DL reception.

[0179] The information transmitted by the WTRU to the network may include buffer information at the application layer / higher layers / AS layer. For example, the WTRU may transmit information at the application regarding the amount of data payload or buffer levels (e.g., relative to one or more configured thresholds), including data waiting to be delivered to lower layers for UL transmission and data received in the DL that may be waiting to be consumed / exhausted / processed. For example, such buffer information may be reported based on an estimated or measured duration of data waiting in the buffer before being delivered to lower layers or consumed by the application. Such buffer information may be reported based on a data rate delivered to lower layers or a data consumption / exhaustion rate at higher layers (e.g., determined as a ratio of payload size to duration).

[0180] For example, the WTRU may transmit similar information about data payload amount or buffer level (e.g., relative to one or more configured thresholds) at a higher layer (e.g., NAS layer) and / or AS layer (e.g., in SDAP, PDCP, RLC, MAC, LCH, LCG).

[0181] The information transmitted by the WTRU to the network may include QoS requirements or expected QoS associated with the data. For example, the WTRU may transmit QoS requirements or expected QoS for one or more flows associated with an application, including data rate, latency, reliability, and / or absolute / relative priority values. Information about QoS requirements may also include statistical / distribution information, such as average, minimum, maximum, and standard deviation values.

[0182] The WTRU may also indicate that such QoS requirements or expected QoS may be supported at different QoS granularities, such as per PDU, per PDU subgroup (e.g., one or more PDUs) within a PDU set, per PDU set, per group of PDU sets, per flow, per session. The WTRU may also indicate a time window (e.g., start time, duration, end time) during which such QoS requirements or expected QoS may be applicable at different QoS granularities.

[0183] The information transmitted by the WTRU to the network may include RTT latency information. For example, the RTT latency information provided by the WTRU may include end-to-end latency (e.g., application in the WTRU to application in the server to application in the WTRU). For example, such RTT latency may include motion-to-photons (e.g., the delay between a user's movement and a change in a device display reflecting the user's movement), motion-to-audio, and motion-to-haptics. The RTT information may be provided by the WTRU at different granularities, including on a per-PDU, per-PDU set, per-flow, and per-session basis.

[0184] For example, the RTT latency information provided by the WTRU may include only latency components associated with over-the-air UL transmission and DL reception (e.g., over a Uu link) and / or latency in the network (e.g., upstream and downstream). Such RTT latency may or may not include latency at the application layer (e.g., processing latency, reproduction latency, encoding / decoding latency).

[0185] The information transmitted by the WTRU to the network may include stream synchronization. For example, the WTRU may transmit information about synchronization including the delay difference between one or more PDUs or sets of PDUs in one or more related streams of the same and / or different devices / users (e.g., visual-tactile synchronization delay, audio-tactile synchronization delay). For example, such synchronization delay difference may refer to the delay between the arrival of the last PDU in a set of PDUs in a first stream and the arrival of the last PDU in a set of PDUs in an associated second stream. For example, the WTRU may transmit information about synchronization including the delay difference between a unicast stream and a multicast stream (e.g., for 1-to-M interactions and N-to-M interactions).

[0186] The information transmitted by the WTRU to the network may include posture information (e.g., orientation, position / location). For example, the posture information may be associated with measurements in any spatial dimension (e.g., 6DoF, 3DoF), including but not limited to longitude, latitude, altitude, roll, pitch, and yaw in one or more coordinate systems (e.g., Cartesian coordinate system, spherical coordinate system).

[0187] In one example, the pose information transmitted by the WTRU may be associated with the orientation and / or position / location of the WTRU. The WTRU may also transmit information about the movement of the WTRU (e.g., movement rate expressed in linear movement (e.g., distance / second) or rotational movement (e.g., degrees / second)). The pose information may include uncertainty information (e.g., certainty or reliability in the predicted pose / movement).

[0188] The information transmitted by the WTRU to the network may include capability information associated with connectivity. For example, the information about interfaces may include the number and / or types of interfaces supported by the WTRU (e.g., NR Uu, NR SL, WLAN, Bluetooth). For example, the capability information about interfaces that may be supported by the WTRU and / or required for the WTRU to support any WTRU action / behavior may include any of the following: bandwidth, BWP, number of carriers, number of transmit antennas, number of receive antennas, etc.

[0189] The information transmitted by the WTRU to the network may include capability information associated with the WTRU action / behavior. For example, capability information related to WTRU actions (including visual sensing) that may be supported by the WTRU (e.g., a sensor, camera associated with the WTRU) and / or required by the WTRU may include any of the following: FoV resolution (e.g., megapixel count), rendering window (e.g., view-through ID), FoV size (e.g., 120 degrees), aperture size, shutter delay and start-up time, image quality (e.g., minimum / maximum range), zoom lens options, image stabilization, exposure settings, battery life, sound / audio, display standards (e.g., corrections applied to distortion and chromatic aberration), and the ability to merge overlapping frames from different angles (e.g., stitching frames from independent captures together for a panoramic image / video).

[0190] The information transmitted by the WTRU to the network may include preferred configuration information. For example, the WTRU may transmit one or more preferred mapping configurations, forwarding configurations, and / or resource configurations (e.g., CG, DG) to the network, including specific parameters associated with the forwarding / resource configurations, for supporting any WTRU actions that may be performed / supported by the WTRU and / or any other associated WTRUs.

[0191] The forwarding configuration transmitted by the WTRU associated with the supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include a latency requirement. In one example of a PDU, the latency requirement may be expressed in terms of a packet delay budget (PDB) associated with an IP packet / PDU. In one example of a PDU set, the latency requirement may be expressed in terms of a PDU set delay bound or frame delay budget associated with a PDU set (e.g., video / media frame).

[0192] The forwarding configuration transmitted by the WTRU associated with the supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include a data rate requirement (e.g., Mbps). In an example of a PDU, the data rate may be expressed in terms of a bit rate (minimum, maximum, average, guaranteed) associated with one or more PDUs (e.g., individual PDUs, groups of PDUs, bursts). In an example of a set of PDUs, the data rate may be expressed in terms of a bit rate (minimum, maximum, average, guaranteed) associated with one or more sets of PDUs (e.g., video / media frames).

[0193] The forwarding configuration transmitted by the WTRU associated with the supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include reliability requirements. In one example, reliability may be expressed in terms of packet error rate (PER). In an example PDU set, reliability may be expressed in terms of frame error rate or PDU set error rate.

[0194] The forwarding configuration transmitted by the WTRU associated with a supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include an absolute / relative importance / priority value associated with the UP / CP configuration (e.g., radio bearer, logical channel, link).

[0195] The forwarding configuration transmitted by the WTRU associated with the supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include an LCP configuration. For example, the WTRU may indicate LCP rules and / or restrictions (e.g., restrictions associated with mapping from DRBs and / or LCHs to configured resource grants) that may be applied to a set of forwarding / resource configurations (e.g., CGs), whether such LCP rules / restrictions may be temporarily changed over a period of time, conditional LCP configurations that apply when certain configured events are detected (e.g., a surge in the number of PDUs / data with high QoS requirements), fallback and / or default LCP configurations.

[0196] In one example, when transmitting a request related to a preferred configuration, the WTRU may associate weight / probability values ​​to different forwarding / resource configurations and / or indicate weight / probability values ​​to different forwarding / resource configurations. In this case, the weight / probability values ​​may be determined based on the likelihood of the configuration to be applied during the transmission and other application and / or AS layer information and / or indications. The network may use such weight and / or probability information to determine and provide to the WTRU a combined configuration and / or for activation and / or deactivation of a configuration that may match the weight value indicated by the WTRU.

[0197] The information transmitted by the WTRU to the network may include an indication for activating and / or deactivating a configuration. For example, the WTRU may transmit an indication to the network to request activation and / or deactivation of mapping, forwarding, resources and / or configuration, and / or parameters associated with the configuration (which may be pre-configured in the WTRU). The WTRU may include the ID of the configuration and / or parameter when sending the request indication. In one example, the request to activate / deactivate a configuration may be accompanied by information about the WTRU action (e.g., splitting / merging QoS flows / PDU sets / PDUs).

[0198] The information transmitted by the WTRU to the network may include measurement results related to the application and / or AS layer. For example, the WTRU may transmit RSRP measurement results, RSRQ measurement results, RSSI measurement results of signals, channels, radio links, carriers, etc. that may be associated with one or more WTRU actions. For example, the WTRU may transmit posture and / or positioning measurement results (e.g., location information, posture in 6DoF, rate of user / WTRU movement / movement). For example, the WTRU may transmit measurements and / or estimates related to RTT / MTP, application buffer level, buffer exhaustion time, exhaustion rate. For example, the WTRU may transmit QoS-related measurements related to the number of PDUs or PDU sets that may be received within a period of time, changes in QoS (e.g., data rate, latency, increase / decrease in reliability), the life time associated with the PDU or PDU set, and the remaining time for delivering the PDU or PDU set.

[0199] Information transmitted by the WTRU to the network may include uncertainty information. For example, for any information transmitted / reported by the WTRU, including application layer information (e.g., posture information, QoS flows, MTP latency) and AS layer information (e.g., preferred forwarding configuration, RTT latency), the WTRU may also transmit the uncertainty associated with the information. In one example where the WTRU may perform a prediction or estimation of a parameter (e.g., RTT latency), the WTRU may indicate to the network the uncertainty associated with the estimation / prediction.

[0200] The embodiments described herein and below may use one or more of the above descriptions (eg, assistance information, preferred configuration) transmitted by the WTRU to the network.

[0201] In one embodiment, the WTRU may receive configuration / assistance information that enables the WTRU to support any processes, mechanisms, rules, actions, etc. associated with ensuring RTT latency during UL transmission and / or DL ​​reception of data / PDU or PDU sets in one or more data and / or QoS flows.

[0202] The WTRU may receive configuration and / or assistance information from the network periodically (e.g., with one or more configured periodic values), aperiodically / dynamically (e.g., status indication / information or request / request messages), and / or semi-persistently (e.g., transmitted with a periodic value within a time window / duration).

[0203] The WTRU may receive configuration and / or auxiliary information via any of the following: RRC signaling and / or messages (e.g., dedicated / unicast signaling, broadcast / SIB); control PDU associated with any AS layer in the AS layer (e.g., SDAP control PDU, PDCP control PDU); DL MAC CE; DCI; PDCCH; PUSCH; non-AS (NAS) layer signaling (e.g., PDU session establishment response or PDU session modification command); application layer signaling / messages.

[0204] The configuration and / or assistance information that the WTRU may receive from the network may include one or a combination of the following:

[0205] Configuration and / or assistance information that may be received by the WTRU from the network may include mapping, forwarding and / or resource configuration and / or parameters. For example, the WTRU may receive one or more configurations and / or configuration parameter sets to apply to different layers of the AS protocol stack (e.g., RRC, SDAP, PDCP, RLC, MAC, PHY, or any new layer).

[0206] Configuration parameters to be applied at different layers may include: (1) SDAP / PDCP; (2) PDCP; (3) RLC; (4) MAC; and (5) PHY.

[0207] SDAP / PDCP parameters may be one-to-one, one-to-M, or N-to-M mapping configurations, flags, indications, IDs to be applied (e.g., associated with processing QoS flows, PDU sets, association information between UL PDUs or PDU sets and DL PDUs or PDU sets), and / or ranges of values ​​associated with importance / priority information to be identified in PDUs or PDU sets. SDAP / PDCP mapping configurations may refer to information used to map packets at the SDAP layer to PDCP entities and / or sublayers. PDCP parameters may be IDs and sequence numbers to be applied, RoCH configurations, security / encryption parameters, and / or packet duplication configurations. RLC parameters may be parameters for AM / UM / TM operations. MAC parameters may be LCH parameters (e.g., priority, PBR, BSD at PDU and / or PDU set level), LCP configurations (e.g., rules / restrictions / policies for PDU and / or PDU set level processing, duration of switching between different LCP rules / policies), and / or configurations for multiplexing / assembly. PHY parameters may be MCS and / or HARQ configurations.

[0208] For example, the WTRU may receive one or more resource configurations, including: (1) configured granted resources / configuration for UL data transmission; (2) semi-persistent scheduling (SPS) resources / configuration for DL ​​data reception; (3) dynamic granted resources for UL data transmission (e.g., triggered by UCI, SR, BSR, MAC CE); and / or (4) dynamic scheduled resources for DL ​​data reception (e.g., triggered by DCI, PDCCH, MAC CE).

[0209] Parameters associated with CG resources / configuration may include periodicity, starting offset, duration, BWP, parameter set / SCS value, number of PRBs, number of opportunities, number of PUSCH time slots per opportunity, maximum number / duration / length of PDSCH, one or more MSC values ​​for authorization, antenna ports, etc. Parameters associated with SPS resources / configuration may include periodicity, starting offset, duration, BWP, parameter set / SCS value, number of PRBs, number of opportunities, number of PDSCH time slots per opportunity, maximum number / duration / length of PDSCH, one or more MCS values ​​for authorization, antenna ports, etc.

[0210] The WTRU may receive at least one set of configuration parameters associated with a default configuration, which may be activated and / or used during a normal scenario for sending / receiving data. The WTRU may also receive another set of configuration parameters associated with abnormal operation, which may be activated and / or used when any of the triggering events and / or conditions described herein are detected.

[0211] The WTRU may receive default priority values ​​associated with a resource configuration (e.g., a CG). For example, a first resource configuration may be associated with a first priority value and a second resource configuration may correspond to a second priority value. The first resource configuration and the second resource configuration may be associated with the same application, and for a PDU or a set of PDUs using the first resource configuration and the second resource configuration during transmission, the first set of priority values ​​may be intended to achieve default QoS performance (e.g., default latency, default RTT, default data rate), and the second set of priority values ​​may be intended to achieve abnormal QoS performance (e.g., surge / burst data rate, very low latency, very low RTT).

[0212] Configuration and / or assistance information that may be received by the WTRU from the network may include AS layer status information and / or indications. The AS layer status information / indications may include identifiers / IDs. For example, the WTRU may receive information about one or more IDs applied during transmission / reception, including any of the following: (1) WTRU ID, such as C-RNTI, I-RNTI, NAS ID, TMSI / IMSI; (2) ID associated with the application (e.g., application ID, service ID, session ID, application configuration ID); (3) group ID (e.g., associated with a group of QoS flows, a group of forwarding configurations, a group of devices / WTRUs); (4) ID of a single QoS flow, mapping configuration, forwarding configuration; (5) data type / message ID (e.g., PDU set ID, PDU ID); (6) resource configuration ID (e.g., CG ID, SPSID).

[0213] AS layer status information and / or indications may include the status of the forwarding / resource configuration. For example, when one or more forwarding / resource configurations are used, the WTRU may receive information about the achieved / achievable QoS (e.g., RTT latency). For example, when sending and / or receiving data and / or PDUs or PDU sets, such information may be received by the WTRU in terms of data rate, latency (e.g., expected latency, remaining latency), RTT latency, reliability, achievable and / or achieved priority. The WTRU may also receive statistical / relative / absolute information associated with the achieved / achievable QoS in terms of mean, maximum, minimum and / or standard deviation.

[0214] AS layer state information and / or indications may include flow control. For example, the WTRU may receive explicit or implicit flow control indications from the network indicating whether to start, increase, decrease, pause and / or stop the transmission of a PDU or a set of PDUs (to achieve the indicated transmission rate, latency, RTT delay, reliability aspects in one or more forwarding configurations).

[0215] Configuration / assistance information that may be received by the WTRU from the network may include validity information. For example, the WTRU may receive validity information associated with forwarding and / or resource configurations, indicating whether and / or when the configuration may be considered valid or invalid based on one or more of triggering events and / or conditions. The WTRU may also receive information about whether the configuration will be deactivated and / or released when it is determined that the configuration is invalid. For example, the WTRU may receive information about whether the configuration will be considered valid / invalid based on the RRC state of the WTRU (e.g., CONNECTED, INACTIVE, IDLE) and / or when transitioning between different RRC states.

[0216] Configuration and / or assistance information that may be received by the WTRU from the network may include thresholds. One threshold may be a buffer occupancy threshold. For example, the buffer occupancy threshold associated with any of the forwarding configurations may indicate a maximum / minimum amount (e.g., in terms of total payload size / volume) of data / PDUs or sets of PDUs that may be included in a buffer (e.g., an application layer buffer, an AS layer / LCH buffer).

[0217] Another threshold may be a PDU or PDU set payload size. For example, the payload size threshold may be associated with one or more upper and / or lower values ​​corresponding to the total size (e.g., in bits or bytes) of the payload of one or more PDUs or PDU sets. In another example, the payload size threshold may be associated with one or more upper and / or lower values ​​corresponding to the total number of PDUs in a PDU set.

[0218] Another threshold may be the RTT delay. The RTT delay threshold may be associated with one or more upper and / or lower limits corresponding to the maximum and / or minimum RTT delay values. Such RTT delay thresholds may be intended to identify and / or determine the maximum and / or minimum RTT delay tolerated by the network, application, and / or WTRU. The RTT delay may be the result of delays due to processing, jitter, transmission, and / or congestion.

[0219] Another threshold may be an RTT difference threshold. For example, the RTT difference threshold may be associated with one or more upper and / or lower limit values ​​corresponding to the difference between a first RTT delay value (e.g., a default RTT delay) and a second RTT delay value (e.g., a new and / or modified RTT delay value).

[0220] Another threshold may be an expected threshold time value. For example, the WTRU may receive one or more of an expected threshold time value or an expected time of arrival (ETA) threshold corresponding to an expected time for receiving a PDU or a set of PDUs in a data stream, where the PDU may be the first and / or last PDU associated with the set of PDUs or any subsequent PDU after receiving an earlier PDU.

[0221] In another example, the ETA threshold may be associated with an expected delay of receiving and / or sending a second PDU or set of PDUs after a first PDU or set of PDUs having a first delay value. In one example, the second PDU may correspond to a last PDU in the set of PDUs.

[0222] In another example, the ETA threshold may be associated with an expected latency of receiving and / or sending a PDU or set of PDUs in a second associated data and / or QoS flow after receiving and / or sending a PDU or set of PDUs in a first data / QoS flow having a first latency value.

[0223] In another example, the ETA threshold may be associated with a duration or time value. For example, the WTRU may start a timer at a time instance of receiving / sending a first PDU and stop the timer when the timer expires at a time instance corresponding to the threshold time value and / or when a second PDU is received and / or sent (e.g., the first PDU and the second PDU may be associated with the same PDU set).

[0224] Another threshold may be an expected data rate (EDR) threshold. For example, the WTRU may receive one or more expected data rate (EDR) thresholds associated with a data rate expected for receiving / sending a PDU or a set of PDUs in one or more data / QoS flows. The data rate may correspond to any of the following units: PDU or PDU set per second, frame per second, and / or bit / byte per second.

[0225] In another example, the EDR threshold may be associated with an expected data rate for a second PDU / set of PDUs after receiving / sending a first PDU and / or set of PDUs having a first data rate value. In another example, the EDR threshold may be associated with an expected data rate for a PDU or set of PDUs in a second associated data / QoS flow after receiving / sending a PDU or set of PDUs in a first data and / or QoS flow having a first data rate value.

[0226] Another threshold may be an expected reliability threshold. For example, the WTRU may receive one or more expected reliability (EER) thresholds associated with the reliability expected for receiving a PDU or a set of PDUs in one or more data and / or QoS flows. The reliability value may correspond to a packet error rate, a frame / PDU set error rate, and / or an error probability.

[0227] In another example, the EER threshold may be associated with an expected reliability of a second PDU / set of PDUs after receiving / sending a first PDU / set of PDUs having a first reliability value. In another example, the EER threshold may be associated with an expected reliability of a PDU or set of PDUs in a second associated data / QoS flow after receiving and / or sending a PDU or set of PDUs in a first data and / or QoS flow having a first reliability value.

[0228] Another threshold may be a pose difference threshold. For example, the pose difference threshold may correspond to the difference between the pose information measurement results of the first time instance and the second time instance, where the time instance may correspond to any one of the following units: time slot, symbol duration, SFN, and seconds / milliseconds.

[0229] Another threshold may be a WTRU mobility threshold. For example, the WTRU mobility threshold may correspond to a difference between a position or rotation angle of the WTRU between a first time instance and a second time instance, where these time instances may correspond to any of the following units: time slots, symbol duration, and / or SFN, seconds and / or milliseconds.

[0230] Another threshold may be a correlation time window. For example, a correlation time window may correspond to the minimum time difference between two triggering events (e.g., posture information measurement, QoS event), where the two events may be considered to be related to each other when they occur within the correlation time window. When the two events occur at time instances outside the correlation time window, they may be considered to be independent. In one example, the WTRU may use the correlation time window to determine whether to transmit an indication to the network (e.g., indicating a change in RTT latency, a change in WTRU location / movement, or a change in QoS).

[0231] The embodiments described herein and below may use one or more of the above-mentioned configuration / assistance information received by the WTRU from the network.

[0232] The WTRU may be configured with one or more events and / or conditions associated with triggering one of the above-mentioned WTRU actions, including transmitting auxiliary information / indications to the network, receiving configuration and / or auxiliary information from the network, transmitting indications and / or requests for changing resource configurations, and transmitting indications and / or requests for changing forwarding configurations.

[0233] Such triggering events and / or conditions may be related to ensuring that the RTT latency and / or the expected RTT latency is met when sending and / or receiving a PDU or a set of PDUs in one or more associated QoS flows. Such triggering events and / or conditions may specify whether the WTRU can perform an action and which action can be performed. Such triggering events and / or conditions may specify when (at what moment) the WTRU performs an action (i.e., any of the events, conditions and / or criteria described herein are met). For example, the WTRU may determine and / or select a resource configuration (e.g., CG, SPS, DG) for meeting the expected RTT based on the detection of one or more triggering events and / or conditions. Such conditions may be based on one or more of the following:

[0234] Such triggering events and / or conditions may be based on indications and / or information from the network. For example, the WTRU may receive indications and / or information from the network (e.g., gNB) regarding the expected / achievable RTT for transmission and / or reception over the Uu link (in UL and / or DL). This information may be received semi-statically, dynamically, and / or during or at the time of configuration. For example, the WTRU may trigger actions described herein (e.g., determining and / or selecting a mapping, forwarding, or resource configuration) based on indications and / or information received from the network.

[0235] For example, the expected and / or achievable RTT may be indicated on a per PDU, per PDU set, per QoS / data flow, per forwarding configuration, and / or per resource configuration basis. In another example, the WTRU may implicitly receive information about the expected and / or achievable RTT from the network based on one or more of the following: the number of times HARQ feedback is received, the size and / or timing of allocations for resource grants (e.g., configuration grants, dynamic grants, etc.), the allocation of retransmission grants corresponding to one or more forwarding configurations (e.g., LCH / DRB / BWP), and / or de-prioritization of PUSCH / grants for one or more LCHs due to intra-WTRU / inter-WTRU prioritization.

[0236] For example, when an indication is received from the network (e.g., in an RRC, MAC CE, other control PDU, or DCI), the WTRU may be triggered to perform any of the above WTRU actions. The indication received by the WTRU may be related to a change and / or update in forwarding and / or resource configuration at the WTRU and / or an expected RTT associated with one or more PDU sets and / or QoS flows.

[0237] Such triggering events and / or conditions may be based on indications and / or information from the application and / or higher layers. For example, upon receiving an indication from the application / higher layers, the WTRU may perform any of the WTRU actions. Such indications may include information about changes in traffic characteristics / patterns associated with generating / processing / receiving PDUs or sets of PDUs in one or more QoS / data flows. For example, an application hosted in the TE portion of the WTRU may transmit the indication in an AT command to the MT portion of the WTRU.

[0238] In one example, an application may indicate to the WTRU information regarding: an expected number of QoS flows that may be associated with the application, an expected number of PDUs per PDU set, an expected frame / PDU set in a subsequent time instance (e.g., the next frame generation instance), an expected change in importance / priority distribution of generated PDUs, an expected increase / decrease in latency (e.g., due to processing at the codec / application), an expected increase / decrease in RTT, and / or jitter for delivering a PDU or PDU set in the UL and / or DL, an expected change in the time to live associated with a PDU or PDU set, and / or an expected change in WTRU or user motion or movement (e.g., an increase or decrease in motion rate).

[0239] For example, the WTRU may receive an indication from an application and / or higher layers indicating the arrival of one or more PDUs or sets of PDUs (e.g., in batches / bursts) from an application in the WTRU (for UL) or from an application in the network (in DL). Information about the arrival of a PDU or set of PDUs may include, for example, an expected timing (e.g., timeslot / frame) of generation of the PDU / set of PDUs at the application and / or an expected timing of reception at the WTRU. Such information may be indicated to the WTRU via a timestamp and / or a sequence number.

[0240] For example, the WTRU may be triggered to perform any of the WTRU actions based on an indication of the importance or priority of sending a PDU or set of PDUs. Upon receiving an indication containing an importance / priority value above a threshold, the WTRU may trigger an action (e.g., changing forwarding / resource configuration) for sending a possibly delayed PDU with compensation (e.g., low latency).

[0241] Such triggering events and / or conditions may be based on buffer status and load at a forwarding configuration (e.g., DRB / LCH). Such buffer status may include at least a condition (e.g., compared to a threshold) associated with any of the following measurements or combinations of measurements: (1) the amount of PDUs or PDU sets that may be in one or more buffers associated with the forwarding configuration over a period of time; (2) the arrival or departure rate of PDUs or PDU sets in one or more buffers associated with the forwarding configuration; (3) the average, maximum, and minimum size / volume of PDUs or PDU sets in the buffers associated with the forwarding configuration (e.g., the number of PDUs in the LCH buffer); (4) a measure of the amount of time spent in one or more PDUs or PDU sets in the buffers associated with the forwarding configuration; and / or (5) the number of forwarding configurations that meet a condition / threshold associated with data volume, arrival rate, PDU or PDU set size (e.g., total payload size).

[0242] For example, if at least one PDU or set of PDUs in a forwarding configuration (e.g., a UL LCH buffer waiting to be sent in the UL and / or a DL LCH / higher layer buffer waiting to be processed) exists in the buffer for a period of time greater than a threshold time value, the WTRU may perform any of the actions described herein (e.g., change the forwarding configuration and / or change the resource configuration). For example, if the buffer status of the forwarding configuration exceeds a threshold, the WTRU may perform any of the actions described herein (e.g., transmit a report or status indication).

[0243] For example, other buffer status metrics that may be monitored to determine expected QoS include the number of PDUs or PDU sets buffered in one or more associated forwarding configurations that are above / below a configured threshold, and / or the rate at which PDUs or PDU sets arrive or leave the buffer relative to a configured arrival / departure rate.

[0244] In another example, the WTRU may determine the number of PDUs or sets of PDUs received within a duration / window to determine whether the rate of PDUs received (e.g., from higher layers for UL transmission or from the network for DL ​​reception) is within an expected range for QoS. For example, this duration / window may be used to determine whether the PDUs received from the network are received within the RTT delay. If the received PDUs or sets of PDUs are outside the expected range for QoS, the WTRU may determine and / or select a mapping configuration to adjust / compensate for the expected QoS.

[0245] Such triggering events and / or conditions may be based on a change in one or more configurations at the WTRU. For example, when a change to a mapping configuration, a forwarding configuration, and / or a resource configuration is determined, the WTRU may be triggered to perform a WTRU action (e.g., transmit an indication / report to the network) including changing at least one of the parameters at the mapping configuration (e.g., mapping a QoS flow to a new forwarding configuration), the DRB / LCH (e.g., priority, PDB, PBR), the LCP configuration, and / or the resource configuration / parameters (e.g., CG / DG / SPS). For example, when any of the CDRX / DRX configuration and associated parameters applied at the WTRU are modified / updated, the WTRU may be triggered to perform a WTRU action, which may affect the transmit / receive mode and / or the achievable QoS (e.g., RTT) during data transmission.

[0246] Such triggering events and / or conditions may be based on timing / timestamp information that may be associated with the expected QoS (e.g., RTT latency). For example, the WTRU may track timing related information (e.g., timestamp, sequence number, tag, or timing control PDU) in one or more PDUs or PDU sets received in an earlier time window to determine latency or jitter. The timing information may then be used to determine the expected QoS (e.g., expected RTT) of an upcoming / new PDU or PDU set in the next time window.

[0247] In one example, the timing information may be determined / indicated as a deadline / delay bound and / or a time to live that may be met on a per-PDU, per-PDU set, or per-QoS flow basis. Such timing information may be determined across one or more associated / related QoS flows (e.g., including associated UL flows, associated DL flows, and associated UL+DL flows). In another example, the timing information may also be determined / indicated on a count basis (e.g., a PDU or PDU set count). When determining the timing information and its impact on whether the expected QoS (e.g., RTT) may be met, the WTRU may trigger actions described in the family of solutions herein (e.g., determining a mapping / forwarding configuration).

[0248] In another example, the WTRU may send information about expected QoS based on measurements associated with the duration that a PDU or a set of PDUs spends in a forwarding configuration (e.g., the time elapsed from the receipt of a PDU or PDU from a higher layer to its transmission in the UL, the time elapsed from the transmission of a PDU or PDU in the UL to its reception in the DL, and the time elapsed from the reception of a PDU or PDU in the DL to its forwarding to a higher layer).

[0249] In another example, the WTRU may transmit an indication / information regarding the RTT delay of a PDU or a set of PDUs sent in the UL and received in the DL based on monitoring / measurement at an AS layer entity / sublayer (e.g., SDAP, PDCP, RLC, MAC). For example, a PDCP entity used by the WTRU for UL transmission of a set of PDUs (e.g., one or more PDUs) may start a timer (e.g., a discard timer, an RTT timer), possibly before / after including a sequence number and / or transmitting the set of PDUs to lower layers. The WTRU may measure the RTT delay at the PDCP entity based on the reception of an associated set of PDUs (e.g., one or more PDUs) with a corresponding sequence number (e.g., a DL sequence number may be added by the gNB). In this case, if the timer expires before the set of PDUs is received in the DL (e.g., a discard timer), the WTRU may transmit an indication to the gNB to discard / abandon the set of PDUs, transmit a set of PDUs with a lower priority, or transmit a set of PDUs with a higher priority. In another example, the WTRU may transmit information / indications / reports to the network periodically or based on the setting / expiration of a configured timer (eg, as described in another section herein).

[0250] Such triggering events and / or conditions may be based on measurements over the Uu link. For example, the WTRU may perform measurements (e.g., corresponding to RSRP, RSSI, CQI, and CSI) over the Uu link to determine the expected QoS. Channel and / or load measurements made over a specific configured duration may indicate whether a PDU or set of PDUs can achieve the expected QoS during transmission and / or reception or whether the QoS budget (e.g., RTT latency) may be exceeded. The WTRU may trigger actions as described in the family of solutions herein (e.g., determining a mapping configuration) based on measurements over the Uu link.

[0251] In another example, the WTRU may determine the Uu link condition based on the number of ARQ / HARQ (ACK / NACK) feedback messages and / or the number of ARQ / HARQ retransmissions performed by one or more HARQ processes associated with the forwarding configuration applied for transmitting the PDU or PDU set. The expected QoS (e.g., RTT latency) may then be determined based on a (configured) mapping function between the feedback / ReTx counts in the UL and / or DL ​​and the expected QoS. For example, a ReTx count above a threshold may translate into a poor Uu link / channel condition and, therefore, reduce the expected QoS. In another example, the WTRU may determine the channel / link condition based on CSI reports sent to and / or received from the network.

[0252] For example, when channel measurements (e.g., RSRP, RSSI, RSRQ, CQI, CSI) made on the Uu link increase / decrease relative to a configured threshold and / or remain above / below a threshold for a specific duration, the WTRU may be triggered to perform a WTRU action and / or transmit an indication to the network. For example, when one or more QoS related measurements (e.g., latency / RTT measured for a PDU or set of PDUs in one or more forwarding configurations) exceed a specific threshold, the WTRU may be triggered to perform a WTRU action.

[0253] In another example, the WTRU may trigger actions described in embodiments herein based on a determination of a duration / jitter or a change in duration / jitter between the reception of consecutive PDUs associated with a PDU set and / or the reception of a PDU or PDU set in one or more related streams in the UL and / or DL. For example, the WTRU may infer an increase / decrease in jitter between consecutive PDUs to determine whether the processing load at the application / higher layers is high and / or low. In this case, to determine the duration, the WTRU may set a timer when a first PDU arrives and reset the timer when a second PDU associated with the same PDU set arrives.

[0254] Such triggering events and / or conditions may be based on compensation for expected QoS. For example, the WTRU may be triggered to perform a WTRU action based on a determination of an expected QoS (e.g., RTT) for one or more PDUs or sets of PDUs, where the expected QoS may indicate that the PDU may be delayed or arrive early during UL transmission and / or DL ​​reception. In this case, the WTRU may trigger an action so that the delayed or early PDU or set of PDUs may be sent with a determined amount of compensation, for example, by selecting an appropriate resource configuration (e.g., CG or DG resources). In one example, the action may be triggered when it is detected that the expected QoS (e.g., RTT) of the PDU or set of PDUs changes by a certain threshold (e.g., higher / lower).

[0255] In one example, the WTRU may determine a delayed PDU to transmit using a forwarding and / or resource configuration that satisfies a compensation amount determined by subtracting an expected RTT delay from an actual RTT delay.

[0256] Such triggering events and / or conditions may be based on attributes associated with the link / channel associated with the forwarding configuration. For example, the WTRU may be configured with attributes specific to the forwarding configuration / link / channel, such as forwarding configuration / link / channel priority and / or configuration parameters that enable / disable specific actions for the forwarding configuration / link / channel.

[0257] Such triggering events and / or conditions may be based on the detection of QoS events (e.g., a surge in payload size and / or high importance data). For example, a QoS event may include a surge event associated with an increase in the number of PDUs or PDU sets or the amount of data (which may occur within a certain time window, such as indicated / marked with high importance / priority). Similarly, other QoS events may include a QoS contraction that may be associated with a decrease in the number of PDUs or PDU sets or the amount of data / payload within a time window. In another example, a QoS event may occur when the WTRU detects a bad radio condition. For example, a bad radio condition may be detected based on measurement results, increased retransmissions, and / or increased NACKs of uplink packets.

[0258] For example, when one or more QoS events are detected, the WTRU may be triggered to perform one or more WTRU actions. For example, the WTRU may consider the duration indicated and / or determined by the expected duration of the QoS event. The WTRU may then perform other WTRU actions that may result in a fallback to a default configuration, possibly after the detected QoS event ends. In one example, when a surge event (e.g., an increase in the total payload and / or number of PDU sets) is detected, the WTRU may trigger an action to change the resource configuration in the UL and / or DL ​​(e.g., an updated CG and / or SPS for the duration of the surge) so that the surge can be accommodated within the RTT. When a reduction in the surge or the end of the surge event is determined, the WTRU may fall back to using the default resource configuration in the UL and / or DL ​​(e.g., a default CG and / or SPS).

[0259] The WTRU may determine the association of a PDU with a PDU set based on explicit or implicit indications and / or parameters. For example, the WTRU may determine whether a PDU in one or more QoS / data flows sent in the UL and / or received in the DL is associated with a PDU set and / or an application / higher layer function (e.g., NAS). The WTRU may determine the association of a PDU with a PDU set and / or an application / higher layer function based on explicit indications and / or implicit parameters / identifiers detectable by the WTRU in the PDU or QoS flow. Similarly, the WTRU may also determine the association between one or more PDUs or PDU sets sent in the UL and one or more PDUs or PDU sets received in the DL based on explicit indications and / or implicit parameters / identifiers detectable by the WTRU in the PDU or PDU set or QoS flow.

[0260] The parameters / identifiers used to determine the association of a PDU to a PDU set or the association between UL and DL PDUs or PDU sets may be configured in the WTRU (e.g., via RRC signaling, NAS layer signaling, and / or application / higher layer signaling). The parameters / identifiers used by the WTRU to identify the association of a PDU or PDU set may include a combination of one or more of the following:

[0261] Parameters and / or identifiers used by the WTRU to identify the association of a PDU or a set of PDUs may include an identifier, ID, index and / or sequence number associated with a flow and / or an application. For example, when a common identifier, ID, index and / or sequence number associated with a set of PDUs is detected, the WTRU may determine that a first PDU and / or a second PDU in the same QoS flow or a different QoS flow may be associated with the set of PDUs. Such an ID may be detected within a PDU in one or more QoS flows (e.g., in a header and / or payload). For example, an ID of a PDU set and / or an application associated with a set of PDUs may be pre-configured in the WTRU. A set of similar identifiers, IDs, indexes and / or sequence numbers may be used to identify an association between a PDU or a set of PDUs sent in the UL and a PDU or a set of PDUs received in the DL.

[0262] The parameters and / or identifiers used by the WTRU to identify the association of a PDU or a set of PDUs may include priority and / or importance information associated with the stream. For example, the WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows may be associated with a PDU set based on the detection of common and / or similar importance and / or priority indications in the PDUs in the QoS flows (e.g., in the header and / or payload). Such importance / priority indications may be related to spatial or temporal indications. In another example, when the importance / priority indication detected by the WTRU (e.g., in the PDU header or payload) may be above / below one or more importance / priority thresholds, the WTRU may determine that the PDU may be associated with a PDU set. Similar importance / priority indications may be used to identify the association between a PDU or a set of PDUs sent in the UL and a PDU or a set of PDUs received in the DL.

[0263] The associated parameters and / or identifiers used by the WTRU to identify a PDU or a set of PDUs may include time and / or timing information in the associated stream. For example, when the WTRU receives a PDU within a duration and / or window, the WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows may be associated with a set of PDUs. The duration and / or window may correspond to a time difference between a reception time of a first PDU (e.g., at t1) and a reception time of a second PDU (e.g., at t2) within the same QoS flow. The duration / window may correspond to a time difference between a reception time of a PDU in the first QoS flow (e.g., at t1) and a reception time of a PDU in the second flow (e.g., at t2). In this case, when the time difference (e.g., t2-t1) is less than a duration and / or window threshold, the WTRU may determine that a first PDU and a second PDU in the same or different QoS flows may be associated with a set of PDUs. For example, the duration and / or window threshold may be associated with a frame rate (e.g., 60 Hz, 120 Hz) used by an application / higher layer to generate a PDU or a set of PDUs.

[0264] Similar methods as described above may be applied to determine an association between a PDU or set of PDUs sent in the UL and received in the DL based on time and / or timing information. For example, the duration and / or window may be related to an RTT delay corresponding to a time difference between a transmission time of a PDU in a first stream in the UL (e.g., at t1) and a reception time of a PDU in a second stream in the DL (e.g., at t2). In this case, when the time difference (e.g., t2-t1) is less than a duration / window threshold (e.g., an RTT delay threshold), the WTRU may determine that the first PDU and the second PDU in the UL and DL streams may be associated.

[0265] In another example, the WTRU may determine that a first PDU and a second PDU in one or more streams may be associated with a PDU set, or may be associated between UL and DL, based on a common format and / or granularity of timing information (e.g., timestamp, packet count, sequence number) carried in the PDU.

[0266] The associated parameters and / or identifiers used by the WTRU to identify a PDU or a set of PDUs may include spatial / pose information in the associated stream. For example, when a PDU carrying spatial information corresponds to a common spatial parameter / ID, the WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows may be associated with a set of PDUs, or may be associated between UL and DL. For example, the spatial parameter / ID may include any of the following: direction / orientation of the FoV of the user / WTRU, slices and / or tiles of a video / media frame, location information (e.g., coordinates of the WTRU), pose information, etc. The WTRU may determine the spatial parameters and / or ID based on detection of certain PDUs carrying spatial information (e.g., pose and / or control PDUs that the WTRU may identify based on a data type identifier) ​​or detection of other PDUs that may contain spatial information within a PDU (e.g., in a header and / or payload).

[0267] The parameters and / or identifiers used by the WTRU to identify the association of a PDU or a set of PDUs may include an explicit indication from an application / higher layer / AS layer. For example, upon receiving an explicit indication / message from the WTRU or a higher layer / AS layer in the network, the WTRU may determine that a first PDU and / or a second PDU in one or more QoS flows may be associated with a set of PDUs, or may be associated between the UL and the DL. For example, the WTRU may receive timing information (e.g., periodicity, burst time window, and / or duration) in the indication during which the PDUs may be associated. In this case, in addition to the timing information (e.g., burst duration), the WTRU may assume that the PDUs may not be related and / or may not be associated with a set of PDUs, or may not be associated between the UL and the DL.

[0268] The WTRU may determine the alignment between the UL resource configuration and the DL resource configuration to satisfy the RTT delay. Figure 3 is a diagram illustrating an example process in which a WTRU determines alignment between UL resource configuration and DL resource configuration to meet RTT latency.

[0269] like Figure 3As shown, the WTRU 302 may determine the alignment between the UL resource configuration and the DL resource configuration to meet the RTT delay based on the timing of the arrival of the PDU or PDU set and the configured threshold associated with the RTT delay. To ensure the RTT delay, the WTRU 302 may be configured by the network 304 (e.g., gNB) with a CG and / or SPS resource configuration for performing UL transmission and / or DL ​​reception of the PDU or PDU set. However, in order to meet the strict RTT delay (e.g., 15ms), it may be wasteful to configure high periodicity for the CG and SPS resources when the arrival time of the PDU or PDU set from the upper layer at the WTRU is not known in advance. This may be due to jitter and / or processing delays at the higher layers or application layer.

[0270] In addition, the base station may not know which SPS opportunity may correspond to or be associated with a CG opportunity that carries associated UL and DL PDUs or PDU sets within the RTT delay. Since this association information is visible to the WTRU, the WTRU can help the base station to properly align the CG and SPS resource configuration and / or parameters (e.g., starting offset, periodicity, duration, number of PUSCH / PDSCH time slots) based on the arrival time of the PDU or PDU set that meets the RTT delay.

[0271] To implement this method, the WTRU may receive configuration information from the network, including one or more CG configurations and / or resources, one or more SPS configurations and / or resources, and a threshold T associated with ensuring the RTT delay. The threshold T may be indicated in milliseconds, time slots, PUSCH time slots. The CG and / or SPS configurations and / or resources received by the WTRU may correspond to a default configuration, which the WTRU may expect to use during default and / or normal conditions (e.g., UL data arrives within the threshold T). For example, the configuration information may be received by the WTRU via RRC signaling, MAC CE, DCI. The configuration may be received based on auxiliary information provided by the WTRU to the network, which indicates a business mode and QoS information, including the expected RTT delay to be met during UL transmission and DL reception, the number of associated streams in the UL and / or DL, the delay bound in the UL and / or DL ​​(e.g., PSDB), the expected periodicity of data transmission in the UL and / or DL, and / or the payload size of the PDU or PDU set in the UL and / or DL ​​(e.g., average, maximum, minimum).

[0272] The WTRU may then receive data from a higher layer or application layer consisting of one or more PDUs or PDU sets that are expected to be sent in the UL using CG resources. If a UL PDU or PDU set is received or expected to be received within T time slots before the next CG opportunity (for example, where the CG opportunity may consist of one or more CG resources or PUSCH time slots), the WTRU may use the CG resources to send one or more UL PDUs or PDU sets in the next CG opportunity. The WTRU may then receive one or more DL PDUs or PDU sets that may be associated with the UL PDU or PDU set in the DL within the RTT delay. The DL PDU or PDU set may be received in SPS resources in one or more SPS opportunities or PDSCH time slots. Such CG and SPS resources may correspond to a default CG and / or SPS configuration pre-configured in the WTRU. Alternatively, the DL PDU or PDU set may be received by the WTRU via dynamic grant / scheduling resources / time slots.

[0273] The WTRU may enter sleep mode when sending a UL PDU or a set of PDUs using CG resources. This transition to sleep mode may be performed by the WTRU when the WTRU does not expect to send and / or receive any data in the UL / DL for the duration of the RTT delay or any other duration. In one example, the WTRU may also transmit an indication to the base station to indicate the transition to sleep mode. During sleep mode, the WTRU may not monitor any DL control channels / indications (e.g., DCI, PDCCH, wake-up signal) until the expected reception time window of the DL PDU or set of PDUs using SPS resources. The time window in which the WTRU initiates monitoring of DL control channels / indications and / or DL ​​data reception (e.g., PDSCH) may be related to the RTT delay. For example, after sending the UL at t1, the WTRU may enter sleep mode for the duration of the RTT delay R. The WTRU may then initiate monitoring of DL control / data reception at t1+Rd ms / slot, where d may correspond to a starting offset time that may range from 0 ms / slot to several ms / slots.

[0274] If a UL PDU or PDU set is received or expected to be received before T time slots before the next CG opportunity, the WTRU may determine whether any DL time slot / opportunity associated with one or more configured SPS configurations and / or resources can allow the DL PDU or PDU set associated with the UL PDU or PDU set to be received within the RTT delay. The WTRU may determine the number of DL time slots / opportunities and possible PDSCH time slots based on the pre-configured SPS configuration / resources and the perception of the DL PDU or PDU set expected for the PDU or PDU set sent in the UL (e.g., payload size, arrival timing).

[0275] If one or more time slots / opportunities associated with one or more configured SPS configurations / resources do not match the DL time slots / opportunities determined by the WTRU (e.g., there is no matching time slot within the RTT delay), the WTRU may send an indication to the base station in one or more time slots before / within the RTT delay to request a first DG resource for UL transmission and / or a second DG resource for DL ​​reception. Such an indication may be sent by the WTRU in, for example, an SR (e.g., UCI), a BSR (e.g., MAC CE), or an RRC message. Such an indication may contain information about the expected RTT, the remaining time for sending in the UL and / or receiving in the DL, the expected payload size of the PDU or PDU set in the UL / DL, the priority of the data sent in the UL and expected in the DL, an indication that no suitable resources / time slots were found for DL ​​reception, an indication to update / modify the CG and / or SPS resources / configuration (e.g., changing the starting offset, changing the periodicity, increasing / decreasing the CG and / or SPS grant size, changing parameters such as MCS, changing the validity duration for any modifications to the CG / SPS that will apply, etc.).

[0276] In one example, the WTRU may receive resource allocations for the DG, including for a first DG resource (e.g., for UL transmission of a PDU or PDU set that arrives early) and / or a second DG resource (e.g., for DL ​​reception of an associated PDU or PDU set). In another example, the WTRU may receive an indication of an adjustment / modification of a CG and / or SPS configuration / resource and / or an activation / deactivation indication of a new CG and / or SPS configuration / resource. For example, such adjusted / new CG and / or SPS resources may be used to accommodate the early arrival of a PDU or PDU set. The WTRU may also receive information about the duration for which the adjustment / modification of the CG and / or SPS resources may be applicable, after which the WTRU may switch / fall back to using the default CG and / or SPS resources. Such resource allocation indications (e.g., for DG, CG, SPS) may be received by the WTRU in a DCI (e.g., a single DCI containing resource allocations for UL and DL, or multiple DCIs for UL and DL resource allocations), a MAC CE, or an RRC message.

[0277] The WTRU may then use, for example, the first DG resources and / or the adjusted / new CG resources to send one or more early UL PDUs or PDU sets. The WTRU may use the second DG resources and / or the adjusted / new SPS resources to receive one or more DL PDUs or PDU sets associated with the UL PDU or PDU set in the DL within the RTT delay.

[0278] Alternatively, if one or more time slots and / or opportunities associated with one or more configured SPS configurations and / or resources match a DL time slot and / or opportunity determined by the WTRU (e.g., there is no matching time slot within the RTT delay), the WTRU may send an indication to the base station to request DG resources for UL transmission. Such an indication may be sent by the WTRU in an SR (e.g., UCI), a BSR (e.g., MAC CE), or an RRC message. Other WTRUs may also send other information to the base station, similar to the case when the WTRU cannot find any matching DL time slots / opportunities for DL ​​reception. In one example, the WTRU may receive a resource allocation of DG resources for UL transmission of a PDU or PDU set that arrives early. In another example, the WTRU may receive an indication indicating an adjustment / modification of a CG configuration / resource and / or an activation / deactivation indication of a new CG configuration / resource. The WTRU may also receive information about the duration for which the adjustment and / or modification of the CG resources may be applicable, after which the WTRU may switch and / or fall back to using default CG resources. Such resource allocation indication (e.g., for DG, CG, SPS) may be received by the WTRU in a DCI (e.g., a single DCI containing resource allocations for UL and DL, or multiple DCIs for UL and DL resource allocations), a MAC CE, or an RRC message.

[0279] The WTRU may then use the received DG resources and / or adjusted / new CG resources to send one or more early UL PDUs or PDU sets. The WTRU may receive one or more DL PDUs or PDU sets that may be associated with a UL PDU or PDU set in the DL within the RTT delay using the default SPS resources.

[0280] The WTRU may determine the timing of DL reception for adjustment within the RTT delay based on the delay in the UL transmission. Figure 4 is a diagram illustrating an example of a WTRU determining timing for DL ​​reception to compensate for a higher than expected delay in the arrival of a PDU for UL transmission.

[0281] like Figure 4As shown, in one embodiment, the WTRU may determine the timing of DL reception to compensate for higher than expected delays during UL transmissions to meet adjusted and / or new RTT delays. In an example scenario, higher than expected processing delays at the application and / or higher layers (e.g., video codec) at the WTRU may cause earlier UL data to arrive much later than its expected CG opportunity and closer to the next CG opportunity. However, the CG grant in the next CG opportunity may not be sufficient to accommodate the earlier (e.g., delayed PDUs and / or PDU sets) and new UL data. This may affect the UL transmission and DL reception of delayed data within the RTT delay.

[0282] Because the WTRU may have visibility of delays during data transmission in the UL, the WTRU may determine some adjustments that may be performed to the timing and / or grant size of the UL and / or DL ​​resource configurations so that the RTT delay may be maintained. To implement this approach, the WTRU may receive configuration information from the network including one or more CG configurations and / or resources, one or more SPS configurations and / or resources, and a threshold L associated with ensuring the RTT delay in view of jitter. The threshold L may correspond to an upper limit on how much a set of one or more earlier PDUs or PDU sets (e.g., a PDU or PDU set that may be mapped to an earlier CG opportunity) may be delayed due to jitter in order to meet the RTT delay through some adjustments to the UL and / or DL ​​resources.

[0283] The threshold L may be indicated in milliseconds, time slots, PUSCH time slots, etc. The CG and / or SPS configuration / resources received by the WTRU may correspond to a default configuration, which the WTRU may expect to use during default / normal conditions (e.g., UL data arrives within threshold L and / or earlier than threshold L). Such configuration information may be received by the WTRU via, for example, RRC signaling, MAC CE, DCI. Such configuration may be received based on auxiliary information provided by the WTRU to the network, which indicates the traffic mode and QoS information, including the expected / default RTT delay to be met during UL transmission and DL reception, the maximum jitter at the WTRU during UL transmission, the payload size of the PDU or PDU set in the UL and / or DL ​​(e.g., average, maximum, minimum), etc.

[0284] The WTRU may receive first UL data (e.g., consisting of one or more PDUs or PDU sets delayed due to jitter) and second UL data (e.g., consisting of one or more PDUs or PDU sets) from an application / higher layer. In this case, during UL transmission, the first UL data may be associated with and / or intended to use a previous CG opportunity, and the second UL data may be associated with and / or intended to use a current CG opportunity.

[0285] If the first UL data is received or expected to be received within L time slots before the next CG opportunity (for example, where the CG opportunity may be composed of one or more CG resources or PUSCH time slots), and / or the CG resources in the next CG opportunity can accommodate the first UL data and the second UL data, the WTRU may use the CG resources in the next CG opportunity to send the first UL data and the second UL data. On the other hand, if the CG resources in the next CG opportunity cannot accommodate the first UL data and the second UL data, the WTRU may determine a new RTT delay for receiving DL data associated with the delayed first UL data based on the timing of the next CG opportunity and the expected RTT delay. For example, the WTRU may determine the new RTT delay by subtracting the start time of the next CG opportunity from the expected RTT delay.

[0286] The WTRU may determine one or more DL time slots / opportunities and / or possible numbers of PDSCH time slots based on the new RTT delay for possible reception of DL data (e.g., one or more PDUs or PDU sets) associated with the first UL data within the new RTT delay.

[0287] The WTRU may send an indication to the base station to request a first DG resource for UL transmission in a time slot / timing that is the same / similar to the next CG timing and / or a second DG resource for DL ​​reception in one or more time slots before / within the new RTT delay. Such an indication may be sent by the WTRU in an SR (e.g., UCI), a BSR (e.g., MAC CE), or an RRC message. Such an indication may contain information about the new RTT, the remaining time for transmission in the UL and / or reception in the DL, the expected payload size of the PDU or PDU set in the UL / DL, the priority of the data sent in the UL and expected in the DL, an indication to update / modify the CG and / or SPS resources / configuration (e.g., change the starting offset, change the periodicity, increase / decrease the CG and / or SPS grant size per time slot, change parameters such as MCS, change the validity duration for any modifications to the CG / SPS that will be applicable, etc.

[0288] In one example, the WTRU may receive resource allocations for a DG, including for a first DG resource (e.g., for UL transmission of a delayed PDU or PDU set) and / or a second DG resource (e.g., for DL ​​reception of an associated PDU or PDU set). In another example, the WTRU may receive an indication of an adjustment and / or modification of a CG and / or SPS configuration / resource and / or an activation / deactivation indication of a new CG and / or SPS configuration / resource. For example, such adjusted / new CG and / or SPS resources may be used to accommodate a delayed PDU or PDU set. For example, the WTRU may also receive information about the duration for which the adjustment / modification of the CG and / or SPS resources may be applicable, after which the WTRU may switch / fall back to using a default CG and / or SPS resource (e.g., resource. Such resource allocation indications (e.g., for DG, CG, SPS) may be received by the WTRU in a DCI (e.g., a single DCI containing resource allocations for UL and DL, or multiple DCIs for UL and DL resource allocations), a MAC CE, or an RRC message.

[0289] The WTRU may then use, for example, the first DG resources and / or the adjusted / new CG resources to send one or more delayed first UL data (e.g., one or more PDUs or PDU sets). The WTRU may use, for example, the second DG resources and / or the adjusted / new SPS resources to receive DL data (e.g., one or more PDUs or PDU sets) that may be associated with the first UL data in the DL within the new RTT delay. The WTRU may use the default CG resources to send the second UL data in the next CG opportunity. The WTRU may use the default SPS resources / opportunity within the expected / default RTT to receive DL data that may be associated with the second UL data.

[0290] The WTRU may determine adjustments to the timing of DL data reception based on the change in RTT delay. In one embodiment, the WTRU may determine the new RTT delay based on QoE and / or application layer measurements (e.g., estimates / measurements of the remaining data time in the application buffer) and may transmit an indication to the gNB to adjust the UL and DL resource configurations to match the new RTT delay. For example, an application hosted in the TE portion of the WTRU may transmit the QoE and / or application layer measurements to the MT portion of the WTRU in an AT command.

[0291] In an example scenario, the RTT latency of some PDUs or PDU sets sent in the UL and received in the DL may vary over time based on some application layer functions (e.g., amount of posture change, application layer correction, error concealment at the application) and / or QoE measurements. For example, if the WTRU posture change is significant (e.g., the amount of posture change or movement of the WTRU is above a threshold), the DL latency may be lower even when the actual latency in the UL is within the UL PDB value. In this scenario, the RTT latency may be the most stringent (e.g., the RTT latency may be set to 15ms). Alternatively, if the WTRU posture change is not significant and / or the application can perform some corrections for any posture change using existing data, the DL latency may be relaxed. In this scenario, the RTT latency may be relaxed (e.g., the RTT latency may be set to 50ms). In this regard, performing some adjustments / changes to the UL and / or DL ​​resource configurations (e.g., CG, SPS, DG) based on changes in expected RTT latency may be beneficial from a scheduling, resource utilization efficiency, and power saving perspective.

[0292] To implement this method, the WTRU may receive configuration information from the network, including one or more CG configurations and / or resources, one or more SPS configurations / resources, and a threshold D associated with the RTT difference relative to a default RTT delay value. The WTRU may be configured with a CG and / or SPS configuration / resource to meet the default RTT delay value.

[0293] The WTRU may receive UL data (e.g., consisting of one or more PDUs or sets of PDUs) that may be expected to be sent in the UL from an application / higher layer. The WTRU may also receive data consumption status from the application / higher layer, including the current application buffer level and / or data consumption rate. This data consumption status may be related to data that the WTRU previously received in the DL and / or is waiting in the application layer buffer for later processing and / or consumption. Next, the WTRU may determine a new RTT delay expected for the UL data and / or associated DL data. For example, the new RTT delay may be determined based on an estimate of the remaining time for exhausting the data in the application buffer and the data consumption status (e.g., remaining time = current buffer level / data consumption rate). For example, an application hosted in the TE portion of the WTRU may transmit the data consumption status to the MT portion of the WTRU in an AT command.

[0294] If the difference between the new RTT delay and the default RTT delay is less than or equal to the RTT difference threshold D (e.g., |default RTT-new RTT|<=D), indicating a smaller difference compared to the default RTT delay, the WTRU may use the CG resources to send UL data in the next CG opportunity. The WTRU may then receive DL data associated with the sent UL data in the SPS resources in one or more SPS opportunities before the default RTT delay.

[0295] If the difference between the default RTT delay and the new RTT delay is greater than the RTT difference threshold D (e.g., default RTT - new RTT > D), indicating a new RTT delay that is more stringent than the default RTT delay, the WTRU may determine a new DL time slot / opportunity for receiving DL data associated with the UL data for DL ​​reception within the new RTT delay. The WTRU may send an indication to the gNB (e.g., in an SR, UCI, BSR, MAC CE, or RRC message) indicating any of the following: the new RTT delay, the determined new DL time slot / opportunity for receiving DL data, a request for DG resources for DL ​​reception, and a request for SPS resources for DL ​​reception. The WTRU may use the DG resources or the CG resources to send UL data in the next CG opportunity. The WTRU may receive DG resources (e.g., in a DCI) and / or SPS resources for DL ​​data reception from the gNB. The WTRU may then receive DL data in the DG and / or SPS resources before or at the new RTT delay.

[0296] If the difference between the new RTT delay and the default RTT delay is greater than an RTT difference threshold D (e.g., new RTT - default RTT > D), indicating a new RTT delay that is relaxed compared to the default RTT delay, the WTRU may determine a new DL time slot / opportunity for receiving DL data associated with the UL data for DL ​​reception within the new relaxed RTT delay. The WTRU may send an indication to the gNB (e.g., in an SR, UCI, BSR, MAC CE, or RRC message) indicating any of the new RTT delay, the determined new DL time slot / opportunity for receiving DL data, and a request to skip one or more SPS resources for DL ​​reception associated with the default RTT delay. The WTRU may use the DG resources or the CG resources to send the UL data in the next CG opportunity. The WTRU may receive the DG resources (e.g., in a DCI), the new SPS resources associated with the new RTT delay, and / or an indication confirming the skipping of the SPS resources associated with the default RTT delay from the gNB. The WTRU may then receive DL data in the DG and / or SPS resources before or at the new relaxed RTT delay.

[0297] Figure 5 An exemplary method performed by a WTRU is illustrated. At 502, the WTRU may receive configuration information from a base station. At 504, the WTRU may receive one or more protocol data units (PDUs) associated with at least one of a set of uplink PDUs from an application layer. At 506, the WTRU may determine a buffer delay for sending the PDU in resources associated with a configuration grant (CG) physical uplink shared channel (PUSCH) transmission opportunity. At 508, in the event that the buffer delay is greater than a delay threshold and there are no available resources associated with a semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) transmission opportunity within a time window, the WTRU transmits an indication of a time offset for the time window.

[0298] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of 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 built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information from a base station; receiving one or more uplink protocol data units (PDUs) from the application layer; determining a buffering delay for transmitting the one or more uplink PDUs in resources associated with a configuration grant (CG) physical uplink shared channel (PUSCH) opportunity; and An indication of a time offset for the time window is sent on the condition that the buffering delay is greater than a delay threshold and there are no available resources associated with a semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) opportunity within the time window. 2 . The method of claim 1 , wherein the configuration information comprises at least one of the time offsets associated with a start of the time window. The method of claim 1 , wherein the configuration information includes the delay threshold. The method of claim 1 , wherein the configuration information comprises one or more starting offsets associated with the time window. The method according to claim 1 , wherein the configuration information includes a CG configuration and an SPS configuration.

6. The method according to claim 5, wherein the CG PUSCH opportunities in the CG configuration are time-aligned in the time window. The method of claim 5 , wherein SPS PDSCH opportunities in the SPS configuration are time-aligned in the time window.

8. The method of claim 1, wherein the time window is a round trip time (RTT) window.

9. The method of claim 1, wherein the indication is sent in uplink control information (UCI).

10. The method according to claim 1, further comprising: The one or more uplink PDUs are sent to the base station in a CG PUSCH opportunity.

11. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: Transceiver; and processor; Wherein the transceiver and the processor are configured to: receiving configuration information from a base station; receiving one or more uplink protocol data units (PDUs) from an application layer; determining a buffering delay for transmitting the one or more uplink PDUs in resources associated with a configuration grant (CG) physical uplink shared channel (PUSCH) opportunity; and An indication of a time offset for the time window is sent on the condition that the buffering delay is greater than a delay threshold and there are no available resources associated with a semi-persistent scheduling (SPS) physical downlink shared channel (PDSCH) opportunity within the time window.

12. The WTRU of claim 11, wherein the configuration information comprises at least one of the time offsets associated with the time window.

13. The WTRU of claim 11, wherein the configuration information includes the delay threshold.

14. The WTRU of claim 11, wherein the configuration information includes one or more starting offsets associated with the time window.

15. The WTRU according to claim 11, wherein the configuration information includes CG configuration and SPS configuration.

16. A WTRU according to claim 15, wherein the CG PUSCH timing in the CG configuration is time-aligned in the time window.

17. The WTRU of claim 15, wherein SPS PDSCH opportunities in the SPS configuration are time-aligned in the time window.

18. The WTRU of claim 11, wherein the time window is a round trip time (RTT) window.

19. The WTRU of claim 11, wherein the indication is sent in uplink control information (UCI).

20. The WTRU of claim 11 wherein the transceiver and the processor are further configured to: The one or more uplink PDUs are sent to the base station in a CG PUSCH opportunity.

Images