Method for supporting end-to-end QOS

Abstract

To provide a method for achieving end-to-end quality of service (QoS) performed by a wireless transmit / receive unit (WTRU).SOLUTION: The method may include receiving a protocol data unit (PDU) and an excess time indication from a source WTRU and determining an expected latency of a next hop link based on a measure of channel loading. The method may also include dynamically determining a next hop latency budget based on the received excess time indication and the expected latency, and determining resources for transmitting the received PDU based on the determined next hop latency budget. If the resources are available, the received PDU may be transmitted on the next hop using the determined resources.SELECTED DRAWING: Figure 4B

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 027,646, filed May 20, 2020, and U.S. Provisional Application No. 63 / 091,648, filed October 14, 2020, which are incorporated by reference as if fully set forth. [Background technology]

[0002] The new radio (NR) sidelink can focus on supporting vehicle-to-vehicle / vehicle-to-everything (V2X) communications-related road safety services. This design provides support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Furthermore, considering a wider range of applications and services, sidelink-based relay functionality can be considered for sidelink / network coverage extension and power efficiency improvement.

[0003] To further explore coverage extension for sidelink-based communications, in wireless transmit / receive unit (WTRU)-to-network coverage extension, Uu coverage reachability may be required for a WTRU to reach a server in a PDN network or a corresponding WTRU outside the proximity area. However, current solutions for WTRU-to-network relay may be limited to Evolved Universal Terrestrial Radio Access (EUTRA)-based Mobile Telecommunications System (MTS) technologies and may not apply to NR-based systems, for both NG Radio Access Network (NG-RAN) and NR-based sidelink communications.

[0004] Regarding WTRU-to-WTRU coverage extension, proximity reachability is currently limited to a single-hop sidelink link via either EUTRA-based or NR-based sidelink technologies, which may not be sufficient in scenarios where Uu coverage does not exist, given the limited single-hop sidelink coverage.

[0005] Sidelink connectivity can be further extended in the NR framework to support enhanced quality of service (QoS) requirements. Summary of the Invention

[0006] Disclosed are methods, systems, and devices for determining whether to relay a received PDU from a relay wireless transmit / receive unit (WTRU) to one or more other WTRUs. The method may include receiving information regarding a first communication range from a source WTRU, the information being provided in a control indication over one of the control channels; determining a second communication range based on the first communication range and location information of the source WTRU and the relay WTRU; determining that the received information should be relayed based on the determined second communication range, the first communication range, and a distance threshold; and relaying the information based on determining that the received information should be relayed.

[0007] Also disclosed are methods, systems, and devices for determining radio bearer mapping in a remote radio transmit / receive unit (WTRU). The remote WTRU can be configured with mapping configuration information to perform N:1 or 1:N mapping. The remote WTRU can send control information associated with the mapping configuration to a network or a relay WTRU. The remote WTRU can perform mapping in an adaptation layer or other equivalent logical functions operating in hardware or software. The remote WTRU can perform mapping of logical flows to radio bearers based on trigger conditions. The remote WTRU can receive an indication of a change or update to the mapping configuration information from the relay WTRU.

[0008] According to some embodiments of the present disclosure, a method for achieving end-to-end quality of service (QoS) performed by a wireless transmit / receive unit (WTRU) may include receiving a protocol data unit (PDU) and an excess time indication from a source WTRU and determining an expected latency of a next-hop link based on a measure of channel loading. It may also include dynamically determining a next-hop latency budget based on the received excess time indication and the expected latency, and determining resources for transmitting the received PDU based on the determined next-hop latency budget. If resources are available, the received PDU may be transmitted on the next hop using the determined resources.

[0009] According to some embodiments of the present disclosure, a relay wireless transmit / receive unit (WTRU) configured to relay information from a source WTRU to a target WTRU and achieve end-to-end quality of service (QoS) may include a processor coupled to a transceiver configured to receive a protocol data unit (PDU) and an overtime indication from the source WTRU. The processor coupled to the transceiver may be configured to determine an expected latency of a next-hop link based on a channel load measure, dynamically determine a next-hop latency budget based on the received overtime indication and the expected latency, and determine resources for transmitting the received PDU based on the determined next-hop latency budget. The processor coupled to the transceiver may be further configured to transmit the received PDU on the next hop using the determined resources, if the resources are available. [Brief explanation of the drawings]

[0010] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1 illustrates an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) for use within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B illustrates an exemplary radio access network (RAN) and core network (CN) used within the communications system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] FIG. 1B is a system diagram illustrating a further exemplary RAN and CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] FIG. 10 is a diagram of the user plane radio protocol stack for WTRU to network relay (PC5) with Layer 2 involvement. [Figure 3] FIG. 1 is a diagram of a control plane radio protocol stack for Layer 2 evolved WTRU to network relay (PC5). [Figure 4A] FIG. 1 illustrates a semi-static configuration of an end-to-end latency budget, according to some embodiments. [Figure 4B] 1 is a schematic diagram illustrating a method for achieving end-to-end quality of service according to some embodiments. [Figure 4C] FIG. 1 illustrates dynamic latency variation according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0011] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0012] 1A, communications system 100 may include wireless transmit receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, 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 (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronic device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0013] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation Node B such as a gNode B (gNB), a new radio (NR) Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0014] The base station 114a may be part of the RAN 104, 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), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

[0016] More specifically, as noted above, the communications system 100 may be a multiple-access system and may use one or more channel access schemes, such as, for example, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a of the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 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 ​​Uplink (UL) Packet Access (HSUPA).

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

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

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

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

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

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

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

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

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

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

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

[0028] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use 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.

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

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

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

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

[0033] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripherals 138 may include one or more sensors. The sensor 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, a humidity sensor, and the like.

[0034] The WTRU 102 may include a full-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception)).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0054] The WTRUs 102a, 102b, 102c may communicate with the 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 the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time).

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

[0056] 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 for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

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

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

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

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

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

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

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

[0065] According to an implementation of the disclosed subject matter, a WTRU (e.g., a relay WTRU) determines whether to relay a received protocol data unit (PDU) to one or more other WTRUs (e.g., a destination WTRU) based on a communication range and at least one of the WTRU location (e.g., source and / or relay location) and a cast type offset distance.

[0066] A WTRU (e.g., a relay WTRU) may receive information regarding the first communication range from the source WTRU. Such information may be carried on a control channel (e.g., Sidelink Control Information (SCI)) or in a control indication (e.g., MAC CE, etc.) in the received PDU. The WTRU may determine a second communication range based on the first communication range and location information of the source WTRU and relay WTRU.

[0067] The relay WTRU may determine location information of the source WTRU from the zone identifier indicated by the source WTRU in the SCI. The relay WTRU may determine a second communication range by subtracting the distance between the source WTRU and the relay WTRU and an offset distance (e.g., determined from location information of the source WTRU and the relay WTRU) from the first communication range. In the case of unicast, the offset distance may be determined as a function of the locations of the source, relay, and destination WTRU. In the case of groupcast, the offset distance may be determined as a function of the number of destination WTRUs in the group and / or based on a configuration.

[0068] The WTRU may also determine whether to relay the received PDU based on the determined second communication range, the first communication range, and a distance threshold. The relay WTRU may relay the received PDU in the SCI along with information about the second communication range if the difference between the first communication range and the second communication range is less than the distance threshold. Alternatively or additionally, the relay WTRU may drop the PDU and indicate the decision to drop the PDU to the source WTRU.

[0069] According to some implementations, a WTRU (e.g., a relay WTRU) may determine resources for relaying a received PDU to one or more WTRUs (e.g., destination WTRUs) by performing resource (re)selection based on resource selection information (e.g., periodicity, offset) received from another WTRU (e.g., a source WTRU).

[0070] The relay WTRU may receive resource selection information from the source WTRU, where the resource selection information includes timing information, eg, periodicity and offset parameters. The relay WTRU may determine resources based on the received resource selection information, e.g., such that the relay WTRU (re)selects resources according to or corresponding to (e.g., matching) the received periodicity and / or offset parameters. The relay WTRU may perform resource reselection when the previously selected resources are not according to or corresponding to the received resource selection information.

[0071] The relay WTRU may relay the received PDU using the determined resource.

[0072] Implementations disclosed herein can include the use of both PC5 (sidelink)-based WTRU-to-network relay and WTRU-to-WTRU relay. The New Radio (NR) sidelink may focus on supporting vehicle-to-vehicle / vehicle-to-everything (V2X) communications-related road safety services. This design can provide support for broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Furthermore, considering a broader range of applications and services, sidelink-based relay functionality can be considered for sidelink / network coverage extension and power efficiency improvement.

[0073] To further explore coverage extension for sidelink-based communications, in wireless transmit / receive unit (WTRU)-to-network coverage extension, Uu coverage reachability may be required for a WTRU to reach a server in a PDN network or a corresponding WTRU outside the proximity area. However, current solutions for WTRU-to-network relay may be limited to EUTRA-based technologies and may not apply to NR-based systems for both NG-RAN and NR-based sidelink communications.

[0074] With regard to WTRU-to-WTRU coverage extension, proximity reachability may currently be limited to a single-hop sidelink link via either EUTRA-based or NR-based sidelink technologies, which may not be sufficient in scenarios where Uu coverage does not exist, given the limited single-hop sidelink coverage.

[0075] Sidelink connectivity can be further extended in the NR framework to support enhanced quality of service (QoS) requirements.

[0076] Single-hop NR sidelink relaying may be explored based on mechanisms with minimal specification impact to support SA requirements for sidelink-based WTRU-to-network relaying and WTRU-to-WTRU relaying, focusing on aspects for Layer 3 relaying and Layer 2 relaying (where applicable) [RAN2]. Aspects may include relay (re)selection criteria and procedures, relay / remote WTRU authorization, QoS for relay functionality, service continuity, security of the relay connection after SA3 provides its conclusion, and / or impact on the user plane protocol stack and control plane procedures, e.g., connection management of the relay connection. Additionally, assuming no new physical layer channels / signals [RAN2], single-hop NR sidelink relaying may be explored to support higher layer operation of discovery models / procedures for sidelink relaying. Further input from SA WGs, e.g., SA2 and SA3, may be considered for the aspects outlined above. WTRU-to-network relaying and WTRU-to-WTRU relaying can use the same relay solution. Forward compatibility for multi-hop relay support in future releases may need to be considered. For Layer 2 WTRU to network relay, the end-to-end Packet Data Convergence Protocol (PDCP) and hop-by-hop Radio Link Control (RLC) architectures can be taken as a starting point.

[0077] With respect to WTRU-to-network relay, relaying via a ProSe WTRU-to-network relay can extend network coverage to out-of-coverage WTRUs by using PC5 (D2D), for example, between an out-of-coverage WTRU and a WTRU-to-network relay. The ProSe WTRU-to-network relay can provide a general L3 forwarding function that can relay any type of IP traffic between the remote WTRU and the network. One-to-one and one-to-many sidelink communications are used between the remote WTRU and the ProSe WTRU-to-network relay. Only one single-carrier (i.e., public safety ProSe carrier) operation is supported for both the remote WTRU and the relay WTRU (i.e., Uu and PC5 should be the same carrier for the relay / remote WTRU). The remote WTRU may be allowed by higher layers, for example, to be in coverage of the public safety ProSe carrier or out-of-coverage on any supported carrier, including the public safety ProSe carrier, for WTRU-to-network relay discovery, (re)selection, and communication. The ProSe WTRU-to-network relay may always be within the coverage of a network such as EUTRAN. The ProSe WTRU-to-network relay and the remote WTRU perform sidelink communication and sidelink discovery.

