CN117322056A

CN117322056A - Method and apparatus for supporting adaptive quality of service (QoS) in side link relay

Info

Publication number: CN117322056A
Application number: CN202280035385.8A
Authority: CN
Inventors: 贾耶·拉奥; 马蒂诺·弗雷达; O·泰耶; 黄祥
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2021-03-30
Filing date: 2022-03-30
Publication date: 2023-12-29

Abstract

Methods and apparatus for supporting adaptive quality of service (QoS) in side link relays are described. A wireless transmit/receive unit (WTRU) includes a receiver and a processor. The transceiver and the processor receive a configuration from the wireless network, the configuration indicating an initial first hop delay budget for communications via the relay WTRU. The transceiver and the processor also receive one or more packets from higher layers and an indication from the relay WTRU. The transceiver and the processor also determine an updated first hop delay budget based at least on the received indication.

Description

Method and apparatus for supporting adaptive quality of service (QoS) in side link relay

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional application No. 63/168,042, filed on 3 months of 2021, and U.S. provisional application No. 63/308,332, filed on 9 months of 2022, the contents of which are incorporated herein by reference.

Background

For release 16 new air interface (NR), a first version of the NR side link has been developed, which focuses on supporting V2X related road safety services. The design is intended to provide support for broadcast, multicast and unicast communications in both out-of-coverage scenarios and in-network coverage scenarios.

Disclosure of Invention

Methods and apparatus for supporting adaptive quality of service (QoS) in side link trunking are described. A wireless transmit/receive unit (WTRU) includes a receiver and a processor. The transceiver and the processor receive a configuration from the wireless network, the configuration indicating an initial first hop delay budget for communications via the relay WTRU. The transceiver and the processor also receive one or more packets from higher layers and an indication from the relay WTRU. The transceiver and the processor also determine an updated first hop delay budget based at least on the received indication.

Drawings

A more detailed understanding of the description may be derived from the following description, taken in conjunction with the accompanying drawings, wherein like reference numerals refer to like elements, and in which:

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

fig. 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in fig. 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

Fig. 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used in the communication system shown in fig. 1A according to one embodiment;

fig. 2 is a diagram of a user plane radio protocol stack for a layer 2 evolved WTRU-to-network relay (PC 5);

fig. 3 is a system diagram of an example of a remote WTRU, a relay WTRU, and a base station (e.g., a gNB) operating in an exemplary QoS compensation mode; and is also provided with

Fig. 4 and 5 are flowcharts of exemplary methods of supporting adaptive QoS in a side link relay that may be implemented at a remote WTRU and a relay WTRU, respectively, in a system such as that shown in fig. 3.

Detailed Description

Fig. 1A is a schematic diagram illustrating 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, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero-tail unique word discrete fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filter OFDM, filter Bank Multicarrier (FBMC), and the like.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a Radio Access Network (RAN) 104, a Core Network (CN) 106, a Public Switched Telephone Network (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. For 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), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptop computers, netbooks, personal computers, wireless sensors, hot spot or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head Mounted Displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronic devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or 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 the other networks 112. As an example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs (enbs), home node bs, home evolved node bs, next generation node bs, such as a gnnode B (gNB), new air interface (NR) node bs, site controllers, access Points (APs), wireless routers, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

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, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as noted above, communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. For example, the base station 114a and WTRUs 102a, 102b, 102c in the RAN 104 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116.WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (hspa+). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or high speed Uplink (UL) packet access (HSUPA).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may use NR to establish the air interface 116.

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. 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).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (WiFi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by drones), road, etc. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish a pico cell or femto cell. As shown in fig. 1A, the base station 114b may have a direct connection with the internet 110. Thus, the base station 114b may not need to access the internet 110 via the CN 106.

The RAN 104 may communicate with a 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, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that RAN 104 and/or CN 106 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104 that may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, wiMAX, E-UTRA, or WiFi radio technology.

The CN 106 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in 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, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

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

Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other peripheral devices 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs), any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

The transmit/receive element 122 may be configured to transmit signals to and receive signals from a base station (e.g., base station 114 a) 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 emit and/or receive, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive RF and optical signals. It should be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

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

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

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as 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. Further, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

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

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

The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connections. For example, the number of the cells to be processed, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photographs and/or video), universal Serial Bus (USB) ports, vibrating devices, television transceivers, hands-free headsets, wireless communications devices, and the like,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geographic position sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, and the like.

WTRU 102 may include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with a particular subframe for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and/or simultaneous. The full duplex radio station may include an interference management unit for reducing and/or substantially eliminating self-interference via hardware (e.g., choke) or via signal processing by a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which some or all signals are transmitted and received (e.g., associated with a particular subframe for UL (e.g., for transmitting) or DL (e.g., for receiving).

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

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In an embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160 a may use multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, and the like. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (PGW) 166. Although the foregoing elements are depicted as part of the CN 106, it should be appreciated that any of these elements may be owned and/or operated by entities other than the CN operator.

The MME 162 may be connected to each of the evolved node bs 162a, 162B, 162c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.

The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

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

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

A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using the 802.11ac infrastructure mode of operation or similar modes of operation, the AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20MHz wide bandwidth) or a dynamically set width. The primary channel may be an 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/collision avoidance (CSMA/CA) may be implemented, for example, in an 802.11 system. For CSMA/CA, STAs (e.g., each STA), including the AP, may listen to the primary channel. If the primary channel is listened to/detected by a particular STA and/or determined to be busy, the particular STA may backoff. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, via a combination of a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and 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 a Medium Access Control (MAC).

The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).

WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA is transmitting to the AP (only supporting 1MHz mode of operation), all available frequency bands may be considered busy even if most available frequency bands remain idle.

The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In 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.

Fig. 1D is a system diagram illustrating a RAN 104 and a CN 106 according to one embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. RAN 104 may also communicate with CN 106.

RAN 104 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 104 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, gnbs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from gnbs 180a, 180b, 180 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. 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 the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from one transmission to another, from one cell to another, and/or from one portion of the wireless transmission spectrum to another. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). 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 enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slices, interworking between DC, NR, and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

The CN 106 shown in fig. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of the CN 106, it should be appreciated that any of these elements may be owned and/or operated by entities other than the CN operator.

The AMFs 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 control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and so on. The AMFs 182a, 182b may provide control plane functionality for switching between the RAN 104 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi.

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

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 a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

The CN 106 may facilitate communications with other networks. For example, the CN 106 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may connect to the 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 local DNs 185a, 185b.

In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): the WTRUs 102a-102d, base stations 114a-114B, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMFs 182a-182B, UPFs 184a-184B, SMFs 183a-183B, DNs 185a-185B, and/or any other devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.

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

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

The side link based relay functionality may be improved in terms of side link/network coverage extension and power efficiency improvement in view of a wider range of applications and services. For WTRU-to-network coverage extension, the WTRU may need Uu coverage reachability to reach a corresponding WTRU outside a server or neighborhood in a Packet Data Network (PDN). For both NG-RAN-based and NR-based Side Link (SL) communications, release 13 WTRU-to-network relay may be limited to EUTRA-based techniques and thus may not be suitable for NR-based systems. For WTRU-to-WTRU coverage extension, proximity reachability may currently be limited to single hop side links via EUTRA-based or NR-based side link technologies. However, this may not be sufficient without Uu coverage considering limited single hop side link coverage. In summary, it may be necessary to further extend the side link connection in the NR framework in order to support the enhanced QoS requirements.

Release 17 will investigate the use of PC5 (side link) based on both WTRU-to-network relay and WTRU-to-WTRU relay. In particular, assuming no new physical layer channels/signals, release 17 may study single hop NR sidelink relay by studying the mechanism (with minimal canonical impact) that supports the Standalone (SA) requirements of sidelink-based WTRU-to-network and WTRU-to-WTRU relay, and studying the mechanism that supports the upper layer operation of the discovery model/procedure of sidelink relay. For layer 3 and layer 2 relays, the study of the mechanism (with minimal specification impact) to support the SA requirements of side-link based WTRUs to network and WTRU to WTRU relays may focus on relay (re) selection criteria and procedures, relay/remote WTRU authorization, quality of service (QoS) for relay functions, service continuity, security of the relay connection after SA3 has provided its conclusion, and impact on user plane protocol stacks and control plane procedures (e.g., connection management of the relay connection).

Relay via ProSe WTRU-to-network relay is introduced in release 13 to extend network coverage to out-of-coverage WTRUs by using PC5 (D2D) between the out-of-coverage WTRU and the WTRU-to-network relay. ProSe WTRU-to-network relay may provide a generic L3 forwarding function that may relay any type of IP traffic between a remote WTRU and the network. One-to-one and one-to-many link communications may be used between one or more remote WTRUs and ProSe WTRU-to-network relay. For both remote and relay WTRUs, only a single carrier (e.g., a public safety ProSe carrier) operation may be supported (e.g., uu and PC5 should be the same carrier for relay/remote WTRUs). The remote WTRU may be authorized by the upper layer and may be within the coverage of the public safety ProSe carrier or outside the coverage of any supported carrier, including the public safety ProSe carrier for WTRU-to-network relay discovery, selection and/or reselection and communication. ProSe WTRU-to-network relay may always be within the coverage of EUTRAN. ProSe WTRU-to-network relay and remote WTRUs may perform side link communication and side link discovery as described in sections 23.10 and 23.11 of 3gpp TS 36.300 (e.g., V15.4.0), respectively.

Relay selection/reselection for ProSe WTRU-to-NW relay may be performed based on a combination of AS layer quality measurements (e.g., RSRP) and upper layer criteria. The eNB may control whether the WTRU may act as a ProSe WTRU-to-network relay. ProSe WTRU-to-network relay operation may be supported in a cell if the eNB broadcasts any information associated with ProSe WTRU-to-network relay operation. The eNB may use broadcast signaling for the rrc_idle state and dedicated signaling for the rrc_connected state to provide transmit resources for ProSe WTRU-to-network relay discovery and broadcast signaling to provide receive resources for ProSe WTRU-to-network relay discovery. The eNB may broadcast a minimum and/or one or more maximum Uu link quality (RSRP) thresholds that ProSe WTRU-to-network relay needs to adhere to before it may initiate a WTRU-to-network relay discovery procedure. In rrc_idle, the WTRU may use a threshold to autonomously start or stop the WTRU-to-network relay discovery procedure when the eNB broadcasts a pool of transmission resources. While in rrc_connected, the WTRU may use a threshold to determine if it may indicate to the eNB that it is a relay WTRU and that it wishes to initiate ProSe WTRU-to-network relay discovery. If the eNB does not broadcast a pool of transmission resources for the ProSe-WTRU to network relay discovery, the WTRU may initiate a request for the ProSe-WTRU to network relay discovery resources through dedicated signaling in view of these broadcast thresholds.

If ProSe-WTRU-to-network relay is initiated by broadcast signaling, proSe WTRU-to-network relay discovery may be able to be performed while in rrc_idle. If ProSe WTRU-to-network relay is initiated by dedicated signaling, it may be able to perform relay discovery as long as it is in rrc_connected. ProSe WTRU-to-network relay performing side link communication for ProSe WTRU-to-network relay operation may have to be in rrc_connected. After receiving a layer 2 link setup request or a Temporary Mobile Group Identity (TMGI) monitoring request (upper layer message) from a remote WTRU, the ProSe WTRU-to-network relay may indicate to the eNB that it is a ProSe WTRU-to-network relay and is intended to perform ProSe WTRU-to-network relay side link communication. The eNB may provide resources for ProSe WTRU-to-network relay communications.

The remote WTRU may decide when to start monitoring ProSe WTRU-to-network relay discovery. The remote WTRU may transmit the ProSe WTRU-to-network relay discovery request message while in rrc_idle or in rrc_connected, depending on the configuration of resources for ProSe WTRU-to-network relay discovery. The eNB may broadcast a threshold that the remote WTRU may use to determine whether it may transmit ProSe WTRU-to-network relay discovery request messages in order to connect or communicate with ProSe WTRU-to-network relay WTRUs. The rrc_connected remote WTRU may use the broadcasted threshold to determine whether it may indicate to the eNB that it is a remote WTRU and that it wishes to participate in ProSe WTRU to network relay discovery and/or communication. The eNB may use broadcast or dedicated signaling to provide transmission resources and broadcast signaling to provide reception resources for ProSe WTRU-to-network relay operation. The remote WTRU may cease using ProSe WTRU-to-network relay discovery and communication resources when Reference Signal Received Power (RSRP) exceeds a broadcast threshold. The exact time of the traffic switch from Uu to PC5 or from PC5 to Uu may be up to higher layers.

The remote WTRU may perform radio measurements at the PC5 interface and use them with higher layer standards for ProSe WTRU-to-network relay selection and reselection. If the PC5 link quality exceeds a configured threshold (pre-configured or provided by the eNB), then ProSe WTRU-to-network relay may be considered appropriate in terms of radio standards. The remote WTRU may select a ProSe WTRU-to-network relay that may meet higher layer standards and have the best PC5 link quality among all suitable ProSe WTRU-to-network relays. When the current ProSe WTRU-to-network relay PC5 signal strength is below the configured signal strength threshold and it receives an upper layer message (such as a layer 2 link release message) from the ProSe WTRU-to-network relay, the remote WTRU may trigger ProSe WTRU-to-network relay reselection.

In release 14, a study of WTRU-to-NW relay for business use cases tailored to wearable devices and IoT devices was performed in the RAN. Although such studies did not produce any specifications, technical Report (TR) provided some preferred solutions for such relays. In contrast to ProSe WTRU-to-NW relay using L3 (IP layer) relay methods, WTRU-to-NW relay for wearable devices is expected to be L2 relay.

Fig. 2 is a diagram of a user plane radio protocol stack for a layer 2 evolved WTRU-to-network relay (PC 5). More specifically, fig. 2 illustrates user plane radio protocol stacks for a remote WTRU 202, an L2 relay WTRU 204, an eNB 206, and a core network 208. In the example shown in fig. 2, it may be seen that RLC, MAC, and PHY layer communications between remote WTRU 202 and L2 relay WTRU 204 may occur over PC5 link 210, and RLC, MAC, and PHY layer communications between L2 relay WTRU 204 and eNB 206 may occur over Uu link 212, for example.

The relay in the previous release of the LTE specification may have been based on a one-to-one communication link established at an upper layer (e.g., proSe layer) between two WTRUs (e.g., a remote WTRU and a WTRU-to-NW relay). Such connections may already be transparent to the AS layer and connection management signaling, and the processes performed at the upper layers may be carried by the AS layer data channels. Thus, the AS layer may not be aware of such one-to-one connections.

In NR V2X (release 16), the AS layer may support a unicast link between two WTRUs. Such unicast links may be initiated by upper layers (as in ProSe one-to-one connections). However, the AS may be informed of the existence of such unicast links, AS well AS any data transmitted between peer WTRUs in a unicast manner. With such knowledge, the AS layer may support HARQ feedback, CQI feedback, and possibly unicast-specific power control schemes.

