Relay wtru with sr / bsr and discard triggers considering indications from remote wtru

Abstract

A first wireless transmit / receive unit (WTRU) may receive configuration information for relaying data from a second WTRU to a network. The configuration information may include a first data threshold and a first timing threshold. The first WTRU may receive, from the second WTRU, first protocol data unit (PDU) set information. The first PDU set information may include an indication of a time associated with a PDU set delay budget (PSDB) for a first PDU set and an indication of a size of the first PDU set. Based on a determination that an amount of data remaining to be received for the first PDU set at a time corresponding to the first timing threshold prior to the time associated with the PSDB is greater than the first data threshold, the first WTRU may transmit a buffer status report (BSR) for the first PDU set to the network.

Description

RELAY WTRU WITH SR / BSR AND DISCARD TRIGGERS CONSIDERING INDICATIONS FROM REMOTE WTRUCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Patent Application Number 63 / 526,805, filed on July 14, 2023, the entire contents of which are incorporated herein by reference.BACKGROUND

[0002] The term extended Reality (XR) may refer to different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), and the realities interpolated among them.

[0003] The operation of XR at a remote wireless transmit / receive unit (WTRU) communicating while out of coverage (OOC) via a WTRU to network (NW) relay adds additional issues associated with handling protocol data unit (PDU) sets. The introduction of a network (NW) relay hop adds a need to consider the latency of the relaying in the PDU set delay budget (PSDB). Using a scheduling request and / or Buffer status report (SR / BSR) to meet XR requirements involves providing latency / PDU set size information within the BSR. For relays, however, the WTRU generating the traffic (the remote WTRU) is different from the WTRU requesting resources using BSR (the relay WTRU), which results in a need to extend or revisit some of the assumptions made in XR with respect to SR / BSR. Also, for relays, there may be multiple different WTRUs generating XR traffic which may make it difficult for the relay WTRU to meet all the latency requirements associated with each remote WTRU.

[0004] What is needed are methods to meet PSDB the requirements for a PDU set transmitted over two (or more) transmission hops (e.g., using a sidelink (SL) relay) and to determine when to discard pending PDUs of the PDU set when the PSDB of the PDU set cannot be met.SUMMARY

[0005] A first wireless transmit / receive unit (WTRU) (e.g., a relay WTRU) may be configured to trigger a scheduling request (SR) and / or a buffer status reporting (BSR) to the network. The WTRU may be configured to trigger a discard operation based on a status of PDU set reception. The first WTRU may receive configuration information associated with the first WTRU. The configuration information may comprise one or more of: a delta buffer status report (BSR), a delta discard, a threshold BSR, a first data threshold for triggering a BSR for protocol data unit (PDU) set data received from a second WTRU, a first timing threshold for triggering the BSR for the PDU set data received from the second WTRU, and a threshold discard. In examples, the configuration information may comprise a plurality of the aforementioned thresholds (e.g., a first and a second data threshold for triggering BSR for PDU set data received from a second WTRU, and a first and a second timing threshold for triggering discard of the PDU set data received from the second WTRU). The first WTRU may receive PDU set information from a second WTRU (e.g., remoteWTRU), the PDU set information comprising an indication of a time (e.g., a first slot number) associated with a PDU set delay budget (PSDB) and / or an indication of a PDU set size. The first WTRU may buffer data of a PDU set received from the second WTRU. The first WTRU may determine an amount of data associated with the PDU set still to be received at a second slot number. The first WTRU, in response to determining that the amount of data associated with the PDU set still to be received is larger than a threshold (e.g., at a time corresponding to the first timing threshold prior to the time associated with the PSDB), may send (e.g., trigger) a scheduling request (SR) and / or BSR to the network. The SR / BSR may indicate an amount of data of the PDU set still to be received (e.g., for the first PDU set) if it is determined, and / or an expected time that the data remaining to be received will become available.

[0006] In examples, the first WTRU may discard data associated with a first PDU set (e.g., based on determining that an amount of data remaining to be received from the second WTRU for the first PDU set at a time corresponding to the second timing threshold prior to the time associated with the PSDB is greater than a second data threshold). The WTRU may send an indication of the discard to the second WTRU. The indication of the discard may include a rationale associated with the discard. In examples, the first WTRU may send a preemptive BSR based on an indication of the size of the first PDU set. The first WTRU may receive a discard indication (e.g., from the second WTRU) that indicates to discard one or more PDUs of the first PDU set; and may discard one or more PDUs based on the discard indication. The first WTRU may discard data associated with a PDU set and sent, to the network, an indication of the data that was discarded.BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0008] FIG. 1 B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0009] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0010] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 2 is a system diagram illustrating an example single path wireless transmit / receive unit (WTRU) to network (NW) relay.

[0012] FIG. 3 illustrates an example user plane protocol stack for a layer 2 (L2) WTRU to NW relay.

[0013] FIG. 4 illustrates an example control plane protocol stack for an L2 WTRU to NW relay.

[0014] FIG. 5 illustrates an example data burst of multiple PDU sets of different types.DETAILED DESCRIPTION

[0015] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 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 uniqueword DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0016] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated 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" and / or a "STA", may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g. , a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a WTRU.

[0017] The communications systems 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 ON 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0019] 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).

[0020] As noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include 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 UL Packet Access (HSUPA).

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

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

[0023] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0024] 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), GSM EDGE (GERAN), and the like.

[0025] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g, for use by drones), a roadway, 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 femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0026] The RAN 104 / 113 may be in communication with the CN 106 / 115, 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 varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc, and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0027] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and / or the internet protocol (IP) in the TCP / IP internet protocol suite The networks 112 may include wired and / or wireless communications 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 / 113 or a different RAT.

[0028] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multimode capabilities (e.g, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicatingwith different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A 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.

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

[0030] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

[0034] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0035] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the 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, and the like.

[0036] 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

[0038] 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 particular subframes for both the UL (e.g., for transmission) and downlink (e.g., forreception) may be concurrent and / or simultaneous. The full duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

[0039] FIG. 1C is a system diagram illustrating the RAN 104 and the ON 106 according to 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.

[0040] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-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 eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

[0041] Each of the eNode-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, scheduling of users in the UL and / or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0043] The MME 162 may be connected to each of the eNode-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, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. 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.

[0044] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

[0046] The ON 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 communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and / or wireless networks that are owned and / or operated by other service providers.

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

[0048] In representative embodiments, the other network 112 may be a WLAN.

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

[0050] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented, for example in in 802.11 systems. For CSMA / CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primarychannel 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.

[0051] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0053] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11ac.802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum According to a representative embodiment, 802.11 ah may support Meter Type Control / Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0054] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest 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, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (e.g., which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

[0056] FIG. 1 D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0057] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c Thus, the gNB 180a, for example, may use multiple antennas to transmit 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, the gNB 180a may transmit multiple component carriers to the 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, the 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).

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

[0059] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160csubstantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, 102c.

[0060] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

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

[0062] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0063] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 115 via an N11 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 115 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating WTRU IP address, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and the like. A PDU session type may be IP-based, non-IP based, Ethernet-based, and the like.

[0064] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The 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 downlink packets, providing mobility anchoring, and the like.

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

[0066] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0067] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, 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. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may perform testing using over-the-air wireless communications.

[0068] The one or more emulation devices may perform the one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0069] FIG. 2 is a system diagram illustrating an example system 200 having single path WTRU to network (NW) relay. As shown in FIG. 2, remote WTRU and / or relay WTRU behavior for WTRU to NW relays, may allow a remote WTRU (e.g., which is out of coverage) to be served by the network via a relay WTRU.

[0070] Layer 2 (L2) and layer 3 (L3) WTRU to NW relays may be provided.

[0071] FIG. 3 illustrates an example user plane (UP) protocol stack 300 for a L2 WTRU to NW relay. FIG. 4 illustrates an example control plane (CP) protocol stack 400 for a L2 WTRU to NW relay. As shown in FIG. 3 and FIG. 4, the SRAP sublayer is placed above the RLC sublayer for both CP and UP at both the PC5 interface and the Uu interface. The Uu SDAP, PDCP, and RRC sublayers are terminated between L2 UE / WTRU-to-network (U2N) Remote WTRU and gNB, while SRAP, RLC, MAC, and PHY sublayers are terminated in each hop (e.g., the link between L2 U2N Remote WTRU and the L2 U2N Relay WTRU and the link between L2 U2N Relay WTRU and the gNB). Herein, the terms U2N and WTRU2N have the same meaning and may be used interchangeably.

[0072] For a L2 U2N Relay, the SRAP sublayer over PC5 hop may be for (e.g., only for) bearer mapping. The SRAP sublayer is not present over PC5 hop for relaying the L2 U2N Remote WTRU's message on BCCH and PCCH. For L2 U2N Remote WTRU's message on SRB0, the SRAP header is not present over PC5 hop, but the SRAP header is present over Uu hop for both DL and UL.

[0073] Mode 1 and Mode 2 resource allocation may be provided The PC5-link of the WTRU to NW relay may use sidelink (SL) resource allocation techniques applicable to sidelink (SL) WTRUs. A SL WTRU may be configured to operate in either mode 1 or mode 2. In mode 1, the WTRU is scheduled on sidelink by the network (e.g., DCI scheduling sidelink grants). In mode 2, the WTRU / UE performs resource (re)selection to schedule sidelink resources.

[0074] Mode 2 resource selection is further characterized by the potential use of sensing. A WTRU that supports sensing may use the results of sensing (e.g., the Indication of sidelink control information (SCI) transmissions over a period of time that are forward booking resources) to select a set of resources for transmission. Resource selection may include determining a set of available resources based on these sensing results and comparing the observed SCIs reference signal received power (RSRP) with a threshold that is dependent on the priority of the transmission to be made during the sensing and the transmission announced by the other SCI. If a certain percentage of resources is deemed available, a WTRU may randomly select resources (either for a single transmission or for multiple periodic transmissions announced by a forward booking indication in SCI) to be used for transmission. When insufficient resources are available to perform random selection, the WTRU may increase its threshold for availability by 3dB until a sufficient amount of resources is deemed available.

[0075] Mode 2 resource selection is further limited by congestion control. The WTRU measures the channel busy ratio (CBR) and is configured with some limitations in transmission based on the CBR (e.g., max number of retransmissions, MCS, maximum number of subchannels, etc.) to avoid further increasing congestion when it is high. Congestion parameters are further conditioned on the priority of a transmission so that high priority transmissions suffer less from congestion control limitations.

[0076] The term extended Reality (XR) may refer to different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR), and the realities interpolated among them.

[0077] Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within limits defined by the application.

[0078] Augmented Reality (AR) provides users with additional information or artificially generated items, or content overlaid upon their current environment.

[0079] Mixed Reality (MR) is an advanced form of AR where some virtual elements are inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. XR may include all real- and-virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0080] The notion of immersion in the context of XR applications / services refers to the sense of being surrounded by the virtual environment as well as providing the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality practically indiscernible from actual reality.

[0081] XR devices may be typically associated with capabilities that offer various degrees of spatial tracking. XR devices may be equipped with various sensors to enable spatial tracking, for example, monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, etc. Spatial tracking may be performed at different levels such as 3 Degrees of Freedom (DoF) (e.g., rotational motion along the X, Y, and Z axis) and 6 DoF (e.g., rotational and / or translational motion along the X, Y, and Z axis).

[0082] Spatial tracking may result in an interaction to experience some form of virtual content. The user may act in and / or interact with the components within extended reality. For example, the actions and / or interactions may involve movements, gestures, eye tracking, etc. Spatial tracking is an important enabler for the immersive XR experience. For example, some form of head and / or motion tracking may ensure that the simulated visual and audio components from the user's perspective are updated to be consistent with the user's movements. Imprecise and / or delayed spatial tracking may lead to a sensation of discomfort and / or motion sickness for the user.

[0083] A WTRU may correspond to any XR device / node, which may come in various form factors. Typical a WTRU (e.g., XR WTRU) may include, but is not limited to, head mounted displays (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, etc. In addition to the above, several different types of XR WTRU may be envisioned based on XR device functions, including display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing, and power supply, to be provided by one or more devices, wearables, actuators, controllers and / or accessories. One or more devices / nodes / WTRUs / UEs may be grouped into a collaborative XR group to support any XR applications / experience / services.

[0084] The QoS flow may be the finest granularity of QoS differentiation in a PDU session. The 5QI may determine one or more QoS characteristics. This implies that each packet in a QoS flow may be treated according to the same QoS requirements.

[0085] For XR / media services, a group of packets is used to carry payloads of a PDU set (e.g., a frame, video slice / tile). A PDU set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g., a frame or video slice).

[0086] In the media layer, packets in such a PDU set are decoded / handled as a whole. For example, the frame / video slice may be decoded {e.g., only be decoded) if all or a certain amount of the packets carrying the frame / video slice are successfully delivered. For example, a frame within a group of pictures (GOP) can only be decoded by the client if all frames on which that frame depends are successfully received. Hence the groups of packets within the PDU set have an inherent dependency on each other in the media layer. Without considering such dependencies between the packets within the PDU set, 5GS may perform scheduling with low efficiency. For example, the 5GS may randomly drop packet(s) but try to deliver other packets of the same PDU set, which are useless to the client and thus waste radio resources.

[0087] Audio samples, haptic applications, or remote-control operations may benefit if the 5GS considers the PDU set characteristics. If such dependency between packets of a PDU set (e.g., a frame / video slice) can be considered, it's possible to enhance the efficiency and promote user experience.

[0088] 3GPP is studying the required enhancements to the current 5GS QoS framework to support different QoS handling for PDU sets. PDU sets may carry different content (e.g., I / B / P frames, slices / tiles within an l / B / P frame, etc.). For example, differentiated QoS handling where the different importance of PDU sets may be considered. For example, treating packets (e.g., PDUs) belonging to less important PDU set(s) differently to help reduce resource wasting.