[0078] With regard to relay selection for WTRU-to-NW relay, relay selection / reselection for ProSe WTRU-to-NW relay may be performed based on a combination of AS layer quality measurements (RSRP) and higher layer criteria. The Node B may control whether a WTRU can operate as a ProSe WTRU-to-network relay. ProSe WTRU-to-network relay operation is supported in a cell if the eNB broadcasts any information associated with ProSe WTRU-to-network relay operation. The Node B may use broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC_CONNECTED state to provide transmission resources for ProSe WTRU-to-network relay discovery and may use broadcast signaling to provide reception resources for ProSe WTRU-to-network relay discovery. A Node B, such as an eNB, gNB, or network node using any other radio access technology, may broadcast minimum and / or maximum Uu link quality (RSRP) thresholds that it needs to respect before the ProSe WTRU-to-network relay can initiate a WTRU-to-network relay discovery procedure. In RRC_IDLE, when the Node B broadcasts the transmission resource pool, the WTRU can use the thresholds to autonomously start or stop the WTRU-to-Network Relay Discovery procedure. In RRC_CONNECTED, the WTRU uses the thresholds to decide whether it can indicate to the Node B that it is a relay WTRU and wants to initiate ProSe WTRU-to-Network Relay Discovery. If the Node B does not broadcast the transmission resource pool for ProSe-WTRU-to-Network Relay Discovery, the WTRU can initiate a request for ProSe-WTRU-to-Network Relay Discovery resources by dedicated signaling, respecting these broadcasted thresholds.

[0079] If the ProSe-WTRU to network relay is initiated by broadcast signaling, it can perform ProSe WTRU to network relay discovery when in RRC_IDLE. If the ProSe WTRU to network relay is initiated by dedicated signaling, it can perform relay discovery as long as it is in RRC_CONNECTED.

[0080] A ProSe WTRU-to-network relay performing sidelink communication for ProSe WTRU-to-network relay operation may be in RRC_CONNECTED. After receiving a Layer 2 link establishment request or a TMGI monitoring request (higher layer message) from a remote WTRU, the ProSe WTRU-to-network relay indicates to the eNB that it is a ProSe WTRU-to-network relay and intends to perform ProSe WTRU-to-network relay sidelink communication. The Node B may provide resources for the ProSe WTRU-to-network relay communication.

[0081] The remote WTRU can decide when to start monitoring for ProSe WTRU-to-Network Relay Discovery. The remote WTRU can send a ProSe WTRU-to-Network Relay Discovery Request message while in RRC_IDLE or RRC_CONNECTED, depending on the configuration of resources for ProSe WTRU-to-Network Relay Discovery. The Node B can broadcast a threshold value, which can be used by the remote WTRU to determine whether it can send a ProSe WTRU-to-Network Relay Discovery Request message to connect or communicate with the ProSe WTRU-to-Network Relay WTRU. An RRC_CONNECTED remote WTRU can use the broadcasted threshold value to determine whether it can indicate to the Node B that it is a remote WTRU and wishes to participate in ProSe WTRU-to-Network Relay Discovery and / or communication. The Node B can provide transmission resources using broadcast or dedicated signaling, and provide reception resources using broadcast signaling, for ProSe WTRU-to-Network Relay operation. The remote WTRU stops ProSe WTRU-to-network relay discovery and communication resource usage when the Reference Signal Received Power (RSRP) exceeds a broadcasted threshold. The exact time for traffic switching from Uu to PC5 or vice versa may be up to higher layers.

[0082] The remote WTRU can perform radio measurements on the PC5 interface and use them, along with higher layer criteria, for ProSe WTRU-to-network relay selection and reselection. A ProSe WTRU-to-network relay can be considered suitable with respect to the radio criteria, for example, if the PC5 link quality exceeds a configured (pre-configured or Node B-provided) threshold. The remote WTRU selects, among all suitable ProSe WTRU-to-network relays, the ProSe WTRU-to-network relay that meets the higher layer criteria and has the best PC5 link quality.

[0083] The remote WTRU may trigger ProSe WTRU-to-Network Relay reselection when the current ProSe WTRU-to-Network Relay PC5 signal strength falls below a configured signal strength threshold and / or when it receives a Layer 2 link release message (higher layer message) from the ProSe WTRU-to-Network Relay.

[0084] Regarding WTRU-to-Network Relay for wearables, WTRU-to-NW relay for commercial use cases tailored to wearables and IoT devices can be observed in the RAN. In contrast to ProSe WTRU-to-NW relay, which can use an L3 (IP layer) relay approach, WTRU-to-NW relay for wearables can be expected to be an L2 relay based on the protocol stacks shown in Figures 2 and 3. Figure 2 shows the user plane radio protocol stack for WTRU-to-Network Relay (PC5) involving Layer 2. Figure 3 shows the control plane radio protocol stack for Layer 2 evolved WTRU-to-Network Relay (PC5).

[0085] A procedure for connection establishment for unicast links in NR V2X is disclosed herein. Conventional solutions may be based on a one-to-one communication link established at a higher layer (ProSe layer) between two WTRUs (remote WTRU and WTRU-to-NW relay). Such a connection may be transparent to the AS layer, and connection management signaling and procedures performed at the higher layer are carried by the AS layer data channel. The AS layer may not be aware of such a one-to-one connection.

[0086] In NR V2X, the AS layer can support the concept of a unicast link between two WTRUs. Such a unicast link is initiated by higher layers (as in a ProSe one-to-one connection). However, the AS layer is informed of the existence of such a unicast link and of any data transmitted in a unicast manner between peer WTRUs. With such knowledge, the AS layer can support hybrid ARQ (HARQ) feedback, Channel Quality Indicator (CQI) feedback, and unicast-specific power control schemes. Unicast links at the AS layer are supported via a PC5-RRC connection.

[0087] A PC5-RRC connection may be defined as a logical connection between a pair of source Layer 2 ID and destination Layer 2 ID within an AS. One PC5-RRC connection corresponds to one PC5 unicast link. PC5-RRC signaling may be initiated after the corresponding PC5 unicast link is established. The PC5-RRC connection and the corresponding sidelink SRBs and sidelink DRBs are released when the PC5 unicast link is released as indicated by higher layers.

[0088] For each unicast PC5-RRC connection, one sidelink SRB may be used to send PC5-S messages before PC5-S security is established, one sidelink SRB may be used to send PC5-S messages to establish PC5-S security, one sidelink SRB may be used to send PC5-S messages after PC5-S security is established and protected, and one sidelink SRB may be used to send PC5-RRC signaling that is protected and sent only after PC5-S security is established.

[0089] The PC5-RRC signaling may include a sidelink configuration message (RRCReconfigurationSidelink) in which one WTRU configures RX-related parameters for each SLRB in a peer WTRU. Such a reconfiguration message may configure parameters for each protocol in the L2 stack (SDAP, PDCP, etc.). The receiving WTRU may confirm or reject such a configuration depending on whether it can support the configuration proposed by the peer WTRU.

[0090] WTRU-to-WTRU relay may be a candidate topic for discussion and further development. One aspect of WTRU-to-WTRU relay is the ability to meet higher layer QoS requirements (e.g., PQI, coverage) on an end-to-end (E2E) basis when transmitting at the AS layer via one or more relay WTRUs.

[0091] Ensuring QoS on the sidelink may be primarily under the control of the transmitting WTRU. The transmitting WTRU may configure the SLRB sublayer / parameters (e.g., resource selection window, HARQ configuration) and control transmission such that the QoS requirements of all packet flows carried by the SLRB are met. The receiving WTRU has no control over how QoS is guaranteed. When including a relay WTRU to forward a packet flow over a multi-hop link, relying solely on the transmitting WTRU or the source WTRU may not be adequate to guarantee E2E QoS due to the source WTRU's unawareness of link conditions / congestion at subsequent hops.

[0092] In addition, when an L2 relay is employed for WTRU-to-WTRU relay, the protocol stack, including the lower layers (RLC, MAC), may hide E2E QoS parameters from the relay WTRU, which may limit the relay WTRU's ability to meet QoS requirements when transmitting in subsequent hops.

[0093] Enhancements may be needed in the multi-hop SLRB design used in WTRU-to-WTRU relay and in the behavior of the source WTRU and relay WTRU so that flows can be seamlessly forwarded without incurring additional latency / loss.

[0094] Techniques for supporting E2E QoS in a WTRU-to-WTRU relay are disclosed herein. Techniques for determining an SLRB configuration in a WTRU-to-WTRU relay to ensure E2E QoS are further disclosed herein. A WTRU may be configured with rules for mapping upper layer data flows to relayed versus non-relayed SLRBs. According to one implementation, the WTRU can determine whether to map an upper layer data flow to an SLRB configured with a relay or to an SLRB configured without a relay WTRU based on receipt of upper layer markings / flags. Specifically, the WTRU can perform mapping / multiplexing at the SDAP sublayer of one or more upper layer flows to SLRBs configured to achieve QoS performance at the access stratum (AS) layer that is equivalent to upper layer 5QI. A WTRU may be configured with two SLRB types, including a first type including an end-to-end direct path between a source WTRU and a destination WTRU, and another type including a relay path via one or more relay WTRUs.

[0095] The WTRU may be configured with mapping rules in the SDAP for mapping between flows to SLRB types based on markings in the upper layer PDUs (e.g., in the upper layer PDU headers). The mapping rules may include detecting markings / flags in the upper layer PDUs and identifying suitable SLRBs at the AS layer. The mapping rules may include additional rules for allowing / disallowing mapping of specific flows to SLRBs that may include a relay WTRU in the end-to-end path. For example, the rules may include detecting a marker / flag in the upper layer PDU. The marker indicating the inclusion / exclusion of a relay WTRU may be indicated in the QoS profile or as an additional parameter in the upper layer PDU, or may be determined implicitly from the QoS profile. In this case, the WTRU selects an SLRB configured with or without a relay WTRU for a data flow (QFI) based on detection of the marker / flag. For example, the WTRU may be (pre-)configured (e.g., in SIB / pre-configuration / dedicated signaling) with a mapping of allowable QoS profiles and / or QFIs to SLRB types (relay vs. non-relay).

[0096] A WTRU may be configured to relay and indicate allowable path types on its transmission. The WTRU may send an indication to the relay WTRU to enable the relay WTRU to decide whether to relay or not relay the data. Such an indication may be sent in a control channel (e.g., SCI) or in a control indication (e.g., MAC CE) within the transmitted data. Such an indication may be obtained from higher layers, such as via RRC or MAC signaling or any other logical equivalent (e.g., for a source WTRU). Such an indication may be derived by the WTRU from corresponding such values ​​configured in the WTRU and / or received in the transmission to be relayed (e.g., for the relay WTRU). For example, a relay WTRU configured with a maximum hop count may receive the remaining hop count in the indication and may determine the hop count to be transmitted based on the corresponding remaining hop count (e.g., subtract one or reuse the same value). A WTRU may further include such maximum / remaining hop count or allowable route type information only when transmitting to a WTRU that is itself a relay WTRU for the intended transmission.