Unicast links at the AS layer may be supported via a PC5-RRC connection. In 3GPP TS 38.300 (e.g., V16.1.1), a PC5-RRC connection can be defined as follows. The PC5-RRC connection may be a logical connection between a source layer 2ID and a destination layer 2ID pair in the AS. One PC5-RRC connection may correspond to one PC5 unicast link. PC5-RRC signaling as specified in sub-clause 5.X.9 may be initiated after its corresponding PC5 unicast link establishment. When the PC5 unicast link is released as indicated by the upper layer, the PC5-RRC connection and corresponding side link Signaling Radio Bearers (SRBs) and side link Data Radio Bearers (DRBs) may be released.

For each PC5-RRC connection that is unicast, one side link SRB may be used to transmit the PC5-S message before the PC5-S security has been established. One side chain SRB may be used to transmit PC5-S messages to establish PC5-S security. One side link SRB may be used to transmit PC5-S messages after the PC5-S security has been established that may be protected. One side chain SRB may be used to transport PC5-RRC signaling, which may be protected and sent only after PC5-S security has been established.

The PC5-RRC signaling may include a side link configuration message (e.g., rrcrecon configuration sip link) where one WTRU may configure the RX related parameters of each SLRB in a peer WTRU. Such reconfiguration messages may configure parameters of each protocol (e.g., service Data Adaptation Protocol (SDAP), packet Data Convergence Protocol (PDCP), etc.) in the layer 2 (L2) stack. The receiving WTRU may acknowledge or reject such configuration depending on whether it may support the configuration proposed by the peer WTRU.

In release 17L 2 WTRU-to-NW relay and WTRU-to-WTRU relay, mapping from N ingress RLC channels (which may include RLC channels, MAC channels, PHY channels) to one egress RLC channel may be supported at the adaptation layer of the relay WTRU. Mapping from N E2E radio bearers (which may include an SDAP radio bearer and a PDCP radio bearer) to one or more egress RLC channels may also be supported at an adaptation layer at the remote WTRU. For L2 WTRU-to-NW relay, end-to-end (E2E) QoS may be split by the gNB, and RLC channels at the remote WTRU and the relay WTRU may be configured such that the split QoS may be implemented at each hop. For WTRU-to-WTRU relay, E2E QoS may be split based on higher layer configuration, and correspondingly, RLC channels at the remote WTRU and relay WTRUs may be configured such that split QoS may be implemented at each hop.

At the relay WTRU, congestion on the PC5 link may cause PDUs from one or more remote WTRUs to be received with higher than expected delay (e.g., higher than the Packet Delay Budget (PDB) determined when splitting E2E QoS). The number of remote WTRUs supported by the relay WTRU for relaying PDUs in the UL and the traffic pattern of the remote WTRUs may change dynamically, resulting in a dynamically changing congestion level and QoS achievable over the PC5 link. This may also cause the expected QoS on the Uu link from the relay WTRU to vary accordingly. Since the adaptation layer is supported at the relay WTRU, it is possible to compensate for the higher delay on the PC5 link by changing the mapping at the adaptation layer so that delayed PDUs can be sent over Uu links with lower delay via some of the egress RLC channels. However, it may be challenging to perform compensation reactively after receiving a PDU at the relay WTRU due to delays associated with changing the configuration at the adaptation layer and possibly at the egress RLC channel. Additionally, any actions/mechanisms to support QoS compensation for PDUs delayed due to PC5 link congestion may be ineffective because there may be pending PDUs from other remote WTRUs and/or relay WTRUs in the buffer of the egress RLC channel.

At the remote WTRU, the E2E radio bearer may carry one or more QoS flows, where different QoS flows may have different E2E QoS requirements. In E2E QoS splitting, different QoS flows may be split so that the QoS to the relay WTRU may be different over the first hop PC5 link. In this case, when N:1 mapping/multiplexing is supported at the adaptation layer of the remote WTRU, PDUs belonging to different QoS flows and/or E2E radio bearers may be mapped to the same egress buffer and the same configuration (e.g., priority) applied at the egress PC5RLC channel. Thus, since the first hop QoS for each mapped PDU is not differentiated, this may result in some PDUs failing to meet the expected QoS on the PC5 link.

In this regard, it may be desirable to develop a mechanism that can achieve the following objectives: congestion on the PC5 link and load at the relay WTRU are effectively detected and handled to eliminate situations where E2E QoS may not be met at the time of relay; ensuring that PDUs delayed on the PC5 link can be selectively compensated for without affecting other buffered PDUs at the relay WTRU when transmitting on the Uu link to meet E2E QoS; and when mapping/multiplexing PDUs belonging to different QoS flows to a single egress PC5RLC channel, ensuring E2E QoS (e.g., delay) at the remote WTRU while considering different first hop QoS on the PC5 link for the mapped PDUs.

In embodiments described herein, the remote WTRU may use the updated relay delay in some cases to select resources for transmission. For example, the remote WTRU may select a side link resource for transmitting data to the relay WTRU using the determined 1 st hop delay budget, which may take into account additional delays due to congestion on the SL and loading at the relay WTRU based on configuration information received from the network (such as E2E delay and/or 1 st hop delay budget), which may indicate loading delays and CBR measurements received from the relay WTRU.

In some embodiments, the relay WTRU may first trigger a change of configuration at LCH/MAC on Uu link based on the backoff mode configuration and/or backoff mode trigger condition in preparation for receiving a delayed PDU from the remote WTRU. For example, the relay WTRU may be configured to flexibly update a protocol stack including an Adaptation Layer (AL) and layers in one or more ingress/egress RLC channels (e.g., including or consisting of an RLC sublayer, a MAC sublayer, and a PHY sublayer) based on detection of one or more configured trigger conditions. At the adaptation layer of the relay WTRU, PDUs corresponding to one or more QoS flows with the same or different E2E and/or hop-by-hop (H2H) QoS requirements may be mapped to one or more egress RLC channels. When forwarding a PDU in the next hop, one or more egress RLC channels may be configured to implement/enforce different H2H QoS. For example, PDUs received in the egress PC5 RLC channel may be mapped at the adaptation layer to one or more egress buffers associated with the egress RLC channel. When mapped to the egress buffer, the configuration at the egress RLC channel for achieving/enforcing QoS in the next hop is applicable to all PDUs in the egress buffer.

In this regard, a PDU to be received from a remote WTRU may have a different expected QoS to be met in a subsequent hop or hops. In this case, based on a determination of the expected QoS of PDUs received or to be received in different ingress RLC channels, the relay WTRU may apply some backoff mechanism at the adaptation layer, logical Channel (LCH)/MAC, and/or egress RLC channels so that the expected QoS of the PDUs may be met when received at the relay WTRU.

The term expected QoS may be used herein to refer to an expected margin (e.g., qoS to be achieved/implemented when transmitting in a next hop link) for a certain QoS metric (e.g., delay and data rate) before the PDU arrives or when the PDU arrives at the relay WTRU. In one example, the expected QoS may correspond to a duration of time available at the relay WTRU to forward the PDU on the Uu link. For example, the expected QoS may be determined by subtracting the QoS (e.g., delay) achievable on the first hop link from the E2E QoS. In the case of DL, the expected QoS may be a QoS requirement expected to be met through a link between the relay WTRU and the remote WTRU, while in the UL, the expected QoS may be a QoS requirement expected to be met through a link between the relay WTRU and the gNB (in a WTRU-to-NW relay scenario).

In some examples, the expected QoS may be more stringent or relaxed than the per-hop QoS metric used. For example, if a PDU arrives at the relay WTRU late, having experienced more delay than the configured PC5 Packet Delay Budget (PDB), the expected delay to meet the E2E delay requirement of the PDU on the Uu link may be lower than the PDB typically used to send the PDU over the Uu link. Alternatively, if a PDU is expected to arrive well before the PC5 PDB or if the PDU arrives at the relay UE, the expected delay budget to the gNB over the Uu link may be considered higher than the PDB typically used for such PDUs over the Uu link.

In summary, the expected QoS may dynamically change based on the QoS experienced in the first hop (PC 5 link for UL, uu link for DL for WTRU-to-NW relay), where for a fixed E2E QoS (e.g., E2E PDB, GBR), the increase/decrease of the expected QoS on the first hop link and/or relay WTRU translates to a decrease/increase of the expected QoS on the next hop.

In some embodiments, the remote WTRU may be configured to perform a 1:1, n:1, or 1:n mapping from one or more E2E radio bearers to one or more egress (PC 5) RLC channels to enable flexible utilization of radio bearers and resources on different hops while meeting E2E QoS. For example, the RLC channel may consist of or include an RLC sublayer, a MAC sublayer, and a PHY sublayer, each of which may be associated with one or more RLC, MAC, and PHY configurations and entities, respectively.

For example, at a remote WTRU, PDUs received via one or more radio bearers may be multiplexed/demultiplexed at the adaptation layer when mapped to the next hop egress RLC channel. For example, when a 1:1 or N:1 mapping is supported, the adaptation layer may be configured to multiplex PDUs associated with one or more E2E radio bearers into a single egress RLC channel. In another example, when supporting 1:n mapping, the adaptation may be configured to demultiplex PDUs associated with the E2E radio bearer to one or more egress RLC channels (Uu or PC 5).

An E2E radio bearer originating from a remote WTRU may carry PDUs corresponding to one or more QoS flows, where different QoS flows may be mapped to one or more PC5 RLC channels at the remote WTRU. In this case, for example, different QoS flows may differ in QFI and other QoS characteristics/parameters, including bit rate (e.g., guaranteed or best effort), delay, and reliability. Some QoS parameters may be met on an end-to-end (E2E) and hop-by-hop (H2H) basis (e.g., delay, reliability), while other parameters may be met on an E2E or H2H basis. To meet the H2H qos requirements, different sublayers (e.g., RLC, MAC, and PHY) in the RLC channel may be configured with different configuration parameters. For example, such configuration parameters may include support for AM/UM in RLC, LCP rules/restrictions at MAC and associated LCH parameters (e.g., PBR, BSD, priority), and number of HARQ transmissions. For example, for E2E QoS requirements, it may be possible to configure certain parameters (e.g., sequence number size and ROCH) in the PDCP sublayer and certain parameters (e.g., mapping between QFI and radio bearers) in the SDAP sublayer.

For example, in the case of WTRU-to-NW relay, splitting the E2E QoS requirements into H2H requirements/budgets may be performed by the gNB based on higher layer QoS parameters provided by the remote WTRU and/or core network functions (e.g., AMF, SMF). Alternatively, the splitting may be performed based on coordination between the remote WTRU, the relay WTRU, and/or the gNB.

In the case of WTRU-to-WTRU relay, splitting the E2E QoS requirements into H2H requirements may be performed by the relay WTRU and the remote WTRU based on higher layer configurations when the WTRUs are out of coverage. In the case where one or more WTRUs are in coverage, the splitting may be performed with the assistance of the gNB. For example, a QoS flow with E2E delay requirements or E2E PDBs may be split into a first PDB to be satisfied on a first hop (e.g., a PC5 link) and a second PDB to be satisfied on a second hop (e.g., a Uu link). For example, in splitting E2E QoS, configuration to meet/implement H2H QoS at different sub-layers may be performed by the remote/relay WTRU and/or the gNB using RRC and/or PC5 signaling.