[0089] A Data Burst is a set of data PDUs generated and sent by the application in a short period of time. A Data Burst can be composed of multiple PDUs belonging to one or multiple PDU sets.

[0090] PDU-Set Delay Budget (PSDB) defines an upper bound for the time that a PDU-Set may be delayed between the WTRU and the N6 termination point at the UPF.

[0091] PDU-Set Error Rate (PSER) defines an upper bound for the rate of PDU-Sets that have been processed by the sender of a link layer protocol (e.g., RLC layer) but where one or more (e.g., all) of the PDUs in the PDU-Set are not successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP layer).

[0092] If a PDU set is associated with and / or marked with a PDU Set Integral Handling Indication (PSIHI), all the PDUs of the PDU set must be received successfully at the receiving entity / application for the information included within the PDU set to be useful (e.g , application may not be able to combine / render the information in the PDUs of the PDU set even if all but one of the PDUs of the PDU set are received successfully).

[0093] Time To Live (TTL) of a PDU set is how much of the PSDB of the PDU is remaining For example, if the PSDB is x ms, and it has been y ms since the first PDU of the PDU set becomes available for transmission at the remote WTRU, the TTL is x-y ms.

[0094] FIG. 5 illustrates an example data burst 500 of multiple PDU sets of different types.

[0095] The WTRU may receive information about the size of PDU sets / data bursts (e.g., size of frame and / or PDU and / or PDU-set and / or group of PDU sets) and other information such as PSDB, PDU set type, importance, etc., by one or more of the following means.

[0096] These means may include the WTRU receiving indications from the application and / or higher layers about the size of the PDU set. For example, an indication may come in the packet header of the first packet / PDU in the PDU set.

[0097] The WTRU may receive indications from the application that the WTRU may use to infer the size of the PDU set. For example, the WTRU may receive indications about the first and the last packet in the PDU set, which may be indicated in the headers of the first and the last packet.

[0098] The WTRU may receive size information on a more granular level. For example, the WTRU may receive indications from the application about the typical size of different frames (e.g., l-frame, P-frame, B-frame). The first / last packet in the PDU set may include information indicating its type (e.g., corresponding to an l-frame or P- frame) and that it's the first / last packet of the PDU set. Based on this information, the WTRU may be able to estimate the size of the PDU set.

[0099] In an encoding scheme where different types of frames are encoded into different traffic streams (e.g., GOP-based whereby a single video frame is either an l-frame or P-frame), the WTRU may receive an indication linking the data flow to the frame type once (e.g., only once) at the start of the session. For example, the indication from the application to the WTRU may be a bit-type, where "0" may correspond to a data flow with l-frames while "1 " may correspond to a data flow with P-frames.

[0100] The WTRU may receive information about the size of the PDU set on a PDU set basis and / or on a per-flow basis (e.g., in the GOP-based encoding scheme). This exchange may happen at the start of the XR session. The WTRU may receive regular updates throughout the XR session periodically or (e.g., only) if there is a change in the information (e.g , a change in the size of the PDU set).

[0101] The WTRU may receive information from the application / higher layers on multiple PDU sets (e.g., the granularity of a group of PDU sets). The application may group PDU sets based on similarities between individual PDU sets (e.g., same size, type, importance / priority, etc.).

[0102] The importance of data may be indicated to the WTRU from the application on different data-unit granularities (e.g., the importance on a per-frame basis and / or per PDU basis and / or per PDU set basis and / or pergroup of PDU sets basis, etc.).

[0103] An indication of importance may be indicated for each data unit. Alternatively, it may be indicated for a first data unit, and no indication may be sent for the following data units until or unless there is a change in importance. An indication of importance may be a bit-wise binary indication or a flag indication if the data is important enough to necessitate a special treatment, for example.

[0104] An indication of importance may be indicated through a table mapping different QoS levels in the legacy QoS framework to different importance levels. For example, the four most important QoS levels from the QoS framework may be flagged as important such that the WTRU may determine that any data mapped to radio bearers with the corresponding QoS flows from the four most important QoS levels may need to be sent before transitioning to another cell / gNB. Any data mapped to radio bearers with QoS flows from the remaining QoS levels may wait until after handover (HO) is completed to be transmitted.

[0105] In some cases, an indication of importance may override QoS levels from the traditional QoS framework (e.g., if the data in the buffer is about to expire).

[0106] Several areas for enhancing Uu for XR WTRUs may be addressed. These areas may include XR awareness that may provide for the provisioning of XR traffic information from CN to RAN (PDU set, burst).

[0107] Power saving that may provide for discontinuous reception (DRX) support of XR frame rates corresponding to non-integer periodicities (through at least semi-static mechanisms, e.g., RRC signaling).

[0108] Capacity enhancements that may provide for multiple configured grant (CG) PUSCH transmission occasions in a period of a single CG PUSCH configuration, dynamic indication of unused CG PUSCH occasion(s) based on uplink control information (UCI) by the WTRU, BSR enhancements including at least BS Table(s), delay reporting of buffered data in uplink, provision of XR traffic assistance information for DL and UL (e.g., periodicity), and discard operation of PDU sets.

[0109] Operating XR at a remote WTRU communicating while the remote WTRU is out of coverage (OOC) via a WTRU to NW relay may add additional issues associated with handling of PDU sets. Introduction of the WTRU to NW relay may add the need to consider the latency of the relaying in the PSDB. SR / BSR to meet XR requirements may include providing latency / PDU set size information within the BSR. For relays, however, the WTRU that generates the traffic (e.g., the remote WTRU) may be different than the WTRU requesting resources using BSR (e.g., the relay WTRU), which results in a need to extend or revisit some of the assumptions made in XR with respect to SR / BSR. Multiple different WTRUs may generate XR traffic which may make it difficult for the relay WTRU to meet one or more (e.g., all) the latency requirements associated with each remote WTRU.

[0110] One or more PSDB requirements may be met for a PDU set transmitted over two (or possibly more) transmission hops (e.g., using a SL relay). One or more pending PDUs of the PDU set may be discarded when the PSDB of the PDU set cannot be met.

[0111] A PSDB (PDU set delay budget) may refer to the required time between the reception of the first packet of a PDU set from the upper layers of WTRU to the successful transmission of the last packet of the PDU set.

[0112] A remaining PSDB may refer to the remaining time budget from the original time budget that the WTRU was given after some time has elapsed (e.g., determined by removing the elapsed time after reception of the first PDU of the PDU set from the original PSDB). In certain cases discussed herein, PSDB and remaining PSDB may be used interchangeably.

[0113] PDU set information may include one or more of: a PSDB, remaining PSDB, PDU set priority, PDU set size, PSIHI or related information, arrival indication / time of the first PDU of a PDU set, and / or a slot number or absolute time associated with the expiry of the PSDB of a PDU set

[0114] The PSIHI or related information may indicate whether a PDU set should be discarded if one or more of the PDUs cannot be delivered on time, the number or percentage of which when are not delivered on time may prevent the reconstruction of the PDU set at the receiving end.

[0115] PDU set information may be exchanged between WTRUs. Such WTRUs may be sidelink WTRUs and possibly a remote WTRU and a relay WTRU. Such WTRUs may be collaborating WTRUs, such as WTRUs connected via SL, IAB, or using a non-3GPP link (such as two WTRUs that may be collocated or connected with an ideal link).

[0116] A remote WTRU may transmit to a relay WTRU, or a relay WTRU may receive from the remote WTRU.

[0117] In an embodiment, a remote WTRU may transmit XR traffic communicating with a WTRU to a NW relay over a sidelink. The SL WTRU performing transmission over sidelink may be a remote WTRU transmitting to a WTRU to a NW relay. For example, the SL WTRU may use conditions associated with its XR traffic or associated with the relay WTRU and / or link to the relay WTRU to determine SL resource transmission behavior.

[0118] In embodiments, an SL WTRU may transmit XR traffic to another SL WTRU. The SL WTRU performing transmission over SL may transmit the XR traffic to another WTRU (e.g., a rendering device). The SL WTRU may use conditions associated with its XR traffic or conditions associated with the receiving SL WTRU and / or link to the receiving SL WTRU to determine SL resource transmission behavior.

[0119] In embodiments, a SL relay WTRU may receive XR traffic from another SL WTRU (e.g., a remote WTRU or another relay WTRU) and may relay the traffic to another SL relay WTRU (e.g., over SL), a SL destination WTRU, or a network node. This embodiment may include multi-hop U2N or U2U relaying.

[0120] The SL WTRU performing transmission over SL may be transmitting XR traffic received from another SL WTRU (e.g., a remote WTRU or another SL relay WTRU) to another SL WTRU. The SL WTRU may use conditions associated with the received XR traffic over SL or conditions associated with the receiving SL WTRU and / or link to the receiving SL WTRU to determine SL resource transmission behavior.

[0121] In embodiments, a WTRU may transmit XR traffic to a network node using SL or using Uu. A WTRU generating XR traffic may transmit the traffic to a network node using Uu or using SL. If SL is used to transmit the traffic, the WTRU may use conditions associated with the XR traffic or the receiving network node. Alternatively, aWTRU generating XR traffic over Uu may, in the very general sense, adapt the aggressiveness of its transmission as the PSDB window progresses or based on the amount of remaining data still to be transmitted by the WTRU.

[0122] All embodiments disclosed herein may apply to any kind of traffic / service where there is a dependency between a certain subset of the PDUs.

[0123] In a WTRU2NW relay architecture, the relay WTRU terminates the RLC layer and, as such, doesn't have PDCP level information. Thus, enhancements are required (e.g., information from the remote WTRU to the relay WTRU) to enable the embodiments described herein.

[0124] In embodiments, the remote WTRU, upon determining that it is transmitting the XR traffic via a relayed link, may refrain from performing segmentation at the RLC level. That is, each PDCP PDU (e.g., RLC SDU) will be mapped into one RLC PDU. That way, there will be a 1 :1 mapping between PDCP PDUs and RLC PDUs, and as such, information relevant to PDCP PDUs can be inferred from RLC PDUs (as further elaborated in the sections below).

[0125] In embodiments, the remote WTRU may be configured to apply the 1 :1 mapping between PDCP and RLC for all XR bearers.

[0126] In embodiments, the remote WTRU may be configured to apply the 1 :1 mapping between PDCP and RLC for a subset (e.g., only a subset) of the XR bearers (e.g., configured by the gNB in the RLC / PDCP configurations) while it is allowed to perform RLC segmentation for the rest of the XR bearers.

[0127] In embodiments, the remote WTRU may be configured to apply the 1 :1 mapping between PDCP and RLC for (e.g., only for) the PDUs of certain PDU sets within a given XR bearer while it is allowed to perform RLC segmentation for the other PDUs of a PDU set.

[0128] For example, the WTRU may be configured to apply this behavior for (e.g., only for) the PDUs of a PDU set with one or more characteristics that may include PSDB below / above a certain threshold, remaining PSDB below / above a certain threshold, importance level below / above a certain threshold, PSI HI PDU sets, and non-PSIHI PDU sets.

[0129] In embodiments, the remote WTRU may be configured to apply the 1 :1 mapping between PDCP and RLC for PDU sets depending on the SL radio conditions. For example, the WTRU may be configured to apply the 1 :1 mapping between PDCP and RLC PDUs when (e.g., only when) the SL RSRP / RSRQ is above a certain threshold but allowed to perform RLC segmentation when the SL RSRP / RSRQ is below the threshold. For example, the WTRU may be configured to apply the 1 :1 mapping when (e.g., only when) the SL CBR is below a certain threshold but allowed to perform RLC segmentation when the CBR is above the threshold.

[0130] In embodiments, the remote WTRU may indicate (e.g., in the RLC PDU header) that an RLC PDU includes the first PDU of the PDU set.

[0131] In embodiments, the remote WTRU may indicate (e.g., in the RLC PDU header) that an RLC PDU includes the last PDU of the PDU set.

[0132] In embodiments, the remote WTRU may indicate to the relay WTRU about the sequence number (SN) space of the PDU set (e.g., the SN of the RLC PDU that corresponds with the first PDU of the PDU set, the SN of the RLC PDU that corresponds with the last PDU of the PDU set, the SN range, e.g., the first and last SN of the RLC PDUs that correspond with the PDU set, etc.,).

[0133] In embodiments, this information is included in the RLC PDU header. For example, in the RLC PDU that corresponds to the first PDCP PDU of the PDU set, the remote WTRU may include the SN of the last RLC PDU that will include the last PDCP PDU of the PDU set. Alternatively, the remote WTRU may include the total number of RLC packets that will be in the PDU set instead of the last SN.

[0134] In embodiments, the remote WTRU may not have this information available when it starts receiving the PDUs of the PDU (e.g., the application layer is not providing the PDUs all at once to the PDCP or it is not providing separate metadata to the AS layer about the PDU set). In these cases, the remote WTRU may not be able to provide the SN space or the number of packets in the PDU set in the header of the first RLC PDU corresponding to the PDU set. Additionally, or alternatively, the remote WTRU may provide the information to the relay WTRU when it becomes available (e.g., the last PDU of the PDU set is received from application layer, the application layer informs the AS layer about the PDU set size in the middle of the PDU set reception at PDCP, etc.) in the header of any subsequent RLC PDU that it is sending after the PDU set information has become available (e.g., in the first RLC PDU that is being sent after the PDU set information has become available).

[0135] In embodiments, the information regarding the SN space of the PDU set may be provided to the relay WTRU via an RLC Control PDU (e.g., a RLC control PDU).