[0097] A similar solution may be implemented in a relay WTRU. Specifically, the relay WTRU may decide whether to relay received sidelink data over a direct path or a relay path. The WTRU may make such a decision based on received indications / information, such as the QoS profile and / or QFI (in which case the decision is similar to that of the source WTRU), an explicit indication (relay or non-relay) included in the header of the SDU (e.g., RLC, MAC, etc.), or the maximum hop count or the allowable number of remaining hops. For example, the relay WTRU may relay the SDU if the received maximum remaining hop count is greater than some value (e.g., 0); otherwise, it should relay via the direct path. As another example, the relay WTRU may relay the SDU if the received maximum hop count is greater than the number of hops of such a path (possibly obtained from higher layers).

[0098] The WTRU may determine / send the AS layer configuration for the next-hop WTRU. According to an implementation, a WTRU configured with an end-to-end SLRB may determine the lower layer configuration consisting of RLC, MAC, and possibly PHY configuration to be applied at the relay WTRU to ensure end-to-end QoS. In one example, the lower layer configuration applied at the relay WTRU may include PDCP, RLC, MAC, and PHY configuration. The lower layer configuration may include at least one configuration including: i) PDCP configuration, which may include parameters related to sequence number (SN) size, discard timer, and packet duplication; ii) RLC configuration, which may include parameters related to acknowledged and / or unacknowledged modes, and LCH-to-LCH mapping rules when mapping between an ingress RLC entity (transmit (TX) side) and an egress RLC entity (receive (RX) side); iii) MAC configuration, which may include parameters related to LCH configuration for one or more LCHs, including logical channel prioritization (LCP) restrictions, discontinuous reception (DRX) configuration, priority, prioritized bit rate, and bucket size duration; and / or iv) PHY configuration, which may include resource pool configuration, channel state information (CSI) reporting configuration, and HARQ configuration. In another example, the lower layer configuration may consist of one or more logical channels (LCHs) of an RLC entity and associated LCH configurations in the MAC. A WTRU may be configured to determine lower layer configurations for itself and / or one or more next hop relay WTRUs.

[0099] The WTRU may update parameters associated with the lower layer configuration for the relay WTRU. According to one implementation, the WTRU may determine the lower layer configuration parameters of the next-hop WTRU in the SLRB. The WTRU may be configured with a set of default parameters and / or a set of allowed configuration parameters that may be modified and updated in various entities of the lower layers (RLC, MAC, PHY). The WTRU may also be configured with specific range values ​​(e.g., maximum and minimum) within which parameters at lower layers are allowed to be modified. For example, different LCH parameters, including priority, PBR, and BSD, may be configured with specific maximum and minimum ranges that the source WTRU and / or next hop / relay WTRU may be allowed to change.

[0100] A WTRU can select a lower layer configuration for a relay WTRU from multiple pre-configurations. According to one implementation, a WTRU can select a lower layer configuration for a WTRU from multiple lower layer (pre-)configurations. For example, the WTRU can select a lower layer configuration for its egress LCH and / or at one or more next-hop WTRU egress LCHs. When selecting a lower layer configuration, parameters in the RLC and MAC entities associated with the LCH may be updated, for example, according to or to correspond to (e.g., match) the parameters of the selected lower layer configuration. In another example, the RLC and MAC entities may be associated with a primary lower layer configuration and one or more secondary lower layer configurations, where different configurations may correspond to different parameters applied in the RLC and MAC entities. The primary (default) and secondary lower layer configurations may be pre-configured in a WTRU associated with an SLRB during (re-)configuration. These different configurations may be identified using an identifier that may be used by the WTRU when selecting / indicating / activating / deactivating lower layer configurations. In this case, for example, a primary (default) configuration may be initially activated during a (re)configuration, while a secondary configuration may be deactivated.

[0101] The WTRU may send multiple pre-configurations to the relay WTRU, and the relay WTRU selects one of the configurations. According to one implementation, the WTRU may receive multiple lower layer configurations for the relay WTRU and may send all or a subset of such multiple lower layer configurations to the relay WTRU. The relay WTRU may be configured with rules for selecting one of the received lower layer configurations based on measurements received at the WTRU or from peer WTRUs, such as CBR, CR, CQI, RSRP, etc., based on buffer occupancy at the WTRU (e.g., in RLC), based on the number of configured unicast links or bearers that the WTRU is currently relaying, possibly with the same source WTRU or for any / all source WTRUs, and / or based on the number of hops in the relayed path for the SLRB.

[0102] For example, the WTRU may be configured with rules to select one of the lower layer configurations received from the source WTRU (or a previous WTRU) based on the number of configured SLRBs currently being relayed by the WTRU.

[0103] The WTRU may forward a subset of the received configurations to the next hop based on its own configuration selection. According to one implementation, the WTRU may select a subset of the received configurations (intended for itself and / or the next-hop WTRU) to be sent to the next-hop WTRU based on its own configuration selection. Specifically, the WTRU may be configured with rules whereby its own configuration selection excludes the use of another configuration by the next-hop WTRU. Such rules may be based on a relationship between one or more parameters of the configurations and / or the alignment of such parameters with the next-hop WTRU. For example, the WTRU may exclude all HARQ-disabled configurations for use by the next hop if the WTRU selects a HARQ-enabled configuration.

[0104] A trigger / indication received by a WTRU to update its or another WTRU lower layer configuration is provided herein. A WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with an SLRB based on an indication from the network. For example, the network may send an indication (e.g., dedicated RRC signaling or SIB) to change the lower layer configuration, which may include values ​​of parameters of different entities to be changed. The network may send an indication to change the lower layer configuration in an SLRB to one or more WTRUs having an RRC connection to a network node (e.g., a source WTRU and / or a relay WTRU). The network may also indicate to a WTRU to change the lower layer configuration in another WTRU configured with an SLRB.

[0105] Based on the lower layer status and measurements, the WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with the SLRB. Status information received from the lower layer may be used to update the lower layer configuration. For example, the WTRU may be configured to receive status information from the lower layer related to the performance of one or more configured lower layer configurations itself. In this case, different sublayers / entities in the lower layer may be configured with periodic or event-based triggers to send status information to the WTRU due to the following triggers:

[0106] A WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with an SLRB based on the RLC status information. For example, an RLC entity may be configured to send status information and / or change its configuration when the number of ARQ retransmissions to a peer WTRU exceeds a certain value.

[0107] Based on the MAC status information, the WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with the SLRB. The MAC entity may be configured to send status information and / or change configuration upon detecting, for example, a maximum HARQ feedback failure from a next-hop relay WTRU.

[0108] Based on the PHY status information, the WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with the SLRB. The PHY layer may be configured to provide status information and / or change configuration due to an event trigger, for example, when channel measurements (e.g., RSRP, CSI feedback) and / or CBR measurements related to a resource pool in the direct link or a sidelink carrier exceed a certain threshold.

[0109] A WTRU may update its own lower layer configuration or the lower layer configuration in one or more WTRUs associated with an SLRB based on buffer occupancy information associated with one or more layers (e.g., RLC, MAC, PHY). For example, a WTRU may be configured to send status information and / or change its configuration when buffer occupancy or channel occupancy (e.g., CR) exceeds a threshold.

[0110] The WTRU may be configured with a first lower layer configuration and a second lower layer configuration and a rule for determining the lower layer configuration based on a status indication, where the WTRU may change to the second lower layer configuration if, for example, a status indication (e.g., number of HARQ feedback failures) is received while using the first lower layer configuration.

[0111] The status indication may be a higher layer status. For example, a higher layer (e.g., PC5-RRC, or any other logical equivalent) may trigger a reconfiguration of one or more lower layers in the WTRU due to a possible reconfiguration of one or more SLRBs associated with the WTRU. Reconfiguration of an SLRB may include modifying an existing SLRB, adding another SLRB (e.g., for transporting PDUs belonging to an existing or new QFI), or terminating an existing SLRB. Reconfiguration of an SLRB may trigger a modification of one or more lower layer configurations associated with the existing SLRB.

[0112] The status indication may be an indication from the relay / next-hop WTRU. For example, if an indication is received from the next-hop relay WTRU indicating a change in existing conditions at the relay WTRU and / or the next-hop link, the existing lower layer configuration may be modified. In this case, the changing conditions at the relay WTRU and next-hop link may be inferred as an inability to meet target QoS requirements on one or more links. For example, a condition at the relay WTRU that may trigger an indication may include reaching a threshold in a buffer associated with an LCH. Similarly, a condition related to the next-hop link that may trigger an indication may include, for example, channel measurements (e.g., RSRP, CSI) and / or congestion levels (e.g., CBR) exceeding different thresholds.

[0113] An indication sent by a WTRU to update the lower layer configuration is disclosed herein. Upon deciding to update the lower layer configuration, the WTRU can individually send the new configuration to each relay WTRU configured with an SLRB. Alternatively, the WTRU can simultaneously send the new configuration (e.g., via groupcast / broadcast) to one or more relay WTRUs configured with an SLRB (e.g., identified by an L2 source / destination ID) by including a relay WTRU ID (i.e., an identifier associated with the relay WTRU) in the message. The indication message for updating the lower layer configuration at the relay WTRU may include parameters to be applied in the lower layer configuration (e.g., ingress / egress LCH), an identifier / index (e.g., LCH ID) of the selected lower layer configuration, and / or a duration for applying the indicated lower layer configuration. For example, the indicated lower layer configuration may be applied at the relay WTRU in the first slot of the indication duration. After the last slot of the indication duration, the relay WTRU may change the lower layer configuration to the previous (default) configuration. Alternatively, the WTRU may be configured with a lower layer configuration that may be applied for a duration following the detection of a failure event / condition (e.g., RLF on a link). After the expiration of the duration, the WTRU may apply the previous lower layer configuration.

[0114] The WTRU may send an indication related to updating the lower layer configuration in the SCI, MAC CE, PC5-RRC, and / or RRC, or any other logically equivalent signal or message. In the SCI, for example, the WTRU may send an indication of either the first stage SCI or the second stage SCI. The WTRU may use a dedicated resource (e.g., PSFCH) when sending the indication in the SCI. In the MAC CE, for example, the WTRU may send an indication to the next-hop relay WTRU in the SL MAC CE. In the PC5-RRC, for example, the WTRU may send an indication to the next-hop relay WTRU in the SL-SRB. In the RRC, for example, the WTRU may send an indication to the network in an RRC message (e.g., WTRU Assistance Information). The indication to the network may include an L2 source / destination ID corresponding to the end-to-end SLRB and the relay WTRU ID. The indication may be sent to the next-hop relay WTRU via another logically equivalent message or transmission.

[0115] The WTRU may send an indication to the network to request that the lower layer configuration in the relay WTRU be updated. According to one implementation, the WTRU may send a request to the network requesting that the lower layer configuration in one or more WTRUs indicated in the request and / or associated with an SLRB be updated. The WTRU may send the request in an RRC message (e.g., "sidelinkWTRUInformation") or any other logical equivalent to obtain the indicated lower layer parameters or to obtain an identifier / index of the lower layer configuration for the indicated WTRU. Alternatively, the request may include measurement reports (e.g., per-link latency, RSRP, CBR, HARQ statistics) that can be used by the network to determine the lower layer configuration that meets the target QoS performance.

[0116] The WTRU may include in the request to determine the lower layer configuration an L2 source / destination ID, an LCH ID, measurements reported by lower layers, and / or QoS-related attributes. The L2 source / destination ID may be to indicate the end-to-end SLRB between the source WTRU and the destination WTRU. If the SLRBs are associated with different L2 IDs, an L2 ID associated with each unicast link between any two peer WTRUs in the end-to-end path (e.g., source WTRU to relay WTRU, relay WTRU to destination WTRU) may also be included. The LCH IDs of one or more LCHs configured for the SLRB may be included. Measurements reported by lower layers associated with the indicated egress LCH at the WTRU and / or next-hop WTRU (e.g., number of HARQ / RLC retransmissions, CBR) may be included. QoS-related attributes reported by the next-hop WTRU associated with the indicated egress LCH (e.g., latency per link, packet error rate) may also be included.