The relay WTRU may be configured with one or more conditions and/or configurations associated with handling/processing of data to be received at the relay WTRU (via the ingress RLC channel) and/or existing data at the relay WTRU (e.g., the relay WTRU's own data and data received from other remote WTRUs over the ingress RLC channel). Such one or more conditions may relate to or may reflect an expected QoS for the relevant data upon reaching the relay WTRU (e.g., in view of a QoS margin to be consumed over the ingress PC5 link) or a change in such expected QoS.

The relay WTRU may perform any of the following actions based on such conditions described herein. In some embodiments, the relay WTRU may select from its configured LCH/MAC configurations an LCH/MAC configuration associated with one or more egress RLC channels on the Uu link, which the relay WTRU may use when transmitting data/PDUs in the UL. The selection of LCH/MAC configuration may be based on the conditions described herein. Such implementations may also be referred to herein as determining LCH/MAC configurations at relay WTRUs that support the intended QoS.

In some embodiments, the relay WTRU may trigger the LCH/MAC configuration in advance to compensate for the change in QoS achievable over the PC5 link so that the intended data/PDU from the remote WTRU may meet E2E QoS. In such embodiments, the relay WTRU may trigger a backoff mode operation to selectively backoff the affected PDUs to be relayed. Triggering of the LCH/MAC configuration for compensation may be based on the conditions described herein. Such implementations may also be referred to herein as triggering LCH/MAC configuration to compensate for changes in achievable QoS on SL channels.

In some embodiments, the relay WTRU may report to the network SL channel/load conditions associated with one or more configured SL resource pool/bandwidth parts (BWP) based on the conditional triggers described herein. Such implementations may also be referred to herein as triggering reporting of events to network SL channels and/or load conditions.

The relay WTRU may be configured with one or more conditions related to triggering one of the actions described above. Such conditions may relate to the expected QoS of PDUs to be received in one or more ingress RLC channels on SL and are used to identify how much QoS on the next hop is available and/or whether any of the embodiments described herein are applied (e.g., changing LCH/MAC configuration and/or egress RLC channel configuration and/or triggering reporting events to the network) to meet E2E QoS. Such conditions may specify whether an action can/should be performed. Such conditions may specify when (e.g., at what time) to perform an action (e.g., meet conditions/criteria). Such conditions may be based on one or more of the following: the indication and/or information from the network, the indication or information from the remote WTRU, the buffer status and load at the ingress/egress buffers and associated RLC channels, a change in configuration at the relay WTRU and/or remote WTRU, timing/timestamp information (which may be associated with an expected QoS), measurements on SL/Uu, compensation based on the expected QoS, attributes associated with the remote WTRU or link to which the RLC channel is associated, and/or QoS attributes associated with the RLC channel.

For example, the relay WTRU may receive information from the gNB regarding an expected QoS for transmission over a Uu link (for the case of UL) and/or an expected QoS for transmission over a PC5 link (for the case of DL). The information may be semi-statically received during/while configuration of the E2E radio bearer between the remote WTRU and the gNB. The relay WTRU may be indicated the expected QoS when configuring the adaptation layer mapping configuration, LAC/MAC configuration, and/or the egress RLC channel. For example, the relay WTRU may trigger actions described in embodiments herein (e.g., determine LCH/MAC configuration) based on the indication/information received from the network.

For example, the expected QoS may be indicated on a per remote WTRU, per ingress RLC channel, per egress RLC channel, and/or per ingress to egress mapping. For example, in splitting E2E QoS, the gNB may provide the relay WTRU with an expected QoS (e.g., PDB) for an egress RLC channel configured on the Uu link. While relaying in UL, the gNB may provide an expected QoS (e.g., per-egress RLC channel) over Uu, and the relay WTRU may change the mapping configuration and/or LCH/MAC configuration at the adaptation layer, e.g., based on the received expected QoS.

In another example, the relay WTRU may implicitly receive information about the expected QoS from the gNB based on one or more of the following: the number of times HARQ feedback is received, allocation of retransmission grants on Uu corresponding to one or more LCHs, de-prioritization of PUSCH/grants for one or more LCHs due to intra/inter WTRU prioritization, etc. For example, when an indication is received from the network (e.g., in an RRC, MAC CE, or other control PDU or DCI, such as in a WTRU-to-NW relay), the relay WTRU may be triggered to perform an action. For example, the indication received by the relay WTRU may relate to a change/update of configuration at the relay WTRU and/or an expected QoS associated with one or more QoS flows relayed via the relay WTRU.

Regarding the indication/information from the remote WTRU, in one example, the relay WTRU may receive semi-static information about the expected QoS from the (source) remote WTRU from which the E2E radio bearer may be configured. For example, when E2E QoS splitting is performed in the first hop and subsequent hops, the intended QoS may be indicated to the relay WTRU. For example, when relaying in the UL, the remote WTRU may estimate/measure QoS consumption on the PC5 link and based on knowledge of E2E QoS, the remote WTRU may indicate information about the expected QoS (e.g., per RLC channel) to the relay WTRU for changing the configuration at the egress RLC channel. For example, the relay WTRU may trigger actions described in embodiments herein (e.g., determine LCH/MAC configuration) based on the indication/information received from the remote WTRU.

For example, the relay WTRU may receive an indication from the remote WTRU indicating the arrival of one or more PDUs (e.g., in a batch/burst manner) before receiving the PDUs. For example, the information about PDU arrival may include an expected timing of transmission (e.g., slots/frames) at the remote WTRU, an expected timing of reception at the relay WTRU, and/or a number of PDUs in transmission from the remote WTRU. In one example, the relay WTRU may receive information about PDU arrival from the remote WTRU due to changes in SL channel/load conditions and/or changes in traffic arrival patterns (e.g., from higher layers) at the remote WTRU. For example, the relay WTRU may receive this information when the SL Channel Busy Rate (CBR) increases/decreases by a certain threshold. For another example, the relay WTRU may be triggered to perform an action based on an indication of priority from the remote WTRU for the relay PDU. For example, upon receiving an indication containing a priority value above a threshold, the relay WTRU may trigger an action (e.g., change LCH/MAC configuration) to relay PDUs that may be delayed with compensation (e.g., low latency). For another example, when an indication is received from a remote WTRU (e.g., in PC5-RRC, SL MAC CE, and/or control PDU to SCI), a relay WTRU may be triggered to perform an action.

The ingress/egress buffers and buffer status and load at the associated RLC channel may include at least conditions associated with any measurement or combination of measurements (e.g., as compared to a threshold value) such as: the amount of data in the one or more RLC/LCH buffers (e.g., over a period of time), the arrival/departure rate of packets in the RLC/LCH buffers, the average size of PDUs in the RLC/LCH buffers, the maximum size, the minimum size (e.g., the number of PDUs in the RLC buffers), a measure of the amount of time spent by the one or more PDUs in the RLC/LCH buffers, and/or the RLC/LCH buffer number satisfies the conditions associated with the amount of data, the arrival rate, and/or the PDU size.

For example, if at least one PDU in the RLC buffer for the ingress/egress RLC channel is in the buffer for a period of time greater than a threshold, the relay WTRU may perform any of the actions described herein (e.g., change the mapping configuration and/or LCH/MAC configuration at the adaptation layer). For another example, if the buffer status of the ingress/egress RLC channel exceeds a threshold, the relay WTRU may perform any of the actions described herein (e.g., trigger a reporting event). For another example, other buffer status metrics that may be monitored for determining remaining QoS may include, for example, the number of buffered PDUs above/below a configured threshold and the PDU arrival/departure rate in the buffer relative to the configured arrival/departure rate. For another example, in the case of an egress buffer, the relay WTRU may also monitor the arrival/departure rate of its own traffic generated from higher layers, which may be included in the egress buffer for transmission over the next hop (Uu link or PC5 link). For example, the relay WTRU may then determine or infer an expected QoS for other relay traffic (e.g., from other ingress buffers) based on its own monitoring of QoS for transmissions/traffic that may use the shared/common egress RLC channel. In another example, the relay WTRU may determine the number of PDUs received in the ingress RLC channel within the duration/window to determine whether the rate of the received PDUs is within the expected range for QoS in the first hop. For example, the relay WTRU may then determine the expected QoS based on the QoS implemented in the first hop PC5 link using the configured mapping function.

Regarding a change in one or more configurations at the relay WTRU and/or remote WTRU, for example, when changing the mapping configuration and/or LCH/MAC configuration at the adaptation layer, the relay WTRU may be triggered to perform actions including changing at least one parameter (e.g., priority, PDB, and/or PBR) in the LCH configuration at the ingress/egress RLC channel. For example, when the DRX configuration applied at the relay WTRU is modified/updated, the relay WTRU may be triggered to perform actions and/or send indications to the network and/or the remote WTRU that may affect the reception mode and/or QoS achievable in the first hop link at the ingress PC5 RLC channel. In another example, the relay WTRU may be triggered to perform actions and/or send indications to the network when other configurations related to the PC5 RLC channel between the remote WTRU and the relay WTRU change (e.g., enabling/disabling HARQ and/or resource pool changes used on the PC5 link).

Regarding timing/timestamp information, for example, the relay WTRU may track timing related information (e.g., a timestamp, a flag, or a timing control PDU) in one or more PDUs received in an earlier time window to determine the delay incurred over the first hop (e.g., a PC5 link for UL and/or Uu link for DL). For example, the timing information may then be used to determine the expected QoS for the upcoming PDU using a configuration mapping function between the previously implemented first hop QoS and the expected QoS and/or between the E2E QoS and the previously implemented first hop QoS.

In one example, the timing information may be indicated as deadline/delay bound that may be met on a per-hop and/or end-to-end basis. In another example, timing information may also be indicated based on a count (e.g., a hop count). For example, the relay WTRU may trigger actions described in embodiments herein (e.g., determine LCH/MAC configuration) based on timing/timestamp information regarding the intended QoS. In another example, the remote WTRU may send information from the relay WTRU regarding the expected QoS in the next hop, which may be determined by the remote WTRU subtracting the achievable/expected first hop QoS on the PC5 link from the E2E QoS. For example, it is contemplated that the first hop QoS may be determined by the remote WTRU based on measurements made on the PC5 link (e.g., SL channel: SL RSRP or SL load: CBR) and/or feedback received from the relay WTRU (e.g., ARQ/HARQ feedback). In one example, the remote WTRU may send information about the intended QoS in a control PDU, MAC CE, or along with other PDUs (e.g., in a PDU header).

For example, the relay WTRU may perform measurements over one or more SL resource pools/BWP associated with the ingress PC5 RLC channel to trigger actions (e.g., determine an expected QoS). For example, the channel related measurements may include SL RSRP, SL-RSSI, CQI, and CSI, and the load related measurements may include CBR and CR. Similarly, the relay WTRU may perform measurements (e.g., corresponding to RSRP, RSSI, CQI and CSI) over the Uu link to determine the expected QoS. Channel/load measurements made over a certain configured duration may indicate whether a PDU received over the SL is within the expected QoS range in the first hop or has exceeded the QoS budget. For example, the relay WTRU may also determine the expected QoS for the PDU to receive based on a configuration mapping function between SL channel/load measurements and the expected QoS and/or between E2E QoS and channel/load measurements. For example, the relay WTRU may trigger actions described in embodiments herein (e.g., determine LCH/MAC configuration) based on measurements on SL/Uu.

In another example, the relay WTRU may determine the SL condition based on an ARQ/HARQ (ACK/NACK) feedback message and/or an ARQ/HARQ retransmission over one or more SL channels and a resource pool associated with the ingress RLC channel. The expected QoS may then be determined based on a configured mapping function between SL feedback/ReTx counts and expected QoS, for example. As an example, a ReTx count above a threshold may translate into poor SL channel conditions and thus reduce the expected QoS. In another example, the relay WTRU may determine the SL channel/load condition based on SL channel/CSI reports and/or SL load/CBR reports sent by the remote WTRU. For example, when a channel measurement (e.g., RSRP, RSSI, RSRQ, CQI, CSI) made on a remote link (e.g., uu link or PC5 link) increases/decreases relative to a configured threshold and/or remains above/below the threshold for a certain duration, the relay WTRU may be triggered to perform an action and/or send an indication to the network and/or the remote WTRU. For example, the relay WTRU may be triggered to perform one or more actions when one or more QoS related measurements (e.g., delay on the ingress/egress RLC channel over a previous/next hop) exceeds a certain threshold (e.g., PDB).

In another example, the relay WTRU may trigger actions described in embodiments herein based on a determination of duration or duration change between consecutive PDUs (e.g., new PDUs and/or retransmissions due to HARQ/ARQ) received from a remote WTRU over one or more SL channels. For example, the relay WTRU may infer an increase/decrease in duration between consecutive PDUs received from the remote WTRU to determine whether the congestion level on the SL is high/low. In this case, for example, to determine the duration, the relay may set a timer when a first PDU arrives and reset the timer when a second PDU arrives from the same remote WTRU. For example, the relay WTRU may then determine a congestion level on the SL based on the determined configuration mapping between duration and CBR.

With respect to the compensation based on the expected QoS, for example, the relay WTRU may be triggered to perform one or more actions based on a determination of the expected QoS for one or more PDUs to be received on the SL from the remote WTRU, where the expected QoS may indicate that the PDUs may be delayed (e.g., > = PC5 PDB) or arrive in advance (e.g., < PC5 PDB). In this case, for example, the relay WTRU may trigger an action such that the delayed PDU may be forwarded over the Uu link with the determined offset. In one example, this action may be triggered when an expected QoS of a PDU is detected to change by a certain threshold (e.g., higher/lower). In one example, for example, the relay WTRU may use the RLC channel and/or LCH/MAC configuration to determine the delayed PDUs to send, which may enable the compensation amount to be satisfied, where the compensation amount may be determined by subtracting the expected delay from the E2E delay.

Regarding attributes associated with a remote WTRU or a link associated with an RLC channel, for example, a WTRU may be configured with remote WTRU-or unicast link-specific attributes, such as WTRU/link priority and/or configuration parameters that enable/disable specific actions for the WTRU/link. For example, a WTRU/link configured with a high priority may allow the relay WTRU to change the mapping configuration and/or LCH/MAC configuration (relative to an initial or default configuration) of the RLC channel. For example, a relay WTRU may change the LCH/MAC configuration of a high priority WTRU/link as long as the change affects only other lower priority WTRUs/links.

Regarding QoS attributes associated with an RLC channel, for example, a WTRU may determine whether an action (e.g., a change in LCH/MAC configuration) may be performed on the RLC channel based on QoS related parameters (e.g., priority values) configured with the RLC channel. For example, the condition of when an action is performed (e.g., determining Uu RLC channel configuration) may depend on QoS-related parameters (e.g., priority values) configured with the RLC channel.

In an embodiment, the relay WTRU may select or reselect an LCH/MAC configuration on the Uu link to apply to PDUs received or to be received over the SL in one or more ingress RLC channels. The LCH/MAC configuration may include one or more parameters associated with at least one Logical Channel (LCH) and/or MAC sublayer, including LogicalChannelConfig, priority, prioritisedBitRate (PBR), bucketSizeDuration (BSD), logicalChannelGroup, and/or Logical Channel Priority (LCP). In one example, the relay WTRU may select an LCH/MAC configuration to meet the determined desired QoS for the PDU. In another example, the relay WTRU may select an LCH/MAC configuration based on the determined expected QoS for the PDUs to compensate for the change in QoS (e.g., higher delay) experienced by one or more PDUs on the SL channel so that E2E QoS may be met.

The selection of LCH/MAC configuration may be performed by the relay WTRU using one or more of the following: regarding the reception of a configuration of LCH/MAC (e.g., from a network), autonomous (re) selection from a set of (pre) configured LCH/MAC configurations (which may be associated with one or more egress RLC channels based on selection rules), dynamic activation/deactivation of one or more configured or pre-configured LCH/MAC configurations based on conditions (e.g., indications received from the network and/or remote WTRUs), and/or derivation of parameters to be applied at one or more LCHs and/or MACs.

Regarding the reception of the configuration on the LCH/MAC (e.g., from the network), the WTRU may request the MAC/LCH configuration or reconfiguration, for example, by sending an indication to the network. The WTRU may be configured to send an indication when any of the conditions described above are met. In one example, a relay WTRU may receive a configuration associated with one or more LCH/MAC configurations and/or an egress RLC channel from a network. For example, one or more of the configurations received by the relay WTRU may be associated with a compensation mode configuration. In this case, the relay WTRU may use a backoff mode configuration for one or more LCH/MAC and/or RLC channel configurations, for example, when triggered based on any of the above conditions. For example, the relay WTRU may receive an LCH/MAC configuration (e.g., from the network) based on an indication provided by the relay WTRU that includes information related to an expected QoS (e.g., priority, delay, CBR measurements on SL) and/or a load attribute associated with the ingress RLC channel. For example, the LCH/MAC configuration may be received by the relay WTRU in the same or different signaling/messages (e.g., RRC, MAC CE, DCI) used to receive the radio bearer configuration and/or the adaptation layer mapping configuration.

Regarding autonomous (re) selection from the (pre) configured LCH/MAC configuration set, for example, the WTRU may be configured with a selection rule regarding which of the (pre) configured LCH/MAC configurations to apply based on one or more of the conditions described above. The WTRU may also indicate to the network whether it selects either LCH/MAC configuration or pre-configuration.

In one example, the WTRU may be configured with a default/first LCH/MAC configuration and at least one second LCH/MAC configuration. The second configuration may be applied when triggered by one or more of the conditions described above. For example, the second LCH/MAC configuration may be applied by the relay WTRU when performing QoS compensation and/or operating in the compensation mode. In another example, the relay WTRU may be configured or pre-configured (e.g., by the network) with one or more LCH/MACs and/or an egress RLC channel configuration. Different configurations or pre-configurations may be configured with different parameters associated with sub-layers (e.g., RLC: AM/UM, MAC: LCP rules/restrictions, PBR, BSD, priority, PHY) within the RLC channel for achieving/enforcing a certain QoS (e.g., latency, throughput, reliability) over the Uu link. Different configurations or pre-configurations may also be associated with different identifiers/IDs. The relay WTRU may also be configured with selection rules and conditions to assist in selecting LCH/MAC configurations or pre-configurations. In this case, the relay WTRU may autonomously select a configuration or pre-configuration based on selection rules/conditions, where the conditions may include any of the conditions described above.

For example, the selection rule may indicate that LCH/MAC configuration or pre-configuration is selected when one or more conditions are met. For example, the conditions for selecting the LCH/MAC configuration may be related to the trigger conditions described above. In one example, the conditions associated with the selection rule may relate to an expected QoS of the PDU to be received on the SL and/or a load attribute at the relay WTRU (e.g., the number of (active) egress RLC channels with PDUs in the buffer). As an example, if the expected QoS of PDUs to be received in one or more ingress RLC channels is within a certain range (e.g., within a minimum and maximum value for latency, bit rate, and/or priority), the relay WTRU may select LCH/MAC configuration or pre-configuration on the Uu link. Similarly, the relay WTRU may select LCH/MAC configuration or pre-configuration, for example, if the load attribute is within a certain range (e.g., the number of PDUs in the buffer in the egress RLC channel is below a threshold and/or less than or equal to a maximum value). In one example, selection of LCH/MAC configuration or pre-configuration based on an expected QoS (e.g., delay) may enable transmission of PDUs in a buffer and/or PDUs to be received according to the determined amount of backoff. In this case, for example, the compensation amount may correspond to a difference between the E2E QoS and the expected QoS.

Regarding dynamic activation/deactivation of one or more configured or preconfigured LCH/MAC configurations based on conditions, for example, a relay WTRU may receive activation and/or deactivation of one or more configured or preconfigured RLC configurations from a network and/or a remote WTRU and may apply the activated RLC channel configuration. In another example, one or more LCHs/MACs may be dynamically activated/deactivated by the relay WTRU based on an indication received from the network (e.g., in RRC signaling, MAC CE, or DCI) and/or the remote WTRU (e.g., in PC5-RRC signaling, adaptation layer control, SL MAC CE, or SCI). In this case, the indication may contain an identifier/ID of the LCH/MAC that is configured or preconfigured to activate/deactivate. For example, the relay WTRU may receive an activation/deactivation indication based on other indications sent by the network/remote WTRU, which may include information regarding the expected QoS and/or load attributes associated with the RLC channel.

Regarding the derivation of parameters to be applied at one or more LCHs and/or MACs, in one example, a relay WTRU may derive/determine one or more parameters associated with an LCH/MAC configuration. In this case, the relay WTRU may be configured with a mapping rule configuration for determining parameters associated with one or more LCH/MAC configurations. For example, the mapping rule configuration may be used based on expected QoS and/or load attributes of the RLC channel determined by the relay WTRU. In one example, the relay WTRU may determine one or more configuration parameters to apply at the LCH/MAC based on a mapping rule configuration that may map from an expected QoS (e.g., an expected delay on an egress Uu RLC channel) to the LCH/MAC configuration (e.g., LCH priority). The relay WTRU may also send an indication (e.g., to the network) when determining and changing LCH/MAC configurations. In the above method, the relay WTRU may indicate the selected LCH/MAC configuration or a change in LCH/MAC configuration to the network and/or the remote WTRU.

In an embodiment, the relay WTRU may trigger the use of LCH/MAC configuration to compensate for one or more PDUs that may be received on the SL channel that have a different (e.g., higher/lower) QoS than the QoS configured on the SL RLC channel. For example, the relay WTRU may compensate for higher than expected delays (e.g., due to congestion) on the SL RLC channel by triggering the LCH/MAC configuration so that the received PDU may be transmitted with lower delay in the next hop (e.g., on the Uu link) to meet E2E QoS. The relay WTRU may trigger LCH/MAC configuration, for example, by selecting from one or more LCH/MAC configurations or pre-configurations and/or indicating to the network based on a determination of the expected delay of the PDU on the next hop Uu link if: before the PDU reaches the relay WTRU (e.g., no PDU is received or is not ready to be transmitted over the next hop) and/or when the PDU is received at one or more ingress RLC channels at the relay WTRU.

The relay WTRU may trigger the LCH/MAC configuration based on one or more of the conditions described above to compensate for the change in QoS on the SL channel. For example, the relay WTRU may apply the backoff by selecting an LCH/MAC configuration at granularity and/or based on per remote WTRU, per SL RLC channel, and/or per PDU group (e.g., consisting of or including one or more PDUs). In one example, the relay WTRU may trigger the use of an LCH/MAC configuration when operating in the backoff mode, wherein the relay WTRU may use the LCH/MAC configuration during the backoff mode, which may allow a particular QoS backoff amount (e.g., delay on Uu link) to be implemented. The mechanisms/actions that may be applied by the relay WTRU to implement the compensation by triggering the LCH/MAC configuration may include one or more of the following: a change in priority at LCH over Uu link, a change in LCH mapping restrictions/rules, a change in LCP configuration at MAC, a change in resource grant (dynamic grant/configuration grant) allocation, and/or a change in intra-WTRU multiplexing at MAC.

Regarding the change of priority at the LCH on the Uu link, for example, the priority on the LCH and/or the egress RLC channel may be adjusted so that existing PDUs in the buffer and/or received delayed PDUs may be sent with higher priority. In one example, in the event that a delayed PDU is expected, a first priority value configured at one or more LCHs may be changed to a second priority value. When one or more of the above conditions are met (e.g., the expected QoS of the PDU changes by a certain threshold), the relay WTRU may change the priority associated with the LCH configuration from a first value to a second value.

Regarding the change in LCH mapping restrictions/rules, for example, LCH mapping restrictions/rules (e.g., dynamic grant/configuration grant) associated with the mapping between LCHs and resources at the relay WTRU may be changed such that PDUs in the LCH may be allowed to access the appropriate resources to satisfy the determined amount of backoff. In one example, rules associated with mapping from LCH to resources with maximum PUSCH duration may be changed during the backoff mode so that the relay WTRU may access resources that may not normally be associated with LCH in order to send delayed PDUs in LCH as long as the backoff amount is less than the maximum PUSCH duration.

Regarding the change in LCP configuration at the MAC, for example, the relay WTRU may be configured or preconfigured with the first LCP configuration and the second LCP configuration to apply to LCHs during scheduling/multiplexing at the MAC. In this case, the first LCP configuration may be used during normal/typical operation, and the second LCP configuration may be used during compensation mode operation to compensate for any changes in the expected QoS of the PDUs in the one or more LCHs.

Regarding a change in resource grant (dynamic grant/configuration grant) allocation, for example, a relay WTRU may use a previous request and/or dynamic grant/configuration grant allocated for transmitting its own PDU or other relayed PDUs to transmit the received delayed PDUs during backoff. In one example, a relay WTRU may use an grant to transmit a delayed PDU when a PDB associated with its own PDU and/or other relayed PDUs is within a budget for transmitting in a subsequent time slot using the grant. For example, when a delayed PDU is transmitted using a first configuration grant or dynamic grant in an earlier transmit instance/slot, the relay WTRU may use a second configuration grant in the next transmit instance/slot for autonomous transmission of its own PDU.

For example, the relay WTRU may use one or more configuration grants with different priority values in the active BWP associated with the LCH to send the delayed PDUs in the UL. In another example, the relay WTRU may use one or more configuration grants (e.g., allowedCG-List) restricted for URLLC PDUs or other high priority PDUs for delayed PDUs during backoff. For example, the relay WTRU may identify and use a configuration grant configuration with a starting time slot and a duration that may be aligned with the starting and backoff durations, respectively, of the backoff time for the delayed PDU. In this case, for example, the relay WTRU may send an SR to the gNB to indicate that the identified configuration grant is activated to send a PDU with appropriately compensated delay.

Regarding the change in intra-WTRU multiplexing at the MAC, for example, the relay WTRU may change multiplexing of PDUs in the LCH, which may include an LCH carrying delayed PDUs, which are associated with different priorities in the transport block during backoff. In one example, if there is overlap of PUSCH resources between a low priority LCH (e.g., carrying an eMBB PDU), a high priority LCH (e.g., carrying a URLLC PDU), and an LCH carrying a delayed PDU, the relay WTRU may cancel multiplexing of PDUs in the low priority LCH to support the delayed PDU and/or the high priority PDU for UL transmission.

In an embodiment, the relay WTRU may send a request to the network to trigger QoS compensation at the relay WTRU. For example, the relay WTRU triggers a request for QoS compensation for increased latency due to congestion on the SL and/or relay tasks by indicating (via a request) to the network to assist in subsequent transmissions of PDUs received on the Uu link. For example, the relay WTRU may trigger the request in advance to reduce any delay associated with changing the configuration and/or resource scheduling at the relay WTRU. The relay WTRU may trigger a request for QoS compensation (e.g., for increased latency) for one or more of the following reasons: transmissions over the first hop PC5 link exceed the QoS budget (e.g., delay on the first hop is higher due to congestion); the configuration at the relay WTRU is changed/updated, including any change in mapping at the adaptation layer, a change in LCH/MAC configuration, and/or a change in the egress RLC channel configuration; and/or a change in load conditions at the relay WTRU at one or more ingress/egress RLC channels (e.g., due to arrival of PDUs from a remote WTRU or from a higher layer of a relay WTRU with higher priority), which may result in increased latency due to buffering. When the trigger is due to a configuration change/update at the relay WTRU, an indication may be made to the network when the relay WTRU recognizes the change in configuration and/or the relay WTRU autonomously changes configuration.

In these scenarios, the relay WTRU may send a request (e.g., in an SR/BSR) to the network for requesting one or more of: the look-ahead allocation of resources (e.g., prior to PDU arrival) and/or changing one or more configurations at the relay WTRU associated with mapping at the adaptation layer, LCH/MAC configuration for supporting PDUs that may be delayed, and/or RLC channel configuration. The relay WTRU may send a request to the network based on one or more of the conditions described above. In one example, a relay WTRU may send a request to activate a backoff mode operation in the relay WTRU, wherein the backoff mode may enable one or more configured or preconfigured configurations (e.g., LCH/MAC) to be used at the relay WTRU to achieve a particular QoS backoff amount for the delayed PDU (e.g., delay on Uu link).

In embodiments, when one or more of the above conditions are detected (e.g., CBR change threshold and/or number of HARQ/ARQ retransmissions in SL is higher than a count), the relay WTRU may be triggered to send a report associated with the SL channel and/or load condition to the network. In one example, the report triggered by the relay WTRU may be intended to request the network to assist in meeting the expected QoS for the PDU to be relayed.

When triggered by the above conditions, the content of the report sent by the relay WTRU to the network may include one or more of the following: an identifier/ID, timing information, information about channel/load measurements, information about QoS, information about LCH/MAC applied at one or more remote WTRUs, configuration of one or more RLC channels and/or adaptation layers, an indication for suspension/resumption, and/or an indication for changing transmission rate.

Regarding the identifier/ID, for example, the relay WTRU may send IDs for one or more ingress PC5 RLC channels or egress RLC channels. Regarding timing information, for example, the relay WTRU may send information regarding start/end timing and/or duration relative to a reference time slot for performing actions, as described in the previous section, including using a start/end of configuration or pre-configuration (e.g., LCH/MAC, adaptation layer mapping, egress RLC channel) at the relay WTRU. In another example, the relay WTRU may send information regarding start/end timing associated with suspending and/or resuming transmissions over one or more RLC channels on the PC5 link.

Information about channel/load measurements, e.g., relay WTRUs may send SL channel measurements (e.g., RSRP, RSSI, and/or CSI) and SL load measurements (e.g., CBR and/or CR) to the network in a report. For example, a report containing SL channel/load measurements may be sent by the relay WTRU based on one or more conditions including periodic transmissions and event triggers (e.g., expiration of a timer configured since the last transmission of the report, change in RSRP and/or CBR by some margin).

Information about QoS, e.g., relay WTRUs may indicate the determined/estimated expected QoS (e.g., latency, throughput) that may be achieved/implemented on different links/hops (e.g., PC5 link, uu link). The relay WTRU may also indicate the QoS type (e.g., GBR, non-GBR, best effort) of the traffic in the ingress/egress RLC channel. Information or configuration regarding LCH/MAC, one or more RLC channels, and/or adaptation layers applied at one or more remote WTRUs, for example, a relay WTRU may send such configuration information to the network on one or more of the following indication messages: the use of different PC5 RLC channels by the remote WTRU, a change in configuration applied at the remote WTRU (e.g., changing priority applied at the LCH/PC5 RLC channel), and a change in the resource pool associated with the SL RLC channel used to transmit the PDU. When the remote WTRU changes one or more preconfigured mapping configurations at the adaptation layer, the relay WTRU may send the ID of the mapping applied in the indication to the network.

Regarding the indication for suspension/resumption, for example, the relay WTRU may send a report over the configured SL RLC channel indicating the turning off/on, suspension, and/or resumption of transmissions from one or more remote WTRUs. Regarding the indication to change the transmission rate, for example, the relay WTRU may send a report to the relay WTRU regarding the rate of increase/decrease of PDU transmission (e.g., the number of PDUs per transmission instance/slot) from one or more remote WTRUs. For example, the relay WTRU may send a report when the PDU transmission rate changes by a certain amount. Alternatively, the change may be indicated as an incremental value relative to the initial/default transmission rate.

The relay WTRU may send the report to the network in one or more of RRC signaling (e.g., RRM report), SR, MACE (e.g., BSR), UCI/PUCCH, other feedback indications (e.g., CSI report and/or HARQ feedback), data PDU (e.g., PUSCH), and/or adaptation layer indication. For example, the indication may be included in an adaptation layer header, which may be appended to the PDU prior to transmission to a lower layer in the RLC channel. For example, the indication may be sent in an adaptation layer control PDU, which may be sent with the PDU or separately. The indication may be sent in a flow control indication PDU or other control PDU/marker.

In an embodiment, the remote WTRU may support adaptive QoS when mapping/multiplexing from one or more E2E radio bearers to one or more PC5 RLC channels. In this regard, adaptive QoS may refer to the ability to flexibly change configurations at one or more layers of a protocol stack, including adapting mappings at layers, LCH/MAC configurations for ensuring QoS in different hops and/or E2E QoS, and/or RLC channel configurations. Support for adaptive QoS may enable PDUs associated with different QoS flows and E2E radio bearers (e.g., consisting of or including sub-layers within the SDAP, PDCP, and/or RLC channels) that may have different E2E QoS requirements to be mapped to the same egress buffer associated with the egress PC5 RLC channel.

In some embodiments, the remote WTRU may determine and/or apply a Relative Compensation Factor (RCF) value or weight value at the adaptation layer to compensate for different first hop QoS on the PC5 link associated with one or more E2E radio bearers. For example, during/after E2E QoS splitting, different E2E radio bearers may be configured with different first hop QoS over the PC5 link to the relay WTRU. When performing an N:1 or N: M mapping from a radio bearer to an egress RLC channel, the remote WTRU may apply the RCF value at the adaptation layer so that a different first hop QoS associated with the radio bearer may be satisfied.

In one example, the remote WTRU may perform mapping at the adaptation layer based on knowledge of a first hop QoS associated with the E2E radio bearer and/or a batch of PDUs (one or more PDUs per batch) associated with the radio bearer. The mapping may be performed within a duration/window such that different RCF/weight values may be applied when mapping to the egress RLC channel. In this case, when the RCF value is applied to PDUs in different buffers associated with the E2E radio bearer, the number of PDUs that can be mapped to the egress RCL channel in a given mapping window may be proportional to the priority/weight indicated by the RCF value.

The remote WTRU may determine the RCF value to apply at the adaptation layer based on one or more of the semi-static configuration, the dynamic configuration, and/or the derivation of the mapping configuration. Regarding semi-static configurations, for example, the remote WTRU may receive an adaptation layer mapping configuration for mapping from a first hop QoS and/or an attribute affecting the first hop QoS (e.g., CBR measured over a PC5 link and/or a priority indication received from the relay WTRU) to an RCF value (e.g., priority/weight value). The mapping configuration may be received from the network (e.g., via RRC signaling) or from the relay WTRU (e.g., via PC5-RRC signaling).

The remote WTRU may be initially configured with a default mapping configuration for mapping from radio bearers to egress RLC channels at the adaptation layer. The default mapping configuration may also be associated with one or more parameters associated with the first hop QoS (e.g., priority of radio bearers and/or CBR measurements), which may be monitored/tracked by the remote WTRU prior to changing or sending the request to change the default mapping configuration. In one example, when changing or receiving a new/updated adaptation layer mapping configuration, the configuration applied at the egress PC5 RLC channel may also be changed/modified (e.g., by the network and/or relay WTRU).

Regarding dynamic configuration, for example, a remote WTRU may be preconfigured with one or more adaptation layer mapping configurations for mapping from one or more factors associated with a first hop QoS and RCF value (e.g., priority/weight). Different mapping configurations may be identified with different IDs. The different mapping configurations may be dynamically activated/deactivated with an indication that may be received from the network (e.g., via RRC signaling, MAC CE, or DCI) or from a relay WTRU in the SL (e.g., via PC5-RRC signaling, an adaptation layer control PDU, SL MAC CE, or SCI).

The received indication may include an ID of the associated mapping configuration for activation/deactivation. For example, to receive the dynamic activation/deactivation indicator, the remote WTRU may send another indication (to the network or another relay/remote WTRU) indicating a first hop QoS associated with the PDU in the radio bearer. In one example, when the mapping configuration at the adaptation layer is dynamically activated/deactivated, the configuration applied at the egress PC5 RLC channel when mapped at the adaptation layer may be dynamically changed/modified. In one example, the remote WTRU may send an indication to the relay WTRU and/or the network when changing the mapping configuration at the adaptation layer. For example, the remote WTRU may send an indication when changing from a 1:1 mapping to an n:1 mapping. Additionally, an indication may also be sent when one or more of the RCF values applied at the adaptation layer are changed.

Regarding the derivation of the mapping configuration, for example, the relay WTRU may derive/determine the RCF value (e.g., priority/weight) from one or more attributes that affect the remaining QoS. In another example, the relay WTRU may derive/determine the RCF value from one or more configurations associated with an egress RLC channel, which may be configured to achieve some desired first hop QoS and/or load value when mapping from the radio bearer. In one example, the relay WTRU may select or reselect an outgoing RLC channel. In some embodiments, when determining/deriving the RCF value to be applied at the adaptation layer, the relay WTRU may select or reselect the egress RLC channel from one or more preconfigured egress RLC channels having different configurations. In this case, different configurations may be associated with different achievable QoS in the first hop PC5 link. QoS in the first hop PC5 link may be implemented, for example, based on configurations applied in different sublayers of the outgoing RLC channel, including LCP rules/restrictions, LCH/MAC configurations (e.g., PBR, BSD, and/or priority), and PHY configurations.

The trigger conditions for changing/updating the mapping configuration (e.g., RCF values) at the adaptation layer may include one or more of the following: a change in traffic/PDUs in the E2E radio bearer, a change in SL channel/load conditions, an indication from the relay WTRU and/or the network, and/or an indication from the relay WTRU and/or the network. Regarding changes in traffic/PDUs in the E2E radio bearer, the mapping configuration may be updated, for example, when the number of active radio bearers with at least one PDU increases/decreases by a certain amount. Regarding changes in SL channel/load conditions, for example, the mapping configuration may be updated when one or more of the following measurements increases/decreases the threshold of certain configurations: SL channel measurements (e.g., SL-RSRP, SL-RSSI, and/or CSI), SL load measurements (e.g., CBR and/or CR), CSI feedback, ARQ/HARQ feedback, and ARQ/HARQ retransmission times. Regarding the indication from the relay WTRU and/or the network, for example, when an indication (e.g., adaptation layer control PDU, flow control) is received, the mapping configuration may be updated, which may indicate that the decrease/increase of QoS on the first hop PC5 link can/cannot be compensated for.

In an embodiment, the remote WTRU may select an egress RLC channel configuration to apply when mapping/multiplexing at the adaptation layer based on a first hop QoS associated with traffic in the radio bearer. The selection of the egress RLC channel may be performed by the remote WTRU using one or more of: reception of a configuration on an egress RLC channel, autonomous selection or reselection from a set of configured or preconfigured egress RLC channel configurations based on selection rules and conditions, dynamic activation/deactivation of one or more (pre) configured RLC channel configurations based on an indication received from a network and/or relay, and/or derivation of parameters to be applied at the egress RLC channel.

Regarding the receipt of configurations on the outgoing RLC channels, for example, the remote WTRU may receive configurations associated with one or more outgoing RLC channels from the network and/or relay WTRUs, such as based on an indication provided by the remote WTRU. Such an indication may contain information related to the first hop QoS (e.g., priority, delay, and/or CBR measurements on SL) and/or load attributes associated with the radio bearer. In one example, the egress RLC channel configuration applied at the remote WTRU may have a corresponding ingress RLC channel configuration applied at the relay WTRU, such as with matching parameters and/or IDs.

Regarding autonomous selection or reselection from a configured or preconfigured set of egress RLC channel configurations based on selection rules and conditions, for example, a remote WTRU may be configured or preconfigured (e.g., by a network) with one or more egress RLC channel configurations. The relay WTRU may select a pre-configured egress RLC channel configuration based on selection rules and conditions. As an example, the selection rule may indicate that a configured or preconfigured X is selected when one or more selection conditions are met. In one example, the selection condition may relate to a first hop QoS of PDUs in the radio bearer, a SL channel/load condition (e.g., SL-RSRP, CBR, CR), and/or a load attribute at the remote WTRU (e.g., the number of (active) radio bearers and/or PDUs to be mapped in one or more buffers is above a threshold). As an example, if CBR measured by the resource pool in the PC5 link for transmission to the relay WTRU is within a certain range (e.g., within a minimum and maximum value), the relay WTRU may select a configured or preconfigured X for the outgoing RLC channel. For example, when the measured CBR is determined to be below a certain threshold, configuration or pre-configuration (e.g., high PBR, high priority) for the egress PC5 RLC channel may be selected, which may result in low latency and/or high throughput transmissions on the PC5 link.

In one example, the remote WTRU may select a configured or preconfigured egress PC5 RLC channel in a mapping window/duration for mapping traffic from one of the plurality of radio bearers. In this case, the selection of the egress PC5 RLC channel may be made, for example, based on a match of QoS characteristics between the first hop QoS of traffic in the radio bearer and the achievable/desired QoS of the egress PC5 RLC channel. For example, the remote WTRU may dynamically select a first egress RLC channel configuration for mapping traffic/PDUs from the first radio bearer in a mapping duration/window. The remote WTRU may then select a second egress RLC channel configuration for mapping traffic/PDUs from the second radio bearer in a subsequent mapping duration/window.

In another example, when the SL channel/load condition is favorable (e.g., low CBR), the remote WTRU may select a configured or preconfigured egress PC5 RLC channel that enables the mapped PDUs in the buffer to be transmitted with a higher achievable QoS (higher throughput and/or lower latency) than the first hop QoS required for the PDUs. The remote WTRU may send an explicit indication (e.g., in a control PDU, MAC CE, or SCI) to the relay WTRU for indicating a possible change (e.g., lower priority) of the backoff to be applied at the relay WTRU. The change in backoff may also be indicated implicitly by the remote WTRU by using a different configuration of the egress RLC channel than that applied at the relay WTRU when the PDU was sent. For example, when forwarding PDUs in the next hop link, the relay WTRU may adjust QoS (e.g., reduce transmission rate) by changing the mapping configuration at the adaptation layer and/or changing the egress RLC channel configuration in the next hop based on an explicit or implicit indication sent by the remote WTRU.

Regarding dynamic activation/deactivation of one or more configured or preconfigured RLC channel configurations based on indications received from the network and/or relay, for example, one or more configurations or preconfigurations associated with the egress RLC channel may be dynamically activated/deactivated by the remote WTRU based on indications received from the network (e.g., in RRC signaling, MAC CE or DCI) and/or from the relay (e.g., in PC5-RRC signaling, adaptation layer control, SL MAC CE or SCI). Regarding the derivation of parameters to be applied at the egress RLC channel, for example, the remote WTRU may derive/determine one or more parameters associated with the egress RLC channel based on a mapping rule configuration. Such configuration may be used to map from the first hop QoS and/or load attributes of the radio bearer to one or more configuration parameters (e.g., LCH priority, PBR, and/or BSD).

In an embodiment, the remote WTRU may dynamically change the T2 limit for resource selection or reselection to meet QoS (e.g., PDB) on the PC5 link when mapped/multiplexed at the adaptation layer. The remote WTRU may be configured to map/multiplex traffic from one or more E2E radio bearers (possibly with different E2E QoS) to the egress PC5 RLC channel. In this case, the first hop QoS to be achieved by the egress PC5 RLC channel may depend on the number and/or distribution of PDUs belonging to different radio bearers during different resource selection or reselection time windows.

In one example, for a remote WTRU operating in mode 2, the T2 limit for the resource selection or reselection time window may be determined based on the traffic distribution in the buffer of the egress RLC channel. For example, the remote WTRU may set the T2 limit to at least the minimum value of PDB from different PDB values required for PDUs of different radio bearers mapped to the egress buffer in the mapping window (e.g., for i=1, … …, N radio bearers, T2 +.min (PDB) _i ))。