[0136] In embodiments, the remote WTRU may indicate to the relay WTRU any of the information above (e.g., which RLC packet includes the first PDU of the PDU set, which RLC packet includes the last PDU of the PDU set, the SN space of the PDU set, etc.) in a MAC CE (e.g., a MAC CE that is included within the same transport block that includes the first / last / intermediate RLC PDU of the PDU set).

[0137] In embodiments, the remote WTRU may indicate to the relay WTRU any of the information above (e.g., which RLC packet includes the first PDU of the PDU set, which RLC packet includes the last PDU of the PDU set, the SN space of the PDU set, etc.) in an SL-RRC message.

[0138] In embodiments, the remote WTRU may not have the exact information about the PDU set size at the beginning of the reception of the PDUs of the PDU set and may send an indication with the estimate of the size (e.g., the number of packets, the SN space, etc.). If the WTRU gets the exact information about the PDU set size later, it may send an indication that corrects the previous information (e.g., overrides the information or makes a correction such as delta information from the previously sent information).

[0139] Apart from the size of the PDU set, other information such as the PDU set type, importance, PSDB, remaining PSDB, whether the PDU set is a PSIHI PDU set, etc., may also be provided to the relay WTRU by the remote WTRU. Similar mechanisms as described above may be used to indicate such information to the relay WTRUand the different types of information may be included all together at once (e.g., within the same MAC CE, SL-RRC message, RLC header, etc.) or separately (e.g., in different MAC CEs), for example, if the different information becomes available at the remote WTRU at different times.

[0140] The PSDB or remaining PSDB value may be an exact time value, or it may be a preconfigured index that is associated with a range of PSDB values (e.g., index=1 if PSDB < valuel , index =2 if PSDB is greater than or equal to value 1 but below value2, index =3 if PSDB is greater than or equal to value 2 but below value 3, etc.).

[0141] The PDU set size may be an exact PDU set size value (e g., actual size in bytes, number of PDUs, etc.), or it may be a preconfigured index that is associated with a range of PDU set size values (e.g., index=1 if PDU set size < 10 PDUs, index =2 if PDU set size is greater than or equal to 10 PDUs but below 20 PDUs, index =3 if PDU set size is greater than or equal to a value of 20 PDUs but below 30 PDUs, etc.).

[0142] In embodiments, the remote WTRU may indicate in the RLC PDU header that the RLC PDU includes an intermediate PDU and the placement of the PDU within the PDU set (e.g., this PDU is the PDU that is located 50% farther from the start of the first PDU of the PDU set).

[0143] In embodiments, the remote WTRU may assign an ID to a PDU set and communicate that to the relay WTRU. For example, the PDU set ID may be included in the RLC packet header to indicate to which PDU set the data included within the RLC packet belongs. Since NR RLC does not perform concatenation (e.g., no possibility of having PDCP PDUs from different PDU sets combined within one RLC packet), one (e.g., only one) such indication is needed. Such an approach will work even in the case of overlapping PDU sets (e.g., a WTRU starts receiving a PDU set from the application layer while still waiting for some of the PDUs of a previous PDU set).

[0144] In embodiments, the remote WTRU may separately communicate to the relay WTRU the PDU set ID and the relevant RLC SNs for that PDU set (e.g., SN of the RLC packet that includes the first PDU of the PDU set, SN of the RLC packet that includes the last PDU of the PDU set, the RLC SN space / range for the PDU set). For example, this can be done via MAC CE, SL-RRC message, or even in one of the headers of the RLC PDUs that include data of the concerned PDU set.

[0145] If the remote WTRU was not initially sure about the size of the PDU set and has sent (e.g., only sent) an estimated information (e.g., an estimated SN of the RLC PDU that includes the last PDU of the PDU set), a situation may arise where there are RLC packets at the receiver RLC at the relay WTRU waiting to be received that will never be received. For example, if the remote WTRU has estimated a PDU set will be included within 10 RLC packets (SN=x to SN=x+10), but in the end, it was sufficient to use (e.g., only use) 8 RLC packets to transmit the PDU set, RLC packets with SN x+9 and x+10 will never be received This may cause stalling at the receive RLC window and hurt the performance / throughput (e.g., as the next PDU set may start with RLC packet with SN x+11).

[0146] In embodiments, the remote WTRU may explicitly communicate to the relay WTRU about such SN holes (e.g., send an indication in a MAC CE, RLC control PDU, in a header of a certain RLC PDU, etc.) that the relay WTRU may assume the indicated SNs as received (e.g., and progress the left edge of the RLC receive window).

[0147] In embodiments, the remote WTRU may implicitly communicate to the relay WTRU about such SN holes. For example, for the example case above, if the relay WTRU receives the RLC PDU with SN=x+9 that has an indication (e.g., in the RLC header) that this includes the first PDU of a PDU set, or if it receives the RLC PDU with SN=x+8 that indicates this includes the last PDU of the PDU set, the relay WTRU may deduce that the SNs x+9 and x+10 belong to a second PDU set and not the first PDU set.

[0148] In embodiments, the relay WTRU may become aware of the PDU set characteristics (e.g., PSDB, importance level, PDU set type, PSI HI , etc.) as well as which PDU of the PDU set is included in the SL-RLC PDU received from the remote WTRU.

[0149] A remote WTRU may transmit a discard indication to a relay WTRU or vice versa. In embodiments, a WTRU may transmit an indication to a peer WTRU following the first WTRU's decision to perform the discard of a PDU set. This indication may include a set of PDUs, or an identifier associated with the set of PDUs to be discarded. The peer WTRU may use the indication and may subsequently discard the PDUs.

[0150] A remote WTRU may be configured with conditions related to its XR traffic to be transmitted. In embodiments, a WTRU may be configured with one or a combination of conditions related to XR-related traffic, which may be used to trigger one or more actions related to communication via a relay WTRU. Such actions may include the triggering of transmission of data or control (e.g., a MAC CE) to a relay WTRU. Specifically, the conditions may result in initiating the transmission of data or the transmission of control information, such as PDU set information, to a relay WTRU.

[0151] The actions may also include triggering a change in the mechanism, parameters, or scheme for data transmission to the relay WTRU, possibly on sidelink, such as: changing / determining the transmission mode (mode 1 or mode 2) on sidelink and changing / determining the resource selection parameters for mode 2 resource allocation.

[0152] The actions may also include changing / determining the number of carriers used for transmission on sidelink

[0153] The actions may also include triggering a discard of the PDU set.

[0154] The actions may also include triggering resource reselection.

[0155] In embodiments, a WTRU may perform one or more of the above-described actions based on any or a combination of the following: the size of one or more PDU sets; the value of the PSDB for one or more PDU sets; the remaining time associated with the PSDB for one or more PDU sets; the amount, portion of data, or percentage of data associated with one or more PDU set already transmitted to the relay WTRU; the amount, portion of data, or percentage of data associated with one or more PDU set still to be transmitted to the relay WTRU; the amount, portion of data, or percentage of data associated with one or more PDU set still to be received by the remote WTRU from upper layers; and the remote WTRU receives an indication from the relay WTRU to discard a PDU set.

[0156] For example, the remote WTRU may trigger an action or determination when the time remaining for a successful transmission of the PDU set (based on the PSDB) is below a network configured threshold time.

[0157] For example, the remote WTRU may trigger an action or determination when the amount of data remaining in the PDU set still to be transmitted by the WTRU is above a configured threshold amount of data, possibly at a configured / specified or dynamically determined time, where such time may be related to the PSDB (e.g., some configured delta time period prior to the expiry of the PSDB for a PDU set).

[0158] For example, the WTRU may be configured with multiple time instances (e.g., slots) within the PSDB window of a PDU set. At each instance, the WTRU may be configured with a maximum amount of data to be transmitted to the relay WTRU or a minimum amount of data already transmitted to the relay WTRU. The WTRU may, at any of the time instances configured, trigger an action or determination when the maximum amount is above a threshold or when the minimum amount is below a threshold.

[0159] For example, the remote WTRU may be configured with two or more ranges of time periods associated with a PSDB (e.g., the first portion of the PSDB, the second portion of the PSDB, etc.), and may be configured with different actions or determinations for each range of time period.

[0160] For example, the remote WTRU may trigger an action or determination when the PSDB associated with the PDU set is below / above a network configured threshold or within the range of two network configured thresholds.

[0161] For example, the remote WTRU may trigger an action or determination when the PDU set size is above a network configured threshold.

[0162] For example, the remote WTRU may trigger an action or determination when the number of PDU sets pending for transmission is above a network configured threshold or when the amount of data associated with data of one or more PDU sets is above a network configured threshold.

[0163] For example, the remote WTRU may trigger an action or determination if (e.g., only if) the PDU set is associated with a discard operation based on PSI HI.

[0164] For example, the remote WTRU may trigger an action or determination if (e.g., only if) the PDU set has a high priority.

[0165] For example, the remote WTRU may trigger an action or determination when the amount of data remaining to be transmitted associated with a PDU set divided by the amount of time remaining in the PSDB (e.g., in a number of slots) is above / below a threshold

[0166] For example, the remote WTRU may trigger an action or determination (e.g., resource reselection) when it receives an indication / message from the relay WTRU indicating that a PDU set has been (or should be) discarded (by the relay and the remote WTRU).

[0167] A remote UE may be configured with conditions associated with its own transmission, possibly via the relay. In embodiments, a WTRU may be configured with one or a combination of conditions related to XR-related traffic, which may be used to trigger one or more actions related to communication via a relay WTRU. Such actions may include the triggering of transmission of data or control (e.g., a MAC CE) to a relay WTRU. Specifically, theconditions may result in initiating the transmission of data or the transmission of control information, such as PDU set information, to a relay WTRU.

[0168] The actions may further include triggering a change in the mechanism, parameters, or scheme for data transmission to the relay WTRU, possibly on sidelink, such as: changing / determining the transmission mode (mode 1 or mode 2) on sidelink and changing / determining the resource selection parameters for mode 2 resource allocation.

[0169] The actions may further include changing / determining the number of carriers used for transmission on sidelink.

[0170] The actions may further include triggering a discard of the PDU set.

[0171] The actions may further include triggering resource reselection.

[0172] A UE may perform one or more of the actions above based on any or a combination of the following: a condition based on the number, amount, size, or timing of any SL grants, possibly where such timing is related to the PDU set information associated with timing; a condition based on the SL measurements, such as SL RSRP, SL CBR, SL CQI reports, etc., associated with the link to the relay WTRU; a condition based on the timing of, or contents of, information received from the relay UE, possibly in a control message, data, header; a condition based on the coverage situation of the remote UE, such as whether the remote UE is in coverage, out of coverage, etc.; and a condition based on the number of hops to the destination (which may be determined from signaling with the relay UE), the type of destination (e.g., UE or NW), and / or the number of alternate paths to the destination.

[0173] The control message, data, header, etc., may include flow control indication; information about the quality of the next hop of the data, such as Uu RSRP (for a U2N relay) SL RSRP (for a U2U relay), etc.; and indication from the relay WTRU about an error condition such as Uu RLF, SL RLF, RRC connection failure, HO, reselection, etc., which may be received from a SL notification message from the remote WTRU.

[0174] For example, the remote WTRU may trigger an action or determination when a flow control indication is received from the relay WTRU and congestion is indicated.

[0175] For example, the remote WTRU may trigger an action or determination when the SL RSRP is below or above a threshold.

[0176] For example, the remote WTRU may trigger an action or determination when the number of hops is below or above a threshold.

[0177] For example, the remote WTRU may trigger an action or determination when the number and / or size of SL grants within the PSDB is below a threshold amount or below an amount related to the amount of data associated with the PDU set still to be transmitted.

[0178] A relay WTRU may receive PDU set information from a remote WTRU A relay WTRU may receive such PDU set information in a MAC CE, RRC message, protocol header, protocol control PDU, SCI, or physical layer channel (e.g., PSFCH).

[0179] A relay WTRU may initiate an SR / BSR and / or discard trigger in consideration of PSDB indication by a remote WTRU.

[0180] In the normal Uu case, when the WTRU has XR traffic, the traffic may be available at the WTRU, and the WTRU may inform the network of the PDU set information (e.g., PDU set size, PSDB). The network may schedule the WTRU in accordance with the PDU set information.

[0181] In the case of relaying, the network may be aware of the PDU set information but may not be aware of the amount of data of the PDU set that has reached the relay at a given time. The amount of data of the PDU set that has reached the relay at a given time may be important for the network to correctly schedule the relay WTRU and may also be needed at the relay WTRU to trigger the discarding of data belonging to a PDU set that already has the PSDB elapsed (or expected to be elapsed). For example, there is a difference between the network's scheduling decision when the entire PDU set is present at the relay WTRU and half (for example) of the PSDB has elapsed, compared to when a portion (e.g., a small portion) of the entire PDU set is present at the relay WTRU and half (for example) of the PSDB has elapsed.

[0182] A relay WTRU may trigger a SR / BSR based on an amount of data yet to be received for a PDU set at a time indicated by the remote WTRU. The relay WTRU may be configured to relay data from the remote WTRU to the network. A relay WTRU may be configured with configuration information for relaying data comprising one or more of: a first delta (e.g., deltal), a second delta (e.g., delta2), a first threshold (e.g., threshold 1 ), and a second threshold (e.g., threshold2). For example, the relay WTRU may receive the configuration information. The first delta may be a first timing threshold, delta_BSR (e.g., a time delta for triggering a BSR for PDU set data) and the second delta may be a second timing threshold, deltajdiscard (e.g., a time delta for triggering a discard of PDU set data). The first threshold may be a data threshold, threshold_BSR (e.g., for triggering a BSR of PDU set data received from the remote WTRU) and the second threshold may be a threshold_discard (e.g., for triggering a discard of PDU set data received from the remote WTRU). The relay WTRU may receive, from the remote WTRU (e.g., in a MAC CE), PDU set information. The PDU set information may include a PDU set size of a first PDU set and / or a time (e.g., a slot number (X)) from the remote WTRU corresponding to the timing of the PSDB expiry of the first PDU set. The timing of the PSDB expiry may be considered a time that the PSDB is exceeded.