[0117] The WTRU may be configured with triggers to send an indication to the network related to measurements at the WTRU of the QoS related attributes described above.

[0118] The relay WTRU may determine the lower layer configuration based on the received indication for triggering a configuration update. According to one implementation, the relay WTRU determines the lower layer configuration to apply at the ingress side (Rx) and / or egress side (Tx) of the WTRU based on an indication received from another WTRU or the network.

[0119] The relay WTRU may determine the lower layer configuration to be applied based on information included in the received indication. The received indication may be an indication from the source WTRU / previous hop WTRU on the lower layer configuration. For example, the source WTRU may indicate an update to a configuration parameter or identifier of the selected lower layer configuration to be applied at the ingress side (Rx side) associated with the SLRB to match the parameter to be applied at the egress side (Tx side) of the source WTRU. The source WTRU may also indicate the lower layer configuration parameter / identifier to be applied at the egress side (Tx side) associated with the SLRB in the relay WTRU. The indication from the source WTRU / previous hop WTRU including the lower layer configuration parameter / identifier for updating the ingress / egress side may be sent in the SCI, SL MAC CE, or PC5-RRC, or any other logical equivalent.

[0120] The received indication may be an indication from the source WTRU / previous hop WTRU regarding QoS information. For example, the indication from the previous hop WTRU may include parameters related to the remaining QoS (e.g., latency, reliability) for the relay WTRU to take into account when determining / selecting a lower layer configuration for the subsequent hop. In this case, the relay WTRU may use a rule consisting of one or more criteria for determining a lower layer configuration based on the received QoS parameters. As an example, a relay WTRU that may be configured with a first lower layer configuration and a second lower layer configuration may select the first lower layer configuration if the received QoS-related indication (e.g., the remaining PDB is within a first range) satisfies the first criterion. Otherwise, the relay WTRU may select the second lower layer configuration if the QoS-related indication (e.g., the remaining PDB is within a second range) satisfies the second criterion.

[0121] The received indication may be an indication from the network, for example, an in-coverage relay WTRU may receive an indication including a parameter / identifier of the lower layer configuration from the network in either a DCI or an RRC message to update the lower layer configuration.

[0122] The received indication may be an indication from the destination WTRU / next-hop WTRU. For example, if the relay WTRU receives a trigger (RLC / HARQ feedback) from the next-hop WTRU that may infer that it cannot meet the target QoS performance (e.g., increase per latency, decrease per link reliability), the relay WTRU may update the lower layer configuration at the egress side.

[0123] The received indication may be a change in buffer status in one or more LCHs. For example, if data in a buffer belonging to another LCH with a higher priority setting exceeds a configured threshold, the relay WTRU may update the configuration of the LCH.

[0124] The received indication may be a lower layer status. For example, if the relay WTRU receives a status report (e.g., channel measurement report, RSRP, CBR) from the lower layer related to a resource pool / sidelink carrier configured for the lower layer configuration, based on which QoS performance may be inferred, the relay WTRU may update the lower layer configuration.

[0125] The received indication may be an indication from an adaptation layer, for example, the relay WTRU may be triggered by the adaptation layer to change lower layer configurations in one or more lower layers when mapping between different lower layers on the ingress and egress sides is updated.

[0126] After determining the updates to the lower layer configuration to be applied at the egress side, the relay WTRU may send an indication including the status of updating the lower layer configuration, the modification of the lower layer configuration relay WTRU, and the modification of the LCH mapping at the relay WTRU.

[0127] The relay WTRU may send an indication including the status of updating the lower layer configuration based on the received trigger. For example, if the relay WTRU receives an indication including the configuration parameters / identifier of the lower layer configuration, the relay WTRU may respond by indicating the success or failure status of updating the indicated configuration. The relay may send the lower layer configuration update status information (including the configuration identifier or LCH ID) to the source WTRU associated with the SLRB and configured with the L2 ID between the source WTRU and the relay WTRU in either the PC5-RRC, SL MAC CE, or SCI. The relay WTRU may send the status information in response to, for example, a polling request sent by the source WTRU inquiring about the status of the lower layer configuration update. Alternatively, the relay WTRU may send the status information to the network in either the RRC or MAC CE by including the L2 ID and / or LCH ID. The received indication from the relay WTRU may be used by the source WTRU or the network, for example, to report the status of the configuration update to upper layers.

[0128] The relay WTRU may send an indication including the modification of the lower layer configuration relay WTRU. For example, if the relay WTRU determines lower layer configuration parameters / identifiers that may differ from the parameters / identifiers indicated in the received indication, the relay WTRU may send an indication to either the source WTRU or the network of the updated lower subsequent configuration parameters / identifiers to be applied at the relay WTRU for the associated SLRB.

[0129] The relay WTRU may send an indication including a modification of the LCH mapping at the relay WTRU. For example, if a lower layer configuration update triggers a modification of the mapping between the ingress LCH and egress LCH, the relay WTRU may send an indication including the updated mapping and / or the updated lower layer configuration to the network or source WTRU associated with one or more SLRBs configured at the relay WTRU and affected by the change in LCH mapping.

[0130] A solution for determining a relay for a WTRU-to-WTRU relay with E2E communication range is disclosed herein.

[0131] The relay WTRU may determine a decision to relay to a destination WTRU based on the end-to-end communication range. According to some implementations, the relay WTRU may determine a decision to relay a received PDU to a next destination WTRU depending on the received communication range and possibly other location information. In some examples, the relay WTRU may determine whether to relay a received PDU based on the range requirements indicated in the SCI and the relative locations of the source WTRU and / or destination WTRU and / or relay WTRU. For example, the relay WTRU may relay data if the distance to the destination WTRU is less than or equal to the end-to-end communication range requirement. For example, the relay WTRU may relay data if the communication range is greater than the sum of the distance between the source WTRU and the relay and the distance between the relay WTRU and the destination. In another example, a hop count may be applied to estimate the end-to-end communication range, where each hop may be associated with a certain per-hop range, and the total number of allowed hops may be determined as the end-to-end communication range divided by the per-hop range. In this example, the relay WTRU may relay data if the remaining hop count to the destination WTRU is lower than the maximum hop count requirement.

[0132] To determine the decision to relay, the relay WTRU may perform all or a subset of the following: determining the end-to-end range or hop count requirement, the distance from the source WTRU to the relay WTRU, the distance to the destination WTRU, the offset distance of the relay WTRU, and / or the updated communication range from the relay WTRU.

[0133] The relay WTRU may determine the end-to-end range or hop count requirement. For example, the relay WTRU may identify the end-to-end range or hop count based on a range or hop count value indicated in a control channel (e.g., SCI) or in a control indication (e.g., MAC CE) sent by the source WTRU to the relay WTRU along with the data. Alternatively, the relay WTRU may identify the end-to-end range from default configuration values ​​included when configuring the associated LCH / SLRB at the relay WTRU.

[0134] The relay WTRU may determine the distance from the source WTRU to the relay WTRU. For example, the relay WTRU may determine the distance in the first hop link based on the geographic zone / location information indicated in the SCI transmitted by the source WTRU along with the data. According to this implementation, the distance to the source may be determined based on, for example, the difference between the location of the source WTRU and the location of the relay WTRU.

[0135] The relay WTRU may determine the distance to the destination WTRU. For example, the distance to the destination WTRU may be determined based on link status information on the second hop link. The link status information may be obtained by the relay WTRU based on a request message, such as a polling request, HARQ feedback, or CSI report, sent to the destination WTRU. The destination WTRU may include its location information in the SCI, for example, when sending a response / feedback message to the relay WTRU. Alternatively, the destination WTRU may periodically send its location information to the relay WTRU, for example, using a PC5-RRC message, an RRC message, another logically equivalent message, or a periodic data transmission.

[0136] According to one implementation, the relay WTRU may decide whether to relay a message based solely on the range requirement and the distance between the source WTRU and the relay WTRU (i.e., without the knowledge of the destination WTRU). For example, if the distance between the source WTRU and the relay WTRU is less than the communication range, possibly by some (pre-)configured offset value, the relay WTRU may decide to relay the message.

[0137] The relay WTRU may determine an offset distance for the relay WTRU. For example, the relay WTRU may determine the offset distance to take into account the location of the relay WTRU relative to the direct path connecting the source WTRU and the destination WTRU.

[0138] In the case of unicast, the offset distance may be determined as a function of the distance between the source WTRU and the relay WTRU and the angle relative to the direct path connecting the source WTRU and the destination WTRU and the relay path connecting the source WTRU and the relay WTRU. For example, the offset distance d2 may be determined as d2 = d1 × cos θ, where d1 is the distance between the source / previous hop WTRU and the relay WTRU, and θ is the angle between the direct path (e.g., connecting the source WTRU and the destination WTRU) and the relay path (e.g., connecting the source WTRU and the relay WTRU). Information regarding the angle may be carried on a control channel (e.g., SCI) or in a control indication (e.g., MAC CE) in the PDU received from the source WTRU, as an example. In another example, the offset distance for unicast may be applied if the determined offset distance value is greater than or equal to a configured threshold.

[0139] In the case of groupcast, the offset distance may be determined as a function of one or more of the number of destination WTRUs in the group, the location of one or more destination WTRUs in the group, and / or a higher layer indication or network configuration.

[0140] The relay WTRU may determine an updated communication range from the relay WTRU. For example, the WTRU may subtract the distance between itself and the received WTRU from the received communication range (at the SCI). The WTRU may further round the value determined from such subtraction to a larger / smaller allowed communication range value.

[0141] Based on the items enumerated herein, the criteria for relaying may be: a relay WTRU may decide to relay data if the received range requirement is greater than the distance between the source WTRU and the destination WTRU; a relay WTRU may decide to relay data if the received range requirement is greater than the distance between the source WTRU and the relay WTRU itself by at least some delta (positive or negative); a relay WTRU may decide to relay data if the received range requirement is greater than the distance between the source WTRU and the relay WTRU itself; a relay WTRU may decide to relay data if the received range requirement is greater than the distance between the source WTRU and the relay WTRU itself by at least some delta (positive or negative); a relay WTRU may decide to relay data based on a combination of the distance between the source / relay WTRU in addition to the received signal strength of a transmission (e.g., HARQ feedback) from the destination WTRU. For example, a relay WTRU may be configured with a minimum PSFCH received power for a given value (of range requirement minus source / relay distance), whereby the WTRU will relay data if one or more (or average) PSFCH powers are above a threshold.

[0142] The criteria for relaying may be such that the relay WTRU may decide to relay data based on a combination of the distance between the source / relay WTRU in addition to the CQI reported by the destination WTRU. For example, the relay WTRU may be configured with a minimum CQI for a given value (range requirement minus source / relay distance), whereby the WTRU will relay data if one or more (or average) CQIs are above a threshold.

[0143] The criteria for relaying may be that the relay WTRU may decide to relay data based on HARQ feedback received from the destination in response to a recent transmission with the same / similar range requirement. For example, following reception of a DTX for a transmission to a destination for a transmission with a range requirement of X, the relay WTRU may decide to drop subsequent PDUs received with range requirement ≧X, possibly for a (pre-)configured time period.