In another example, the remote WTRU may determine the T2 limit based on traffic/PDUs from radio bearers mapped to the associated egress PC5 RLC channel in the mapping window/duration. During operation, the remote WTRU may change the mapping configuration, wherein a batch of PDUs (consisting of or including one or more PDUs) from the radio bearer may be mapped to the egress PC5 RLC channel in the mapping window. In this case, for example, the remote WTRU may change the T2 limit at a different time, which T2 limit may be coordinated/synchronized with the mapping window/duration used at the adaptation layer (e.g., using an appropriate offset value). The remote WTRU may also change the value of the T2 limit based on the first hop QoS of the mapped batch of PDUs, for example. As an example, the remote WTRU may use a T2 limit, which may correspond/match with the first PDB value of the first batch of PDUs in a given time window. The remote WTRU may then use another T2 limit, which may correspond to a second PDB value for a second batch of PDUs in a next time window.

In an embodiment, the remote WTRU may determine whether to send or discard one or more PDUs based on the first hop QoS, E2E QoS, and associated T2 limits for resource (re) selection. The remote WTRU may be configured with one or more egress PC5 RLC channels for carrying PDUs/traffic associated with the E2E radio bearer/QoS flow to the network or next hop WTRU via the relay WTRU. In performing QoS partitioning, the network and/or higher layers (e.g., in the relay/remote WTRU) may indicate first hop QoS and/or E2E QoS to the remote WTRU. The first hop QoS may then be used to configure one or more egress PC5 RLC channels and/or to determine parameters associated with resource (re) selection, such as for operation in mode 2.