[0183] If (e g., the amount of data associated with the PDU set still to be received at a first time (e.g., slot number X-delta1) is larger than the first threshold, the relay WTRU may trigger a SR / BSR to the network and / or may indicate the amount of data still to be received If the amount of data associated with the PDU set still to be received at a second time (e.g., slot number X-delta2) is larger than the second threshold, the relay WTRU may discard buffered and / or future (e.g., all buffered and future) received PDUs associated with the same PDU set, indicate discarding of the PDU set (e.g., and a rationale for discarding) to the remote WTRU, and / or send a BSR to the network. For example, the relay WTRU may send the BSR for the first PDU set to the network based on determining that anamount of data remaining to be received from the remote WTRU for the first PDU set at a time corresponding to the first timing threshold prior to the time associated with the PSDB expiry is greater than the first data threshold.

[0184] A relay WTRU may determine a condition associated with the status of PDU set reception.

[0185] A relay WTRU may receive a PDU set from a remote WTRU to be relayed to the network. A relay WTRU may determine a condition associated with the status of PDU set reception from a remote WTRU. This determination may relate to one of the following factors or a combination of such factors: the amount, portion, or ratio of the PDU set that has been received by the relay WTRU; the amount, portion, or ratio of the PDU set that has yet to be received by the relay WTRU but which the relay WTRU is aware of (e.g., from reception of PDU set information described herein); the priority, importance, or other characteristics of the PDU set; and a time criteria associated with the PDU set.

[0186] The time criteria may include any or a combination / relation between the following times: the time in which the relay WTRU received the first PDU of the PDU set; the time in which the relay WTRU received the PDU set information; the time, possibly indicated by the remote WTRU, in which the PSDB will expire or be exceeded; the time, possibly associated with the end indication of a PDU set (e.g., in the last RLC PDU that includes the last PDU of PDU set); the PSDB value associated with the PDU set; the remaining time (e.g., remaining PSDB) value associated with the PDU set, as received by the relay WTRU at a given time; the time associated with a grant (e.g., configured grant, a dynamic grant) at the relay WTRU (e.g., the start offset or periodicity of a CG configuration); and a NW configured threshold time difference and / or a condition associated with any of the above time values with such threshold.

[0187] A relay WTRU may trigger a discard operation based on the status of PDU set reception.

[0188] The relay WTRU may perform the discard of the RLC PDUs that it is going to transmit over the Uu that corresponds with a certain PDU set based on an indication received from the remote WTRU (e.g., MAC CE, SL- RRC, SL-RLC Control PDU, etc.,). For example, the remote WTRU may indicate to the relay WTRU that it has decided to discard a PDU set, and based on this indication, the relay WTRU may discard any pending RLC PDUs on the Uu link that are associated with the indicated PDU set.

[0189] The remote WTRU may indicate to the relay WTRU the identity of the PDU set that is being discarded at the remote WTRU.

[0190] The remote WTRU may indicate to the relay WTRU an SL-RLC SN (e.g., corresponding to the last or the first SN of the SL-RLC PDU that included data of the PDU set).

[0191] The remote WTRU may indicate to the relay WTRU a set of or a range of SL-RLC SNs.

[0192] The relay WTRU may keep (e.g., maintain and / or store) a mapping of the SL-RLC SNs to the Uu-RLC SNs (e.g., that SN of Uu RLC that includes the data received from the remote WTRU in an SL-RLC with a certain SN). For example, the mapping could be 1 :1 (e.g., each SL-RLC packet corresponds to a Uu-RLC packet). For example, oneSL-RLC packet may correspond to multiple Uu-RLC packets. For example, one Uu-RLC packet may include data from multiple SL-RLC packets.

[0193] In embodiments, the relay WTRU, based on the discard indication received from the remote WTRU, may determine the corresponding / relevant Uu RLC PDUs and may discard all the corresponding Uu RLC PDUs.

[0194] In embodiments, the relay WTRU may discard the corresponding Uu RLC PDUs if (e.g., only if) a certain percentage of the PDU set's data has already been successfully transmitted over the Uu.

[0195] In embodiments, the relay WTRU may discard the corresponding Uu RLC PDUs if (e.g., only if) a certain percentage of the PDU set's data remains to be transmitted over the Uu.

[0196] In embodiments, the relay WTRU may discard (e.g., discard only) a certain percentage of the corresponding Uu RLC PDUs (e.g., randomly, ones with lower SNs, ones with higher SNs, etc.).

[0197] In embodiments, the relay WTRU may discard the corresponding Uu RLC PDUs or a certain percentage of them, depending on the Uu-UL buffer status at the relay WTRU (e.g., perform the discards only if the UL buffer level is above a certain threshold).

[0198] In embodiments, the relay WTRU may discard the corresponding Uu RLC PDUs or a certain percentage of them, depending on the UL resource availability (e.g., if there are configured grants available and WTRU expects to send some or all the pending Uu RLC PDUs that correspond with the PDU set, WTRU may refrain from discarding all or a certain percentage of the PDUs).

[0199] In embodiments, the relay WTRU may discard all or a certain percentage of the corresponding Uu RLC PDUs of a certain PDU set after a certain time has elapsed since the reception of a discard indication of the PDU set from the remote WTRU (e.g., the relay WTRU will discard the Uu RLC PDUs corresponding to the PDU set that the remote WTRU has indicated to be discarded that are still in the relay UE's buffer).

[0200] In embodiments, the relay WTRU may determine to discard some or all of the Uu RLC PDUs that correspond with a given PDU set without receiving an explicit indication from the remote WTRU. For example, upon determining the Uu UL buffer level at the relay WTRU is above a certain level, the relay WTRU may discard some or all of the Uu RLC PDUs associated with PDU sets that have one or more of the following characteristics: importance level below a certain level; TTL below a certain level; with a certain percentage of the PDU set data remaining to be sent; with more than a certain percentage of PDU set data remaining to be sent; PSI HI PDU sets; and PDU sets of a certain type.

[0201] In embodiments, the relay WTRU may receive a general indication (e.g., from the remote WTRU, from the network) that is related to discard operations (e.g., without specifying a PDU set identity, RLC SN or SNs, etc.) and the relay WTRU may determine which Uu RLC PDUs to discard.

[0202] In embodiments, the relay WTRU, after performing a discard operation that leads to the discarding of one or more Uu RLC PDUs, sends an indication to the network (e.g., in RLC control PDU, RLC header, MAC CE, RRCmessage, etc.,) indicating the SNs of the PDUs that have been discarded. This indication ensures that the peer RLC receive entity at the gNB will not experience stalling while waiting for RLC PDUs that will never be sent.

[0203] In embodiments, the relay WTRU, after performing a discard operation that leads to the discarding of the outstanding Uu RLC PDUs corresponding to a PDU set (without getting an explicit discard indication from the remote WTRU), sends an indication to the remote WTRU (e.g., in SL-RLC control PDU, SL-RLC header, SL-MAC CE, SL- RRC message, etc.,) indicating the discard (e.g., PDU set identity, SL-RRC SNs corresponding to the of the Uu RLC PDUs that has been discarded, etc.). Upon getting such an indication, the remote WTRU may discard any parts of the corresponding PDU set (e.g., SL-RRC PDUs) that are still pending to be transmitted (or buffered at the PDCP level pending confirmation from the gNB).

[0204] The relay WTRU may trigger the discard operation of a PDU or PDU set, or part thereof received from the remote WTRU based on one or more of the following factors.

[0205] The trigger to discard the PDU may be based on the PSDB of the PDU set having expired and / or been exceeded.

[0206] The trigger to discard the PDU may be based on the PDB of any one or more constituent PDUs of the PDU set having expired and / or been exceeded.

[0207] The trigger to discard the PDU may be based on the PDB of a specific PDU of the PDU set having expired and / or been exceeded. In embodiments, the relay WTRU may discard the remaining PDUs of the PDU set if the PDB of a specific PDU of the PDU set (e.g., the first PDU of the PDU set) has expired and / or been exceeded.

[0208] The trigger to discard the PDU may be based on the PDB of a specific subset of PDUs of the PDU set having expired and / or been exceeded. In embodiments, the relay WTRU may discard the remaining PDUs of the PDU set if the PDB of the first few PDUs of the PDU set (e.g., in the header that may include information on the PDU set) has expired and / or been exceeded.

[0209] The trigger to discard the PDU may be based on the PDU set importance (PSI). In embodiments, the relay WTRU may discard the PDU set if it is of low importance (e.g., PSI < threshold configured by the network).

[0210] The trigger to discard the PDU may be based on the importance of PDUs within the PDU set. In embodiments, the relay WTRU may discard the PDU if it is of low importance, irrespective of the PSI of the PDU set the PDU may belong to.

[0211] The trigger to discard the PDU may be based on the presence of congestion. For example, the WTRU may be able to detect congestion (e.g., based on buffer level monitoring at the WTRU and / or if the WTRU is unable to transmit data in its buffer due to congestion leading to buffer level overflow). As another example, the WTRU may receive an indication of congestion from the network (e.g., due to heavy loading at the network).

[0212] The trigger to discard the PDU may be based on the reception of indication from the remote WTRU to discard a PDU set or part thereof. In embodiments, the relay WTRU may receive an indication from the remote WTRU to discard some PDUs of a PDU set that should have been discarded at the remote WTRU but may havealready been transmitted to the relay WTRU. In embodiments, the relay WTRU may receive an indication from the remote WTRU of when to perform the discard (e.g. , at which slot, after what percentage of the PSDB has elapsed, etc.). The remote WTRU may receive this indication (e.g., at the same time as receiving the PDU set or part thereof from the remote WTRU). An indication may include information on the identity of the PDU and / or PDU set (e.g., PDU set sequence number, PDU number in PDU set, etc.). For example, (1 ,1), (1 ,2), and (1,3) may be signaled to identify PDUs 1 , 2, and 3 in PDU set 1.

[0213] The trigger to discard the PDU may be based on the reception of an indication from the network. The indication from the network may be the status of the successful delivery of PDU. For example, the WTRU (e.g., transmitting PDCP entity in WTRU) may trigger the discard of a PDU if it receives an indication from the network (e.g., receiving PDCP entity in gNB) that the PDU has been successfully received at the network.

[0214] The indication from the network may be the status of the successful delivery of the PDU set. The status of successful delivery may be delivered on a PDU set basis (as opposed to on a PDU basis as in legacy). On reception of an indication from the network (e g., receiving PDCP entity in gNB) that the PDU set was successfully received at the network, the WTRU (e.g., transmitting PDCP entity in WTRU) may trigger the discard of any copies of the PDUs of the PDU set. The indication may include information on the identity of the PDU and / or PDU set (e.g., PDU set sequence number, PDU number in PDU set, etc.). For example, (1 ,1), (1 ,2), and (1 ,3) may be signaled to identify PDUs 1 , 2, and 3 in PDU set 1 .

[0215] The trigger to discard the PDU may be based on indications from the application and / or other layers in the WTRU. In embodiments, the WTRU (e.g., transmitting PDCP entity in WTRU) may receive an indication from higher / application layers in the WTRU to discard a PDU set, or part thereof based on the application no longer needing that PDU set or part thereof. In embodiments, the WTRU (e.g., a transmitting RLC entity in the WTRU) may receive a portion of PDUs of the PDU set that are pushed down into the lower layers (e.g., RLC channels) before the remaining PDUs of the PDU set are received at the PDCP. Suppose the PDCP does not receive the remaining PDUs of the PDU set or determines that it will not receive the remaining PDUs of the PDU set within the PSDB. In that case, an indication may be sent to the lower layers (e.g., RLC, MAC) to trigger the discard of the first portion of the PDUs of the PDU set, as they may no longer be useful in the decoding of the PDU set.

[0216] The trigger to discard the PDU may be based on a combination of one or more of these factors. For example, the relay WTRU may discard (e.g., only discard) low importance PDU sets if congestion is detected on the Uu link with the network.

[0217] In embodiments, the discard operation depends on one or more characteristics of the PDU set. For example, the discard operation may be applied if (e.g., only if) the PDU set is a PSI HI PDU set. For example, the discard operation may be applied if (e.g., only if) the PDU set has a certain importance level.

[0218] There may be relay WTRU actions associated with triggering discard operation. The relay WTRU may send an indication to the network or may send an indication to the remote WTRU.

[0219] The indication of discard to the network may avoid reordering delays if the network is expecting the reception of some PDUs / PDU sets. It may be mandatory for the WTRU to report the discard of any PDUs or PDU set or part thereof that were discarded on the basis of the PSIHI indicator, and the WTRU may be configured as such (e.g., PDCP and / or RLC discard Indication from UE to network).

[0220] The indication to the network may include information on the identity of the PDU and / or PDU set (e.g., PDU set sequence number, PDU number in PDU set, etc.). For example, (1 ,1), (1 ,2), and (1 ,3) may be signaled to identify PDUs 1, 2, and 3 in PDU set 1.

[0221] The indication to the network may also be with regard to a grant that will not be used. For example, the WTRU may send an indication of any unused CG PUSCH occasions to the network based on the payload of data in the WTRU buffers and / or impact(s) from the discard mechanism.

[0222] The indication to the network may be (e.g., only be) transmitted when the UE has discarded the PDUs / PDU sets. Indication of expected PUSCH usage (e.g., number / percentage of unused / used PUSCH resources) being transmitted too early may result in the network reallocating the configured PUSCH resources to other WTRUs.

[0223] The indication may be transmitted when the WTRU has discarded the PDUs / PDU sets. Indication of expected PUSCH usage (e.g., number / percentage of unused / used PUSCH resources) being transmitted too late may not be useful to the network if it is unable to reallocate the resources.

[0224] The indication to the network may be a BSR. In embodiments, if the relay WTRU previously sent a BSR requesting a certain amount of data and the relay WTRU later did some discarding, it may send another BSR with an updated payload that may cancel the first BSR that was transmitted. The relay WTRU may send a preemptive BSR based on the expected size of the PDU set (e.g., by comparing the expected size with a threshold_BSR, a threshold discard, or a different threshold). Later on, following the discard operation, it may transmit an actual BSR. Reception of an actual BSR at the network may take priority over a preemptive BSR.

[0225] Since there may be several reasons for the relay WTRU to perform discard (e.g., expiry of PDB / PSDB, reception of status report from receiving end, PSI being less than a threshold, high congestion resulting in inability to transmit and buffer overflow at UE, etc.), the WTRU may include the rationale behind the discarding in an indication to the network.

[0226] The indication to the remote WTRU may include information on the identity of the PDU and / or PDU set (e.g., PDU set sequence number, PDU number in PDU set, etc.). For example, (1, 1), (1 ,2), and (1 ,3) may be signaled to identify PDUs 1 , 2, and 3 in PDU set 1.

[0227] The indication to the remote WTRU may include a purpose and / or rationale of discard.

[0228] In examples, the relay WTRU sends a BSR to the gNB regarding the amount of data of a PDU set that is yet to be received at the relay WTRU (e.g., pending at the remote WTRU) and / or an estimated / expected time that this data is to become available. For example, multiple data sizes (e.g., in number of PDUs, bytes, percentage of the PDU set, etc.) and estimated / expected time values can be specified in one BSR.

[0229] A relay WTRU may change BSR reporting based on the time between reception of an indication from a remote WTRU and corresponding PDU set information from that remote WTRU.

[0230] The start of the PDU set, and the information associated with the PDU set (e.g., the size and the PSDB) may not be received at the relay WTRU at the same time, especially in the case of multi-hop. For a WTRU2NW relay, BSR information could be sent about the entire PDU set, assuming this information is available. However, if not present immediately, the network should still be aware of the PDU set to schedule any data received related to the PDU set. In essence, without PDU set information at the network, there is an uncertainty about the scheduling requirements of the data associated with a PDU set arriving at the relay WTRU, which is not the case when PDU set information is received.

[0231] In embodiments, a relay WTRU may receive an indication signaling the first PDU of a PDU set transmitted by the remote WTRU to the relay WTRU (e.g., in the RLC header on SL). The relay WTRU, if it does not receive timing information (e.g., PSDB) of the corresponding PDU set from the remote WTRU within a configured time period, may initiate periodic BSR (e.g., legacy format) to report (e.g., report only) the logical channel groups (LCGs) associated with the PDU set until PDU set information is received. The relay WTRU, if it receives a PDU set information from the remote WTRU (e.g., in a MAC CE) associated with a PDU set that was previously indicated, may stop periodic BSR if started due to latency between PDU start and information and may trigger regular BSR (e.g., new format) to report the PDU set information along with buffer status.

[0232] In embodiments, if the relay WTRU has not got the full information about an ongoing PDU set (e.g., the relay WTRU has received SL-RLC PDUs that include the first few PDUs of the PDU set but still has not got information about the characteristics of the PDU set, such as the PSDB), it may send a BSR concerning the PDU set depending on the Uu UL buffer level (e.g., if the total UL buffer level is above a certain value or certain percentage, if the UL buffer level corresponding to the concerned PDU set is above a certain value or certain percentage, etc.).

[0233] In embodiments, the relay WTRU may send the BSR depending on the amount of Uu UL resources that it has (e.g., configured grants, dynamic grants that are soon to be used) and the amount of buffer level (e.g., send the BSR only if the amount of available UL resources is lower than the buffer level, or the amount of UL resources is lower than the buffer level by a certain absolute / percentage threshold, etc.).

[0234] In embodiments, when the relay WTRU gets information (e.g., full information) about an ongoing PDU set from the remote WTRU, it may trigger a BSR that includes the detailed information of the PDU set (e.g., how much data of that PDU set is available to be sent at the relay WTRU, how much data of that PDU set is still pending to be received at the relay WTRU from the remote WTRU, what is the expected time arrival of these data at the relay WTRU, where the amount of data is indicated in actual buffer levels, index values represent buffer level ranges, or a percentage level such as a percentage of the PDU set size).

[0235] A relay WTRU may send a BSR to the network with certain information and / or based on certain criteria. The information and / or criteria may include the amount of data in the relay WTRU buffer (e.g., if the amount / volume ofdata in bytes / kbi ts / M bi ts, etc.; number of PDUs in PDU set; number of PDUs; number of PDU sets is above a preconfigured threshold)

[0236] The information and / or criteria may include the upcoming data in the relay WTRU buffer (e.g. , if the upcoming amount / volume of data in bytes / kbits / Mbits, etc.; number of PDUs in PDU set; number of PDUs; number of PDU sets is above a preconfigured threshold). The relay WTRU may have knowledge of the upcoming data from the remote WTRU based on estimations from previous transmissions from the remote WTRU.

[0237] The information and / or criteria may include the amount of data in the remote WTRU buffer (e.g., the remote WTRU may send an indication to the relay WTRU on the amount of data in its buffer).

[0238] The information and / or criteria may include the upcoming data in the remote WTRU buffer (e.g., the remote WTRU may receive indications from its internal application on upcoming data). The remote WTRU may send a corresponding indication to the relay WTRU before the data arrives in its buffer.

[0239] All the aforementioned data (e.g., amount / volume thereof) may be determined in the WTRU (e.g., the relay WTRU or remote WTRU). For example, the MAC entity in the WTRU may determine the amount of UL data available for a logical channel or logical channel group and trigger BSR if any of the following events occur for an activated cell group.

[0240] The aforementioned data for a logical channel (e.g., belonging to an LCG) may become available to the entity responsible for sending a BSR (e.g., MAC entity in relay WTRU).

[0241] The aforementioned data may arrive at the relay WTRU at a logical channel with higher priority than any other logical channel including other / available / buffered UL data belonging to any LCG in the relay WTRU.

[0242] The aforementioned data may arrive at a logical channel belonging to an LCG at the relay WTRU at a time when none of the other logical channels belonging to that LCG have any available / buffered UL data.

[0243] For example, if the relay WTRU does not receive information of the corresponding PDU set from the remote WTRU within a configured time period, it may send periodic BSR (e.g., if it is configured with the parameters for periodic BSR) to report (e.g., report only) the LCGs associated with the PDU set until PDU set information is received.

[0244] For example, if the relay WTRU receives a PDU set information from the remote WTRU (e.g., in a MAC CE) associated with a PDU set that was previously indicated, the relay WTRU may stop the periodic BSR and trigger BSR to report the PDU set information along with the buffer status.

[0245] PDU set information may include any one or more of the following: PDU set size (e.g., bits / bytes, number of PDUs); PDU set type (e.g., PDU set corresponding to l-frame, PDU set corresponding to a P-frame, etc.); start PDU of a PDU set / data burst; end / last PDU of a PDU set / data burst (e.g., end marker); timing information; PDU set importance; and PDU set periodicity (e.g., frame generation rate).

[0246] The timing information may include delay budget / PSDB I PDB. The timing information may further include a timestamp indicating the time when PDU is generated or received in a buffer, remaining delay with respect to adelay budget (e.g., PSDB), hop count (e.g. , number of traversed or remaining hops), timing offset with respect to a reference time (e.g., SFN, the arrival time of first PDU of PDU set).

[0247] In embodiments, the remote WTRU may determine whether to discard packets associated with a PDU set based on information associated with the relay WTRU(s).

[0248] PDU set discard was introduced in XR to avoid using resources to transmit packets associated with a PDU set (or related set of PDUs) that have a common time relationship. Specifically, if a PDU set does not meet its PSDB, any pending PDUs for that PDU set should be discarded to avoid unnecessary use of NW resources. Such a decision may further need to be taken at the remote WTRU. However, the remote WTRU may not have the full information of whether a PDU or set of PDUs pending for transmission at the remote WTRU may be transmitted on time to the end device (e.g., the network) due to the additional transmission stage associated with the relay and the uncertainty associated with the relay WTRU’s own latency. Whether the PSDB will be met end to end will depend on the latency associated with the next hop and / or on how much data is still to be transmitted on the first hop.

[0249] In embodiments, a remote WTRU may determine (e.g., from upper layers) a PSDB associated with the PDU set. The remote WTRU may determine an expected latency over the relay path based on the portion / amount of the PDU set still to be transmitted and information about subsequent hop(s) (e.g., selecting one of a configured latency value associated with each of CBR, CR, SL RSRP, flow control, etc., Uu RSRP, number of hops). The remote WTRU may determine whether the PDU set is associated with discard operation (PSI HI indicator present). The remote WTRU, if the expected latency is larger than the remaining PSDB of the packets and PSIHI is present, may drop all PDUs associated with the PDU set and indicate to the relay WTRU to drop all PDUs associated with a PDU set.

[0250] In embodiments, a remote WTRU may trigger PDU set discard upon the occurrence of specific events.

[0251] A WTRU (e.g., a remote WTRU) may trigger PDU set discard. For example, a WTRU may discard all packets associated with a PDU set upon the occurrence of a specific event. In addition, a WTRU that has triggered PDU set discard may inform another WTRU to which a portion of the PDU set have already been sent (e.g., a relay WTRU). For example, following a decision to discard a PDU set, a remote WTRU may further inform a relay WTRU if the remote WTRU has already successfully transmitted packets of the PDU set to the relay WTRU.

[0252] A remote WTRU may trigger PDU set discard upon the occurrence of one or more of the following events.

[0253] A remote WTRU may trigger PDU set discard upon detection of SL RLF by the remote WTRU.

[0254] A remote WTRU may trigger PDU set discard upon reception of a notification from the relay WTRU, such as indication of a handover experienced by the relay WTRU, indication of Uu RLF by the relay WTRU, indication of RRC connection failure, and indication that the relay UE is moving to RRCJDLE / INACTIVE.

[0255] A remote WTRU may trigger PDU set discard upon reception of a path switch / HO command at the remote WTRU.

[0256] A remote WTRU may trigger PDU set discard upon reception of a flow control message from the relay WTRU. For example, indicating congestion or indicating an increase in the level of congestion.

[0257] A remote WTRU may trigger PDU set discard upon an LBT failure upon an attempt to transmit on an unlicensed spectrum.

[0258] A remote WTRU may trigger PDU set discard upon detection of consistent LBT failure.

[0259] A remote WTRU may trigger PDU set discard upon resource reselection by the remote WTRU.

[0260] A remote WTRU may trigger PDU set discard upon reception of one or more RLC NACK(s) from the relayWTRU.

[0261] A remote WTRU may trigger PDU set discard upon expiry of a timer (or a period of time) started following the occurrence of another event.

[0262] A remote WTRU may trigger PDU set discard upon reception, from the relay WTRU, of an indication of a path change, a change in the QoS splitting characteristics (e.g., the maximum delay incurred by each hop or the first hop), a change in the number of hops to reach the destination, a change in the specific relay(s) on the paths, and / or a change in the RRC state of any of the relays along the path to the destination.

[0263] A remote WTRU may trigger PDU set discard upon reception of a protocol (e.g., PDCP) control PDU.

[0264] A WTRU (e.g., a remote WTRU) may trigger PDU set discard. For example, a WTRU may discard all packets associated with a PDU set when a specific condition is satisfied. Such a condition may further be evaluated at one of the events described above. Specifically, the WTRU may trigger PDU set discard when one of the above events is triggered and when one of the following conditions is met. Additionally, or alternatively, the conditions below may be monitored continuously by the WTRU, and PDU set discard may be triggered when one or a combination of conditions is met.

[0265] Conditions may relate to XR traffic to be transmitted. Specifically, any of the conditions may be monitored by the remote WTRU to determine when to trigger discard of a PDU set. For example, the WTRU may be configured with a time instant associated with the PSDB and a threshold amount of data to be transmitted. If the amount of data to be transmitted by the remote WTRU at the configured time instant is above a threshold, the remote WTRU may discard the PDU set. For example, the WTRU may be configured with a threshold remaining PSDB and / or threshold amount of data still to be transmitted. Upon an event that may trigger discard (e.g., reception of a HO indication by the relay WTRU, trigger of SL RLF, etc.), if the remaining PSDB is below a threshold, and / or the amount of data to be transmitted is above a threshold, the remote WTRU may discard the PDU set.

[0266] Conditions may relate to SL measurements. For example, the remote WTRU may determine whether to discard a PDU set based on SL measurements such as SL RSRP, SL CBR, SL CQI, SL CR, etc.

[0267] Conditions may relate to the QoS split of the data associated with the PDU set over the multiple hops toward the destination. For example, the remote WTRU may determine whether to discard a PDU set based on the QoS split or the PDB configured over the link with the relay WTRU. For example, the remote WTRU may determine the expected latency for transmission of the PDU set using the PDB over the link with the relay WTRU and may discard the PDU set if the expected latency is larger than the remaining PSDB.

[0268] Conditions may relate to an indication of and / or the contents of a flow control message received from the relay WTRU. Specifically, the remote WTRU may be configured with a level of congestion or a specific value of the flow control indication for which the remote WTRU discards a PDU set. Such level of congestion may further depend on other factors, such as the SL measurements, the amount of remaining data to be transmitted for the PDU set, the remaining PSDB, etc.

[0269] For example, a remote WTRU may start a timer following the reception of a flow control message indicating congestion / high load at the relay WTRU. The remote WTRU may have data of a PDU set pending for transmission to the relay WTRU. The value of the timer may further be configured based on the value of the remaining PSDB. For example, the WTRU may be (pre)configured with a timer value associated with each possible range of PSDB. If the WTRU does not receive an additional flow control message indicating alleviation of the congestion problem, the remote WTRU may discard the PDU set.

[0270] Conditions may relate to an indication / information received in the path switch / HO command to the remote WTRU. For example, the remote WTRU may receive an explicit indication of whether or not discard any pending PDU set at the WTRU. In examples, the remote WTRU may receive an implicit indication that dictates the latency associated with the path switch / HO command (e.g., whether or not to perform RACH-less) and under the condition that the remaining amount of data in the PDU set is larger than a threshold and / or the remaining PSDB is smaller than a threshold, the remote WTRU may discard the PDU set.

[0271] The remote WTRU may discard a PDU set based on a determination that resource selection and / or resource usage at the remote WTRU does not result in selection and / or use of a sufficient amount of resources to transmit the remaining data of the PDU set to the relay WTRU. For example, such a determination may include consideration of any or a combination of the following events: if pre-emption occurs on a resource intended for transmission of data from the PDU set; if selection of resources requires an increase in the energy threshold associated with occupied resources by x dB at least a configured number of times; if the number of carriers that can be selected for transmission (e.g., due to measurement of CBR, capability limitation, etc.) is less than a threshold; and / or if dropping of a transmission or a resource, possibly associated with transmission of data from the PDU set, occurs due to LBT failure, UL / SL prioritization, etc.

[0272] In examples, a resource associated with transmission of data from a PDU set may be a resource that was selected with selection parameters (e.g., maximum number of channels) that determined based on the presence of PDU set transmission at the WTRU

[0273] In embodiments, a remote WTRU may determine an expected latency for the PDU set in order to determine whether to discard the PDU set.

[0274] For example, a remote WTRU may determine an expected latency for the PDU set over the relayed path. Such expected latency may be derived as a value of time used to compare with the remaining PDSB. For example, aremote WTRU may compute such expected latency from one or a number of the factors / conditions which determine the discard operation.

[0275] In examples, the remote WTRU may determine the expected latency as a number of slots required for transmitting the remaining data in the PDU set to be transmitted, considering the WTRU selects up to the maximum allowable channel occupancy ratio (CR). If the expected latency is larger than the remaining PSDB, the remote WTRU may discard the PDU set.

[0276] In examples, the remote WTRU may, possibly in addition to the computed expected latency, determine a latency that is a (pre)configured factor times the flow control level indicated by the relay WTRU. If the expected latency is larger than the remaining PSDB, the remote WTRU may discard the PDU set.

[0277] In examples, the remote WTRU may, possibly in addition to the computed expected latency, determine a latency (pre)configured for each range of CBR and / or next hop RSRP (provided by the relay WTRU). If the expected latency is larger than the remaining PSDB, the remote WTRU may discard the PDU set.

[0278] In examples, the remote WTRU may, possibly in addition to the expected latency computed in the previous examples, add an equivalent determined latency for each hop in the case of multi-hop relaying to the remote WTRU. If the expected latency is larger than the remaining PSDB, the remote WTRU may discard the PDU set.

[0279] In examples, the remote WTRU may, possibly in addition to the computed expected latency, multiply one of the expected latencies by a (pre)configured factor associated with the amount of data still to be transmitted to the remote WTRU. If the expected latency is larger than the remaining PSDB, the remote WTRU may discard the PDU set.

[0280] In embodiments, the relay WTRU may send a Uu latency report to the remote WTRU (e.g., including an average and / or expected latency for a Uu RLC PDU over the Uu from the time of reception of the corresponding SL RLC PDU from the remote WTRU). The remote WTRU may use this information to determine whether or not to discard some PDU sets. For example, if the relay WTRU has indicated that the average / expected latency over the Uu is x ms and there is a PDU set at the remote WTRU that still has data pending to be transmitted over the SL to the relay WTRU and the TTL of the PDU set is less than x ms, the remote WTRU may pre-emptively discard the outstanding PDUs of the PDU set.

[0281] In embodiments, a remote WTRU may inform a relay WTRU of a discarded PDU set.

[0282] A remote WTRU that discards a PDU set may send a message to a relay WTRU. Such a message may be a MAC CE, RRC message, SCI, an indication in SCI, an indication in a protocol data header, a protocol control PDU, PUCCH transmission, PSFCH transmission, etc. Such a message may identify the PDU set that was discarded. In examples, methods may be used to identify the PDU sets to be discarded in the transmitted message.

[0283] A remote WTRU may transmit a discard message to a relay WTRU under certain conditions. Such conditions may include any or a combination of: the link to the relay WTRU is not failed / released; the remote WTRU has transmitted at least one PDU in the discarded PDU set to the relay WTRU; the remote WTRU has transmitted atleast a number of PDUs of the PDU set or ratio of PDUs of the PDU set (possibly configured) to the relay WTRU; and transmission of the last PDU associated with the discarded PDU set occurred at most a period of time X (possibly configured) prior to the discard operation.

[0284] A WTRU (e.g., a relay WTRU), upon reception of a discard message, may discard all PDUs associated with the identified PDU set(s) in the discard message. The WTRU may transmit a discard message to the next hop (e.g., to a WTRU or the network node).

[0285] The discard operation may be done by the remote WTRU if the concerned PDU set is a PSI HI PDU set. The discard operation may be done by the remote WTRU because for a PSIHI PDU set to be usable / decodable at the receiver, all the PDUs of the PDU set must be received properly. Thus, the remote WTRU may determine to preemptively discard the pending PDUs of the PDU set if it estimates that they will not be received on time before the PSDB expires.

[0286] In embodiments, the remote WTRU may pre-emptively discard PDUs of a non-PSIHI PDU set upon determining that a certain percentage of the PDU set have already been received at the gNB (e.g., based on an indication / status received from the gNB or the relay WTRU). This can be further constrained by other data pending at the remote WTRU. For example, the WTRU may pre-emptively discard a non-PSIHI PDU if (e.g., only if) a certain percentage of the PDU set have already been received at the gNB and if there are PDUs of a more important PDU set that the concerned PDU set pending to be transmitted at the remote WTRU.

[0287] In embodiments, a relay WTRU may be allowed to use a grant based on the number of remote WTRUs indicating PSDB requirements / issues to the relay WTRU.

[0288] A relay WTRU may serve multiple remote WTRUs, and if each of these remote WTRUs has data to be transmitted before the PSDB boundary, the network may want to allocate resources more urgently to this relay WTRU (compared to a relay WTRU with few or no remote WTRU’s with PDU sets to be transmitted).

[0289] In embodiments, a relay WTRU may be configured with a remaining time threshold and a number of WTRUs threshold. The relay WTRU may be further configured with a grant associated with a logical channel restriction (e.g., a CG). The relay WTRU may receive, from each remote WTRU (e.g., in a MAC CE) PSDB information including a slot number (Xi) from a remote WTRU (i) corresponding to the time of PSDB expiry. The relay WTRU may allow transmission on the grant for data associated with the logical channels for each Uu logical channel including traffic relayed from one or more remote WTRUs, if the number of remote WTRUs, whose traffic is multiplexed into the Uu logical channel and have an indicated Xi which occurs in less than the remaining time threshold from the current slot, is greater than a threshold number of WTRUs.

[0290] In embodiments, the relay WTRU may determine a subset of remote WTRUs / PDU sets to serve.

[0291] A relay WTRU may determine a subset of the remote WTRUs and / or PDU sets that should be served by the relay WTRU. In examples, a relay WTRU may forward XR traffic received from multiple remote WTRUs. The relay WTRU may determine a condition in which the relay WTRU may forward a subset of the XR traffic, possiblyassociated with a subset of the remote WTRUs, while the other traffic (e.g., associated with the non-selected remote WTRUs) may not be relayed. In examples, the relay WTRU may drop one or more PDU sets associated with one or more remote WTRUs in order to ensure that the PSDB requirements of the subset of remote WTRUs are met.

[0292] A relay WTRU may determine that a subset of remote WTRU’s PDU sets should be selected based on a computation that may consider one or more of the following factors: PDU set information received from the remote WTRU and any XR related conditions; any relay related conditions; Uu measurements (e.g., Uu RSRP); SL measurements (e.g., SL RSRP); and number / nature of subsequent hops (e.g , number of hops to the destination, whether the next hop is Uu or SL).

[0293] In embodiments, a relay WTRU may determine an amount of data (e.g., possibly associated with PDU sets transmitted by the remote WTRUs) to be transmitted to the network over Uu within a time window. The time window may include of a (pre)configured time period starting from an evaluation time. The time window may correspond to the minimum / maximum remaining PSDB received from the different remote WTRUs. The time window may correspond to the period of time in which at least X PDU sets or the PDU sets from X WTRUs need to be transmitted to meet the remaining PSDB. The evaluation instance may include fixed and / or predetermined times or may be triggered by an event. For example, the relay WTRU may perform the evaluation upon reception of PDU set information, periodically upon reception of data from a remote WTRU (e.g., possibly associated with a PDU set), etc. The relay WTRU may compute an average amount of data to be transmitted per unit of time within the evaluation window (e.g., per slot). If the average amount of data exceeds a specific value (e.g., a configured threshold, a value associated with its currently allocated grant size, etc.), the relay WTRU may determine that it needs to select a subset of the remote WTRUs / UEs / PDU sets to forward, and possibly drop the remaining WTRU / UE PDU sets not selected.

[0294] In embodiments, a relay WTRU may compute an average amount of data associated with remote WTRU PDU set(s) being transmitted over Uu to the network, an average amount of data to be transmitted (e.g., in the future in order to meet the PSDB of all PDU sets), or an average ratio of UL data associated with PDU sets having PSDB requirements compared to total UL data to be transmitted. If the amount / ratio is above a threshold, the relay WTRU may determine that it needs to select a subset of the remote UEs / WTRUs / PDU sets to forward and possibly drop the remaining UE / WTRU PDU sets not selected.

[0295] In embodiments, a relay WTRU may determine the computation based on the amount of data associated with PDU sets of the remote WTRUs that have yet to be received at the relay WTRU. In examples, the relay WTRU may receive PDU set information, which includes the PSDB and PDU set size, from a remote WTRU. A relay WTRU may, at a specific computation time or event (such as those discussed in other embodiments), determine an average amount of data yet to be received from all of the remote WTRUs over a period of time (where such period of time may be computed similar to methods discussed in other embodiments). If the computed average is above athreshold, the relay WTRU may determine that it needs to select a subset of the remote WTRUs / UEs / PDU sets to forward.

[0296] In embodiments, a relay WTRU may perform the computation as in the previous example, where the computation for a given remote WTRU's PDU sets may further be different depending on the SL RSRP with that specific remote WTRU.

[0297] In embodiments, a relay WTRU may perform the computation in any of the previous examples, where the computation may be performed differently depending on the Uu RSRP.

[0298] A relay WTRU may determine the subset of remote WTRUs / UEs / PDU sets based on one or more conditions / factors.

[0299] A relay WTRU may determine the subset of remote WTRUs / UEs / PDU sets based on PDU set information received from the remote WTRU and any XR related conditions. These may include remaining PDSB, amount / ratio of data from the PDU set already received at the relay WTRU, and PDU set size.

[0300] A relay WTRU may determine the subset of remote WTRUs / UEs / PDU sets based on the priority / importance of a PDU set, as received in PDU set information. For example, a relay WTRU may select the remote WTRU / UE / PDU set having the larger priority / importance.

[0301] A relay WTRU may determine the subset of remote WTRUs / UEs / PDU sets based on the nature / type of the link with the remote WTRU. For example, a relay WTRU may select the remote WTRU with the non-3GPP link over the remote WTRU with the SL link.

[0302] A relay WTRU may determine the subset of remote WTRUs / UEs / PDU sets based on the quality of the SL, such as measured by SL RSRP, SL CBR, SL CQI, etc. For example, a relay WTRU may select the remote WTRU with the best SL RSRP. For example, a relay WTRU may not select any remote WTRU when the SL RSRP of that remote WTRU is below a threshold.

[0303] The conditions / factor for determining the subset of remote WTRUs / UEs / PDU sets may be combined. In examples, remote WTRUs (e.g., only remote WTRUs) that satisfy a first condition and a second condition may be selected. In examples, remote WTRUs (e.g., only remote WTRUs) that satisfy a first condition or a second condition may be selected. In examples, if multiple remote WTRUs satisfy a first condition, another condition is used for the selection; otherwise, the first condition is used. In examples, one condition is used as a threshold or as a computation factor for finding a value that determines a second condition.

[0304] In embodiments, if the amount / ratio of the PDU set still to be transmitted is above a threshold for a particular WTRU, PDU sets for that specific WTRU are selected when (e.g., only when) the SL RSRP with that WTRU is above a threshold.

[0305] In embodiments, if the PDU set priority / importance associated with a remote WTRU is below a threshold, the relay WTRU selects that remote WTRU within the subset of remote WTRUs if (e.g., only if) the amount of data still to be received from that remote WTRU is below a threshold.

[0306] In embodiments, the relay WTRU may select a subset of remote WTRUs that maximize the number of PDU sets, possibly with an importance above a certain priority, that can be transmitted to the next hop (e.g., the network on Uu).

[0307] In embodiments, a relay WTRU may select a first remote WTRU to exclude from the subset (e.g., to drop data for the PDU sets from that remote WTRU). A relay WTRU may continue to select additional remote WTRUs to exclude until the conditions for having to continue to select a subset of WTRUs is no longer met. In examples, the motivation behind such an approach may be to select a subset of the PDU sets to transmit at the relay WTRU to potentially maximize the gain from a PDU set deliver perspective.

[0308] When the relay WTRU / UE selects a subset of PDU sets / remote WTRUs / UEs, it may decide to transmit the PDU sets of the associated remote WTRUs / UEs over the next hop (e.g., to the gNB). Additionally, the relay WTRU may drop one or more of the PDU set(s) associated with the non-selected remote WTRUs. Furthermore, the relay WTRU may inform the non-selected remote WTRUs of the PDU set(s) to be discarded by the remote WTRU, possibly if there is additional data associated with such PDU set(s) still to be received at the relay WTRU.

[0309] In embodiments, the relay WTRU may apply enhanced next hop transmission based on combined conditions associated with remote WTRUs.

[0310] A relay WTRU may trigger an enhanced transmission behavior on the next hop based on conditions associated with the reception of PDU sets from multiple remote WTRUs.

[0311] The enhanced transmission behavior may be a trigger SR (potentially a dedicated SR).

[0312] The enhanced transmission behavior may be a trigger transmission to the network or the inclusion of some information in a transmission to the network, such as trigger BSR or PDU set information in a BSR.

[0313] The enhanced transmission behavior may be a change in the priority of a transmission to the network or the next hop UE. For example, transmit a prioritized BSR versus a non-prioritized BSR or transmit data on the next hop with a higher priority in the SCI.

[0314] The enhanced transmission behavior may be to enable / disable an LCP restriction (e.g., enable transmission on a grant by a logical channel associated with relaying the PDU sets, restrict other logical channels from using a grant).

[0315] The enhanced transmission behavior may be a trigger resource (re)selection.

[0316] In embodiments, a WTRU to NW relay WTRU may be configured with a grant (e.g., a configured grant) and a restriction for the grant associated with logical channels including relayed data. In examples, when certain conditions described for determining the subset of remote WTRUs are met for a particular logical channel, the relay WTRU may be allowed to use such a grant.

[0317] The conditions that trigger the enhanced transmission behavior may further be restricted to the remote WTRUs whose data is multiplexed onto the same LCH (e.g., the Uu LCH for U2N relays). For example, a relayWTRU may determine that it is allowed to use a grant for transmission of data on a Uu LCH by first determining the remote WTRUs whose data is multiplexed onto that LCH. The relay WTRU may then determine if these remote WTRUs satisfy a joint XR related condition considering the PDU set information received from each of the remote WTRUs.

[0318] As such, the trigger may be a combination of conditions. For example, the number of remote WTRUs satisfying a condition of being above / below a threshold. Such a condition may be a combination of the remaining PSDB below a threshold, the remaining amount of data of the PDU set still to be received being larger than a threshold, and / or the average amount of data of a PDU set to be received / transmitted per slot.

[0319] For the remaining PSDB below a threshold condition, the relay WTRU may receive an indication from the remote WTRU of the slot index where the PSDB expires. The condition may include whether the remaining number of slots to the indicated slot index is below a threshold.

[0320] For the remaining amount of data of the PDU set still to be received is larger than a threshold condition, the relay WTRU may receive a PDU set size from the remote WTRU and may keep track of the amount of data associated with the PDU set that is received. It may determine the remaining data still to be received based on the previously received set size.

[0321] For example, considered jointly across all of the remote WTRUs multiplexed onto the Uu LCH that satisfy some condition, any combination of the total amount of data associated with PDU sets from the remote WTRUs is larger than a threshold, the total average amount of data of a PDU set to be received / transmitted per slot is above a threshold, and the time difference between the remaining PDU set PSDB is above / below a threshold.

[0322] In embodiments, a relay WTRU may implement multiplexing restrictions that take into account XR traffic from multiple remote WTRUs. Such multiplexing restrictions may be in the form of an LCP restriction. In examples, traffic from a first remote WTRU and a second remote WTRU may not be multiplexed into the same transport block transmitted by the relay WTRU Additionally, or alternatively, such multiplexing restrictions may be in the form of the SRAP configuration or similar protocol layer configuration that allows the multiplexing of input logical channels to output logical channels. For example, a relay WTRU may allow / not allow multiplexing two input logical channels to the same output logical channel based on XR properties of the remote WTRUs.

[0323] The multiplexing restrictions may be determined on the basis of any of the XR related aspects.

[0324] In examples, the multiplexing restrictions may be determined on the basis of PDU set size. For example, remote WTRUs that indicate a PDU set size within a specific / configured range of each other may be multiplexed together. For example, remote WTRUs that have indicated a PDU set size may be multiplexed together, and remote WTRUs that have not indicated a PDU set size may be multiplexed together.

[0325] In examples, the multiplexing restrictions may be determined on the basis of PDU set importance. For example, remote WTRUs that indicate a PDU set importance that are the same or within a specified / configured range of each other may be multiplexed together.

[0326] In examples, the multiplexing restrictions may be determined on the basis of the amount of data of the PDU set still to be received / transmitted. For example, remote WTRUs having an amount of data of the PDU set still to be received at the relay WTRU that is within a specified / configured range of each other may be multiplexed together.

[0327] In examples, the multiplexing restrictions may be determined on the basis of PSDB or remaining PSDB. For example, remote WTRUs with PDU sets having a PSDB or remaining PSDB when at the relay WTRU that are within a specified / configured range of each other may be multiplexed together.

[0328] In embodiments, instead of or in addition to the number of WTRUs, the amount of data pending that corresponds to the concerned WTRSs may also be considered. For example, the relay WTRU may be configured with thresholds related to the number of WTRUs and / or the amount of buffered data corresponding to the WTRUs.

[0329] In examples, the configured thresholds related to the number of WTRUs and / or the amount of buffered data corresponding to the WTRUs may be configured to schedule the data from a logical channel that has traffic more than a certain buffer level (e.g., thresh 1 ) whose PSDB is to expire within the configured Xi, regardless of the number of WTRUs that are multiplexed over this logical channel.

[0330] In examples, the configured thresholds related to the number of WTRUs and / or the amount of buffered data corresponding to the WTRUs may be configured to schedule the data from a logical channel that has traffic whose PSDB is to expire within the configured Xi, and more than a threshold level (e.g., thresh2) of WTRUs are multiplexed on it, regardless of the total traffic pending transmission on this channel.

[0331] In examples, the configured thresholds related to the number of WTRUs and / or the amount of buffered data corresponding to the WTRUs may be configured for a set of traffic volume levels and number of WTRUs multiplexed over the channel (E.g., n1 WTRUs and b1 buffer level, n2 WTRUs and b2 buffer levels, n3 WTRUs and b3 buffer levels, etc.) to mandate the scheduling of the data from a logical channel.

[0332] In embodiments, a remote WTRU may be configured with different resource selection parameters based on the remaining data in the PDU set to be transmitted to the relay WTRU and the remaining PSDB.

[0333] A relay WTRU may have more difficulty meeting the PSDB requirements of a PDU set if a large amount of data is transmitted at the end of the PDU set compared to transmitting the data evenly over the PSDB. However, the remote WTRU may not receive all data of the PDU set at the same time, especially for multi-hop. One way to avoid this issue would be to ensure timely transmission of PDU set data towards the end of the PSDB, particularly when the PDU set information indicates there is still a large amount of the PDU set still to be transmitted.

[0334] In embodiments, a remote WTRU may be configured with different resource selection parameters for different remaining PSDB and / or a remaining amount of data in the PDU set still to be transmitted. For example, the resource selection parameters may be one set of parameters for a first range of remaining PSDB and a second set of parameters for a second range of remaining PSDB, etc For example, the resource selection parameters may be one set of parameters when the remaining amount of data in the PDU set still to be transmitted is above a threshold when the remaining PSDB reaches a threshold and another set of parameters when the remaining amount of data in thePDU set is below a threshold when the remaining PSDB reaches a threshold. The resource selection parameters may include a maximum number of subchannels (e.g., to select larger resources at the beginning of the PSDB window), a T2 (e.g., to select a smaller T2 towards the end of the window), and other similar types of parameters. The remote WTRU may receive a PSDB (e.g., from upper layers) associated with a PDU set. The remote WTRU, upon arrival of data associated with a PDU set at the remote WTRU, if resource selection at the remote WTRU is triggered by the arrival of data associated with a PDU set, perform resource selection using the parameters associated with the remaining PSDB and remaining data to be transmitted for the PDU set.

[0335] A remote WTRU may increase the aggressiveness and / or robustness associated with its transmission based on the remaining PSDB, based on the amount of data in a PDU set still to be transmitted, based on the importance of the PDU set (e.g., possibly in comparison with other data to be transmitted), or based on a combination of these factors. Increasing the aggressiveness at the WTRU may include, but is not limited to, using a larger amount of resources, using better resources, using a larger number of carriers, using better carriers, transmitting more frequently, requesting resources more frequently, allowing a shorter time between request of resources, using a different transmission scheme, using a different RAT, etc. Increasing the robustness associated with a transmission may include, but not be limited to, performing more repetition, duplicating data, performing transmission with a larger amount of coding, using a different transmission scheme, using a different RAT, using a larger amount of resources to transmit the same amount of data, transmitting for a longer period of time, transmitting on a more reliable medium, transmitting on a more reliable frequency band, carrier, or set of resources, using additional information associated with interference to transmit, transmitting with lower likelihood of interference, etc

[0336] In embodiments, a remote WTRU may determine / change its resource selection parameters based on conditions related to its XR traffic. Such solutions may apply to a remote WTRU communicating via a relay and any SL WTRU that has XR traffic to be transmitted to another WTRU via SL. Such conditions for determining / changing its resource selection parameters may further be based on conditions associated with the relay WTRU and / or the conditions of the link with the relay WTRU.

[0337] A remote WTRU may perform an action, or a combination of actions based on one or more of XR conditions and / or conditions associated with the relay WTRU. The actions may include trigger resource reselection, determine one or more parameters associated with resource selection, determine a number of carriers allowed for transmission on sidelink, determine the parameters or behavior / conditions associated with carrier selection and / or duplication, determine a pre-emption behavior associated with resource selection, determine an SL DRX configuration or behavior for SL, determine a resource allocation mode (mode 1 or mode 2) for SL transmission, determine conditions associated with transmission in unlicensed spectrum, determine an SL LCP restriction, and determining the PHY layer priority of an SL transmission.

[0338] For the trigger resource action, one or more XR conditions, possibly in combination with other conditions associated with the relay WTRU, may be used to determine the WTRU’s resource (re)selection triggering behavior.In examples, examples of such may further be applicable to a relay WTRU receiving XR traffic or control information from a remote WTRU and forwarding such traffic to a next hop relay WTRU on SL.

[0339] For example, a remote WTRU may trigger resource reselection upon the arrival of PDU set information at the remote WTRU. Such a solution may further be applicable to a relay WTRU, for example, in a multi-hop scenario, where the relay WTRU further transmits remote WTRU data over sidelink to the next hop. In examples, a relay WTRU may trigger resource reselection upon reception of PDU set information from another WTRU or upon any condition associated with the reception of PDU set data from a remote WTRU.

[0340] As another example, a remote WTRU may trigger resource reselection if the remote WTRU does not have sufficient grants to transmit all of the data associated with the PDU set within the PSDB.

[0341] As another example, a remote WTRU may trigger resource reselection if certain conditions associated with a PDU set to be transmitted are satisfied, including the PSDB associated with a PDU set being below a configured threshold, the PDU set being associated with discard requirement, and / or the PDU set having a higher priority than any pending PDU set that the WTRU is currently transmitting.

[0342] For determining one or more parameters associated with resource selection action, the resource selection parameters may include any of the resource selection window (e.g., T2), the maximum number of subchannels for resource selection, the periodicity of the resource selection process, the physical layer parameters, and the number of parallel processes (e.g., HARQ processes).

[0343] Concerning the resource selection window (e.g., T2), for example, the remote WTRU may be configured with a value of T2 to use based on conditions related to XR traffic. For example, the remote WTRU may use the T2 associated with the packet / QoS flow when a PDU is associated with a PDU set having a PSDB and may use an alternate value of T2 determined as herein if the PDU is associated with a PDU set having a PSDB. As another example, the remote WTRU may use the T2 associated with the packet / QoS flow when (e.g., remaining) PSDB is above a threshold and may use an alternate value of T2 determined as herein if the (e.g., remaining) PSDB is below a threshold. As another example, the remote WTRU may determine T2 to be the (e.g., remaining) PDSB of the PDU set, possibly if this value is less than the PDB of the packet associated with upper layers. Lastly, for example, the remote WTRU may determine T2 to be the minimum of the PDB of the packet and the PSDB of the PDU set if the packet is part of a PDU set with a PSDB.

[0344] Concerning the maximum number of subchannels for resource selection, for example, the remote WTRU may be configured with a maximum number of subchannels that is a function of any or a combination of the number of PDU sets currently at the WTRU for transmission, the size of the PDU set(s) currently at the WTRU for transmission, the PSDB, or remaining PSDB associated with the PDU set(s) currently at the WTRU for transmission.

[0345] In examples, the remote WTRU may be configured with a first maximum number of subchannels associated with resource selection when the amount of data currently buffered at the WTRU that corresponds to a PDU set having a configured PSDB is above a threshold and may be configured with a second maximum number ofsubchannels associated with resource selection when the amount of data currently buffered at the WTRU that is corresponding to a PDU set having a configured PSDB is below a threshold. Lastly, as another example, the remote WTRU may be configured with a first maximum number of subchannels associated with resource selection when the amount of data buffered that has a remaining PSDB less than a first time threshold is greater than a second amount threshold and with a second maximum number of subchannels otherwise.

[0346] Concerning the periodicity of the resource selection process, for example, the remote WTRU may be configured to select resources with a periodicity that is no smaller than the periodicity indicated in the PDU set information associated with the XR traffic.

[0347] Concerning the physical layer parameters, for example, the remote WTRU may be configured with different transmit power, MCS, etc., based on the size of the PDU set and / or the amount / portion of the PDU set to be transmitted, possibly at a specific time instant, for a specific remaining PSDB, or at a time instant relative to the expiry of the PSDB.

[0348] Concerning the number of parallel processes (e.g., HARQ processes), for example, the remote WTRU may be configured with a different number of allowable parallel processes (e.g., HARQ processes) that it can initiate based on the presence of one or more PDU set(s) to be transmitted, the size of the PDU set(s), the PSDB of the PDU set(s), or the remaining data to be transmitted associated with a PDU set for a given remaining PSDB.

[0349] For determining a number of carriers allowed for transmission on sidelink action, one or more XR conditions herein, possibly in combination with other conditions associated with the relay WTRU, may be used to determine the number of and / or the allowed carriers over which sidelink transmission is allowed. For example, the WTRU may be configured with a maximum number of carriers that may be used simultaneously, corresponding to the number of PDU set(s) and / or the size of the PDU set(s) at the WTRU for transmission. The maximum number of carriers may correspond to any of the number of parallel HARQ processes that can be initiated over different carriers simultaneously and / or the number of allowable carriers that can be used for carrier (re)selection.

[0350] For the parameters or behaviors / conditions associated with carrier selection and / or duplication action, one or more XR conditions herein, possibly in combination with conditions associated with the relay WTRU, may be used to determine the parameters associated with controlling carrier selection, such as the CBR threshold associated with carrier selection and / or the CBR threshold associated with keeping a carrier.

[0351] In examples, a WTRU may select a first CBR threshold associated with carrier selection when determining whether to allow the carrier to be selected when the remaining time in the PSDB is below a threshold. The WTRU may use a second (e.g., higher) CBR threshold when performing carrier selection when the remaining time in the PSDB is above a threshold.

[0352] In examples, for the parameters or behaviors / conditions associated with carrier selection and / or duplication action, whether / when carrier reselection is allowed may depend on the timing associated with a PDU set and / or PDU set information. For example, a WTRU may transmit an entire PDU set on one or a set of carriers and may beallowed (e.g., only be allowed) to perform carrier reselection when the PDU set is successfully transmitted. As another example, a WTRU may apply duplication or a duplication mechanism equally across all PDUs of a PDU set. For example, a WTRU may select the same carriers on which to perform PDCP duplication for all PDUs of a PDU set.

[0353] For determining a pre-emption behavior associated with resource selection action, one or more XR conditions herein may be used to determine whether / when to perform pre-emption on a selected resource and / or whether to send a pre-emption indication on sidelink.

[0354] In examples, if the remaining PSDB is below a threshold while the amount of data to be transmitted in a PDU set is above a threshold, the WTRU may not trigger pre-emption associated with a resource that may have a conflict indication or would require pre-emption based on the determination of sensing results. As another example, a WTRU may be configured with a priority or an offset of priority (e.g., determined from the logical channel priority) to be used when determining the availability of a resource during re-evaluation. For example, re-evaluation may include comparing the priority of other WTRU transmissions occurring within selected resources with the WTRU's own transmissions to decide if pre-emption is needed. The WTRU may use a (pre)configured priority for its own WTRU transmissions when one or more XR conditions herein are met. Additionally, or alternatively, the WTRU may offset its transmit priority by a (pre)configured priority amount.

[0355] As an example of whether to send a pre-emption indication on sidelink, if the remaining PSDB is below a threshold while the amount of data to be transmitted in a PDU set is above a threshold, the WTRU may transmit a pre-emption indication to obtain a resource when insufficient resources are available.

[0356] For determining an SL DRX configuration or behavior for SL action, one or more XR conditions herein may be used to determine whether the TX WTRU should transmit a DRX disable signal, a WUS or similar signal to an RX WTRU to have the RX WTRU disable DRX for a period of time; whether the TX WTRU should include, in its transmission to the TX WTRU / UE, and indication that forces the RX WTRU / UE to stay on for a period of time following transmission of the indication; and / or whether the TX WTRU should reconfigure DRX to ensure that the RX WTRU is in the on duration during the PSDB.

[0357] As an example of transmitting a DRX disable signal, a wake-up-signal (WUS), or a similar signal, if the PSDB is below a threshold, the TX WTRU may send an SL-WUS or a MAC CE to an RX WTRU (e.g., the relay WTRU) to indicate that the RX WTRU should stay awake for a period of time.

[0358] When transmitting an indication that forces the RX WTRU to stay on for a period of time, the TX WTRU may further include the PSDB or the remaining PSDB as part of the message, and the RX WTRU may use the PDSB to derive the time to remain on.

[0359] When reconfiguring DRX, the remote WTRU may reconfigure SL DRX to disable DRX for the unicast link with the relay WTRU when it receives a PDU set for transmission or a similar burst of data from upper layers. Theremote WTRU may reconfigure SL DRX to change specific parameters (e.g., on duration or offset) to ensure the RX WTRU is on during the PSDB or remaining PSDB when it receives a PDU set.

[0360] For determining a resource allocation mode (mode 1 or mode 2) for SL transmission action, one or more XR conditions may determine whether a WTRU uses mode 1 or mode 2 resource allocation. For example, SL WTRU may initiate an RRC connection when it receives a PDU set from upper layers. As another example, an SL WTRU may be configured with a threshold remaining PSDB and / or a threshold remaining amount of data to be transmitted for which, when the threshold(s) are met, the WTRU may trigger an RRC connection to allow the network to configure mode 1. In examples, the SL WTRU may further indicate to the network (e.g., in SidelinkUEInformation) the reason for the RRC connection (e.g., the arrival of XR data for transmission).

[0361] For determining conditions associated with transmission in unlicensed spectrum action, one or more XR conditions may be used to determine WTRU behavior in unlicensed spectrum, such as (i) whether the WTRU shares a COT or initiates a COT for transmission of a PDU on a SL grant and / or (ii) whether the WTRU / UE transmits on an unlicensed carrier or a licensed carrier. If the remaining PSDB is below a threshold and / or the remaining amount of data to be transmitted is above a threshold, the WTRU may initiate a COT in the case where the grant does not allow transmission of data associated with the PDU set (e.g., due to CAPC / destination restrictions associated with the COT information). In examples, when transmitting on an unlicensed carrier or a licensed carrier, the WTRU may trigger carrier reselection and / or select a licensed carrier if the remaining PSDB is below a threshold and / or the remaining amount of data to be transmitted is above a threshold, possibly if the WTRU is currently transmitted data on the unlicensed carrier

[0362] For determining an SL LCP restriction action, one or more XR conditions may be used as criteria to determine whether / when to apply a SL LCP restriction on a SL grant. For example, a remote WTRU may be allowed to use an SL configured grant when the PSDB is below a threshold and / or the amount of data still to be transmitted by the remote WTRU / UE in the PDU set is above a threshold.

[0363] For determining the PHY layer priority of an SL transmission action, a SL WTRU may transmit data associated with the PDU set with a (pre)configured priority (e.g., rather than the actual data priority) and / or with a priority determined as a configured delta from the actual data priority, when a condition associated to XR described herein is met (for example, the remaining PSDB is below a threshold and / or the amount of data still to be transmitted for the PDU set is above a threshold at a given time).

[0364] In embodiments, a remote WTRU may perform transmission of a PDU set to the network via a relay WTRU. At an initial time instant, the remote WTRU may receive a PDU set with a PSDB requirement. Such a PDU set may be associated with a PSI HI, for example, an indicator to determine whether the PDUs of the PDU set should all be delivered within the PSDB.

[0365] Upon reception of the PDU set, the remote WTRU may trigger resource reselection. Triggering resource reselection may further be conditioned on whether the WTRU has already triggered resource selection associatedwith PDU set data or not. Additionally, or alternatively, the remote WTRU may always trigger resource reselection upon the arrival of a PDU set to transmit. Resource (re)selection parameters may be configured specifically for the cases where the remote WTRU has a PDU set to transmit to the relay WTRU. In examples, the remote WTRU may be configured with a different set of maximum number of subchannels, MCS, value of T2 (a window for resource selection) based on whether the WTRU has data associated with a PDU set to transmit or not. A WTRU may trigger resource (re)selection based on a change in the presence of PDU state information for transmission. In examples, the WTRU may trigger resource (re)selection when a PDU set arrives for transmission at the remote WTRU. Similarly, the WTRU may trigger resource (re)selection when the remote WTRU decides to discard a PDU set or when the remote WTRU receives an indication from the relay WTRU to discard a PDU set.

[0366] A WTRU may further be configured with specific time instances within a PSDB (e.g., every slot, at specific slots, or determined by specific events, etc.) where the WTRU may evaluate the progression of transmission of a PDU set, either to another WTRU, a WTRU to NW relay, a WTRU-to-WTRU relay, or to the NW itself. At such specific times, a WTRU may trigger resource (re)selection if the amount / percentage of data of a PDU set transmitted or still to be transmitted is above / below a threshold. Additionally or alternatively, upon resource (re)selection, the WTRU may choose a different set of resource selection parameters (e.g., maximum number of subchannels for selection, MCS, etc.) or resource selection behavior depending on whether the amount / percentage of data of a PDU set transmitted or still to be transmitted is above / below a threshold. Additionally, or alternatively, upon ( re-election, the WTRU may choose a different set of resource selection parameters (maximum number of subchannels for selection, MCS, etc.) or resource selection behavior depending on whether the remaining PSDB is above / below a threshold.

Claims

CLAIMS:1 . A first wireless transmit / receive unit (WTRU) comprising a processor and memory, wherein the processor and memory are configured to: receive configuration information for relaying data from a second WTRU to a network, wherein the configuration information comprises a first data threshold for triggering a buffer status report (BSR) for protocol data unit (PDU) set data received from the second WTRU, and a first timing threshold for triggering the BSR for the PDU set data received from the second WTRU; receive, from the second WTRU, first PDU set information, wherein the first PDU set information comprises an indication of a time associated with a PDU set delay budget (PSDB) for a first PDU set and an indication of a size of the first PDU set; and based on a determination that an amount of data remaining to be received from the second WTRU for the first PDU set at a time corresponding to the first timing threshold prior to the time associated with the PSDB is greater than the first data threshold, transmit the BSR for the first PDU set to the network.

2. The first WTRU of claim 1 , wherein the indication of the time associated with the PSDB comprises a slot number.

3. The first WTRU of claim 1 , wherein the configuration information for relaying data from the second WTRU to the network further comprises a second data threshold for triggering the first WTRU to discard PDU set data received from the second WTRU, and a second timing threshold for triggering the first WTRU to discard PDU set data received from the second WTRU.

4. The first WTRU of claim 3, wherein the processor and memory are further configured to: discard data associated with the first PDU set, based on a determination that an amount of data remaining to be received from the second WTRU for the first PDU set at a time corresponding to the second timing threshold prior to the time associated with the PSDB is greater than the second data threshold; and send an indication of the discard to the second WTRU.

5. The first WTRU of claim 4, wherein the indication of the discard indicates a rationale associated with the discard.

6. The first WTRU of claim 1 , wherein the BSR indicates the amount of data remaining to be received from the second WTRU for the first PDU set.

7. The first WTRU of claim 1 , wherein the BSR indicates an expected time that the data remaining to be received will become available.

8. The first WTRU of claim 1 , wherein the processor and memory are further configured to send a preemptive BSR based on the indication of the size of the first PDU set.

9. The first WTRU of claim 1 , wherein the processor and memory are further configured to: receive a discard indication from the second WTRU that indicates to discard one or more PDUs of the first PDU set; and discard the one or more PDUs of the first PDU set based on the discard indication.

10. The first WTRU of claim 1 , wherein the processor and memory are further configured to: discard data associated with the first PDU set; and send, to the network, an indication of the data associated with the first PDU set that was discarded.

11. A method to be performed by a first wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information for relaying data from a second WTRU to a network, wherein the configuration information comprises a first data threshold for triggering a buffer status report (BSR) for protocol data unit (PDU) set data received from the second WTRU, and a first timing threshold for triggering the BSR for the PDU set data received from the second WTRU; receiving, from the second WTRU, first PDU set information, wherein the first PDU set information comprises an indication of a time associated with a PDU set delay budget (PSDB) for a first PDU set and an indication of a size of the first PDU set; and based on a determination that an amount of data remaining to be received from the second WTRU for the first PDU set at a time corresponding to the first timing threshold prior to the time associated with the PSDB is greater than the first data threshold, transmitting the BSR for the first PDU set to the network.

12. The method of claim 11, wherein the indication of the time associated with the PSDB comprises a slot number.

13. The method of claim 11, wherein the configuration information for relaying data from the second WTRU to the network further comprises a second data threshold for triggering the first WTRU to discard PDU set data received from the second WTRU, and a second timing threshold for triggering the first WTRU to discard PDU set data received from the second WTRU.14 The method of claim 13, further comprising: discarding data associated with the first PDU set, based on a determination that an amount of data remaining to be received from the second WTRU for the first PDU set at a time corresponding to the second timing threshold prior to the time associated with the PSDB is greater than the second data threshold; and sending an indication of the discard to the second WTRU.15 The method of claim 14, wherein the indication of the discard indicates a rationale associated with the discard.

16. The method of claim 11, wherein the BSR indicates the amount of data remaining to be received from the second WTRU for the first PDU set.17 The method of claim 11, wherein the BSR indicates an expected time that the data remaining to be received will become available.

18. The method of claim 11, further comprising sending a preemptive BSR based on the indication of the size of the first PDU set.19 The method of claim 11 , further comprising: receiving a discard indication from the second WTRU that indicates to discard one or more PDUs of the first PDU set; and discarding the one or more PDUs of the first PDU set based on the discard indication.

20. The method of claim 11 , further comprising: discarding data associated with the first PDU set; and sending, to the network, an indication of the data associated with the first PDU set that was discarded.

Images