[0144] The criteria for relaying may be that the relay WTRU may decide to relay data if the difference between the range requirement (e.g., the distance between the source WTRU and the destination WTRU) and the updated distance between the relay WTRU and the destination WTRU is less than a configured distance threshold. The updated distance between the relay WTRU and the destination WTRU may be determined, for example, by subtracting an offset distance from the distance between the relay WTRU and the destination WTRU.

[0145] If the WTRU determines that it does not need to relay a PDU (based on the conditions described above), it may decide to drop the PDU. Alternatively, the WTRU may decide to either drop or relay the PDU depending on other factors such as the CBR, CB, number of relay hops, or the priority of the transmission itself.

[0146] The relay WTRU may send a packet drop indication to the source WTRU. If configured, the relay WTRU may explicitly indicate its decision to drop or relay a PDU to the source WTRU. For example, the relay WTRU may send a message to the source WTRU indicating that one or more PDUs, possibly associated with a particular communication range, have been dropped by the relay WTRU. The relay WTRU may send such information in an SL MAC CE, an SL RRC message, or another logical equivalent, or using a new / existing PHY channel (e.g., SCI, transmission on dedicated PSFCH resources).

[0147] Upon receiving such a packet drop indication, the source WTRU may further drop PDUs with the same or larger minimum communication range, possibly for a preconfigured time period after receiving the indication, or may change transmission parameters associated with transmissions with the same or larger minimum communication range (e.g., map such transmissions to a default SLRB configuration or modify some parameters of the associated SLRB configuration).

[0148] Disclosed herein is a solution for determining resources for WTRU-to-WTRU relay with E2E QoS, as well as a solution that allows the WTRU to make resource selection based on the next-hop WTRU's configuration and the expected remaining packet delay budget.

[0149] According to some implementations, a WTRU may obtain resources for transmission in one hop of a relayed WTRU-to-WTRU link with one or more relay WTRUs or make resource selections based on resource selection information provided by another WTRU.

[0150] According to some implementations, a WTRU configured in an autonomous resource selection mode (e.g., Mode 2) determines the setting of the resource selection window taking into account the resource selection configuration applied at the next-hop relay WTRU, in which case the WTRU at the first hop may select resources for transmission at the first-hop link such that the remaining time from the end-to-end latency budget is available to the relay WTRU at the next-hop link for making subsequent transmissions.

[0151] According to some implementations, the Tx WTRU at the first hop (source WTRU), which may be configured in Mode 2, can determine the resource selection window by considering the end-to-end latency budget (e.g., PDB) combined with knowledge of the relay link. The source WTRU can also determine the resource selection window based on knowledge of the resource selection mode used by the relay WTRU. The source WTRU can also consider processing delays at the relay WTRU as part of the resource selection window calculation.

[0152] The resource selection mode and / or processing delay at the relay WTRU may be provided to the source WTRU, for example, during (re)configuration of the SLRB and associated LCH. Alternatively or additionally, the source WTRU may assume a fixed or (pre-)configured value for the processing delay. Alternatively or additionally, the relay WTRU may indicate an updated configuration to the source WTRU, for example, in a PC5-RRC, SL MAC CE, SCI, or another logically equivalent message or transmission. As an example, if the resource allocation mode at the relay WTRU changes from Mode 2 to Mode 1, or if the processing duration at the relay WTRU changes (e.g., exceeds a certain threshold), an indication may be sent to the source WTRU to indicate the updated configuration. For example, if the end-to-end latency budget is M (timeslots), the source WTRU may set T2 = M - M2 - M1, where M2 and M1 are the expected time budget / updated time budget (number of time slots) at the next hop link and the processing duration at the next hop WTRU, respectively. T2 at the next hop relay WTRU may be set as, for example, M2.

[0153] In one example, the source WTRU and relay WTRU may equally share the overall time budget for transmission (i.e., PDB), taking into account processing latency and / or resource selection mode at the relay WTRU. Specifically, M2 may be set as (PDB-M1) / 2. Alternatively or additionally, the time budget at the source / relay WTRU may be set / adjusted based on factors such as the CBR at the source / relay WTRU, the observed sensed load, the CR, etc. For example, M2 may be scaled based on the CBR observed at the relay and / or source WTRU and exchanged between the WTRUs using the mechanisms described herein.

[0154] According to some examples, the WTRUs may explicitly exchange time budgets. Specifically, a resource selection window may be configured at the WTRU (e.g., a source WTRU or a relay WTRU) based on the predicted time budget available for the next-hop link and / or the updated time budget for the next-hop link.

[0155] The resource selection window may be set in the WTRU based on the expected time budget available for the next-hop link. For example, the WTRU may estimate the time available for the next-hop link based on the next-hop / relay WTRU's T2 value provided during SLRB / LCH (re)configuration. For example, the relay WTRU may be configured with a set of T2 values ​​that it can use (given the current measurement conditions) for each possible value of priority or LCH configuration and may signal such values ​​to the source WTRU.

[0156] The resource selection window may be set at the WTRU based on the updated time budget of the next hop link. For example, the updated time budget for transmission on the next hop link may be indicated by the next hop / relay WTRU based on the conditions of the next hop link (e.g., CBR, RSRP). If the time budget on the next hop link changes from the initial configuration value or the value provided in a previous update, the relay WTRU may send an indication to the source / previous hop WTRU.

[0157] The WTRU may inform the NW of the processing delay / link conditions for the relay WTRU. According to some implementations, when the source WTRU is in Mode 1 and the relay WTRU is in Mode 2 or out of coverage (OOC), the source WTRU may send a request to the network by including information about the processing delay and / or link conditions at the relay WTRU for the next hop link. Specifically, the source WTRU may send any of the following: the CBR reported by the relay WTRU, the processing delay of the relay WTRU, the calculated / expected time budget (for one or more priorities) at the relay WTRU, the sensing results, or any indication of the sensed load measured by the relay WTRU, and / or RSRP / CQI measurements at the next hop link.

[0158] Such information may be sent upon link establishment with the relay WTRU. Alternatively or additionally, it may be sent whenever the source WTRU receives such updated information at the relay. The purpose of such information is to enable the NW to schedule resources at the source WTRU taking into account the requirements of the peer WTRUs.

[0159] The relay WTRU may use the remaining time budget to determine the resource selection window. According to one implementation, the relay WTRU may then select resources for transmission on the next-hop link based on the remaining time indicated by the WTRU at the first hop. For example, the source WTRU may provide the remaining time budget (e.g., T2—the timing of the actual resources selected) and may provide such information to the relay WTRU. The relay WTRU may use the remaining time budget in calculating its own value of T2. Specifically, the relay WTRU may increase the time budget of its resource selection by the remaining time budget received from the source WTRU.

[0160] A WTRU may perform resource (re)selection for periodic resources based on a periodic resource at a previous hop WTRU. According to one implementation, a WTRU configured to transmit periodically may determine the resources to be used based on receiving an indication related to the use of periodic resources at another WTRU (i.e., the previous hop link). Specifically, the previous hop / source WTRU may determine the resources for periodic transmission. A next hop / relay WTRU may perform periodic resource selection by selecting resources based on the timing of the resources used by the previous hop / source WTRU. For example, the relay WTRU may select resources with a similar periodicity and with some time offset that takes into account the processing / forwarding delay at the relay WTRU.

[0161] According to one implementation, upon receiving periodic resources (i.e., a configured grant) from the network or upon selecting periodic resources in Mode 2, the source WTRU may indicate the periodic resource configuration to the relay WTRU through an explicit message (e.g., PC5-RRC or another logical equivalent). The WTRU may send such a message upon initial selection of resources or upon reselection of such resources triggered at the source WTRU. Upon receiving such a message, the relay WTRU may perform resource (re)selection using the same periodicity and possibly including some offset (possibly (pre)configured or predetermined based on WTRU capabilities). The relay WTRU may further select resources such that the offset is greater than a first value and / or less than a second value, where the first value may be pre-configured or defined based on WTRU capabilities and / or the second value may be pre-configured and may depend on the QoS of the data that may be transmitted on the periodic resource and / or the channel conditions at the relay (e.g., CBR, CQI reported by the destination WTRU, RSRP reported by the destination WTRU, etc.).

[0162] The source WTRU or the network can indicate periodic resource usage to one or more relay WTRUs by indicating the periodic resource configuration in the sidelink to the relay WTRU. For example, the resource configuration indication can include any of the identifier of the resource pool configuration, the starting subchannel, the number of subchannels, the starting time slot, the offset time slot, and the periodicity to be applied by the relay WTRU when using the resources to transmit in the next hop link. For some parameters, such as the offset time slot, the allowed range may also be indicated, e.g., so that the relay WTRU can apply its own changes when using the resources while adhering to the allowed range constraints. The resource configuration may be indicated by the source WTRU to each relay WTRU configured with an SLRB in individual PC5-RRC messages (or via other logical equivalents), or to the relay WTRU in a single PC5-RRC message (or logical equivalent), where each relay WTRU may be identified using a WTRU ID in the message. If the relay WTRU is in coverage, the periodic resource configuration may be indicated by the network in an RRC message or any logical equivalent.

[0163] The source WTRU or the network may indicate periodic resource usage to the relay WTRU by activating a periodic resource configuration in the relay WTRU in the sidelink. For example, the source WTRU may send an activation message to activate the use of periodic resources, possibly previously configured in the relay WTRU. The activation message for activating the use of periodic resources may include an identifier associated with the configured periodic resources and / or an allowance offset value to be used by the relay WTRU when transmitting in the next hop link. The activation message may be sent by the source WTRU to the relay WTRU in the SCI, in the SL MAC CE, or another logical equivalent.

[0164] Upon receiving a configuration / trigger (e.g., SCI) from the source WTRU to use periodic resources, the relay WTRU may use the parameters indicated by the source WTRU / network (i.e., offset time slots and periodicity) on the indicated periodic resources (i.e., resource configuration identifier, starting subchannel, number of subchannels) when making resource selection. For example, the relay may use the same periodicity value used by the source WTRU on the periodic resources, while applying the offset time slots to offset delays associated with data reception and processing at the relay WTRU.

[0165] According to one implementation, a relay WTRU can trigger resource (re)selection upon detection (e.g., in an SCI) of a periodic resource used by a resource WTRU. Specifically, resource (re)selection may be triggered by the relay WTRU when it detects an SCI transmitted by a source WTRU that has reserved a periodic resource, where such periodic resource indicates a destination ID that matches the destination ID of the relay WTRU. The relay WTRU may use the same / similar parameters (e.g., periodicity, number of resources) for its own periodic process and may select such resources based on an offset as described herein. The WTRU may further perform such (re)selection based on the presence of some explicit indication or trigger from the source WTRU (e.g., sent in the SCI). For example, the source WTRU may be configured to include an indication in the SCI when such a process is used to carry data of a particular LCH / QoS. The relay WTRU may then perform resource (re)selection for the associated periodic process only if such an indication is present in the SCI.

[0166] The relay WTRU may trigger an indication to the NW upon receiving a periodic process from the source WTRU. According to one implementation, the relay WTRU may send an indication to the network upon receiving a periodic resource configuration or an SCI triggering such periodic resources from a peer (source) WTRU as described herein. Such an indication may be sent in an RRC message (e.g., "WTRUAssistanceInformation, SidelinkWTRUInformation"), a BSR, a dedicated SR, or another logical equivalent. The WTRU may further include details of the periodic resources reserved by the peer (source) WTRU, such as the period, offset, LCH / priority, and L2 ID of the peer WTRU.