In one example, the remote WTRU may use information/requirements associated with a first hop QoS (e.g., PDB) to determine T2 limits related to a resource selection time window that may be used for resource (re) selection from one or more configured SL resource pools. As an example, for a first hop PDB value of Tms, the T2 limit may be set to be less than or equal to Tms. In the case of single hop transmissions over the PC5 link, PDUs intended for transmission may be discarded when the remote WTRU cannot reserve sufficient resources from the pool of resources within the T2 limit. However, in a relay scenario, it is possible for the relay WTRU to compensate for any increase in delay on the first hop PC5 link, since PDUs may be relayed by the relay WTRU over subsequent hops. In this case, the remote WTRU may be configured with one or more T2 limits, which may be used to determine whether the PDU is discarded or forwarded to the relay WTRU.

In one example, a relay WTRU may be configured with a first T2 limit (T2 ₁ ) And a second T2 limit (T2 ₂ ) Wherein the first T2 limit may be based on an initial first hop QoS received at the time of E2E QoS classification (e.g.,PDB ₁ ) Is determined, and a second T2 limit may be determined based on the E2E QoS and a next hop QoS (e.g., an achievable/expected QoS at the relay WTRU). For transmissions with E2E delay requirements, for example, a next hop PDB (e.g., a PDB for transmission from a relay WTRU to a network/remote WTRU ₂ ) Which may range from a minimum PDB ₂ And maximum PDB ₂ Between values, for example, a first T2 limit and a second T2 limit may be determined as T2, respectively ₁ =e2e PDB-maximum PDB ₂ And T2 ₂ =e2e PDB-minimum PDB ₂ 。

The remote WTRU may determine the first T2 limit and/or the second T2 limit based on an indication received from the network and/or the relay WTRU. For example, the remote WTRU may receive an explicit minimum/maximum PDB value associated with the next hop link to determine the T2 limit. Alternatively, the remote WTRU may determine the T2 limit via an implicit indication received from the network/relay WTRU (e.g., a change in load at the relay, a change in CBR) and a mapping rule between information in the indication and the T2 limit, for example.

Based on the determined T2 limit, the remote WTRU may perform the following operations to transmit the PDU. One or more PDUs may be sent to the relay WTRU when sufficient SL resources may be selected in less than or equal to the first T2 boundary. When sufficient SL resources are selectable within a window from the first T2 limit to the second T2 limit, an indication of QoS compensation may be sent to the relay WTRU along with one or more PDUs. When sufficient SL resources cannot be selected in greater than or equal to the second T2 limit, one or more PDUs may be discarded.

In an embodiment, the remote WTRU may perform mapping/multiplexing to the egress PC5 RLC channel at the adaptation layer based on a similar/uniform first hop QoS required/achievable for PDUs in one or more radio bearers. The remote WTRU may be (pre) configured with one or more egress PC5 RLC channels, where different configurations or pre-configurations may be associated with configuration parameter sets (e.g., RLC: AM/UM, MAC: LCP rules/restrictions, PBR, BSD, priority, PHY: HARQ enabled) at different sublayers for achieving a certain QoS over the PC5 link. The remote WTRU may also be configured with one or more E2E radio bearers for carrying PDUs associated with the QoS flow to the network or to a next-hop remote WTRU via the relay WTRU. In this case, the E2EQoS for QoS flows may be split by the network or remote/relay WTRU and configured in the remote WTRU to achieve first hop QoS with the egress PC5 RLC channel. The remote WTRU may then map the different E2E radio bearers to one or more egress PC5 RLC channels at the adaptation layer.

After QoS partitioning, different E2E radio bearers and associated QoS flows configured with the same/similar first hop QoS may be mapped/multiplexed at the adaptation layer to an egress PC5 RLC channel configured to achieve QoS that may support one or both of: the QoS of the PC5 RLC channel matches the first hop QoS associated with the radio bearer and accommodates traffic loads associated with the mapped radio bearer.

Regarding the QoS of the PC5RLC channel matching the first hop QoS associated with the radio bearer, for example, if the corresponding achievable QoS (e.g., first PDB) is within a minimum/maximum range associated with the first hop QoS (e.g., second PDB) of the radio bearer, the PC5RLC channel may be selected for mapping. QoS that may be implemented by the PC5RLC channel may be determined by the remote WTRU based on a mapping function that maps one or more QoS attributes (e.g., PDB, bit rate) from one or more configuration parameters (e.g., priority, PBR) applied at different sublayers. For example, as a result of SL channel conditions (SL RSRP, change in CSI) and/or load conditions (change in CBR), the QoS achievable by the PC5RLC channel over the PC5 link may dynamically change. In this case, for example, the mapping configuration at the adaptation layer may be changed such that radio bearers with similar/uniform first hop QoS are mapped to egress PC5RLC channels, such as with matched updated QoS. Regarding accommodating traffic loads associated with the mapped radio bearers, for example, the number of active radio bearers (e.g., non-empty radio bearers having at least one PDU) that can be mapped/multiplexed to the egress PC5RLC channel may be less than or equal to the maximum number/load value that the egress RLC channel can support.

In one example, the remote WTRU may select from one or more configurations or pre-configurations and/or be configured with a mapping configuration that may be applied at the adaptation layer for mapping from the radio bearer to an appropriate egress RLC channel that may support the first hop QoS of traffic in the radio bearer. In another example, the remote WTRU may dynamically change and/or configure a mapping configuration at the adaptation layer that enables mapping/multiplexing of traffic in the radio bearer to the appropriate egress PC5 RLC channel based on the matching QoS attributes. For example, the remote WTRU may change/update the RCF value in the adaptation layer mapping configuration, which results in mapping/multiplexing traffic from the radio bearer to the selected egress PC5 RLC channel.

In an embodiment, the remote WTRU may send an indication to the relay WTRU regarding compensating QoS when the QoS budget on the first hop PC5 link cannot be met. In one example, the remote WTRU may send a backoff indication to inform the relay WTRU to compensate for a higher than expected delay of PDUs to be transmitted via the PC5 RLC channel on the PC5 link. The backoff indication may include a backoff QoS value to be applied at the relay WTRU, which may include one or more of the following: the priority to be applied to the transmission in the next hop, the modified delay budget to be achieved for the transmission in the next hop, and/or the modified throughput or bit rate to be achieved for the transmission in the next hop.

Regarding the priority to be applied to transmissions in the next hop, for example, when the PC5 link is capable of supporting the intended first hop QoS, the priority to be applied may be the same (e.g., existing) priority (e.g., LCG priority) applied at the PC5 RLC channel during configuration. Alternatively, when the first hop QoS is not achievable, the priority value may be modified to indicate the QoS to be achieved/compensated in the subsequent hop or hops at the relay WTRU. For example, when the existing priority fails to meet the first hop QoS, the remote WTRU may indicate a higher modified priority for the next hop transmission. Regarding the modified delay budget to be achieved for transmitting in the next hop, for example, when the PDB in the first hop cannot be met, the remote WTRU may indicate to the relay WTRU the modified PDB (e.g., lower than the configured PDB) to be used when transmitting in the next hop. With respect to transmitting the modified throughput or bit rate to be achieved in the next hop, for example, the remote WTRU may instruct the relay WTRU of the modified throughput to be achieved in the next hop to compensate for possible throughput loss in the first hop. For example, the modified throughput may include a bit rate and different metrics of PDUs per unit time to indicate.

The remote WTRU may determine a backoff QoS value in the backoff indication to send to the relay WTRU based on one or more of: measurements made over the egress PC5 RLC channel and/or mapping rule configurations for mapping between measurements made over the resource pool associated with the egress PC5 RLC channel and the backoff QoS value (e.g., modified priority, PDB, throughput). Regarding measurements made over the egress PC5 RLC channel, for example, the measurements may include SL channel measurements (e.g., SL-RSRP and/or CSI) and/or SL load measurements (e.g., CBR and/or CR). For example, a compensation indication may be sent when the measurement being made is above/below a configured threshold. Regarding mapping rule configurations for mapping between measurements made over a resource pool associated with the egress PC5 RLC channel and backoff QoS values (e.g., modified priority, PDB, throughput), for example, if measurements made over a resource pool used in the first hop PC5 link (e.g., CBR) are within a certain range (e.g., a tolerable range for achieving desired PDB/throughput) and/or above/below a configured threshold, existing/default parameter values (e.g., priorities) applied in the PC5 RLC channel configuration may be used as backoff QoS values in a backoff indication (e.g., no backoff). Otherwise, the mapping rule between the measurement and the backoff QoS value may be used to determine the backoff QoS value (e.g., the modified priority). For example, when the measured CBR is above a threshold, a higher modified priority may be used to instruct the relay WTRU to compensate for higher latency on the PC5 link.

In an embodiment, the remote WTRU may send an indication to the relay WTRU and/or the network based on a trigger condition associated with the mapping at the adaptation layer and/or the first hop QoS. The content of the indication may include at least one or more of: an identifier/ID of a radio bearer and/or a PC5 RLC channel, a mapping configuration ID, a number of E2E radio bearers mapped to an egress RLC channel, load information related to the E2E radio bearers, qoS flow IDs, path/route IDs, and/or QoS related information.

Regarding the identifiers/IDs of the radio bearers and/or PC5 RLC channels, for example, the remote WTRU may send the IDs of one or more E2E radio bearers in the case of WTRU-to-NW relay and the IDs of the side-link radio bearers in the case of WTRU-to-WTRU relay. For example, the information on the radio bearer ID may be applicable to both the L2 radio bearer type and the L3 radio bearer type. The remote WTRU may also indicate one or more IDs associated with the PC5 RLC channel to which, for example, a radio bearer may be mapped.

Regarding the mapping configuration IDs, for example, if the remote WTRU applies one of the mapping configurations at the adaptation layer, the ID of the mapping configuration may be included in the indication. When the remote WTRU is any of the following combinations: the remote WTRU may include one or more mapping configuration IDs when performing a mapping update, N:1 to 1:1 (and vice versa), N:1 to 1:n (and vice versa), 1:n to 1:1 (and vice versa). Regarding the number of E2E radio bearers mapped to the egress RLC channel, for example, in the case when the remote WTRU performs an N:1 mapping, the remote WTRU may indicate the number of radio bearers mapped to the egress PC5 RLC channel. Regarding load information related to E2E radio bearers, for example, the remote WTRU may indicate the load of N radio bearers mapped to the PC5 RLC channel. For example, the load of the radio bearer may be indicated in terms of data/bit rate (total data/bit rate or average data/bit rate), PDU count and buffer occupancy percentage.

Regarding the flow ID, for example, the remote WTRU may indicate information regarding the QoS flow ID (e.g., QFI) and associated PDUs carried in a radio bearer that may then be mapped to an RLC channel. Regarding path/route IDs, for example, the indicated path ID may correspond to E2E L ID (source/remote WTRU ID, final destination ID) or other E2E route IDs that may be used to assist the relay WTRU in routing traffic to the next hop node (e.g., gNB, destination WTRU). In addition, the path ID may also correspond to the L2ID of the PC5 link between the remote WTRU and the relay WTRU, for example.

Regarding QoS related information, for example, the remote WTRU may include information in the indication to ensure/enforce E2E QoS. For example, the QoS information may include delay related information (e.g., a timestamp indicating a start time for mapping a PDU from a radio bearer to a PC5 RLC channel, an expected delay for transmission on the PC5 link to a relay WTRU, an expected remaining time at the relay WTRU for relaying to a next hop node on the Uu link/PC 5 link) to assist in scheduling and forwarding at the relay WTRU. For example, the remote WTRU may indicate a priority value assigned to the radio bearer, where priority may refer to a per radio bearer priority or a per RLC channel priority when performing an N:1 mapping from multiple radio bearers to RLC channels. For example, when indicating to the relay WTRU that the backoff may not meet the QoS budget (e.g., PDB) on the first-hop PC5 link, the remote WTRU may indicate a modified priority value assigned to one or more PC5 RLC channels. The remote WTRU may also indicate the QoS type (e.g., GBR, non-GBR, best effort) of the radio bearer mapped to the PC5 RLC channel at the adaptation layer.

When transmitting a PDU over the SL/PC5 link, the remote WTRU may send an indication to a relay WTRU associated with the (egress) PC5RLC channel that consists of or includes at least one of the above information. The remote WTRU may send an indication when triggered by one or more of: when changing/updating the mapping configuration at the adaptation layer and/or the configuration of the egress PC5RLC channel and/or when determining a change in QoS achievable over the first hop PC5 link. Regarding the mapping configuration at the adaptation layer and/or the configuration of the egress PC5RLC channel when changing/updating, for example, the remote WTRU may indicate information to the relay WTRU regarding the updated/changed mapping configuration (e.g., ID of the mapping configuration, changed RCF value). The relay WTRU may also indicate the updated parameter value and/or ID of the egress RLC channel. Regarding changes in QoS achievable over the first-hop PC5 link, for example, the remote WTRU may determine whether the QoS budget on the first-hop PC5 link may/may not be met based on a configuration mapping between the achievable QoS and one or more of the following measurements: SL channel measurements (e.g., SL-RSRP, CSI), SL load measurements (e.g., CBR, CR), CSI feedback, ARQ/HARQ feedback, and ARQ/HARQ retransmission times. In this case, the remote WTRU may be triggered to send an indication, for example, when the determined QoS and/or one or more of the above measurements are above/below a threshold/range.

For example, the remote WTRU may also send an indication to the network (in a WTRU-to-NW relay) or to the destination WTRU (in a WTRU-to-WTRU relay) when dynamically changing the mapping configuration. In this case, the indication may be sent via the relay WTRU (e.g., transparently) using E2E RRC signaling or E2EPC5-RRC signaling, respectively, as examples. In the case where the remote WTRU may have a direct link (Uu or PC 5) available to the network or the destination WTRU, the indication may be sent directly without relaying.

The remote WTRU may send an indication to the relay WTRU in at least one of an adaptation layer header, an adaptation layer control PDU, and/or other signaling. Regarding the adaptation layer header, for example, before transmitting PDCP PDUs associated with the radio bearer to the PC5 RLC channel, the indication may be included in the adaptation layer header, which may be appended to the PDUs. Regarding the adaptation layer control PDU, for example, control information may be transmitted in the adaptation layer control PDU, which may be transmitted to a lower layer as a separate adaptation layer PDU. Regarding other control signaling, the indication may be sent in PC5-RRC, SL MAC CE, or SCI, for example.

In embodiments, the WTRU may operate in a backoff mode to ensure that QoS is precompensated prior to data transmission. The remote WTRU may operate in QoS compensation mode to adjust the configuration applied when transmitting data to the network (e.g., base station/gNB) via a relay WTRU that may prevent potential QoS degradation based on the detection of the trigger event/condition described herein. Operation in QoS compensation mode may involve the remote WTRU transitioning from a default or first mode/action set to a different or second mode/action set for a particular duration, which may ensure that the QoS achievable during data transmission remains stable.

Operation in QoS compensation mode (including actions, procedures, rules/restrictions, and configuration parameter sets) may be configured in the remote WTRU (e.g., by the network via RRC signaling) and/or dynamically activated/deactivated. For example, the remote WTRU may operate in QoS compensation mode to ensure that QoS requirements (e.g., delay, data rate, and/or reliability) may be met during data transmission. For example, when the detected trigger event/condition is no longer observed, the remote WTRU may transition/fall back to operating in a default mode/action set, which may last for a certain configured duration.

Fig. 3 is a system diagram of an example of a remote WTRU 304, a relay WTRU 310, and a base station (e.g., a gNB) 314 operating in an exemplary QoS compensation mode. Fig. 4 and 5 are flowcharts of exemplary methods of supporting adaptive QoS in a side link relay that may be implemented at a remote WTRU and a relay WTRU, respectively, in a system such as that shown in fig. 3.

Referring to fig. 3 and 4, the remote WTRU 304 may be configured with a configuration 302 indicating a first delay budget (402). In the example shown in fig. 3, the remote WTRU 304 receives the configuration 302 from the gNB 314. The first delay budget may be a first hop delay budget D1. Alternatively or in addition to the first delay budget, the configuration may include default relay delay R1 and/or CBR thresholds. The first hop delay budget is shown as D1 in fig. 3.

The remote WTRU 304 may receive one or more packets (404). In some embodiments, the packets may be PDUs. Although not shown in fig. 3, packets may be received from one or more higher layers.

The remote WTRU 304 may receive an indication (406). In the example shown in fig. 3, the updated relay delay 306/R2 may be received from the relay WTRU 310. For example, the indication may be an indication of an updated relay delay, but may also be other indications consistent with the embodiments described herein.

The remote WTRU 304 may determine an updated first-hop delay budget (L1 in fig. 3) based on the received indication (408). For example, the updated first-hop delay budget may be determined by subtracting the second-hop delay and the updated relay delay 306/R2 from the E2E delay and adding the configured default delay R1.

In some embodiments, the remote WTRU 304 will compare the updated first-hop delay budget L1 with the initial first-hop delay budget D1. Based on L1< D1, the remote WTRU 304 may perform CBR measurements of the resource pool to the relay WTRU 310 over SL. Based on the CBR < CBR threshold, the remote WTRU 304 may select resources using the initial first hop delay D1 as a resource selection limit T2. The remote WTRU 304 may determine the amount of compensation for the relay WTRU 310 based on the E2E delay, the initial first hop delay budget D1, and the updated relay delay R2. The remote WTRU 304 may transmit a packet and an indication (shown as 308 in fig. 3) to the relay WTRU 310. The indication may include, for example, one or more information or requests that the relay WTRU 310 compensate by an amount of compensation (e.g., an associated high priority value). Based on the CBR++CBR threshold, the remote WTRU 304 may select resources by using the updated first hop delay budget L1 as a resource selection limit T2. The remote WTRU 304 may transmit a packet and an indication (shown as 308 in fig. 3) to the relay WTRU 310. The indication may include, for example, information about the use of L1 (e.g., an associated high priority value).

Based on L1+.D1, the remote WTRU 304 may select resources by using the initial first hop delay budget D1 as a resource selection boundary T2. The remote WTRU 304 may transmit a packet and an indication (shown as 308 in fig. 3) to the relay WTRU 310. The indication may include, for example, information about the use of D1 (e.g., an associated priority value).