[0167] The relay WTRU may ensure that data received from a periodic process is relayed on the associated periodic process / resource at the relay. The relay WTRU may configure LCP restrictions, periodic transmit process restrictions, or the like to ensure that data received by the WTRU on one periodic process is transmitted on the associated transmit periodic process at the relay WTRU. Specifically, when mapping an ingress LCH to an egress LCH and / or performing LCP for a grant associated with an associated periodic process, the relay WTRU may prioritize the data and / or ensure that the transmit process limits data received from the associated receive process. Such may be achieved by the WTRU configured with an LCP restriction associated with the periodic resource that is related to or derived from a similar LCP restriction applied at the source WTRU for the associated periodic resource (the relay WTRU may, for example, receive such an LCP restriction from the source WTRU when a periodic resource is selected). Alternatively or additionally, the WTRU may prioritize an LCH containing data from an LCH received from the source WTRU on the associated periodic resource at the source WTRU during the LCP for the associated periodic resource.

[0168] Solutions for determining radio bearer mapping at a remote WTRU are described herein. In some solutions, the remote WTRU may be configured to perform 1:1, N:1, or 1:N mapping from one or more end-to-end (E2E) radio bearers to one or more PC5 RLC channels to improve SL channel / resource utilization while satisfying E2E QoS.

[0169] In some examples, the remote WTRU may be configured with an adaptation layer, or an equivalent logical process or function operating in hardware or software, to map from one or N E2E radio bearers (e.g., each including at least a PDCP sublayer / entity at the transmitting and receiving sides of the radio bearer) to at least one RLC channel (e.g., each including at least an RLC sublayer / entity at the transmitting and receiving sides of the RLC channel). As an example, an E2E radio bearer may carry PDUs corresponding to one or more QoS flows, where different QoS flows may be mapped to one or more PDCP entities. In this case, the PDUs of the E2E radio bearer may be, for example, PDCP PDUs. In the case of 1:1 or N:1 mapping, the adaptation layer or logical equivalent may, for example, map PDUs associated with one or more E2E radio bearers to a single PC5 RLC channel. In another example, the adaptation layer or logical equivalent may be configured to perform 1:N mapping, where PDUs from an E2E radio bearer may be mapped to one or more PC5 RLC channels. The one or more PC5 RLC channels at the remote WTRU may be directed towards the same relay WTRU or different relay WTRUs.

[0170] An adaptation layer in the remote WTRU, or an equivalent logical process or function operating in hardware or software, may be configured in both a WTRU-to-WTRU relay scenario and a WTRU-to-network relay scenario. In a WTRU-to-WTRU relay scenario, the remote WTRU may map PDUs associated with an E2E sidelink radio bearer (between a source / remote WTRU and a destination / target WTRU) to one or more egress RLC channels (the transmit side of the remote WTRU). In a WTRU-to-WTRU relay WTRU adaptation layer, a received PDU in a corresponding ingress RLC channel (the receive side of the relay WTRU) may be mapped to one or more other egress PC5 RLC channels (the transmit side of the relay WTRU), for example, when relaying to the intended destination WTRU. Similarly, in a WTRU-to-network relay scenario, the remote WTRU may map PDUs associated with an E2E Uu radio bearer (between a remote / source WTRU and a Node B (e.g., an eNB or gNB)) to one or more egress RLC channels (the transmit side of the remote WTRU). In a WTRU-to-Network Relay WTRU adaptation layer or logical equivalent, a received PDU in a corresponding ingress RLC channel (receiving side of the relay WTRU) may be mapped to one or more other egress Uu RLC channels (transmitting side of the relay WTRU) when relaying to, for example, a Node B in the network (e.g., an eNB or gNB).

[0171] The remote WTRU may be configured with a mapping configuration in the adaptation layer or logical equivalent to perform N:1 or 1:N mapping. More specifically, in one solution, the remote WTRU may perform mapping from N E2E radio bearers to RLC channels in the adaptation layer or logical equivalent based on the mapping configuration. For example, mapping of PDUs from one or more E2E radio bearers, where each radio bearer may carry one or more QoS flows, to RLC channels may be performed such that the QoS (e.g., throughput, latency) achieved upon mapping is equal to the QoS before mapping. The remote WTRU may be configured with the mapping configuration in the adaptation layer, for example, by the relay WTRU (e.g., via PC5 signaling) or by the network (e.g., RRC signaling).

[0172] The mapping configuration configured in the remote WTRU may correspond to one or more of the following: a radio bearer (with ID x) may be allowed to be mapped to an RLC channel (with ID y), a radio bearer (with ID x) may be allowed to be mapped to one of M RLC channels (with IDs y1, .. yM), a group of K radio bearers (with IDs x1, .., xK and with group ID G) may be allowed to be mapped to one of M RLC channels (with IDs y1, .. yM), or any one or more of the K radio bearers in a group (with IDs x1, .., xK and with group ID G) may be allowed to be mapped to one of M RLC channels (with IDs y1, .. yM).

[0173] An equivalent mapping configuration may also be configured in the remote WTRU for RLC channels corresponding to one or more allowable radio bearers that may be mapped to the RLC channel. Different mapping configurations or associations between E2E radio bearers and RLC channels may be identified using a mapping ID. As an example, the mapping / association of a radio bearer (with ID x) to M allowable RLC channels (with IDs y1, ... yM) may be identified using a specific ID (e.g., mapping configuration ID x).

[0174] In addition to the mapping configuration, the remote WTRU may also be configured with a default mapping when mapping one or more radio bearers to an RLC channel. For example, if the remote WTRU is configured to map one or more radio bearers to one of M allowable RLC channels, the remote WTRU may map the radio bearer to a default RLC channel that may be configured among the M allowable RLC channels (e.g., a radio bearer with ID x may be mapped to a default RLC channel with ID y). Furthermore, each of the M allowable RLC channels for mapping a radio bearer may also be associated with, for example, a priority or index value. In this case, the remote WTRU may, for example, map PDUs from a radio bearer to the RLC channel with the highest priority until a mapping criterion is met, and then map the PDU to the RLC channel with the next highest priority. The mapping criterion may correspond to any one of the above combinations, including, for example, a PDU count, a buffer in an RLC channel exceeding a threshold, and a timer expiry. The mapping criteria that the remote WTRU may use when mapping / multiplexing radio bearers onto RLC channels may be configured to achieve a particular behavior, such as proportional fairness or round robin.

[0175] In another solution, if 1:N mapping is supported in the adaptation layer or logical equivalent for mapping of radio bearers to one or more RLC channels, the different mapping configurations configured in the remote WTRU may correspond to one or more of the following: A radio bearer (with ID x) may be allowed to be mapped to two RLC channels (with IDs y1, y2), or a radio bearer (with ID x) may be allowed to be mapped to at least two of M RLC channels (with IDs y1, ..., yM).

[0176] As with the N:1 mapping, different mapping configurations or associations between E2E radio bearers and RLC channels may be identified using a mapping ID. Furthermore, when performing 1:N mapping, the remote WTRU may also be configured with splitting criteria for splitting traffic on the radio bearers between the RLC channels. The splitting criteria may correspond to any one of the above conditions, including, for example, PDU count, buffers in the RLC channel exceeding a threshold, and expiration of a timer associated with the RLC channel.

[0177] The remote WTRU may use the mapping configuration at the adaptation layer semi-statically or dynamically when performing N:1 or 1:N mapping. In the case of semi-static configuration at the adaptation layer, or an equivalent logical process or function operating in hardware or software, the remote WTRU may use the mapping configured by the relay WTRU via PC5-RRC, by the network via RRC, or via another logically equivalent message or signal, until a reconfiguration message is received. In the case of dynamic configuration, the remote WTRU may initially be pre-configured with a set of different mapping configurations, for example, as described above. The remote WTRU may then dynamically change or select from the pre-configured set of mapping configurations, for example, based on trigger conditions determined at the remote and / or based on indication messages (e.g., activation / deactivation) received from the relay WTRU or the network. In some examples, the remote WTRU may autonomously determine the mapping in the adaptation layer, or an equivalent logical process or function operating in hardware or software, based on a trigger condition detected at the remote WTRU and / or based on an indication message received from the relay WTRU / network. A description of the trigger conditions and indication messages is provided in the following sections.

[0178] The remote WTRU may send control information associated with the adaptation layer or equivalent logical functions operating in the WTRU. In one solution, if the remote WTRU performs N:1 or 1:N mapping in the adaptation layer, the remote WTRU may provide / send control information related to the radio bearer and / or mapping configuration to be applied when sending the PDU to the RLC channel and then to the relay WTRU.

[0179] The content of the control information may include an E2E radio bearer ID. For example, in the case of WTRU-to-WTRU relay, the radio bearer ID corresponds to a sidelink radio bearer ID, and in the case of WTRU-to-network relay, the radio ID corresponds to a Uu radio bearer ID. Furthermore, the information about the radio bearer ID may be applicable to both L2 and L3 radio bearer types, for example.

[0180] The content of the control information may also include the number of E2E radio bearers to be mapped to the RLC channel. For example, if the remote WTRU performs N:1 mapping, the remote WTRU may indicate the number of radio bearers to be mapped to the RLC channel.

[0181] The content of the control information may also include load information related to the E2E radio bearer. For example, the remote WTRU may indicate the load of N radio bearers mapped to the RLC channel. The load of the radio bearers may be indicated, for example, in terms of data / bit rate (total or average), PDU count, and percentage of buffer occupancy.

[0182] The content of the control information may also include a QoS flow ID. For example, the remote WTRU may include information regarding the QoS flow ID (e.g., QFI) that is carried in a radio bearer that is subsequently mapped to an RLC channel.

[0183] The content of the control information may also include a path / route ID. For example, the path ID may correspond to an E2E L2 ID (source / remote WTRU ID, final destination ID) or other E2E routing ID that may be used to assist the relay WTRU in routing traffic to the next hop node (e.g., gNB, destination WTRU). Additionally, the path ID may correspond to, for example, the L2 ID of the PC5 link between the remote WTRU and the relay WTRU.

[0184] The content of the control information may also include a mapping configuration ID. For example, if the remote WTRU applies one of the mapping configurations configured for mapping between radio bearers and RLC channels, the ID of the mapping configuration may be included. The remote WTRU may include the mapping configuration ID when performing a mapping update in any of the following combinations: N:1 to 1:1 and vice versa, N:1 to 1:N and vice versa, 1:N to 1:1 and vice versa.

[0185] The content of the control information may also include QoS-related information. For example, the remote WTRU may include additional information for guaranteeing / enforcing E2E QoS as part of the control information. The QoS information may include, for example, latency-related information (e.g., a timestamp indicating the start time of mapping a PDU from a radio bearer to an RLC channel, the expected latency on the PC5 link for transmission to the relay WTRU, and the expected remaining time available at the relay WTRU for relaying to the next-hop node) to assist in scheduling and forwarding at the relay WTRU. In addition, the remote WTRU may indicate a priority value assigned to the radio bearer, where the priority may refer to a priority per radio bearer, for example, in case of an N:1 mapping from multiple radio bearers to RLC channels.

[0186] The remote WTRU may send the control information to the next-hop relay WTRU in at least one of the following ways.

[0187] The remote WTRU may also send control information to the next-hop relay WTRU in an adaptation layer header, for example, the control information may be included in an adaptation layer header that may be added to a PDCP PDU associated with a radio bearer before sending the PDU on the RLC channel.

[0188] The remote WTRU may also send control information to the next-hop relay WTRU in an adaptation layer control PDU, for example, the control information may be sent in an adaptation layer control PDU, which may be sent as a separate adaptation layer PDU to the mapped RLC channel.

[0189] The remote WTRU may send control information to the next-hop relay WTRU in other control signaling, for example, the control information may be sent in either PC5-RRC, SL MAC CE, or SCI.

[0190] When sending a PDU over the SL / PC5 link, the remote WTRU may send control information related to the adaptation layer, or an equivalent logical function operating in the WTRU, to a next-hop relay WTRU associated with the (egress) RLC channel, including at least one of the above information. Alternatively or additionally, the remote WTRU may also send control information when changing / updating a mapping configuration in the adaptation layer, or an equivalent logical function operating in the WTRU. For example, if the remote WTRU dynamically updates / changes the mapping configuration, the remote WTRU may indicate control information (e.g., a changed mapping configuration ID) corresponding to the changed mapping to the relay WTRU. The remote WTRU may also send control information to the network (in a WTRU-to-network relay scenario) or to the destination WTRU (in a WTRU-to-WTRU relay scenario), for example, when dynamically changing the mapping configuration. In this case, the control information may be sent (transparently) via the relay WTRU using, as an example, E2E RRC signaling or E2E PC5-RRC signaling, respectively, or another logical equivalent. If the remote WTRU may have a direct link (Uu or PC5) available to the network or destination WTRU, the control information may be sent directly without relaying.

[0191] The remote WTRU may perform mapping in the adaptation layer, or other logically equivalent functions running in the remote WTRU, based on trigger conditions detected / determined at the remote WTRU.

[0192] In some solutions, the remote WTRU may select a mapping configuration from a pre-configured set for mapping E2E radio bearers to RLC channels based on triggering conditions detected and / or determined at the remote WTRU. Rules for selecting a mapping configuration and associated triggering conditions may be configured at the remote WTRU, for example, by the relay WTRU (via PC5-RRC or another logical equivalent) or by the network (via RRC or another logical equivalent). The remote WTRU may use similar triggering conditions to autonomously determine mapping at the adaptation layer or other equivalent logical function running at the WTRU. The remote WTRU may select / deselect RLC channels or mapping configurations for mapping radio bearers to RLC channels at the adaptation layer based on one or more of the following triggering conditions:

[0193] The remote WTRU may select / deselect an RLC channel or a mapping configuration for mapping radio bearers to an RLC channel at the adaptation layer based on the buffer status in the RLC channel. For example, the remote WTRU may determine / select a mapping if the buffer level of the RLC channel drops below a threshold. Similarly, the remote WTRU may not select an RLC channel for mapping if its buffer level increases above a threshold.

[0194] The remote WTRU may also select / deselect an RLC channel or a mapping configuration for mapping radio bearers to RLC channels at the adaptation layer based on a timer. For example, when mapping PDUs from one or more radio bearers to an RLC channel, the remote WTRU may start a timer with a configured duration and perform the mapping until the timer expires. The configured duration may be determined as a function of lower layer measurements corresponding to the sidelink radio channel associated with the RLC channel.

[0195] The remote WTRU may also select / deselect an RLC channel or a mapping configuration for mapping a radio bearer to an RLC channel at the adaptation layer based on a QoS-related marking in the PDU header. For example, the remote WTRU may use a marking in the PDU header, possibly from a higher layer or the SDAP sublayer, to identify an RLC channel for mapping a PDU from a radio bearer. In such a case, the marking in the PDU header may be associated with QoS parameters (e.g., latency / PDB requirements, priority) that the remote WTRU can use together with the QoS-related information (e.g., priority) of the RLC channel to determine an RLC channel that enables the remote WTRU to achieve the QoS requirements of the radio bearer. As an example, the remote WTRU may select / determine a mapping from a radio bearer to an RLC channel whose assigned priority is comparable / matches the priority assigned to the radio bearer.

[0196] The remote WTRU may also select / deselect an RLC channel or a mapping configuration for mapping radio bearers to RLC channels at the adaptation layer based on SL channel conditions. For example, the remote WTRU may determine / select a mapping if measurements (e.g., SL RSRP, CQI) of the SL radio channel associated with the RLC channel are below / above a certain threshold and the measurements remain below / above the threshold for a certain duration. Similarly, the remote WTRU may determine / select a mapping to an RLC channel using the number of HARQ feedbacks (ACK / NACK) received from the relay WTRU on the SL channel associated with the RLC channel. As an example, if the number of HARQ NACK feedbacks on the SL channel exceeds a threshold, the RLC channel associated with the SL radio channel may not be selected for mapping.

[0197] The remote WTRU may also select / deselect an RLC channel or a mapping configuration for mapping radio bearers to RLC channels at the adaptation layer based on the SL load condition. For example, the remote WTRU may determine / select a mapping if the load condition (e.g., CBR or CR) of the SL channel associated with the RLC channel is below or above a certain threshold and the load remains below or above the threshold for a certain duration.

[0198] The remote WTRU can also select / deselect an RLC channel or a mapping configuration for mapping radio bearers to RLC channels in the adaptation layer based on the received indication message. For example, the remote WTRU can determine / select a mapping based on an indication message received from a relay WTRU, the indication message including a trigger for dynamically changing the adaptation layer mapping and / or other control information (e.g., QoS-related information). In a WTRU-to-network relay scenario, control information for changing / updating the mapping in the adaptation at the remote WTRU can also be received by the relay WTRU from the network directly over the Uu link or (transparently) via the relay WTRU in E2E RRC signaling or other logically equivalent signaling. Similarly, in a WTRU-to-WTRU relay scenario, control information for changing / updating the mapping in the adaptation layer can be received by the remote WTRU from the destination WTRU directly over the SL or (transparently) via the relay WTRU in E2E PC5-RRC signaling or other logically equivalent signaling.

[0199] The relay WTRU may send an indication to the remote WTRU to change / update the mapping in the adaptation layer or some other logically equivalent function operating in the WTRU.

[0200] In one solution, the relay WTRU may send an indication message to the remote WTRU to trigger a change / update of the radio bearer-to-RLC channel mapping in the adaptation layer of the remote WTRU. The relay WTRU may also send an indication message to the remote WTRU to dynamically activate / deactivate the mapping configuration. The content of the indication message sent by the relay WTRU may include one or more types of control information related to the mapping applied in the adaptation layer of the remote WTRU.

[0201] The content of the indication message sent by the relay WTRU may include a mapping configuration ID. For example, the relay WTRU may send a command / instruction to select a mapping configuration by indicating the mapping configuration ID. The relay WTRU may send an indication including the mapping configuration ID to perform a mapping update in any of the following combinations: N:1 to 1:1 and vice versa, N:1 to 1:N and vice versa, 1:N to 1:1 and vice versa. The relay WTRU may also include a duration during which the update in mapping may be applied by the remote WTRU, after which the mapping configuration may be transitioned to either the initial configuration, the previous configuration, or the default configuration.

[0202] The content of the indication message sent by the relay WTRU may also include mapping information. For example, the relay WTRU may send one or more radio bearer IDs and RLC channel IDs to indicate the radio bearer-to-RLC channel mapping. The relay WTRU may also indicate a priority value of the radio bearer when mapping to an RLC channel at the remote WTRU.

[0203] The content of the indication message sent by the relay WTRU may include a path / route ID. For example, the relay WTRU may send a path ID (source / remote WTRU ID, final destination ID) or other E2E routing ID corresponding to the E2E L2, which may be used to assist the remote WTRU by changing the mapping in the adaptation layer, resulting in rerouting of traffic from the radio bearer to another RLC channel to the same or a different relay WTRU. In some cases, the path ID may also be associated with path status information indicating the availability or unavailability of the path for transmission, possibly along with the duration of the path availability / unavailability.

[0204] The content of the indication message sent by the relay WTRU may also include QoS information. For example, the relay WTRU may send information related to the QoS associated with the E2E radio bearer, the ingress PC5 RLC channel (i.e., corresponding to the egress RLC channel at the remote UE), and / or the egress RLC channel (i.e., corresponding to the E2E radio bearer, where the egress RLC channel is either Uu or PC5). The QoS information may include, for example, latency-related information (e.g., expected transmission latency on the Uu / PC5 link at the next hop at the relay WTRU, expected latency budget available for transmission at the remote WTRU) to assist scheduling and transmission at the remote WTRU. In addition, the relay WTRU may indicate a priority value assigned to the radio bearer, where the priority may refer to a per-radio bearer priority when an N:1 mapping of multiple radio bearers to RLC channels is performed at the remote WTRU.

[0205] An indication message including at least one of the control information may be sent by the relay WTRU. The indication message including at least one of the control information messages may be sent by the relay WTRU in an adaptation layer control PDU. For example, the relay WTRU may send the control information to the remote WTRU in an adaptation layer control message.

[0206] The indication message including at least one of the control information may also be sent by the relay WTRU in a polling request. For example, the relay WTRU may send a polling request message requesting the remote WTRU to respond with information regarding SL channel measurements and / or load information (e.g., CBR), and the polling request may also include control information corresponding to adaptation layer mapping.

[0207] The indication message including at least one of the control information may also be sent by the relay WTRU in other signaling, such as a PC5-RRC, SL MAC CE, or SCI message.

[0208] The relay WTRU may send an indication message to the remote WTRU based on one or more of the triggering conditions detected / determined at the relay WTRU.

[0209] In some examples, the relay WTRU may send an indication message to the remote WTRU based on a trigger from the network / destination WTRU. For example, the indication may be sent upon receiving a trigger message from the network (e.g., in RRC, MAC CE, or DCI in the case of WTRU-to-network relay) or from the destination WTRU (e.g., in PC5-RRC, SL MAC CE, or SCI in the case of WTRU-to-WTRU relay).

[0210] In some examples, the relay WTRU may send an indication message to the remote WTRU based on the load at the relay WTRU. For example, an indication to update the mapping at the remote WTRU may be sent when a buffer level in an egress RLC channel associated with an ingress PC5 RLC channel from the remote WTRU exceeds a certain threshold and remains above the threshold for a certain duration. Similarly, the relay WTRU may also send an indication to update the mapping when a buffer level in an ingress PCH RLC channel associated with an egress PC5 RLC channel at the remote WTRU exceeds a certain threshold and remains above the threshold for a certain duration.

[0211] In some examples, the relay WTRU may also send an indication message to the remote WTRU based on a change in the adaptation layer configuration at the relay WTRU. For example, an indication may be sent when the mapping configuration at the adaptation layer at the relay WTRU between the ingress and egress RLC channels and / or the configuration of the egress RLC channel (e.g., priority, PDB, PBR) has changed, which may affect the adaptation layer mapping at the remote WTRU.

[0212] In some examples, the relay WTRU may also send an indication message to the remote WTRU based on the channel conditions on the next-hop link. For example, an indication may be sent if the channel conditions (e.g., RSRP, CQI) on the Uu link (WTRU-to-network relay case) or PC5 link (WTRU-to-WTRU relay) drop below a threshold and remain below the threshold for a certain duration. Additionally, in the WTRU-to-WTRU relay case, an indication may be sent if the load (i.e., CBR, CR) on the next-hop PC5 channel exceeds a threshold and remains above the threshold for a certain duration.