In some embodiments, at the end of the relay WTRU 310, the remote WTRU 310 may determine or otherwise be triggered to send an indication to the remote WTRU 304 (506). As mentioned above, the indication may be an indication of updated relay delay information R2. The relay WTRU 310 may receive at least one packet for a second transmission and a second indication of a delay budget for a second hop transmission from the remote WTRU 304 (as shown at 308 in fig. 3). The trigger condition may be one or more of any number of trigger conditions including, for example: the WTRU receives an indication from the network, the WTRU receives an indication from the remote WTRU, a buffer status, a load at one or more of the ingress buffer or the egress buffer, a change in configuration at the relay WTRU, a change in configuration at the WTRU, timing information, measurement of the side link, and an expected quality of service. The information about the delay budget of the second hop may be, for example, one of information about use of an updated first-hop delay budget based on the updated relay delay and information about use of an initial first-hop delay budget. If there are more than two expected hops in a particular transmission, the relay WTRU 310 may transmit/retransmit/one or more packets to one of the wireless network (e.g., the gNB 314 in fig. 3) (the transmission indicated at 312 in fig. 3) or another WTRU. The relay WTRU 310 may transmit one or more packets based at least in part on the indication of the delay budget for the second hop transmission.

The trigger event/condition for triggering operation in QoS compensation mode may be configured in the remote WTRU by the network and/or other WTRUs (e.g., relay WTRUs). The trigger events/conditions that may be monitored and/or detected by the remote WTRU for initiating operation in QoS compensation mode may include one or more of the following: an indication from the network, an indication and/or information from the relay WTRU, a buffer status and load at the remote WTRU ingress/egress buffer and associated RLC channel, a change in configuration at the remote WTRU, timing/timestamp information (which may be associated with an expected QoS), measurements on the SL/Uu channel/link, attributes associated with the relay WTRU or SL to which the RLC channel is associated, and/or QoS attributes associated with the RLC channel.

Regarding the indication/information from the network, for example, the remote WTRU may receive an indication from the gNB to transition to QoS compensation mode, which may last a certain duration and/or until one or more events are observed (e.g., expiration of a timer and/or increase/decrease of CBR threshold by CBR measurement). In another example, the remote WTRU may receive information about any one of the following: a change in load at the relay WTRU (e.g., load increase/decrease load threshold), a change in expected QoS on the next hop (e.g., over Uu link and/or over second PC5 SL), a change in configuration applied at the relay WTRU (e.g., adaptation layer configuration and/or ingress/egress RLC channel configuration), and a change in configuration applied at the remote WTRU (e.g., change in radio bearer configuration parameters and/or change in priority).

For example, the indication/information may be received by the remote WTRU based on per-relay WTRU, per QoS flow, per E2E radio bearer, per-egress RLC channel at the remote WTRU, and/or per-QoS flow to egress RLC channel mapping (e.g., at the sidelink adaptation layer). The remote WTRU may receive the indication from the network directly (e.g., via a Uu link) or indirectly via a relay WTRU.

Regarding the indication/information from the relay WTRU, for example, when transmitting PDUs in subsequent hops, the remote WTRU may receive information/indication regarding the achievable QoS (e.g., delay, data rate, and/or reliability). Information about QoS may be received by the remote WTRU on a per QoS flow, per radio bearer, RLC channel, or per link basis. For example, the remote WTRU may receive an indication (e.g., a flow control indication) as to whether to increase/decrease/stop/pause/resume transmission of PDUs associated with the QoS flow, radio bearer, RLC channel, or link. For example, the remote WTRU may receive timing information (e.g., start time/stop time/duration) for suspending or resuming PDU transmission to the relay WTRU. In another example, the remote WTRU may receive information about the load/processing status (e.g., when the number of PDUs or total payloads in the buffer increases above a threshold) and/or QoS changes due to an increase/decrease in load/processing at the relay WTRU. In another example, the remote WTRU may receive measurement information/reports (e.g., CBR, CR, RSRP of the SL channel and/or RSRP of CSI-RS/SSB of the Uu link), for example. For example, information/indications from the relay WTRU may be received by the remote WTRU in a PC5-RRC message, a SL MAC CE, an adaptation layer control PDU, other control/data PDUs from different protocol layers and/or SCIs.

Regarding the buffer status and load at the remote WTRU ingress/egress buffers and associated RLC channels, the buffer status/load may include at least conditions associated with any one or a combination of the following measurements (e.g., relative to an associated threshold): an amount of data (e.g., number of PDUs, payload in bytes/bit) associated with any of the following: one or more QoS flows (from higher layers/applications), radio bearers (e.g., from PDCP entity), adaptation layers, and RLC/LCH buffers/channels, which may be over a period of time (e.g., within a configured time window); an arrival/departure rate of PDUs in one or more radio bearers (e.g., PDCP entities), adaptation layer, and RLC/LCH buffers/channels; average size, maximum size, minimum size of PDUs in one or more radio bearers (e.g., PDCP entities), adaptation layer, and RLC/LCH buffers/channels; and/or the amount of time that one or more PDUs spends in one or more radio bearers (e.g., PDCP entities), adaptation layers, and RLC/LCH buffers/channels. For example, other buffer status metrics that may be monitored by a remote WTRU may include data received from another remote/relay WTRU (e.g., in a previous hop via SL), including the amount of data, the data arrival/departure rate, the amount of time that data spends in the buffer, etc.

Regarding a change in configuration at the remote WTRU, for example, when changing mapping configurations (e.g., LCH/MAC configurations) at the SDAP layer, adaptation layer, and/or RLC channel, the remote WTRU may be triggered to perform actions including changing at least one parameter in the QoS flow to DRB mapping at the SDAP, at least one parameter LCH configuration (e.g., priority, PDB, PBR, and/or BSD) at the ingress/egress RLC channel. For example, when CDRX and/or DRX configuration parameters (e.g., cycle time duration, on duration, inactivity timer) applied at the remote WTRU are modified/updated, the remote WTRU may be triggered to perform actions and/or send indications to the network and/or relay WTRU that may affect the transmit/receive mode and/or QoS achievable during data transmission over the SL. For another example, when a configuration related to a PC5 RLC channel between the remote WTRU and the relay WTRU is changed (e.g., HARQ is enabled/disabled on the PC5 link and/or the resource pool used is changed), the remote WTRU may be triggered to perform an action and/or send an indication to the network.

Regarding timing/timestamp information, for example, the remote WTRU may keep track of timing related information (e.g., a timestamp, a flag, or a timing control PDU) in one or more PDUs received from higher layers/application layers (e.g., in a PDU header), which may occur over a time window. For example, the timing information may then be used to determine the expected QoS for the PDU buffer and/or the upcoming PDU using a configured mapping relationship between the timing information and the expected QoS. For example, the timing information may be indicated as the time at which the PDU was created and/or the deadline/delay/time-to-live limit that may be met on a per-hop and/or end-to-end basis during transmission. In another example, timing information may also be indicated based on a count (e.g., a hop count). The remote WTRU may trigger an action, which may be based on timing/timestamp information, for example.

Regarding measurements on the SL/Uu channel/link, for example, the remote WTRU may perform measurements over one or more SL resource pools/BWPs associated with the SL and/or the egress RLC channel for triggering actions. For example, the channel related measurements may include SL-RSRP, SL-RSSI, CQI, and CSI, and the load related measurements may include CBR and CR. For example, when a direct Uu link to the network is available, the remote WTRU may perform measurements (e.g., corresponding to RSRP, RSSI, CQI and CSI) over the Uu link to determine the expected QoS.

For example, the remote WTRU may determine the SL condition based on a number of ARQ/HARQ (ACK/NACK) feedback messages received from the relay WTRU and/or ARQ/HARQ retransmissions over one or more SL channels and a resource pool associated with the egress RLC channel/link. The expected QoS may then be determined, for example, based on a (configured) mapping function between the SL feedback/ReTx count and the expected QoS. As an example, a ReTx count above a threshold may translate into poor SL channel conditions and thus reduce the expected QoS. In another example, the remote WTRU may determine the SL channel/load condition based on the SL channel/CSI report and/or the SL load/CBR report sent by the relay WTRU.

For example, a channel/load measurement over a certain configured duration may indicate whether a PDU may be delivered within an expected QoS range in the first hop, or whether a QoS budget may be expected to be exceeded. For example, when the performed measurement (e.g., CBR measurement) is greater than a threshold, the remote WTRU may determine that the expected QoS may not meet the QoS requirements and/or may determine a corresponding action that may result in meeting the QoS requirements.

Regarding attributes associated with a relay WTRU or SL associated with an RLC channel, for example, a remote WTRU may be configured with relay WTRU or SL specific attributes, such as priority values associated with the WTRU or SL and/or configuration parameters enabling/disabling specific actions for the WTRU/link. For example, a WTRU/link configured with a high priority may allow a remote WTRU to change the mapping configuration (e.g., at the SDAP/adaptation layer) and/or LCH/MAC configuration (relative to the initial or default configuration) of the RLC channel. For example, the remote WTRU may change the LCH/MAC configuration of the high priority WTRU/link as long as the change may affect only the processing of data associated with other lower priority WTRUs/links.

Regarding QoS attributes associated with an RLC channel, for example, a remote WTRU may determine whether an action may be performed on the RLC channel based on QoS-related parameters (e.g., priority value, PDB, PER) configured with the RLC channel. For example, the condition of when an action is performed (e.g., determining an egress RLC channel configuration) may depend on QoS-related parameters (e.g., priority value, PDB) associated/configured with the RLC channel.

The actions performed by the remote WTRU upon detecting any of the trigger events/conditions described above and/or while operating in QoS compensation mode may include one or more of the following: transmitting an indication/report to the network and/or relay WTRU, changing a connection with the network/relay WTRU, changing a CDRX or DRX configuration, changing a configuration of RLC channels/LCHs, changing LCH mapping restrictions/rules, changing LCP configuration at MAC, changing use of resource configuration, changing multiplexing behavior within the WTRU, and/or changing PHY layer configuration/parameters.

With respect to sending an indication/report to the network and/or relay WTRU, for example, the remote WTRU may be triggered to send an indication to the network and/or relay WTRU, which may indicate operation in QoS compensation mode. In one example, the remote WTRU may send an indication/report when the estimated QoS and/or channel measurements (e.g., RSRP, RSSI, RSRQ, CQI and/or CSI) over the PC5 link and/or Uu link are greater than/below a configured threshold and/or remain above/below the threshold for a certain duration.

Regarding changing the connection with the network/relay WTRU, for example, the remote WTRU may initiate a procedure (e.g., RRC reconfiguration) for requesting the network to reconfigure any QoS related configuration (e.g., radio bearers, SDAP, adaptation layer, and/or RLC channels) and/or any measurement configuration on the SL/Uu link. In one example, a remote WTRU may initiate a procedure for requesting modification of a resource pool configuration associated with SL resources to increase resources available to the remote WTRU. For example, the remote WTRU may initiate a procedure for aggregating the available set of resource pools, BWP, carriers, links, etc. In another example, when operating in QoS compensation mode, the remote WTRU may trigger a request to establish a direct connection with the network. In another example, the remote WTRU may trigger a procedure for establishing and/or activating a connection with the second relay WTRU, which may be done while maintaining the connection with the first relay WTRU or releasing/deactivating the connection with the first relay WTRU. For example, when a connection with multiple relay WTRUs is established/available, a remote WTRU may transmit data/PDUs to the multiple relay WTRUs or alternate between one relay WTRU and another relay WTRU.

Regarding changing CDRX or DRX configurations, for example, the remote WTRU may initiate a procedure to change its power saving scheme, including configuration parameters when configured with CDRX or DRX configurations. In one example, when operating in QoS compensation mode, the remote WTRU may use and/or select a CDRX/DRX configuration that may result in a longer on duration and/or inactivity timer for enabling use and/or monitoring of the control/data channel.

With respect to changing the configuration of the RLC channel/LCH, for example, the remote WTRU may change configuration parameters (e.g., priorities assigned to LCH and/or outgoing RLC channel) such that PDUs that are expected to be delayed (e.g., due to expected QoS degradation) may be transmitted with higher priority than other PDUs. In one example, a first priority value configured at one or more LCHs may be changed to a second priority value when one or more PDUs of an expected delay are transmitted. Upon detecting the one or more events/conditions, the remote WTRU may change the priority associated with the LCH/RLC channel from a first priority value to a second priority value (e.g., CBR increases above a threshold, an expected QoS reduction threshold for the PDU). For example, when operating in QoS compensation mode, the remote WTRU may change the configuration associated with segmentation/assembly rules at the SDAP, PDCP, adaptation layer, and/or MAC regarding whether to segment and/or assemble PDUs received from higher layers. In one example, the remote WTRU may suspend segmentation of the PDU at the RLC and/or MAC layers so that the PDU may be sent faster using available resources when it is determined that the PDU is expected to be delayed. For another example, when operating in QoS compensation mode, the remote WTRU may autonomously activate packet duplication or initiate a procedure for activating packet duplication at any protocol layer including the SDAP, PDCP, adaptation layer, RLC or MAC layer for increased reliability.

Regarding the change in LCH mapping restrictions/rules, for example, the mapping restrictions for the mapping between LCHs and one or more resource pools/BWPs at a remote WTRU may be changed/relaxed such that PDUs in the LCH may be transmitted by accessing appropriate resources from a limited resource pool when operating in QoS compensation mode. For example, rules associated with mapping from LCH to resources with maximum PSSCH duration may be changed during QoS backoff mode so that as long as the backoff amount is less than the maximum PSSCH duration, the remote WTRU may access resources not normally associated with LCH for transmitting PDUs that are expected to be delayed.

With respect to changing LCP configuration at the MAC, for example, the remote WTRU may be configured and/or preconfigured with the first LCP configuration and the second LCP configuration to apply to the RLC channels/LCHs during scheduling/multiplexing at the MAC. In this case, the first LCP configuration may be used during normal/typical operation, and the second LCP configuration may be used when operating in QoS compensation mode to compensate for any changes in the expected QoS of PDUs in one or more RLC channels/LCHs.

Regarding the use of changing resource configurations, for example, during QoS compensation mode, a remote WTRU operating in mode 2 may use SL resources (e.g., periodic, semi-persistent, and/or aperiodic) previously selected and/or allocated for transmitting PDUs from buffers with higher/lower priority (e.g., in an SDAP, adaptation layer, and/or RLC channel) and/or from buffers/LCH/RLC channels that may tolerate increased delay to transmit delayed PDUs and/or PDUs that are expected to be delayed (e.g., expected to experience QoS degradation). In one example, the remote WTRU may use the resources to transmit PDUs expected to be delayed when PDBs associated with other PDUs (e.g., from delay tolerant RLC channels) are within a budget to transmit using the resources in subsequent slots/instances. For example, when transmitting PDUs expected to be delayed using a first set of SL resources in an earlier transmission instance/slot, the relay WTRU may use a second set of SL resources for autonomous transmission of other PDUs in the next transmission instance/slot. In another example, the remote WTRU may initiate a procedure for changing from operating in mode 2 to mode 1 when the remote WTRU is able to access the network and/or when operating in QoS compensation mode. For example, the remote WTRU may send the PDU expected to be delayed using one or more resource sets with different priority values in the resource pool and/or in the active BWP associated with the RLC channel/LCH. In another example, the remote WTRU may use resources (e.g., allowedCG-List) limited for URLLC PDUs or other high priority PDUs for delayed PDUs during QoS backoff mode.