[0213] In some examples, the relay WTRU may also send an indication message to the remote WTRU based on the QoS on the next hop link. For example, an indication is sent when a QoS-related measurement (e.g., latency on an egress RLC channel on the next hop link) exceeds a certain threshold (e.g., a latency budget). Similarly, the relay WTRU may send an indication to the remote WTRU if load conditions on the next hop link change such that the scheduling latency increases above a threshold or decreases below a threshold.

[0214] In some examples, the relay WTRU may send an indication message to the remote WTRU based on a change in the DRX configuration. For example, an indication may be sent when the DRX configuration at the relay WTRU is modified, which may affect reception on an ingress PC5 RLC channel associated with the egress PC5 RLC channel of the remote WTRU.

[0215] 4A-4C illustrate a solution according to one embodiment of the present invention. In some situations, it may be beneficial to have some WTRU-to-WTRU relay capability within the WTRU to meet QoS requirements (e.g., latency) on an end-to-end (E2E) basis when transmitting through one or more relay WTRUs. However, in many cases, the sender or source WTRU may be unaware of dynamic link conditions or congestion at subsequent hops. Furthermore, in many cases, the relay WTRU may be unaware of QoS parameters, including E2E QoS requirements and dynamic remaining QoS (e.g., due to being unaware of the latency incurred on the previous hop link). Thus, according to one embodiment, a WTRU (e.g., a relay WTRU) may determine resources for relaying a received PDU to one or more target WTRUs to meet E2E QoS (e.g., latency budget) by performing resource selection or reselection based on an overtime indication (e.g., received from a source WTRU) and the expected latency on the next hop link obtained from CBR measurements and a pre-configured mapping relationship.

[0216] 4A, in a situation where a transmission from a source device to a target device may have a total end-to-end latency budget 402, which, if done via a relay, would include two component transmissions: from the source device to the relay device and from the relay device to the target device. Thus, the total end-to-end latency budget may be understood to be a combination of the first hop latency budget 404a and the second / next hop latency budget 406a.

[0217] 4B , a process for achieving end-to-end quality of service (QoS) that can be performed by a WTRU can be understood with reference to a source WTRU 412, a relay WTRU 414, and a target WTRU 416. A transmission from the source WTRU 412 to the target WTRU 416 can pass through the relay WTRU 414. A transmission from the source WTRU 412 to the relay WTRU 414 should be understood to be the first hop, and a transmission from the relay WTRU 414 to the target WTRU 416 should be understood to be the next hop. A next hop may be referred to interchangeably herein as a second hop or a subsequent hop. At the first hop, the relay WTRU 414 may receive 420 a protocol data unit (PDU) and an overtime indication from the source WTRU. Notably, the first hop transmission may not reach or exceed the first hop latency budget 404b. The relay WTRU 414 may then determine an expected latency of the next hop link based on the channel load measure for the subsequent hop. The relay WTRU 414 may then dynamically determine a next hop latency budget 406b based on the received exceedance indication and the expected latency at 420. The relay WTRU 414 may then determine resources for transmitting the received PDU at 420 based on the determined next hop latency budget. If it is determined that resources that meet the next hop latency budget are available and will be used for the subsequent transmission, the relay WTRU may then transmit the received PDU on the next hop using the determined resources at 430. However, in some cases, if there are no available resources that meet the determined next hop latency budget, the relay WTRU 414 may drop the received PDU at 420.

[0218] As seen in FIG. 4C , it should be understood that the remaining latency budget 434 for the second hop depends on the actual latency 432 incurred during the first hop. The second hop latency budget 434 may dynamically change depending on the actual latency of the first hop to compensate for any additional delay incurred during the first hop. The dynamic second hop latency budget 434 may be understood as the aforementioned T2 value (used in the resource selection window) indicating the maximum available time available to complete a transmission. For example, in some cases, the next hop latency budget 434 is equal to the expected latency minus the overtime parameter 438. In other words, the remaining latency budget 434 for the second hop may be offset or reduced by an amount 439, which may be understood by a change in the latency budget margin due to congestion on the second hop. To stay within the total E2E latency budget, this amount 439 should be sufficient to compensate for the excess time 436 used to complete the first hop. The amount of excess time 436 may be understood to mean the additional time beyond the latency budget 404a that the transmission would have had in the static configuration shown in FIG. 4A. Thus, the remaining latency budget 434 for the second hop may be dynamically modified by amount 439 depending on the indication of excess time 438 obtained from the first hop.

[0219] In some embodiments, such as those shown in FIGS. 4A-4C, the relay WTRU 414 may determine the expected latency of the next hop link based on a channel busyness ratio (CBR) measurement and a pre-configured mapping between the CBR and the expected latency. The dynamic determination of the next hop latency budget 434 may depend on the end-to-end latency budget 402 (i.e., the total latency budget) that is unknown to the relay WTRU, and an excess time indication may indicate excess latency 438 due to congestion on the previous hop. In some embodiments, the next hop latency budget may depend on the packet delay budget. The relay WTRU may determine the packet delay budget based on packet delay bits in the headers of packets that the relay WTRU receives from the source WTRU. In some embodiments, the relay WTRU may monitor multiple subchannels available for transmission from the relay WTRU 414 to the target WTRU to obtain a measure of the channel load.

[0220] It should be appreciated that the exceedance time indication sent from the source WTRU 412 to the relay WTRU 414 may indicate that the transmission exceeded the latency budget 404b on the first hop, and the amount 438 by which the latency budget was exceeded may need to be compensated for on the subsequent hop. Furthermore, in some embodiments, the relay WTRU 414 may be configured with a mapping between the CBR and the expected latency on the subsequent hop that enables it to make the remaining latency budget determination described above. Thus, the relay WTRU 414 may determine whether relaying the PDU to the second hop will be possible within the remaining latency budget 406b based on the CBR. After monitoring or sensing the resources (e.g., subchannels) available to or assigned to it, the relay WTRU 414 may determine the CBR and reserve or select resources from its available resource pool that will enable completion of the transmission within the remaining latency budget 406b. In some embodiments, the relay WTRU 414 may preferably select resources that enable a CBR above a predetermined threshold. The resource selection or reselection may be performed according to any of the procedures described herein, including the selection procedure associated with Mode 2 described above. It should be appreciated that if the dynamic second hop latency budget change 439 can be directly correlated with the overtime 436 used during the first hop, the transmission may be completed on the second hop.

[0221] Techniques for SLRB configuration in WTRU-to-WTRU relay to ensure E2E QoS are disclosed herein. The WTRU is configured with rules for mapping upper layer packet flows to relayed versus non-relayed SLRBs. The WTRU is configured to relay and indicate allowable path types on its transmissions. The WTRU can determine / send the AS layer configuration for the next hop WTRU. The WTRU can update parameters associated with the lower layer configuration for the relay WTRU. The WTRU can select a lower layer configuration for the relay WTRU from multiple pre-configurations. Example triggers / indications received by the WTRU to update the lower layer configuration are disclosed. Example indications sent by the WTRU to update the lower layer configuration are disclosed.

[0222] The WTRU may send an indication to the network to request an update of the lower layer configuration in the relay WTRU. The relay WTRU may determine the lower layer configuration based on the received indication to trigger a configuration update.

[0223] Techniques for determining a relay for a WTRU-to-WTRU relay having E2E communication range are disclosed herein. The relay WTRU can determine the decision to relay to the destination WTRU based on the end-to-end communication range. The relay WTRU can send a packet drop indication to the source WTRU. The relay WTRU can derive the range for transmission from the received range requirements.

[0224] Techniques for determining resources for a WTRU-to-WTRU relay with E2E QoS are disclosed herein. The WTRU makes resource selection based on the next-hop WTRU's configuration and the expected remaining packet delay budget. The WTRU can inform the NW of the processing delay / link conditions for the relay WTRU. The WTRU (relay) can use the remaining time budget to determine the resource selection window. The WTRU can make resource selection for periodic resources based on the periodic resource at the previous-hop WTRU. The WTRU (relay) can trigger an indication to the NW upon receiving a periodic process from the source WTRU. The WTRU (relay) can ensure that data received from the periodic process is relayed on the associated periodic process / resource at the relay.

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

Claims

1. 1. A method for achieving end-to-end quality of service (QoS) performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving a protocol data unit (PDU) and an overtime indication from a source WTRU; determining an expected latency of the next hop link based on a measure of channel loading; dynamically determining a next hop latency budget based on the received exceedance indication and the expected latency; determining resources for transmitting the received PDU based on the determined next hop latency budget; and transmitting the received PDU on the next hop using the determined resources, provided the resources are available.

2. The method of claim 1 , further comprising dropping the PDU on the condition that there are no available resources to meet the determined next hop latency budget.

3. The method of claim 1 , wherein the next hop latency budget is equal to the expected latency minus an overtime parameter.

4. The method of claim 1 , wherein determining the expected latency of the next hop link is based on a channel busy ratio (CBR) measurement and a preconfigured mapping between CBR and the expected latency.

5. The method of claim 1 , wherein the dynamic determination of the next hop latency budget is based on an end-to-end latency budget.

6. The method of claim 1 , wherein the excessive time indication indicates excessive latency due to congestion at a previous hop.

7. The method of claim 1 , wherein the next hop latency budget is dependent on a packet delay budget.

8. The method of claim 1 , further comprising receiving a packet delay bit in a header of a packet from the source WTRU.

9. 10. The method of claim 1, further comprising: monitoring a plurality of subchannels available for transmission from the WTRU to a target WTRU to obtain a measure of the channel loading.

10. The method of claim 1 , wherein the end-to-end QoS is associated with a data rate.

11. 1. A relay wireless transmit / receive unit (WTRU) configured to relay information from a source WTRU to a target WTRU to achieve end-to-end Quality of Service (QoS), the relay WTRU comprising: a processor coupled to the transceiver, the processor comprising: receiving a protocol data unit (PDU) and an overtime indication from the source WTRU; determining an expected latency of the next hop link based on a measure of channel loading; dynamically determining a next hop latency budget based on the received exceedance indication and the expected latency; determining resources for transmitting the received PDU based on the determined next hop latency budget; and a relay wireless transmit / receive unit (WTRU) configured to transmit the received PDU on the next hop using the determined resources, provided the resources are available.

12. 12. The relay WTRU of claim 11, wherein the processor coupled to the transceiver is further configured to drop the PDU on a condition that there are no available resources to meet the determined next hop latency budget.

13. The relay WTRU of claim 11 , wherein the next hop latency budget is equal to the expected latency minus an overtime parameter.

14. The relay WTRU of claim 11 , wherein the expected latency of the next hop link is based on a channel busy ratio (CBR) measurement and a preconfigured mapping between CBR and the expected latency.

15. The relay WTRU of claim 11 , wherein the next hop latency budget is based on the end-to-end latency budget.

16. The relay WTRU of claim 11 , wherein the excessive time indication indicates excessive latency due to congestion at a previous hop.

17. The relay WTRU of claim 11 , wherein the next hop latency budget is dependent on a packet delay budget.

18. The relay WTRU of claim 11 , wherein the processor coupled to the transceiver is further configured to receive a packet delay bit in a header of a packet from the source WTRU.

19. 12. The relay WTRU of claim 11, wherein the processor coupled to the transceiver is further configured to monitor a plurality of sub-channels available for transmission from the WTRU to a target WTRU to obtain a measure of the channel loading.

20. The relay WTRU of claim 11 , wherein the end-to-end QoS is associated with a data rate.

Images