For example, the remote WTRU may identify and use resources having a starting time slot and duration that may be aligned with the start of a QoS compensation pattern for transmitting the PDU that is expected to be delayed. In this case, for example, the remote WTRU may send an indication to the relay WTRU and/or an indication (e.g., SR) to the gNB to indicate that the identified resources are activated to send PDUs with appropriate backoff. For example, the remote WTRU may perform resource selection and/or reselection from one or more configured resource pools such that at least transmission of PDUs may result in modification of achievable QoS, such as delay, reliability (e.g., modifying the number of HARQ reTx), diversity (e.g., performing packet duplication), and/or transmit power.

With respect to changing intra-WTRU multiplexing behavior, for example, when operating in QoS compensation mode, the remote WTRU may change the multiplexing rules of the PDUs based on different priorities associated with the buffers, including those at the SDAP, adaptation layer, RLC layer, or MAC layer (e.g., LCH). In examples related to multiplexing at the MAC, if there is an overlap of PSSCH resources between a low priority LCH (e.g., carrying an eMBB PDU), a high priority LCH (e.g., carrying a URLLC PDU), and an LCH carrying a delayed PDU, the remote WTRU may cancel multiplexing of the PDUs in the low priority LCH to support delayed PDUs and/or high priority PDU transmissions to the relay WTRU.

With respect to changing PHY layer configurations/parameters, for example, the relay WTRU may modify one or more configuration parameters associated with the PHY layer in order to achieve a desired QoS compensation when transmitting data to the relay WTRU. In one example, the remote WTRU may modify the configuration applied for link adaptation, including adjustments/offsets to transmit power, transmit scheme, MCS, coding rate, etc. In one example, the remote WTRU may be configured with one or more transmit power levels (e.g., via higher layer signaling, PHY layer signaling), where the transmit power level may be expressed in terms of a ratio to a maximum transmit power level, which may be based on a plurality of resource blocks. When operating in QoS compensation mode, for example, the remote WTRU may select and/or transmit PDUs using an appropriate transmit power level based on the determined expected QoS (e.g., delay, data rate, and/or reliability). For example, the remote WTRU may use a higher transmit power level to increase reliability and/or reduce the number of HARQ retransmissions when determining a lower delay budget for transmitting PDUs to the remote WTRU.

In another example, when operating in QoS compensation mode, a remote WTRU configured with a first MCS, coding and/or spatial transmission scheme set and a second MCS, coding and/or spatial transmission scheme set (e.g., MIMO schemes with different layers and/or number of antenna ports) may transition from using the first MCS/coding/spatial scheme set to using the second MCS/coding/spatial scheme set. For example, the remote WTRU may use a higher order modulation set with a low coding rate and a higher rank for spatial multiplexing in order to transmit PDUs faster in QoS compensation mode, which may occur even where CSI may not be advantageous. The appropriate MCS/coding/spatial scheme set for using the MCS/coding/spatial scheme in QoS compensation mode may be configured by the network in the remote WTRU via higher layer signaling (e.g., RRC).

In some embodiments, the WTRU may perform the resource selection based on congestion on the SL and an indication from the relay WTRU. For example, the remote WTRU may determine SL resources for transmitting data to the network in the UL via the relay WTRU based at least on the determined delay budget (e.g., first hop) on the SL, information about the load at the relay WTRU, and the congestion level on the SL. When the remote WTRU is operating in mode 2, for example, SL resources may be selected by the remote WTRU from one or more configured resource pools such that PDUs may be transmitted from the remote WTRU to the relay WTRU using the selected resources while meeting the determined QoS budget (e.g., delay and/or data rate) on the first hop. When the remote WTRU is operating in mode 1, for example, the remote WTRU may receive a resource grant from a network (e.g., a base station or serving gNB) for performing SL transmission of PDUs to the relay WTRU based on the determined QoS budget. Embodiments of procedures for resource selection at a remote WTRU to meet E2E QoS requirements are described below.

The remote WTRU may initially receive configuration information from a network (e.g., a base station/gNB), wherein the configuration information may include one or more of: E2E QoS requirements, initial QoS budget on SL, default delay at relay WTRU, and/or CBR threshold. Regarding E2E QoS requirements, for example, qoS requirements may include delay, data rate, and/or reliability, when transmitting one or more PDUs via a relay WTRU, it may be desirable to enforce the requirements on an E2E basis (e.g., between a remote WTRU and a network). Regarding the initial QoS budget on SL, for example, the initial QoS budget may include default delay, data rate, or reliability values expected to be achieved when transmitting PDUs over SL hops between the remote WTRU and the relay WTRU. In one example, a default QoS may be determined by the network and provided to the remote WTRU. Regarding default delays at the relay WTRU, for example, the initial/default delays may refer to expected delays that occur at the relay WTRU, which may be due to processing, loading, and relay functions. Regarding the CBR threshold, for example, the CBR threshold may be used by the remote WTRU to determine a congestion level on the SL resource pool for data transmission to the relay WTRU. In one example, the CBR threshold may be used by the remote WTRU to determine whether the remote WTRU and/or the relay WTRU may apply any backoff mechanisms to meet E2E QoS requirements during data transmission.

During operation, the remote WTRU may receive one or more PDUs via the SL from any of the following: an application layer, a higher layer (e.g., NAS layer in a remote WTRU), and another remote/relay WTRU in a previous hop. The remote WTRU may receive an indication from the relay WTRU indicating a delay updated at the relay WTRU (e.g., in a flow control indication, the flow control indication may be received in a PDU, SL MAC CE, or SCI). For example, the updated delay at the relay WTRU may indicate a new delay value, which may be different/the same as the default delay previously indicated at the relay WTRU. In another example, the updated delay at the relay WTRU may indicate an amount of change (e.g., an incremental change) in the delay value from a default delay at a previously received relay WTRU. The change in delay may include, for example, an increase/decrease/no change in the number of slots, the number of symbols, time in ms.

The remote WTRU may determine an updated QoS budget (e.g., delay) on the SL for transmitting PDUs to the relay WTRU based on any of the following: the estimated QoS budget on the second hop, the E2E QoS (e.g., delay), the default delay at the relay WTRU (R1), and the updated delay at the relay WTRU (R2). For example, the estimated QoS budget on hop 2 may be determined by subtracting the initial QoS budget on SL from E2E QoS. In one example, the updated delay budget on SL may be determined as follows: estimated QoS budget on E2E QoS-second hop-default delay at relay WTRU (R2) +update delay at relay WTRU (R1).

If the updated QoS budget is greater than or equal to the initial QoS budget, which means that the remote WTRU may have a more relaxed QoS than the initial allocated QoS budget for data transmission, the remote WTRU may select resources from the configured pool of resources for transmitting one or more PDUs to the relay WTRU by using the appropriate resource (re) selection limit (e.g., T2 limit). For example, when performing resource (re) selection, the remote WTRU may perform CBR measurements and/or use the latest available CBR information. For example, the remote WTRU may perform the resource (re) selection by setting the determined updated QoS budget (e.g., delay) or initial QoS budget (e.g., delay) as the resource (re) selection limit.

The remote WTRU may then transmit the PDU to the relay WTRU using the selected resources. The remote WTRU may also send an indication to the relay WTRU indicating information regarding the use of the updated QoS budget or initial QoS budget determined during transmission over the SL hop. Information regarding the use of the updated/initial QoS budget may be indicated by the remote WTRU through the use of associated indexes, flags, and/or priority values that may be mapped to the applied QoS budget using, for example, a mapping relationship configured by the network. For example, an indication indicating information about the applied QoS budget may be sent by the remote WTRU in any of the following: control/data PDU, SL MAC CE or SCI. For example, when using an initial QoS budget, an indication sent by the remote WTRU to the relay WTRU may be sent with the PDU in the SCI and may include a default priority value associated with the SL channel (e.g., the egress RLC channel).

If the updated QoS budget is less than the initial QoS budget, which means that the remote WTRU may have a tighter/stricter QoS than the initial allocated QoS budget for data transmission, the remote WTRU may select resources from the configured pool of resources by using a different value (e.g., delay) than the initial QoS budget as a resource (re) selection bound (e.g., T2 bound).

The remote WTRU may determine the CBR of the configured resource pool for data transmission to the relay WTRU by performing CBR measurements and/or using the latest available CBR measurement information at the remote WTRU. In this case, if the determined CBR is less than the CBR threshold (e.g., received from the network in the configuration information), which may mean that the congestion level on the SL is relatively low and/or resources may be readily available, the remote WTRU may perform the resource (re) selection, e.g., by setting the determined updated QoS budget (e.g., delay) to a resource (re) selection limit. The remote WTRU may then transmit the PDU to the relay WTRU using the selected resources. The remote WTRU may also send an explicit indication or an implicit indication to the relay WTRU to indicate information regarding the use of the updated QoS budget determined during transmission over the SL hop. For example, information about the updated QoS budget (e.g., control/data PDU, SL MAC CE, or SCI) may be indicated by using associated index, flag, and/or priority values. For example, the remote WTRU may send an indication (possibly with PDUs in the SCI) to the relay WTRU explicitly or implicitly by sending an associated priority value (e.g., matching an updated QoS budget) that is higher than the default priority value associated with the SL channel.

Alternatively, if the determined CBR is greater than or equal to the CBR threshold (e.g., received from the network in the configuration information), which may mean that the congestion level on the SL is relatively high and/or resources may not be readily available, the remote WTRU may perform the resource (re) selection, e.g., by setting the determined updated QoS budget (e.g., delay) or initial QoS budget (e.g., delay) to a resource (re) selection limit. The remote WTRU may then transmit the PDU to the relay WTRU using the selected resources.

The remote WTRU may also determine a QoS backoff value to indicate to the relay WTRU that may be used to request the relay WTRU to compensate for a decrease in the QoS budget available at the remote WTRU when transmitting PDUs over the SL. For example, the QoS compensation value may be determined by the remote WTRU based on the E2E QoS, the initial QoS budget, and the delay of the update at the relay WTRU. For example, the QoS compensation value may be determined as follows: E2E delay-initial QoS budget-delay updated at the relay WTRU. For example, the QoS compensation value may be indicated explicitly or implicitly by the remote WTRU using an associated index, flag, and/or priority value that may be mapped to the applied QoS budget using a mapping relationship configured by the network. For example, the QoS compensation value may be sent by the remote WTRU in any of the following: control/data PDU, SL MAC CE or SCI. For example, the remote WTRU may send a QoS compensation value to the relay WTRU that may be explicitly or implicitly sent with the PDU in the SCI by sending an associated priority value that is higher than the default priority value associated with the SL channel (e.g., matches the QoS compensation value).

Although the features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as 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 the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit/receive unit (WTRU), the WTRU comprising:

a transceiver; and

the processor may be configured to perform the steps of,

wherein the transceiver and the processor are configured to receive a configuration from a wireless network, the configuration indicating an initial first hop delay budget for communications via a relay WTRU,

Wherein the transceiver and the processor are further configured to receive one or more packets from a higher layer,

wherein the transceiver and the processor are further configured to receive an indication from the relay WTRU, and

wherein the transceiver and the processor are further configured to determine an updated first hop delay budget based at least on the received indication.

2. The WTRU of claim 1, wherein the configuration further comprises at least one of a Channel Busy Rate (CBR) threshold, a default relay delay, or an end-to-end (E2E) delay.

3. The WTRU of claim 2, wherein the transceiver and the processor are further configured to perform CBR measurements on a resource pool associated with a side link connected to the relay WTRU based on the updated first-hop delay budget being less than the initial first-hop delay budget.

4. The WTRU of claim 3, wherein the transceiver and the processor are further configured to transmit the one or more packets using the resources selected by the updated first-hop delay budget based on the CBR measurement being less than or equal to the CBR threshold.

5. The WTRU of claim 4, wherein the transceiver and the processor are further configured to transmit information along with the packet, wherein the information is regarding use of the updated first-hop delay budget.

6. The WTRU of claim 3, wherein the transceiver and the processor are further configured to transmit the one or more packets using resources selected by the initial first-hop delay budget based on the CBR measurement being greater than the CBR threshold.

7. The WTRU of claim 1, wherein the transceiver and the processor are further configured to determine the updated first hop delay budget based on at least one of the determined second hop delay, the E2E delay, or the default relay delay.

8. The WTRU of claim 1, wherein the indication is an indication of an updated relay delay.

9. A wireless transmit/receive unit (WTRU), the WTRU comprising:

a transceiver; and

the processor may be configured to perform the steps of,

wherein the transceiver and the processor are configured to transmit a first indication to a remote WTRU based on a trigger condition being met, and

wherein the transceiver and the processor are further configured to receive, from the remote WTRU, at least one packet for a second-hop transmission and a second indication of a delay budget for the second-hop transmission based at least in part on the first indication.

10. The WTRU of claim 9, wherein the trigger condition is at least one of: the WTRU receiving an indication from the network; the WTRU receiving an indication from the remote WTRU; buffer status; a load at one or more of the ingress buffer or the egress buffer; a change in configuration at the relay WTRU; a change in configuration at the WTRU; timing information; measurement of the side link; and an expected quality of service.

11. The WTRU of claim 9, wherein the information about the delay budget for the second hop is one of information about use of an updated first-hop delay budget based on the updated relay delay and information about use of an initial first-hop delay budget.

12. The WTRU of claim 9, wherein the transceiver and the processor are further configured to transmit the one or more packets to one of a wireless network or another WTRU.

13. The WTRU of claim 12, wherein the transceiver and the processor are further configured to transmit the one or more packets based at least in part on the second indication.

14. The WTRU of claim 9, wherein the first indication is an indication of an updated relay delay.

15. A method implemented in a wireless transmit/receive unit (WTRU), the method comprising:

receiving a configuration from a wireless network, the configuration indicating an initial first hop delay budget for communications via a relay WTRU;

receiving one or more packets from a higher layer;

receiving an indication from the relay WTRU; and

an updated first-hop delay budget is determined based at least on the received indication.

16. The method of claim 15, wherein the configuration further comprises at least one of a Channel Busy Rate (CBR) threshold, a default relay delay, or an end-to-end (E2E) delay.

17. The method of claim 16, further comprising performing CBR measurements on a resource pool associated with a side link connected to the relay WTRU based on the updated first-hop delay budget being less than the initial first-hop delay budget.

18. The method of claim 17, further comprising transmitting the one or more packets using resources selected by the updated first-hop delay budget based on the CBR measurement being less than or equal to the CBR threshold.

19. The method of claim 18, further comprising transmitting information along with the packet, wherein the information is regarding use of the updated first-hop delay budget.

20. The method of claim 17, further comprising transmitting the one or more packets using resources selected by the initial first-hop delay budget based on the CBR measurement being greater than the CBR threshold.

21. The method of claim 15, wherein the indication is an indication of an updated relay delay.