NR relay method to support reduced waiting time for SL relays

Abstract

A system, method, and device for addressing New Radio (NR) sidelink latency and protocols. A relay wireless transmit / receive unit (WTRU) can be configured to relay information between a remote WTRU and a network. Certain rules, parameters, thresholds, and / or configurations can be used to control and / or reduce latency. In one example, a remote WTRU can send a message to a relay WTRU indicating parameters for relayed data, and the relay WTRU can send a message thereto to the network.

Description

[[Technical Field]]

[0001] (Cross-Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63,061 / 617, filed on August 5, 2020, and U.S. Provisional Patent Application No. 63 / 223,279, filed on July 19, 2021, the contents of which are incorporated herein by reference. [[Background Art]]

[0002] As wireless communication devices become increasingly sophisticated, more use cases have emerged, and higher efficiency for these use cases is required. Specifically, in situations where a first wireless transmit receive unit (WTRU) needs to communicate with a second out-of-range WTRU or a network, it may be beneficial to be able to relay information using a relay WTRU. How this relaying is performed presents a need for techniques that are novel and / or can improve over known techniques. [[Summary of the Invention]]

[0003] Disclosed are systems, methods and devices for addressing new radio (NR) sidelink latency and protocols. A relay wireless transmit receive unit (WTRU) may be configured to relay information between a remote WTRU and a network. Latency may be controlled and / or reduced using certain rules, parameters, thresholds, and / or configurations. In one example, a remote WTRU may send a message indicating parameters for relayed data to a relay WTRU, and the relay WTRU may send a message related thereto to the network. [[Brief Description of the Drawings]]

[0004] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein like reference numerals indicate like elements. [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1E] This is a system diagram showing an exemplary relay communication system in which one or more disclosed embodiments may be implemented. [Figure 2] This is a diagram illustrating an exemplary user-plane radio protocol stack for a Layer 2 evolved WTRU-to-NW relay (PC5). [Figure 3] This is a diagram illustrating an exemplary control plane radio protocol stack for a Layer 2 evolved WTRU-to-NW relay (PC5). [Figure 4] This is a diagram illustrating an exemplary process for obtaining a relay grant based on a determined waiting time. [Figure 5] This is an illustrative process flowchart for obtaining a relay grant based on the determined waiting time. [Figure 6] This is an illustrative process flowchart for managing resources for relaying data. [Modes for carrying out the invention]

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

[0006] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Generally speaking, what is disclosed herein may be references to communication and / or connectivity between WTRUs and networks, in which case references to networks are intended to represent any entity communicating on behalf of a network (NW), such as network nodes, base stations, WTRUs acting on behalf of a network (e.g., relays), and / or one or more of any functional entities described herein. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d, all of which may be referred to as stations (STAs), may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronic devices, and devices operating on commercial and / or industrial wireless networks.WTRU102a, 102b, 102c, and 102d can all be referred to as UE for compatibility purposes.

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

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

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

[0010] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a of RAN 104 and WTRU 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish an air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

[0013] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to and from multiple types of base stations (e.g., eNB and gNB).

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

[0015] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106.

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

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

[0018] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may use cellular-based radio technology, and base station 114b, which may use IEEE 802 radio technology.

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

[0020] 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, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0021] The transmit / receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, 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 both RF signals and optical signals. It will be appreciated that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

[0023] 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 capability. Accordingly, the transceiver 120 may include a plurality of transceivers to enable the WTRU 102 to communicate via a plurality of RATs, such as, for example, NR and IEEE 802.11.

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

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

[0026] 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.

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

[0028] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, associated with specific subframes of both UL (for example, for transmission) and DL (for example, for reception) may occur simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (for example, associated with specific subframes of either UL (for example, for transmission) or DL ​​(for example, for reception)).

[0029] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0030] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

[0031] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling, etc., in UL and / or DL. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

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

[0033] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting gateways for specific services during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0034] The SGW164 can be connected to each of the eNode-B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as anchoring the user plane during eNode-B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0035] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0036] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, and 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0037] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface (e.g., temporary or permanent) with a communication network.

[0038] In a typical embodiment, the other network 112 may be a WLAN.

[0039] A WLAN in Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA to a destination outside the BSS may be sent to an AP and then delivered to its respective destination. Traffic between STAs within the BSS may be transmitted, for example, via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

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

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

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

[0044] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. For example, if the primary channel is busy, an STA (which only supports 1MHz operating mode) sending to the AP may consider the entire available frequency band to be busy, even if most of the available frequency band is idle.

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

[0046] Figure 1D is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0047] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 180b may use beamforming to transmit and / or receive signals to gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, and the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0048] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with an expandable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or expandable lengths (e.g., varying numbers of OFDM symbols and / or varying durations of absolute time).

[0049] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

[0050] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slice support, interaction between DC, NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c may communicate with each other via the Xn interface.

[0051] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally, a Data Network (DN)185a, 185b. Although the aforementioned elements are shown as part of CN106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0052] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN104 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may play roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of SMF183a and 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b may provide control plane functionality for switching between RAN104 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0053] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0054] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c within RAN104, thereby providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, and facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of DL packets, and mobility anchoring.

[0055] CN106 can facilitate communication with other networks. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. Furthermore, CN106 may provide WTRU102a, 102b, 102c with access to another network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local DN185a, 185b via UPF184a, 184b through N3 interfaces to UPF184a, 184b and N6 interfaces between UPF184a, 184b and DN185a, 185b.

[0056] In one or more embodiments, techniques for configuring and using relay WTRUs (e.g., for reducing latency) may exist. Figure 1E is a system diagram showing an exemplary relay communication system in which one or more disclosed embodiments may be implemented. The exemplary scenario shown in Figure 1E can implement any of the examples described in the specification. Generally, for any relay system, there are at least three entities involved, namely, a source 191, a relay 192, and a destination 193. Note that the source 191 is remotely controllable from the destination 193, and in some cases, the source or destination may be referred to as the remote entity. The source 191 may communicate with the relay 192 via a first link 194, and the relay 192 may communicate with the destination 193 via a second link 195. While this naming may suggest that the source 191 initiates communication, note that this naming should not be interpreted as limiting, but is for illustrative purposes only, and communication may be initiated by any entity (e.g., relay 192 and / or destination 193). Although not illustrated, there may be two or more relays 192, and they may be represented by relay 192 even when only one entity is shown. Furthermore, any description herein may apply to multiple relays, in which case links will also exist between each hop between each relay / entity. Multiple relays would facilitate communication between source 191 and destination 193. In short, the illustrated links are not intended to limit the embodiments described herein to only one connection or one connection layer to each link, but rather to simply indicate that communication may occur between two entities. As described herein, one link may represent multiple logical links (e.g., SRB, LCH, etc.). As described herein, SRB and LCH may be interchangeable. The source, relay, and / or destination may be any type of entity, such as a WTRU, a network node (e.g., a base station or other functional entity), and / or other entities described herein.In one example, source 192 may be a first remote WTRU that may need to communicate with destination 193. Destination 193 may be a network node or a second remote WTRU. Relay 192 may be used to facilitate communication between source 191 and destination 193 (for example, to bridge distances that may be too far to enable communication, or because such bridging may provide other advantages such as better bandwidth, lower latency, and added security). As described herein, source 191 may be referred to as the first remote WTRU, relay 192 may be referred to as the relay WTRU, and destination 193 may be referred to as the second remote WTRU or network node. Furthermore, peer WTRU may mean a WTRU other than those described (for example, the first remote WTRU may transmit a signal to the peer WTRU, which may be transmitted by the relay WTRU, the second remote WTRU, etc.). Figure 1E illustrates direct communication (e.g., unicast), but the entities described also apply to multicast or groupcast messages, in which case there would be two or more sources 191 and / or two or more destinations 193.

[0057] In view of Figures 1A to 1E and their corresponding descriptions, one or more of the functions described herein may be performed by one or more emulation devices (not shown) with respect to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0059] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0060] In general, with respect to relay techniques such as WTRU-to-Network (WTRU-to-NW) relay, there may be certain capabilities required to ensure that higher-layer QoS requirements (e.g., packet delay bound, PDB) are met on an end-to-end (E2E) basis when transmitting data from a remote WTRU-to-NW through the relay WTRU. Similarly, in WTRU-to-WTRU relay scenarios, the relay WTRU may be required to ensure that E2E QoS requirements are met when relaying data received from the source WTRU to the target WTRU through the relay WTRU.

[0061] Unlike conventional relay nodes and IAB nodes, the relay WTRUs described herein do not perform resource scheduling for the associated remote WTRU / source WTRU and can control the timing for data transmission on the sidelink. The remote WTRU (e.g., in a WTRU-to-NW relay) or source WTRU (e.g., in a WTRU-to-WTRU relay) can operate in either mode 1 (e.g., sidelink resources are scheduled by the network) or mode 2 (e.g., sidelink resources are determined autonomously using a resource (re)selection procedure).

[0062] A relay WTRU may request UL resources for relaying based on data reception on the sidelink. However, in the absence of coordination, UL resources may be provided too early by the network (e.g., before the data becomes available) due to the following reasons. Grant It may be assigned either very late or too late. That is, the reason is that the remote WTRU is unaware of the latency in the relay WTRU (e.g., processing delay, half-duplex), and / or the network is unaware of the transmission time in the remote WTRU and the transmission latency through the sidelink (e.g., number of ReTx).

[0063] Similarly, during DL, the network may not be aware of the transmission latency over the sidelink for sending data to the remote WTRU. When performing WTRU-to-WTRU relay, the source WTRU is unaware of the transmission latency at the second hop between the relay WTRU and the target WTRU, which may result in failure to meet E2E PDB requirements if, after receiving data from the source WTRU, it performs resource (re)selection (e.g., for a relay WTRU operating in mode 2) or requests a resource (for a relay WTRU operating in mode 1).

[0064] Therefore, there is a need for various approaches to address these issues with respect to remote WTRUs and relay WTRUs to ensure that resources in sidelink and Uu interfaces are aligned with appropriate timing offsets so that E2EPDB requirements are met. In one or more embodiments disclosed herein, techniques for satisfying end-to-end PDB requirements in WTRU-to-NW relay paths or WTRU-to-WTRU relay paths are addressed when transmitting data from remote WTRUs and relay WTRUs, along with other relevant details and techniques. In one or more embodiments of these, there will be systems, methods, and devices that target the techniques and methods described herein (for example, to reduce latency in sidelink relays and for other purposes).

[0065] In one or more embodiments, there may be systems, methods, and / or devices to address NR sidelink situations where WTRU-to-NW relays and / or WTRU-to-WTRU relays may exist (for example, based on a PC5 sidelink). Generally, NR sidelinks have focused on supporting V2X-related services. Furthermore, NR sidelinks can support broadcast, groupcast, and unicast communications in both out-of-coverage and in-network coverage scenarios. Therefore, NR sidelink-based relay functionality is required because it can result in coverage expansion and improved power efficiency.

[0066] In WTRU-to-NW coverage extension, the reachability of Uu coverage may require the WTRU to reach a server in the PDN network or within the other WTRU outside of its immediate vicinity (e.g., a predefined area that may relate to its ability to receive / transmit signals). However, current methods for WTRU-to-NW relay may be limited to EUTRA-based technologies and are therefore not applicable to NR-based systems for both NG-RAN and NR-based sidelink communications. Thus, new methods and improvements may be justified.

[0067] In extending WTRU-WTRU coverage, current proximity reachability may be limited to single-hop sidelink links via either EUTRA-based or NR-based sidelink technology. However, these limitations may be insufficient in scenarios where Uu coverage is absent, given the limited single-hop sidelink coverage. Therefore, new techniques and improvements may be justified.

[0068] Consequently, the development and methodology of NR sidelinks are needed to support additional use cases, such as enhanced QoS requirements.

[0069] In addition to the issues described above, techniques for addressing one or more of the following are disclosed herein: namely, relay (re)selection criteria and procedures, relay / remote WTRU authorization, QoS for relay functions, continuity of service, impact on user plane protocol stacks and existing control plane procedures (e.g., connection management of relayed connections). Furthermore, techniques may exist for higher-layer operations of discovery models / procedures for sidelink relays (e.g., assuming no new physical layer channels / signals).

[0070] As described herein, any single-hop scenario described is for illustrative purposes only and is not intended to limit the applicability of the techniques and methods disclosed herein to multi-hop scenarios. All techniques and methods disclosed herein are intended to be applied to single-hop and multi-hop scenarios, where applicable.

[0071] In some scenarios, relaying via ProSeWTRU to NW relay can extend network coverage to out-of-coverage WTRUs and between the WTRU to NW relay by using PC5(D2D). For example, ProSeWTRU to NW relay can provide a general-purpose L3 forwarding function that can relay any type of IP traffic between a remote WTRU and the network (e.g., network nodes, base stations, etc.). One-to-one and one-to-many sidelink communication can be used between a remote WTRU and a ProSeWTRU to NW relay. For both the remote WTRU and the relay WTRU, only single-carrier operation (e.g., public safety ProSe carrier) may be supported (e.g., Uu and PC5 must be the same carrier for the relay / remote WTRU). A remote WTRU may be authorized by a higher layer and may reside within the coverage of a public safety ProSe carrier, or outside the coverage of any supporting carrier, including a public safety ProSe carrier, for WTRU-to-NW relay discovery, (re)selection, and communication. A ProSeWTRU-to-NW relay may always reside within the coverage of EUTRAN.

[0072] In some scenarios, relay selection for WTRU versus NW relays may exist. Specifically, relay selection / re-selection for ProSeWTRU versus NW relays may be performed based on a combination of AS layer quality measurements (e.g., RSRP) and higher layer criteria. This is described in more detail herein.

[0073] A network (e.g., eNB, gNB, base station, network node, functional entity, other WTRU acting as a network) can control whether a WTRU can operate as a ProSeWTRU to NW relay, where ProSeWTRU to NW relay operation can be supported within a cell if the network broadcasts any information associated with ProSeWTRU to NW relay operation, and / or if ProSeWTRU to NW relay is initiated by broadcast signaling, it can perform ProSeWTRU to NW relay discovery while in RRC_IDLE. If ProSeWTRU to NW relay is initiated by dedicated signaling, it can perform relay discovery as long as it is in RRC_CONNECTED.

[0074] In some cases, the network may provide transmission resources for ProSeWTRU vs. NW relay discovery using broadcast signaling for the RRC_IDLE state and dedicated signaling for the RRC_CONNECTED state.

[0075] In some cases, the network can use broadcast signaling to provide receiving resources for ProSeWTRU vs. NW relay discovery.

[0076] In some cases, the network may provide (e.g., via broadcast) minimum and / or maximum Uu link quality (e.g., RSRP) thresholds that a ProSeWTRU to NW relay must adhere to before it can initiate the WTRU to NW relay discovery procedure. In RRC_IDLE, when the network broadcasts the transmit resource pool, the WTRU can use the thresholds to autonomously initiate or terminate the WTRU to NW relay discovery procedure. In RRC_CONNECTED, the WTRU can use the thresholds to determine whether it is a relay WTRU and can instruct the network to initiate ProSeWTRU to NW relay discovery.

[0077] In some cases, if the network does not broadcast a transmit resource pool for ProSe-WTRU to NW relay discovery, the WTRU can respect these broadcasted thresholds and initiate a request for ProSe-WTRU to NW relay discovery resources by dedicated signaling.

[0078] A ProSeWTRU to NW relay performing sidelink communication for ProSeWTRU to NW relay operation may need to be located within RRC_CONNECTED. After receiving a Layer 2 link establishment request or TMGI monitoring request (e.g., a higher layer message) from a remote WTRU, the ProSeWTRU to NW relay can instruct the network that it is a ProSeWTRU to NW relay and intends to perform ProSeWTRU to NW relay sidelink communication. The network can then provide resources for the ProSeWTRU to NW relay communication.

[0079] A remote WTRU can determine when to begin monitoring for ProSeWTRU to NW relay discovery. Depending on the configuration of resources for ProSeWTRU to NW relay discovery, the remote WTRU can send a ProSeWTRU to NW relay discovery request message while in the RRC_IDLE or RRC_CONNECTED state. The network can broadcast a threshold, which is used by the remote WTRU to determine whether it can connect to or communicate with the ProSeWTRU to NW relay WTRU by sending a ProSeWTRU to NW relay discovery request message. An RRC_CONNECTED remote WTRU can use the broadcasted threshold to determine whether it is a remote WTRU and wishes to participate in ProSeWTRU to NW relay discovery and / or communication. For ProSeWTRU to NW relay operation, the network can provide transmitting resources using broadcast or dedicated signaling and provide receiving resources using broadcast signaling. A remote WTRU may stop using ProSeWTRU vs. NW relay discovery and communication resources if the RSRP exceeds the broadcasted threshold.

[0080] In some cases, the exact time it takes for traffic to switch from Uu to PC5, or vice versa, can be measured up to the upper layer.

[0081] A remote WTRU can perform radio measurements on the PC5 interface and use them, along with higher-layer criteria, for ProSeWTRU-to-NW relay selection and reselection. A ProSeWTRU-to-NW relay may be considered suitable with respect to the radio criteria if its PC5 link quality exceeds a configured threshold (e.g., pre-configured or provided by the network). The remote WTRU can select a ProSeWTRU-to-NW relay that meets the higher-layer criteria and has the best PC5 link quality among all suitable ProSeWTRU-to-NW relays.

[0082] A remote WTRU can trigger a ProSeWTRU-to-NW relay reselection when the current PC5 signal strength of the ProSeWTRU-to-NW relay falls below a configured signal strength threshold, and / or when it receives a Layer 2 link release message (e.g., a higher layer message) from the ProSeWTRU-to-NW relay.

[0083] In some specific use cases, WTRU-to-NW relays may exist that use L2-based techniques (e.g., for wearable devices and / or WTRUs). Unlike ProSeWTRU-to-NW relays that use L3 (IP layer) relay techniques, WTRU-to-NW relays for wearables can use L2 relays based on protocol stacks such as those shown in Figures 2 and 3. Figure 2 is a diagram of an exemplary user-plane radio protocol stack for a Layer 2 evolved WTRU-to-NW relay (PC5). Figure 3 is a diagram of a control-plane radio protocol stack for a Layer 2 evolved WTRU-to-Network relay (PC5). For NRs, the protocol stacks in the examples in Figure 2 or 3 may also include an SDAP layer (e.g., above PDCP) present in the remote WTRU and / or gNB.

[0084] In some scenarios, a connection establishment process may exist for unicast links in NRV2X. In relay solutions for LTE, this may be based on a one-to-one communication link established at a higher layer (e.g., the ProSe layer) between two WTRUs (e.g., a remote WTRU and a WTRU-to-NW relay). Such a connection can be transparent to the AS layer and connection management signaling, and the procedure may be performed at a higher layer and carried by the AS layer data channel. Therefore, the AS layer cannot recognize such a one-to-one connection.

[0085] In NR V2X, the AS layer can support unicast link techniques between two WTRUs. Such unicast links may be initiated by a higher layer (for example, in a ProSe one-to-one connection). However, the AS layer can receive notification of the existence of such a unicast link and any data that may be transmitted in a unicast manner between peer WTRUs. With such knowledge, the AS layer can support unicast-specific HARQ feedback, CQI feedback, power control schemes, and / or other related features / functions.

[0086] Unicast links at the AS layer can be supported via PC5-RRC connections. These PC5-RRC connections can be logical connections between a pair of source Layer 2 IDs and destination Layer 2 IDs within the AS. One PC5-RRC connection may correspond to one PC5 unicast link. PC5-RRC signaling can be initiated after the establishment of its corresponding PC5 unicast link. The PC5-RRC connection, its corresponding sidelink SRB, and the sidelink data radio bearer (SLRB) can be released when the PC5 unicast link is released as instructed by a higher layer.

[0087] For each unicast PC5-RRC connection, one sidelink SRB may be used to transmit PC5-S messages before PC5-S security is established. One sidelink SRB may be used to transmit PC5-S messages to establish PC5-S security. One sidelink SRB may be used to transmit protected PC5-S messages after PC5-S security has been established. PC5-RRC signal transmission can be transmitted using one sidelink SRB, and that signal transmission can only be transmitted protected after PC5-S security has been established.

[0088] PC5-RRC signaling may include a sidelink configuration message (RRCReconfigurationSidelink) in which the first WTRU configures the RX-related parameters of each SLRB in the second WTRU. Such a reconfiguration message may configure the parameters of each protocol in the L2 stack (e.g., Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), etc.). The second WTRU may approve or reject such configuration depending on whether its reconfiguration message can support the configuration proposed by the first WTRU.

[0089] In some scenarios, integrated access and backhaul (IAB) systems may have buffer status reporting (BSR), where the IAB can support preemptive BSR status reporting. This BSR procedure can be used to provide serving base stations (e.g., gNBs) with information about the UL data volume within a MAC entity. In the case of IABs, it can also be used by IAB mobile terminals (IAB-MTs) to provide their parent IAB distributed units (IAB-DUs) with information about the amount of data expected to arrive at the IAB node's MT from its child nodes and / or connected WTRUs. This BSR is sometimes referred to as a preemptive BSR.

[0090] For BSRs other than preemptive BSRs, the RRC can configure parameters for controlling the BSR: periodicBSR-Timer, retxBSR-Timer, logicalChannelSR-DelayTimerApplied, logicalChannelSR-DelayTimer, logicalChannelSR-Mask, and / or logicalChannelGroup.

[0091] Each logical channel can be assigned to an LCG using logicalChannelGroup. The maximum number of LCGs can be 8.

[0092] The MAC entity can determine the amount of UL data available to the logical channel by following a data volume calculation procedure.

[0093] Other BSRs besides preemptive BSRs can be triggered when any of the following events occur: UL data becomes available to a MAC entity, where the UL data is for a logical channel belonging to an LCG, and this UL data belongs to a logical channel with a higher priority than any logical channel belonging to any LCG that contains available UL data, or does not belong to any logical channel belonging to an LCG that contains any available UL data; in this case, the BSR may hereafter be called a "regular BSR". When a UL resource is allocated, the number of padding bits is greater than or equal to the size of the Buffer Status Report MAC CE plus its subhead; in this case, the BSR may hereafter be called a "padding BSR". When the retxBSR-Timer expires, at least one of the logical channels belonging to an LCG contains UL data; in this case, the BSR may hereafter be called a "regular BSR". And / or when the periodicBSR-Timer expires, the BSR may hereafter be called a "periodic BSR".

[0094] Note that when a regular BSR triggering an event occurs simultaneously for multiple logical channels, each logical channel can trigger one separate regular BSR.

[0095] If a preemptive BSR is configured, the following events will occur, namely UL Grant In the case of a special case of IAB-MT, a BSR may be triggered if either of the following occurs: a BSR is provided to a child IAB node or WTRU, and / or a BSR is received from a child IAB node or WTRU.

[0096] In some situations, a remote WTRU can send an assisting instruction to a relay WTRU on a sidelink to relay data using packet delay limit (PDB) requirements (e.g., QoS or latency requirements). Specifically, a remote WTRU (configured, for example, using an indirect relay path to another WTRU / network via the relay WTRU) can send a remote WTRU assisting instruction to the relay WTRU. The remote WTRU assisting instruction message indicates the availability of data for transmission at the remote WTRU and triggers the relay WTRU to transmit data upon receiving data from the remote WTRU. address UL / SL resources can be obtained to relay to the remote WTRU. The remote WTRU can send instruction messages before sending data to the relay WTRU to minimize latency at the relay WTRU, as associated with the resource scheduling procedure. For example, when the relay WTRU receives instructions from the remote WTRU, the relay WTRU sends an SR and / or BSR to the network and a UL for sending the data to be relayed. Grant It can receive instructions. When a relay WTRU receives instructions from a remote WTRU, it transitions to an RRC connected state and can then perform resource scheduling procedures, for example, if the relay WTRU is initially in an RRC idle state.

[0097] Regarding the content of remote WTRU support instructions, the remote WTRU may include one or more combinations of the following types of information in the remote WTRU support instructions sent to the relay WTRU: the buffer size of the data volume in the remote WTRU, QoS-related parameters, PDB-related information, timing information for relaying data, and the sidelink / HARQ process or configured Grant The index and / or the cell ID of the network node (for example, a network node can be a gNB if the remote WTRU is within the gNB's coverage).

[0098] Regarding the buffer size or data volume in a remote WTRU, for example, a remote WTRU may, in some cases, specify a data volume in one or more LCHs in the remote WTRU associated with relayed data and / or signal-transmitting radio bearers (DRBs and / or SRBs), where the data volume extends between the remote WTRU and the relay WTRU on the NR SL interface, and between the relay WTRU and the network on the NR Uu interface. In this case, for each LCH having a data PDU in the buffer, the remote WTRU may specify the data volume (e.g., bit size) along with the LCH identifier (ID), the LCG ID, and / or the ID of the data and / or signal-transmitting radio bearer.

[0099] Regarding QoS-related parameters, for example, a remote WTRU can indicate the priority associated with an LCH that has buffered data for transmission via a relay WTRU. This priority may be explicitly indicated in the instruction message or implicitly indicated by specifying the LCH ID or the LCG ID associated with the LCH. The remote WTRU can then identify the priority based, for example, on a mapping between the LCH / LCG IDs and the priorities configured in the relay WTRU.

[0100] Regarding packet delay limit (PDB) related information, for example, this can consist of PDBs associated with any one or more portions of an end-to-end route. A PDB can represent the allocated or remaining delay budget across the sidelink portions of a relayed route. A PDB can represent the total allocated or remaining delay budget across the relayed route as a whole (e.g., to a network or destination WTRU). For example, a remote WTRU can indicate the expected remaining time available for the relay WTRU to perform resource scheduling and data transmission at the UL. This expected remaining time can be determined, for example, by subtracting the expected delay due to (re)transmission from the E2E PDB to the sidelink.

[0101] Regarding timing information for relaying data, for example, a remote WTRU may indicate the expected latency or duration for which data is expected to be reliably received by the relay WTRU or transmitted by the remote WTRU. The expected duration may be determined based, for example, on the sidelink channel status / quality (e.g., CBR, CR, SL-CSI) and / or the expected number of HARQ retransmissions performed on the sidelink. The expected duration may also be determined based on the results of resource selection by the remote WTRU. The expected duration may also be determined based on scheduling information received from the network (e.g., in DCI).

[0102] Sidelink / HARQ process or configured Grant Regarding the index, for example, the support instructions sent to the relay WTRU are for a specific (e.g., possibly periodic) sidelink process, or a sidelink configured Grant This can represent an instance of and this support information is configured via side links. Grant The timing / offset and / or periodicity can be specified.

[0103] For example, a remote WTRU assistance instruction sent to a relay WTRU before transmitting data on a sidelink may only indicate the availability of data at the remote WTRU to be transmitted at the UL. Based on receiving the instruction, the relay WTRU can determine when to request UL resources by sending a relay WTRU assistance instruction (e.g., an RRC message such as SR, BSR, preemptive BSR, or UEAssistanceInformation) to the network, taking into account the expected delay on the sidelink for receiving data from the remote WTRU.

[0104] In another example, a remote WTRU may include timing information (e.g., a remote WTRU support instruction) in its remote WTRU support instruction, in addition to data availability information, to trigger a UL resource request message in the relay WTRU. In this example, the remote WTRU may send the remote WTRU support instruction along with the expected latency or duration to ensure the data is received by the relay WTRU. The remote WTRU may determine what timing information should be included in the remote WTRU support instruction based on one or more of the following: sidelink delay, delay instruction from the relay WTRU, and / or QoS status instruction from a higher layer.

[0105] In the case of sidelink delay, the remote WTRU can determine the delay on the sidelink as a function of the expected number of HARQ retransmissions and / or the sidelink channel status / quality. The sidelink channel status (e.g., SL-RSRP, CBR) may be determined based on either CSI feedback provided by the relay WTRU or sensing at the remote WTRU. The delay on the sidelink may also be determined based on the sensing results and / or the resources selected for transmission by the remote WTRU.

[0106] Regarding delay instructions from a relay WTRU, a remote WTRU may be configured to receive either periodic or event-triggered instructions from the relay WTRU regarding the status of transmit latency for one or more LCHs on the Uu interface to the network associated with the remote WTRU. Alternatively, the instructions transmitted by the relay WTRU may be flow control messages indicating either the interruption / resumption status of data transmission on the sidelink or the rate at which data may be transmitted by the remote WTRU. In this case, the latency status in the Uu interface or flow control message can be used, for example, by the remote WTRU to estimate timing information that should be included in the remote WTRU support instructions.

[0107] Regarding instructions for QoS status from higher layers (e.g., a remote WTRU), the remote WTRU can determine timing information based on monitoring the end-to-end (e.g., higher layer) QoS status between the remote WTRU and the network. The higher layer QoS status associated with the PDB may be provided to the remote WTRU by the network in NAS messages, either periodically or based on an event trigger (e.g., when the PDB exceeds a certain threshold). In this case, the QoS status can be used by the remote WTRU to either reduce the duration instructed to the relay WTRU when the end-to-end PDB increases above a threshold, or increase the duration when the end-to-end PDB decreases below another threshold.

[0108] A remote WTRU can send instructions to a relay WTRU in one or more of the following: namely, SCI, SL MAC CE, PC5-RRC, and / or data payload.

[0109] In the case of SCI, for example, an instruction may be transmitted in the Stage 1 SCI or Stage 2 SCI of a PSCCH. The SCI may be transmitted as a standalone transmission consisting only of Stage 1 and / or Stage 2 SCIs, or in conjunction with a PSCCH data transmission. An instruction in the SCI may be used, for example, to trigger a relay WTRU-assisted instruction (e.g., SR, BSR, preemptive BSR) in a relay WTRU for data having one or more fixed data volumes / sizes.

[0110] In the case of SL MAC CE, for example, an instruction transmitted by SL MAC CE may include bitmaps corresponding to one or more of the following information elements: namely, the data volume / buffer size of the exit LCH configured with relayed radio bearers, timing information for triggering relay WTRU-assisted instructions, and the remaining PDBs. One or more different information elements may be transmitted by a single SL MAC CE or by different SL MAC CEs. When information elements in an instruction are transmitted by one or more MAC CEs, they may be identified using a new LCID included in the SL MAC CE header.

[0111] In the case of PC5-RRC, the instruction may be sent to the relay WTRU as a PC5-RRC message in the configured SL-SRB, including, for example, information related to data volume and / or timing information.

[0112] In the case of a data payload, instructions may be sent to the relay WTRU in the data payload. The (small) data payload may be appended to, for example, an ongoing sidelink data transmission, or a new sidelink data transmission may be used.

[0113] Resources for sending remote WTRU support instructions in a sidelink can be determined using one or more techniques, one or more of which may be based on one or more of the following: resources configured to operate in mode 2, random selection from a configured resource pool, semi-persistent or periodic resources, scheduling requests, and / or dedicated resources in the sidelink.

[0114] For resources configured for operation in Mode 2, the remote WTRU can select a resource to send instructions based on its perception of one or more resource pools configured for operation in Mode 2. In this case, if the WTRU is initially operating in Mode 1, for example, the WTRU can either transition to operation in Mode 2 when selecting a resource, or operate in Mode 1 and Mode 2 simultaneously. Similarly, a WTRU operating in Mode 2 can either use a resource selected for a different sidelink data transmission process, or trigger a resource reselection to select a resource to send instructions. To ensure that a relay WTRU can receive instructions sent using resources from a resource pool configured for operation in Mode 2, the remote WTRU can perform resource selection based on its perception of the timing associated with relay WTRU reception and the resource pool monitored by the relay WTRU for reception. Perception of relay WTRU behavior associated with reception may be acquired by the remote WTRU during link / SLRB establishment and / or (re)configuration.

[0115] In the case of random selection from configured resource pools, a remote WTRU can determine a resource by randomly selecting a resource from one or more configured resource pools. The resource pool used to perform the random selection may, for example, be associated with mode 2 operation. The remote WTRU can perform random selection from a subset or bandwidth portion consisting of a limited number of subchannels / PRBs within a resource pool, in which case the subset / bandwidth portion is known to both the remote WTRU and the relay WTRU and may be configured (for example, by the network or WTRU) for sending instructions. In this case, the relay WTRU can identify instructions sent by the remote WTRU based on the receipt of instructions using resources corresponding to the configured subset / bandwidth portion within the resource pool.

[0116] For semi-persistent or periodic resources, the remote WTRU is configured to send instructions to the relay WTRU. Grant You can use the semi-permanent or periodic resources provided in this configuration. Grant Based on WTRU support information provided to the network by the remote WTRU, for a remote WTRU operating in Mode 1, the network may provide, for example, WTRU support information that may include the payload size and periodicity information of the remote WTRU support instruction message. A remote WTRU operating in Mode 2 can perform resource selection to reserve periodic resources for sending instructions to the relay WTRU. For example, the remote WTRU may use periodic resources dedicated solely to sending instruction messages, or it may use periodic resources acquired to send data to the relay WTRU if the resources are available to accommodate instructions. Grant Using periodic resources, based on instructions received from the remote WTRU, the relay WTRU is also triggered and configured on the Uu interface. GrantA WTRU support information message can be sent to the network in the RRC to request a periodic resource in and / or to match that resource with a periodic resource used by a remote WTRU on the sidelink. In this case, the relay WTRU will request a periodic resource (e.g., configured) on the sidelink and Uu interface. Grant When aligning the WTRUs, the WTRU support information can specify an offset value associated with delays (e.g., due to processing) in the relay WTRU. In one example, when a relay WTRU receives remote WTRU support information, it can do one of the following: they configure the current UL based on the periodicity / size / timing information received in the remote WTRU support information. Grant The periodicity of, and / or Grant To determine whether the size and / or timing need to be changed, the current UL configured Grant When it is determined that there is a need to change the periodicity / size / timing of the WTRU, the new preferred periodicity / Grant The ability to determine size / offset and / or transmit WTRU support information to the network, UL configured Grant This means requesting a reconstruction of the system.

[0117] In the case of a scheduling request (SR), a remote WTRU operating in mode 1 can trigger an SR when data for relay arrives in the buffer, requesting resources to send an instruction. The triggered SR may be either a regular SR used to request resources to send a BSR, or a dedicated / unique SR used solely to request resources to send an instruction on a sidelink. In the case of a regular SR, the trigger conditions applied by the remote WTRU may correspond to, for example, the arrival of data for relay in the buffer and the unavailability of resources to send an instruction on a sidelink. In the case of a dedicated SR, the remote WTRU may use resources from a configured resource pool or bandwidth portion to send the SR, and these resources may be restricted to, for example, certain types of messages, including remote WTRU-assisted instructions.

[0118] In the case of dedicated resources in a sidelink, the remote WTRU may use one or more resources from a specific area in a configured resource pool or bandwidth portion that may be dedicated to sending instructions. In another example, dedicated resources may be accessible using a dedicated PHY channel such as PSFCH, PSCCH, or PSSCH. Identifiers for instructions may be explicitly or implicitly indicated, for example, based on the use of dedicated resources known to both the remote WTRU and the relay WTRU. In this case, the relay WTRU may be able to identify the received instructions based on filtering resources within a known area in the configured resource pool / bandwidth portion. A configured resource pool that may be an exceptional pool for the remote WTRU may be configured (pre-configured) in the remote WTRU, for example.

[0119] Remote WTRU support instructions may be sent to the relay WTRU due to one or more of the following trigger conditions: data arrival in the buffer, timer, instructions from the relay WTRU, instructions from a higher layer (e.g., NAS), sidelink status / quality value or change thereof, any periodicity of periodic data transmission in the remote WTRU, offset, required Grant These include changes in size, timing information of transmitted data and / or one or more criteria associated with the PDB, and / or the receipt of HARQ feedback.

[0120] Regarding the trigger conditions for data arrival in a buffer, a remote WTRU can generate and transmit instructions when data from a higher layer arrives at an LCH configured for a relayed radio bearer in a sidelink. If the remote WTRU is configured for multiple LCHs for a relayed radio bearer, instructions may be triggered when data arrives at any of the LCHs, or when data arrives at an LCH that may have a higher priority than another lower-priority LCH that may have previously triggered an instruction. To minimize trigger events associated with generating and transmitting instructions, a relay WTRU may be configured for one or more criteria, in which case instructions may only be triggered and transmitted for specific LCHs (e.g., URLLCs) with a priority equal to or greater than a configured priority threshold, or for LCHs configured to allow such instructions to be triggered.

[0121] Regarding timer trigger conditions, instructions may, in some cases, be triggered in a remote WTRU based on a timer associated with delay processing in the relay WTRU. A timer can be used to ensure that instructions are sent in a manner that coincides with the time required to trigger a relay WTRU-assisted instruction (e.g., SR, preemptive BSR) in the relay WTRU. In this case, the remote WTRU may set a timer when data arrives at an LCH configured for a relayed radio bearer, and when the timer expires, the remote WTRU may, for example, send an instruction to the relay WTRU. The timer duration may be set, for example, based on configuration information provided by the relay WTRU or network when configuring the LCH or radio bearer. In another example, the timer duration may be determined by the remote WTRU based on dynamic instructions provided by the relay WTRU, resulting from an increase / decrease in the associated latency of processing and / or load in the relay WTRU.

[0122] Regarding the trigger conditions for instructions from a relay WTRU, a relay WTRU can send instructions that are triggered by changes in traffic load levels and / or congestion conditions at the relay WTRU. For example, a relay WTRU can send load / congestion information only to LCHs that may have an assigned priority value, which may be equal to or greater than the priority level assigned to the LCH associated with the remote WTRU. In this case, the relay WTRU can instruct the remote WTRU when the load / congestion of the LCH exceeds a certain threshold, which may be, for example, a function of the E2E PDB associated with the data at the remote WTRU.

[0123] With respect to trigger conditions for instructions from one or more higher layers (e.g., NAS), instructions may be triggered at the relay WTRU and sent to the remote WTRU based on decisions made at one or more higher layers in the relay WTRU, in which case those decisions may be associated with changes in latency. The higher layers of the relay WTRU (e.g., NAS layer, application layer, etc.) can monitor end-to-end latency and trigger instructions to the remote WTRU if latency increases. Based on instructions from the relay WTRU, the remote WTRU may, for example, generate and send instructions to the relay WTRU to minimize latency associated with resource scheduling and / or triggering relay WTRU support instructions.

[0124] In scenarios where a remote WTRU determines and includes timing information related to latency on the sidelink with respect to sidelink status / quality values ​​or trigger conditions associated with changes therein, the remote WTRU can send instructions to the relay WTRU based on monitoring and / or performing sidelink channel status / quality measurements (e.g., CBR and / or SL-RSRP measurements). Changes in sidelink channel measurements can be used to estimate expected latency associated with data (re)transmission on the sidelink to the relay WTRU. For example, if the sidelink channel status improves / deteriorates (e.g., CBR / SL-RSRP increases above or below a threshold), the remote WTRU can estimate this change as an increase / decrease in latency on the sidelink and trigger a remote WTRU-assisted instruction to inform the relay WTRU of the updated timing information. For example, the remote WTRU may be configured to send instructions when some quality measure (e.g., CBR) exceeds / falls a threshold.

[0125] Periodicity, offset, and required data transmission in remote WTRUs GrantA remote WTRU can trigger a remote WTRU support instruction based on trigger conditions for changes in one or more factors, such as size. This trigger may be based, for example, on changes in the timing / offset of periodic transmissions to the relay WTRU by some (pre-configured) amount.

[0126] Regarding trigger conditions based on one or more criteria associated with the timing information / PDB of the transmitted data, for example, a remote WTRU may send a remote WTRU support instruction if the remaining PDB transmissions of a sidelink transmission fall below a threshold, or if the sidelink transmission timing exceeds a configured first PDB (e.g., a threshold PDB for triggering the instruction). Specifically, a WTRU may be configured with a first sidelink PDB, and preferably can transmit sidelink messages in the first sidelink PDB. If transmission within the first sidelink PDB is not possible (e.g., due to resource selection and / or network scheduling limitations), the WTRU may send a remote WTRU support instruction message, after the first PDB, but in a second PDB. For example, a WTRU may send an instruction if one or more of its selected transmit / retransmit resources do not meet the configured PDB requirements.

[0127] Regarding trigger conditions based on the reception of HARQ feedback, a remote WTRU may send an instruction if it receives a HARQ NACK or DTX for the transmission of one or more data packets.

[0128] In some situations, a remote WTRU operating in Mode 1 can trigger the transmission of a remote WTRU support instruction. Specifically, a remote WTRU operating in Mode 1 can send a remote WTRU support instruction to a relay WTRU after sending an SL-SR and / or SL-BSR to the network to request sidelink resources.

[0129] In one example where a remote WTRU support instruction can include timing information related to expected latency on the sidelink, the instruction may include information after the SL-SR and / or SL-BSR have been sent to the network, and / or the sidelink resources Grant It may be triggered before it receives the signal. The relay WTRU can use the expected latency information in the instruction to determine, for example, the timing information to be included in the relay WTRU support instruction sent to the network.

[0130] In another example where the instruction cannot include timing support information, the instruction may be triggered after the SL-SR and / or SL-BSR have been sent to the network, and / or at a trigger time instance determined based on the recognition of different factors including the E2E PDB, expected latency in the sidelink, and / or processing latency in the relay WTRU. In this case, to ensure that the relay WTRU does not trigger the remote WTRU support instruction (e.g., SR, BSR) too early or too late, the timing for sending the remote WTRU support instruction to the relay WTRU may be aligned, for example, with the timing for the relay WTRU to send the relay WTRU support instruction to the network.

[0131] In one example, a remote WTRU sends WTRU assistance information (e.g., UEAssistanceInformation) to the network to configure sidelinks. Grant After realignment, or from the network, sidelink configured Grant After receiving the (re)configuration, the remote WTRU can send support information. The remote WTRU can send WTRU support information or sidelink configuration. Grant The associated timing information can be included in the remote WTRU support information.

[0132] In some situations, a remote WTRU operating in Mode 2 may trigger the transmission of a remote WTRU support instruction. Specifically, a remote WTRU operating in Mode 2 may initiate a resource (re)selection procedure to determine resources for sidelink data transmission before transmitting a remote WTRU support instruction to a relay WTRU. A resource scheduling instruction may be triggered when the trigger conditions are met (for example, as described herein) and sidelink resources for Mode 2 operation are available to transmit the instruction to the relay WTRU.

[0133] Since the remote WTRU can recognize the E2E PDB requirements for the data, it can set the resource selection window size, consisting of the T1 and T2 parameters, based on the expected time to transmit the data over the sidelink. For example, for a 40ms E2E PDB, the remote WTRU may set T1 to 2ms based on the processing delay at the remote WTRU after sending instructions to the relay WTRU, and T2 to 5ms as the maximum expected time to transmit the data to the relay WTRU over the sidelink. The maximum expected time may consist of one or more transmissions, and if multiple transmissions may occur, those transmissions may include retransmissions resulting from, for example, receiving HARQ feedback from the relay WTRU. In this case, for example, the maximum expected time T2 may be T0+n * It can be estimated as (T1 + T0), where n is the number of retransmissions (e.g., 0 or greater) and T0 is the expected duration per transmission. Based on the selected resources, the remote WTRU can perform data transmission to the relay WTRU within a duration consisting of a minimum time T1 and a maximum time T2.

[0134] When a remote WTRU provides timing information to a relay WTRU in a remote WTRU support instruction, for example, the remote WTRU can specify the maximum expected time (e.g., T2) as timing information.

[0135] In some situations, whether a relay WTRU performs BSR transmission may depend on information in the remote WTRU assistance instructions. Specifically, the relay WTRU may decide whether to transmit buffer status information (e.g., associated with one or more LCHs or LCGs), whether to trigger an SR / BSR, and / or whether to trigger a UEAssistanceInformation based on information in the remote WTRU assistance instructions. Such situations can be motivated in that, for a common gNB, the remote WTRU may have already instructed the gNB of buffer status associated with the data being relayed to the gNB, and as a result, the gNB can similarly schedule the relay WTRU. Upon receiving the assistance instructions, the relay WTRU may decide not to transmit an SR / BSR to the network (e.g., by omitting certain buffer statuses associated with relayed traffic in the BSR) if the relay WTRU determines that the remote WTRU is within the coverage of the same gNB. Otherwise, the relay WTRU may transmit an SR / BSR. Alternatively, the relay WTRU may decide whether to transmit an SR / BSR based on instructions in a remote WTRU support instruction, which may be provided to the remote WTRU by a gNB.

[0136] In one or more embodiments disclosed herein, techniques for reducing latency applicable to relay WTRUs may exist. In some situations, a relay WTRU may send one or more support instructions to perform the transmission of relayed data. A relay WTRU can be triggered to send a relay WTRU support instruction to the network based on a remote WTRU support instruction received from a remote WTRU. A relay WTRU support instruction may be sent to match resources in the sidelink and / or UL so that the transmission of data from the remote WTRU to the network via the relay WTRU can be performed while considering the latency of the sidelink, UL, and / or relay WTRU, while satisfying end-to-end QoS requirements (e.g., PDB). If UL resources (e.g., in UL-SCH) are available and can accommodate the instructions from the relay WTRU (e.g., payload and header), the relay WTRU support instruction may be sent to the network after the LCP-related trigger conditions in the relay WTRU have been met using the available resources. Otherwise, an SR may be sent after the trigger conditions for requesting UL resources to send the relay WTRU support instruction have been met. Similarly, in a WTRU-to-WTRU relay scenario, the relay WTRU can send relay WTRU support instructions to coordinate sidelink resources at the first hop (e.g., between the source WTRU and the relay WTRU) and the second hop (e.g., between the relay WTRU and the target WTRU), and as a result, data transmission from the source WTRU to the target WTRU via the relay WTRU can be performed while considering both sidelink hop and relay WTRU latency, while satisfying end-to-end QoS requirements (e.g., PDB).

[0137] Relay WTRU support instructions may be transmitted in one or more of the following: a UCI of either PUCCH or PUSCH, a control PDU (e.g., the instruction may be transmitted as an RLC control PDU or an adaptation layer control PDU), an RRC (e.g., the instruction may be transmitted as WTRU support information in an RRC message), a data payload (e.g., PUSCH), and / or a UL MAC CE. In the case of a UL MAC CE, the instruction may be transmitted in a UL MAC CE that may contain bitmaps corresponding to one or more information elements (e.g., expected data volume in one or more LCHs associated with a remote WTRU and configured with a DRB, timing information regarding when data in the relay WTRU may be available for UL transmission). Furthermore, one or more different information elements may be transmitted in a single UL MAC CE or in different UL MAC CEs, and one or more information elements in the instruction can be identified with a new LCID included in the UL MAC CE header when transmitted to one or more MAC CEs.

[0138] There may be one or more trigger conditions for sending relay WTRU support instructions, including the following: instructions from the remote WTRU, the priority of the associated LCH, the LCH index, the priority instructed by the remote WTRU, timing information in the remote WTRU support information (e.g., possibly associated with the required or remaining PDBs), and UL in the relay WTRU. Grant Availability or expected availability (e.g., meeting latency requirements / PDBs associated with the timing received in the remote WTRU support instruction, in some cases), and / or trigger time.

[0139] Regarding the trigger conditions for instructions from remote WTRUs, relay WTRU support instructions can be triggered by the receipt of remote WTRU support instructions from a remote WTRU and the availability of UL resources.

[0140] With regard to the priority trigger conditions associated with one or more LCHs, a relay WTRU support instruction may be triggered in the following cases: namely, when the LCG in the relay WTRU's DRB, to which the exit LCH associated with the remote WTRU is mapped, does not have any other associated LCHs that have data or expected data from the relay WTRU or other remote WTRUs, and / or when the priority value of the LCH associated with the remote WTRU is equal to or greater than the highest priority of any other LCH in the LCG that has data for transmission or expected data.

[0141] In one example, one or more LCHs associated with a DRB in a relay WTRU that are associated with data in a buffer may be processed differently from LCHs that have expected data. In this case, the trigger conditions for sending relay WTRU support instructions for LCHs associated with expected data from one or more remote WTRUs may be different from the trigger conditions applied to LCHs that contain regular data in a buffer. In another example, both LCHs associated with expected data and LCHs associated with regular data in a buffer may use the same trigger conditions based on a priority value associated with the LCH, for example.

[0142] Regarding the trigger conditions for LCH indices, the relay WTRU can be configured (in advance) to send relay WTRU support instructions to the network only for specific LCHs.

[0143] Regarding the trigger conditions for priority indicated by a remote WTRU, a relay WTRU-assisted instruction can only be triggered for a specific LCH associated with a remote WTRU that has a priority value equal to or greater than a configured threshold. For other LCHs from the remote WTRU that have a priority value below the configured threshold, the regular BSR trigger condition may apply. The priority value can either be explicitly indicated by the remote WTRU in the remote WTRU-assisted instruction, or it can be implicitly indicated based on the LCH / LCG identifier used in the instruction, which may be configured, for example, using a one-to-one mapping to priority values ​​known to the relay WTRU.

[0144] Regarding the trigger conditions for timing information within remote WTRU support information (for example, it may be associated with some required or remaining PDB in some cases), the relay WTRU can trigger a relay WTRU support instruction for the LCH associated with the remote WTRU when it meets a criterion related to the end-to-end (E2E) PDB between the remote WTRU and the network (e.g., PDCP to PDCP). This criterion can be the sum of the maximum expected latency (L1) resulting from relaying data from the remote WTRU to the relay WTRU and / or the maximum expected latency (L2) in the relay WTRU resulting from processing, the sum of which is greater than or equal to a latency threshold T (e.g., L1 + L2 ≥ T).

[0145] The latency threshold is used for E2E PDB, resource scheduling (e.g., SR / BSR transmission, and UL). GrantThe latency threshold can be determined as a function of the duration associated with the reception of the signal, and / or the duration resulting from data transmission in the UL. The latency threshold can be configured in the relay WTRU (e.g., during the establishment of the relayed route and radio bearer), or determined by the relay WTRU based on the recognition of the E2E PDB, and the duration resulting from data transmission and UL scheduling. The relay WTRU can be configured with thresholds for each LCH or LCG associated with the relay. The relay WTRU can use internal functions / sublayers (e.g., the adaptation layer) to track latency, for example, between the remote WTRU and the relay WTRU, and between the relay WTRU and the network. The expected latency can be determined, for example, from instructions related to timing information received in the remote WTRU support instructions, or based on tracking the transmission time and number of retransmissions in the sidelink from the remote WTRU. In this case, if the latency in the sidelink is expected to increase by a certain threshold from a previously determined value due to, for example, an increase / decrease in sidelink requirements / quality (e.g., SL-RSRP, CBR) and / or an increase in the number of HARQ retransmissions, then a relay WTRU support instruction may be triggered when the above criteria are met. Similarly, a change in processing latency in the relay WTRU by a certain threshold as a result of switching between different TX / Rx modes, including UL receive, UL transmit, sidelink transmit, and / or sidelink receive, and / or a change in load in the relay WTRU by a certain threshold due to possible Tx / Rx from several remote WTRUs with higher priority, may result in the above criteria being met and triggering the transmission of a relay WTRU support instruction. In a WTRU-to-WTRU relay scenario, the processing latency in the relay WTRU may also include the expected transmit latency to the target WTRU due to the sidelink requirements / congestion of the second hop (e.g., CBR, SL-RSRP, SL-CSI).In another example, when the above criteria are met, the relay WTRU may change the priority values ​​assigned to the LCH associated with the remote WTRU, as well as one or more other LCHs associated with the LCG configured in the DRB, to ensure that the relay WTRU support instruction is not delayed. For example, to trigger a relay WTRU support instruction, the relay WTRU may increase the priority value assigned to the LCH associated with the remote WTRU, while in some cases, it may decrease the priority values ​​assigned to other LCHs when the above criteria are met. If the above criteria are not met, the relay WTRU may, based on a (pre-configured) mapping between one or more SR configurations and different timing information, use a selected SR configuration associated with the timing information to send an SR to the network to request resources, or send an instruction to an incapable remote WTRU to satisfy the E2E PDB.

[0146] UL in Relay WTRU Grant Regarding the availability or expected availability trigger conditions (e.g., meeting latency requirements / PDBs associated with the timing received in a remote WTRU support instruction), the relay WTRU support instruction may have a lower priority than the priority assigned to the LCH associated with the remote WTRU, for data in other LCHs. Grant It may be sent based on its expected availability. In this case, UL Grant If it is expected that the available UL will be available due to a BSR trigger on another LCH, and the data on the other LCH may be delayed without violating their respective PDB requirements, the relay WTRU will be available. Grant This allows you to transmit data received from the relay WTRU. Relay WTRU support information includes, for example, expected UL. GrantIt may only be transmitted when it is unable to accommodate data from the remote WTRU. For example, the relay WTRU may meet specific timing requirements determined based on the timing information received in the remote WTRU support instruction. Grant If it does not have, it can trigger the transmission of a relay WTRU support instruction (e.g., SR). For example, the relay WTRU may, based on the timing or other information in the remote WTRU support instruction (e.g., remaining PDBs, priority, etc.), trigger the required UL. Grant The timing can be determined. UL satisfies this timing when relay WTRU Grant If it is determined that it does not have the necessary information, the relay WTRU may trigger the transmission of a relay WTRU support instruction to the network. The relay WTRU then uses the delay-related information in the relay WTRU to further enable UL Grant It is possible to determine whether the timing requirements are met. For example, relay WTRU is UL Grant If it is too early to receive data on the sidelink, or too late to receive the data that should be received on the sidelink, UL Grant It can be determined that the timing requirements are not met.

[0147] Regarding the trigger conditions for trigger time, the relay WTRU receives a remote WTRU support instruction and performs UL (for example, based on tracking sidelink latency and resource scheduling latency) in response to the trigger conditions. Grant Once the latest time to receive is determined, the relay WTRU can trigger the sending of a relay WTRU support instruction in a time instance that allows the E2E PDB to be satisfied, for example, without including timing information in the relay WTRU support information. In this case, when the relay WTRU receives a remote WTRU support instruction, it sends a remote WTRU support instruction within the E2E PDB limit and UL GrantA timer can be set for the duration of the maximum allowable time for receiving. When the timer expires, the relay WTRU can reset the timer and send out a relay WTRU support instruction to the network. If data from a remote WTRU is available for transmission at the relay WTRU before the timer for sending an advanced BSR instruction expires, the relay WTRU cancels the timer and sends a regular SR and / or BSR to the UL. Grant You can request it.

[0148] Relay WTRU support instructions may include one or more of the following: the expected data volume in the LCH, and / or relay transmission timing information.

[0149] In the case of expected data volumes in an LCH, for example, the expected data volumes may include data volumes available in the LCH configuration that are configured in a path relayed by a remote WTRU and / or instructed by the remote WTRU to the relay WTRU in a remote WTRU support instruction.

[0150] In the case of relay transmission timing information, for example, the timing information may be indicated in the form of a time slot index or a time offset value, and these values ​​may be based on an initial / start time slot value (e.g., slot zero) for a frame consisting of a fixed number of time slots, each having a configured duration. This reference initial time slot may be, for example, the time when the data arrives in the buffer of the remote WTRU, or the time when the remote WTRU support instruction is received at the relay WTRU. Alternatively, the timing information may be indicated, for example, as a duration (e.g., 10ms) relative to the initial / start time slot value, or in the form of a number of time slots. In another example, the timing information may be implicitly indicated by using an LCH / LCG identifier and a configured mapping between the LCH / LCG identifier and the timing information. In this case, in order to transmit the timing information in a remote WTRU support instruction, the relay WTRU may select an LCH / LCG and its associated LCH / LCG identifier from a configuration set of LCH / LCG configurations that can be mapped to different time slot / duration values ​​associated with the timing information. For example, a relay WTRU may be configured using a first LCG and a second LCG, which may be mapped to a first time slot / duration value and a second time slot / duration value, respectively. Then, to indicate the sum of the latency in the sidelink and the latency in the relay WTRU, corresponding to the first time slot / duration, the relay WTRU may select the first LCG and its identifier when sending a relay WTRU support instruction to the network. In the relay WTRU support instruction, the relay WTRU may instruct the network of one or more of the following timing information: the expected time when data will be received from the remote WTRU, the expected time when data will be ready for UL transmission in the relay WTRU, and / or UL Grant This is the desired time slot for using it.

[0151] For example, the expected time for data to be received from the remote WTRU may include the duration for the first transmission and / or one or more retransmissions on the sidelink for the expected transmission from the remote WTRU.

[0152] For example, in the case of the time when the data is expected to be ready for UL transmission at the relay WTRU, the relay WTRU may indicate the earliest and / or latest time slot when the data may be transmitted in UL. In this case, the earliest time slot may be determined as the sum of the maximum expected duration due to sidelink transmission and the expected time due to processing at the relay WTRU for the initial time slot. Similarly, the latest time slot may be determined, for example, by subtracting the maximum latency due to sidelink transmission and processing from the E2E latency for the initial time slot.

[0153] UL Grant For the desired time slot for use, for example, the relay WTRU estimates the duration for receiving data from the remote WTRU on the sidelink and the duration for processing it in the relay WTRU, UL Grant The desired time slot for use can be determined. The duration for receiving and processing can be based, for example, on either the average expected time or the maximum expected time determined from previous transmissions.

[0154] A relay WTRU can implicitly indicate a desired time or period using a time index. Such an index may be explicitly included in the message (e.g., a support instruction) or implicitly indicated by the timing of message transmission, transmission type, or priority / LCG information. For example, a relay WTRU can indicate a desired time or period by selecting one of several SR configurations. The desired time or period is UL Grant You can specify one or more slots that need to be provided. The desired time or period is UL Grant You can specify the minimum or maximum time for receiving. The desired time or period is the current Grant (For example, UL configured Grant ) can be specified as an offset from the current Grant Does it need to be changed, or new Grant This is the offset for which the document needs to be issued.

[0155] There may be one or more procedures for determining timing information related to data in a relay WTRU. These procedures may involve the WTRU determining timing information that should be included in the relay WTRU support instructions. This determination may take into account one or more of the following: the expected latency on the sidelink due to data transmission, the explicit indication of resource timing in the remote WTRU support instructions, and / or processing latency in the relay WTRU.

[0156] Regarding the expected latency on the sidelink due to data transmission, upon receiving a remote WTRU support instruction, the relay WTRU can determine the data transmission latency on the sidelink based on the expected number of transmissions, including retransmissions (e.g., HARQ), that may be performed by the remote WTRU to ensure the data is received at the relay WTRU. The expected number of transmissions may then be determined by the relay WTRU based on, for example, the sidelink channel requirements (e.g., CBR, CR, SL-RSRP) and / or the radio bearer configuration related to the maximum number of HARQ retransmissions configured in the SL-RB between the remote WTRU and the relay WTRU. In another example, the relay WTRU can determine the expected latency based on the L1 link adaptation parameters (e.g., MCS) applied by the remote WTRU to transmit data. In this case, the expected latency may be estimated to be shorter when the remote WTRU applies a higher MCS due to improved sidelink channel quality, and similarly, the expected latency may be longer when the remote WTRU applies a lower MCS.

[0157] With regard to explicit indication of resource timing in remote WTRU support information, a relay WTRU can receive indications of time / frequency resources associated with the first / last transmission of a sidelink transmission, and based on this timing and other factors disclosed herein, it can derive timing information that should be included in the relay WTRU support instruction.

[0158] Regarding processing latency in a relay WTRU, it may be determined by one or more of the following: the number of remote WTRUs handled by the relay WTRU, the CBR / CR, and the sidelink intended for reception in the relay WTRU. GrantThe amount of data to be relayed in the relay WTRU's buffer (e.g., the number of SCIs for periodic data that the relay WTRU is expected to receive on the sidelink and therefore cannot transmit on the UL), and / or the amount of data to be relayed in the relay WTRU's buffer (e.g., associated with a higher priority than indicated by the remote WTRU). For example, processing latency may consist of a first component resulting from the processing of prioritized traffic, and a second component resulting from the switching between the Uu / SL interface and half-duplex Tx / Rx mode. For example, the relay WTRU may determine the first component of processing latency based on the available and expected data in the buffer associated with one or more LCHs from the relay WTRU and other remote WTRUs, etc., whose priority may differ from the priority assigned to the LCH associated with the remote WTRU. The relay WTRU may, for example, send data from the remote WTRU before sending data to the UL Grant The processing latency can be determined based on the expected time to receive the data and transmit data to other higher-priority LCHs. In this case, the relay WTRU can either increase or decrease the priority of a particular LCH, and as a result, the end-to-end PDB of data in all LCHs corresponding to the relay WTRU and all associated remote WTRUs may be satisfied. A second component of the processing latency can be determined, for example, as a function of the number of remote WTRUs served by the relay WTRU and / or the type of resources (e.g., aperiodic, periodic) used by the remote WTRUs for sidelink data transmission.

[0159] In some situations, a WTRU may receive support configuration information to satisfy E2E QoS when relaying data. Specifically, a relay WTRU may receive support configuration information from the network, which includes one or more rules and / or configuration parameters that can be applied by the relay WTRU to satisfy E2E QoS when relaying data received from one or more remote WTRUs. The support configuration information, including rules and / or parameters, may be applicable at the granularity of, for example, per remote WTRU, per radio bearer (e.g., an E2E radio bearer extending from a remote WTRU to a gNB via a relay WTRU), and for one or more logical channels within a radio bearer. In one example, the support configuration information received by the relay WTRU may indicate that a first set of rules / parameters may be applicable when relaying data to and from a first remote WTRU, and a second set of rules / parameters may be applicable when relaying data to and from a second remote WTRU.

[0160] A relay WTRU can receive support configuration information, including rules / parameters, either via a quasi-static configuration or when receiving a configuration associated with one or more radio bearers / logical channels (e.g., on a Uu link and / or PC5 link). In either case, the rules / parameters in the support configuration may be associated with specific identifiers (IDs) or, in some cases, may be received via RRC messages. Alternatively, the relay WTRU may dynamically receive one or more rules / parameters, for example, via MAC CE or DCI. In another alternative example, the relay WTRU may receive support configuration information consisting of one or more rules / parameters as a pre-configuration via RRC messages following dynamic activation / deactivation messages that may be received via MAC CE or DCI, and this support configuration information may include, for example, IDs of specific rules / parameters to be activated / deactivated for use by the relay WTRU. As described herein, the links that travel back and forth to the relay WTRU can be described using the first and second links, and either of these links may be a side link or a link to the network. As described herein, the first and second links may be interchangeable, and the examples provided in the description of these links are intended to be illustrative and not limiting. Furthermore, either the first or second link may be interchangeable with any particular type of link disclosed herein, such as a Uu link, a PC5 side link, or any other type of link. For example, the first link may be a link between the network and a relay WTRU, and the second link may be a side link between the relay WTRU and a remote WTRU.

[0161] A relay WTRU can perform one or more actions, including, for example, sending a relay WTRU support instruction to the network based on whether one or more of the rules and / or parameters specified in the support configuration are met. The support configuration parameters received by the relay WTRU, and the corresponding actions performed based on the satisfaction of one or more of the rules / parameters, may include: rules / parameters related to data rate, rules / parameters related to latency, and / or rules / parameters related to reliability.

[0162] Regarding rules / parameters related to data rates, a relay WTRU may receive one or more rules and / or parameters to ensure that a specific data rate can be achieved over a first link (e.g., a Uu link) when relaying data received from one or more remote WTRUs. The rules / parameters that may be used by a relay WTRU to achieve a specific data rate when relaying, and the corresponding actions performed, may include one or more of the following: namely, data rate matching, data rate compensation, and / or data rate throttling.

[0163] With respect to data rate matching, a relay WTRU may consist of one or more rules / conditions for relaying data, so that, for example, the data rate that can be achieved when relaying data over a first link (e.g., a Uu link) is matched with the data rate that can and / or is expected to be achieved over a second link (e.g., a PC5 side link). In one example, a relay WTRU may receive one or more data rate range parameter values ​​over a second link (e.g., a side link) that indicate upper and / or lower limits of the data rate. In this case, provided that the data rate on the second link is within the range (e.g., upper and / or lower limits) of the received data rate range parameter values, the relay WTRU may perform certain operations to ensure that the data rate that can be achieved over the first link matches, or is within, a similar data rate range when transmitting data to the network (e.g., a base station, gNB, etc.). When the relay WTRU detects that the data rate on the second link is within the data rate range parameters (for example, based on a remote WTRU instruction or measurement / detection of the data rate on the side link), the actions performed by the relay WTRU may include sending a relay WTRU support information instruction to the network and / or, for example, instructing that the condition is met when relaying data received from the remote WTRU on the first link, or using a specific logical channel configuration to match the data rates. When the relay WTRU detects that the condition associated with the data rate on the second link is not met, for example, if the side link data rate is outside the configured data rate range, the relay WTRU may send an instruction to the network indicating that the requirement is not met.

[0164] With respect to data rate compensation, a relay WTRU may be configured, for example, with one or more rules when relaying to ensure data rate compensation, so that the data rate that can be achieved when relaying data over a first link (e.g., a Uu link) is higher than the data rate that can and / or is expected to be achieved over a second link (e.g., a PC5 side link). In one example, the relay WTRU may receive one or more data rate thresholds indicating a lower limit data rate that can or is expected to be achieved over the second link. The relay WTRU may also receive a corresponding mapping to the expected data rate value that should be achieved on the first link for different lower limit data rate values ​​on the second link. Under the condition that the data rate on the second link is less than or equal to the lower limit data rate value, the relay WTRU may perform a specific operation so that the data rate achieved on the first link is at least above the lower limit data rate on the second link and / or increases by a specific value up to the maximum data rate value expected when transmitting over the first link. When a condition associated with the data rate on a second link is detected (for example, based on a remote WTRU instruction or measurement / detection of the data rate on the sidelink), the actions that the relay WTRU may take include, for example, sending a relay WTRU support instruction to the network that instructs the trigger for data rate compensation to increase the data rate to an expected data rate value when relaying data received from the remote WTRU on the first link. When a condition associated with the data rate over the sidelink is detected not to be met, for example, if the sidelink data rate exceeds a configured lower limit data rate, the relay WTRU may send an instruction to the network indicating that the condition is not met.

[0165] With respect to data rate throttling, a relay WTRU may be configured with one or more rules when relaying, so that, for example, to support data rate throttling / reduction, the data rate that can be achieved when relaying data over a first link (e.g., a Uu link) is lower than the data rate that can and / or is expected to be achieved over a second link (e.g., a PC5 side link). In one example, a relay WTRU may receive one or more data rate thresholds indicating a higher limit data rate value that can or is expected to be achieved over the second link. A relay WTRU may also receive a corresponding mapping to the data rate value that is expected to be achieved on the first link for different higher limit data rate values ​​on the second link. Provided that the data rate on the second link is greater than or equal to the higher limit data rate value, the relay WTRU may perform a specific operation so that the data rate achieved over the first link is reduced, for example, to a higher limit data rate on the second link and / or expected to be achieved when transmitting over the first link. When a condition associated with the data rate on the second link is detected (for example, based on a remote WTRU instruction or measurement / detection of data on the sidelink), the actions that the relay WTRU may take include, for example, sending a relay WTRU support instruction to the network that instructs a trigger for data rate throttling to reduce the data rate to an expected data rate value when relaying data received from the remote WTRU via the first link. When a condition associated with the data rate on the second link is detected not to be met, for example, if the second link data rate falls below a configured higher limit data rate, the relay WTRU may send an instruction to the network indicating that the condition is not met.

[0166] Regarding rules / parameters related to latency, for example, a relay WTRU may receive one or more rules and / or parameters to ensure that a specific latency can be achieved over a first link (e.g., a Uu link) when relaying data received from one or more remote WTRUs. The rules / parameters that may be used by the relay WTRU to achieve a specific latency when relaying, and the corresponding actions performed, may include one or more of the following: namely, latency compensation and / or latency threshold T to satisfy the E2E latency.

[0167] With respect to latency compensation, a relay WTRU may be configured using one or more rules when relaying, so that the latency that can be achieved when relaying data over a first link (e.g., a Uu link) is shorter than the latency that is achieved and / or expected to be achieved over a second link (e.g., a PC5 side link) to satisfy, for example, an E2E latency requirement. In one example, the relay WTRU may receive one or more sidelink latency thresholds indicating the latency on the second link. The relay WTRU may also receive a corresponding mapping for different latency thresholds on the second link to the expected latency value to be achieved over the first link. Provided that the latency on the second link is greater than or equal to the latency threshold, the relay WTRU may perform a specific action so that the latency achieved over the first link is reduced by a specific value to the expected latency value when transmitting over the first link. If the relay WTRU detects that the latency on the second link is not met (for example, based on a remote WTRU instruction or measurement / detection of latency on a side link), the actions it may take include, for example, sending a relay WTRU support instruction to the network that instructs a trigger for latency compensation to reduce latency to an expected latency value when relaying data received from the remote WTRU over the first link. Alternatively, another action that the relay WTRU may take may include determining / selecting a logical channel configuration over the first link, which may be configured with one or more parameters related to priority, prioritized bit rate (PBR), bucket size duration (BSD), etc., so that, for example, the latency that can be achieved over the first link can be reduced to an expected latency value.If the latency on the second link falls below the latency threshold, and the relay WTRU detects that the condition associated with the latency on the second link is not met, it may, for example, send an instruction to the network indicating that the condition is not met, or it may not send any instruction and continue to use the existing configuration when relaying.

[0168] With respect to a latency threshold T for satisfying E2E latency, for example, a relay WTRU may receive a latency threshold T to help determine whether and / or when to send relay WTRU support information to the network. In this case, the relay WTRU may send a relay WTRU support instruction to the network when the estimated latency for relaying, determined as a function of one or more component latency values, is greater than or equal to the latency threshold T. For example, the component latency values ​​used by the relay WTRU to determine the estimated latency for relaying may include one or more of the following: the expected latency resulting from relaying data from a remote WTRU to the relay WTRU, the expected latency in the relay WTRU due to processing (e.g., sending data in a buffer), and resource scheduling (e.g., sending SR / BSR / support information, and UL). Grant / configured Grant This is the expected time due to the reception / activation of the WTRU and the expected latency due to the transmission of data in the WTRU. In this case, under conditions associated with the latency threshold T being met and the estimated latency for relaying (e.g., the sum of latency components) being greater than or equal to the latency threshold T, the relay WTRU can, for example, send a relay WTRU support instruction to the network.

[0169] Regarding reliability-related rules / parameters, for example, a relay WTRU may receive one or more rules and / or parameters to ensure that a certain level of reliability can be achieved over a first link (e.g., a Uu link) when relaying data received from one or more remote WTRUs. The rules / parameters that may be used by the relay WTRU to achieve a certain level of reliability when relaying, and the corresponding actions performed, may include reliability alignment.

[0170] With respect to reliability matching, a relay WTRU may be configured with one or more rules / parameters for relaying data, so that the reliability of data transmission that can be achieved when relaying over a first link is consistent with the reliability that can and / or is expected to be achieved over a second link (for example, the Uu link is consistent with the reliability that can and / or is expected to be achieved over a PC5 sidelink). In one example, a relay WTRU may receive one or more reliability range parameter values ​​(e.g., packet error rate, bit error rate, etc.) indicating upper and / or lower limits of the reliability that can and / or is expected to be achieved over a sidelink. In this case, provided that the reliability over the second link is within the received reliability range parameters (e.g., upper and / or lower limits), the relay WTRU may perform certain operations to ensure that the reliability that can be achieved over the first link is consistent with, or within, a similar reliability range when transmitting data over the second link. When the relay WTRU detects that the reliability on the second link is within the range of the reliability range parameter (for example, based on a remote WTRU instruction or measurement / detection of the reliability on the side link), the actions performed by the relay WTRU may include sending a relay WTRU support information instruction to the network, in which case the relay WTRU support information may indicate that the condition is met, for example, by using one or more logical channel configurations or one or more lower-layer configurations (e.g., MCS configuration, number of HARQ retransmissions) to match the reliability when relaying data received from the remote WTRU over the first link. When the relay WTRU detects that the condition associated with the reliability on the second link is not met, it may send an instruction to the network indicating that the condition is not met.

[0171] In some situations, a relay WTRU can change the prioritization of relayed data to satisfy the E2E PDB. Specifically, a relay WTRU can compensate for sidelink latency caused by data transmission from a remote WTRU by dynamically changing the LCH configuration (e.g., priority) in one or more LCH / DRBs configured in the relay WTRU, thereby satisfying the E2E PDB for data associated with the remote WTRU.

[0172] A relay WTRU may be configured with one or more LCHs per DRB, in which case each LCH may be configured with different parameters such as priority, preferred bitrate (PBR), and / or bucket size duration (BSD) to achieve a specific QoS profile (e.g., E2E PDB) when relaying data associated with a remote WTRU. The LCH configuration may further include mapping LCHs to UL LCGs for BSR reporting. The LCH configuration may further instruct routing of SL LCHs to UL LCHs.

[0173] To enable dynamic adaptation of LCH configuration for an LCH associated with a remote WTRU, a relay WTRU may be pre-configured with a plurality of allowed configuration parameters per LCH. Different configurations associated with an LCH may be identified using a configuration identifier / index value together with an LCH ID. Among different configurations, one of the configurations may be designated as a primary / default configuration for the LCH, and one or more other configurations may be designated as secondary configurations for the LCH. For example, a first configuration parameter for an LCH may include a priority level that may be lower / higher than the priority level assigned to a second configuration for the LCH. This priority level may, in turn, correspond to different achievable latencies for a given amount of traffic load (e.g., data in an LCH buffer) when transmitting data in the UL. As an example, for a first LCH configured with a priority level p1 that results in a latency of t1 ms, and for a second LCH configured with a priority level p2 that results in a latency of t2 ms, when p2>p1, the relative latency may result in t2<t1.

[0174] A relay WTRU may be initially configured to activate a first configuration for an LCH associated with a remote WTRU. The relay WTRU may also be configured with rules to activate a second LCH configuration when a latency-related trigger is detected. The first LCH configuration having a priority p1 may, for example, be activated by the network during initial configuration of an end-to-end radio bearer (e.g., between a remote WTRU and a NW). Then, when p2>p1, the relay WTRU may activate the second LCH configuration having a priority p2 when the criteria are satisfied that the E2E latency when using p1 for the LCH associated with the remote WTRU exceeds E2EPDB and / or the E2E latency when using p2 for the LCH associated with the remote WTRU is equal to or less than E2EPDB.

[0175] UL GrantIn scenarios where it is available due to a previous transmission of the BSR, the relay WTRU is available for the remote WTRU (e.g., E2E PDB1). Grant When it may be possible to use, different LCH configurations and priority levels can be applied / activated to LCHs associated with a relay WTRU or other remote WTRU, for example, to lower the priority of UL transmissions without affecting their respective E2E PDBs (e.g., E2E PDB2). In this case, in addition to the above criteria, the relay WTRU can activate a second LCH configuration with priority p2 for the remote WTRU while activating an LCH configuration with priority p4 (e.g., from the previous priority level p3, but p3 > p4), provided that the E2E latency when using p3 for LCHs associated with the relay WTRU and / or other remote WTRUs is less than or equal to E2E PDB2.

[0176] To ensure that both the network and the relay WTRU apply the same configuration to the LCH, the relay WTRU can instruct the network when the LCH configuration is changed in the relay WTRU. For example, when a second configuration is activated for the LCH, and possibly after deactivating the initial first configuration, the relay WTRU can instruct the network of the index associated with the second configuration. The relay WTRU can also instruct changes to the LCH configuration in remote WTRU support information, as an example.

[0177] In some situations, a relay WTRU operating in Mode 1 can receive DL data and sidelink resource scheduling information for a remote WTRU. A relay WTRU operating in SL Mode 1 can receive downlink data from the network for a remote WTRU and relay the data to the remote WTRU in an associated sidelink transmission scheduled by the same network node (e.g., gNB). To perform such relay transmissions, a relay WTRU can receive one or more of the following: downlink relay data for the remote WTRU in an NR PSSCH and associated PSCCH transmission, and / or sidelink resource scheduling information for an associated sidelink transmission in an NR PSCCH transmission. A relay WTRU can receive such data and information listed below in two consecutive DL transmissions having a DL DCI in one transmission and an SL DCI in the other, and / or in a single DL transmission having a DL DCI that includes both DL scheduling information and sidelink scheduling information.

[0178] In one case where a relay WTRU receives information in two consecutive DL transmissions having a DL DCI in one transmission and an SL DCI in the other, the relay WTRU can use its assigned C-RNTI or CS-RNTI to decode the downlink control information (DCI) format in the NR PDCCH (e.g., DCI1_1 or DCI1_0) in the (pre-configured) NR PDCCH lookup space / CORESET for downlink data scheduling information. Based on the decoded DCI, the relay WTRU can decode the associated NR PDSCH which may contain downlink relay data.

[0179] The relay WTRU can determine that the received downlink data can be relayed to a remote WTRU based on higher-layer configurations such as LCH identification information and / or sidelink destination ID information. The relay WTRU can store the received downlink relay data in an SL HARQ buffer and transmit the sidelink to the remote WTRU. The relay WTRU can then use SL-RNTI or SL-CS-RNTI to decode the DCI in the NR PDCCH, such as DCI3_0 in the (pre-configured) NR PDCCH lookup space / CORESET for sidelink scheduling information. The network then allows the relay WTRU to relay the received downlink relay data to the sidelink. Grant Sidelinks can be used to recognize that they may be needed. Grant Such sidelink scheduling information can be sent to the relay WTRU without receiving an SR / BSR for the request. The relay WTRU then sends the received DL data for the remote WTRU to the sidelink. Grant In connection with this, based on the sidelink scheduling information included in the received DCI3_0 transmission, the received DL data can be transmitted to the remote WTRU in the PSSCH transmission.

[0180] In one case where a relay WTRU receives information in a DL transmission that has a DL DCI containing both DL scheduling information and sidelink scheduling information, the relay WTRU may be (pre-configured) using a relay DCI having a format that can include both downlink scheduling information for an NR PDSCH transmission carrying downlink relay data and sidelink scheduling information for a subsequent SL PSSCH transmission to a remote WTRU. A relay DCI format such as DCI1_X (where x is just a placeholder for any number) can include information from DCI1_1 / DCI1_0 and / or DCI3_0. For example, DCI1_1 / DCI1_0 may be used for scheduling PDSCH in one cell, and DCI3_0 may be used for scheduling NR sidelinks in one cell. In one example, zero-padding can be included in DCI1_1 / DCI1_0 to ensure that all DCI formats are of equal size. The size of the DCI format can be minimized by reducing this zero-padding and introducing (pre-configured) associations between DL resources and sidelink resources. This association may include one or more of the following: an association between a designated DL carrier and / or BWP and a sidelink resource pool; an association between a designated DL frequency resource and a sidelink frequency resource; an association between a designated DL HARQ process number (HPN) and an SL HPN; and / or an association between a designated DL downlink assignment index (DAI) and an SL sidelink assignment index (SAI).

[0181] With regard to the association between the designated DL carrier and / or BWP and the sidelink resource pool, the WTRU can determine the sidelink resource pool for sidelink relay transmission based on the DL carrier and / or BWP included in DCI1_X, without additional DCI instructions for the sidelink resource pool.

[0182] With regard to the association between an indicated DL frequency resource (e.g., the start PRB block of the DL PSSCH) and a sidelink frequency resource (e.g., the index of the lowest sidelink subchannel), the WTRU can determine the start sidelink subchannel index based on the decoded start PSSCH PRB, for example, without additional DCI indication for the start sidelink subchannel index.

[0183] Regarding the association between the indicated DL HPN and SL HPN, the WTRU can determine the SL HPN based on the DL HPN indicated in DCI1_X without any additional DCI indication for the SL HPN.

[0184] Regarding the association between the indicated DL DAI and SL SAI, the WTRU can determine the SL SAI based on the DL DAI and DCI format (for example, a DL DAI in relay DCI format can also be counted as an SL DAI).

[0185] Generally, DCI formats can be distinguished from each other using DCI format identifiers. Furthermore, relay WTRUs can be (pre-configured) using identifiers (e.g., C-relay-RNTI and / or SL-relay-CS-RNTI) to descramble relay-specific DCI1_X formats. Relay WTRUs can decode relay downlink DCI formats within NR PDCCHs in (pre-configured) NR PDCCH search spaces / CORESETs using identifiers (e.g., C-RNTI, C-CS-RNTI, or C-relay-RNTI). In one example, a candidate DCI format associated with one or more such (pre-configured) search spaces / CORESETs may include sidelink relay data. In another example, such a candidate DCI format may include DCI formats for both DL data and sidelink relay data (e.g., a relay WTRU can distinguish DCI formats for sidelink relay data scheduling based on DCI format identifiers and / or descrambled RNTI). Based on the decoded DL data scheduling information contained in the relay DCI (e.g., DCI1_X format), the relay WTRU can decode the associated NR PDSCH which can contain downlink relay data and store the received downlink data in a sidelink HARQ buffer for sidelink relay transmission. Thus, the relay WTRU can transmit the received relay downlink data over the sidelink based on the sidelink scheduling information contained in the same relay DCI transmission. In some cases, the technique of using a single DL transmission that includes both DL DCI containing both DL scheduling information and sidelink scheduling information can thus reduce latency caused by processes such as the WTRU requesting and receiving sidelink resources for relay transmission.

[0186] In some situations, a relay WTRU can determine whether to send buffer status to the network based on the reception of DL LCH and / or DL ​​DCI. The WTRU can avoid reporting sidelink buffer status to the network and / or triggering a BSR when receiving data on an SL LCH, provided the data is associated with a relayed LCH from the network. Specifically, the WTRU can only report sidelink buffer status associated with SL LCHs that are not relayed or mapped to DL LCHs that should be relayed on the sidelink. Alternatively, the WTRU can calculate the amount of data on the SL LCH associated with the relayed data and subtract the buffer status associated with that SL LCH or LCG corresponding to the buffered data from the total amount of data before reporting the buffer status associated with that SL LCH or LCG. Alternatively, the WTRU can only trigger an SL BSR if the data arriving at the SL LCH is not associated with data being relayed from a DL LCH.

[0187] The WTRU may also have the aforementioned behavior associated with reporting the buffer status of the SL LCH based on instructions from the network (for example, in the DL DCI where the relayed data is received). For example, the WTRU may exclude the buffer status associated with the SL LCH if the DL DCI includes instructions for its effect and the WTRU receives data on the DL LCH that should be relayed on the sidelink.

[0188] In some situations, a relay WTRU operating in Mode 2 can trigger resource selection based on initialization instructions received at the DL. A relay WTRU operating in Mode 2 can determine the resource (re)selection window size and / or trigger sensing, and / or pre-selection of resources in order to relay DL data to a remote WTRU, based on resource re-selection initialization instructions received from the network. Because a relay WTRU operating in Mode 2 autonomously determines sidelink resources, pre-selecting resource re-selection can minimize the latency associated with resource determination and sending data to the remote WTRU on the sidelink, and may also meet the E2E PDB requirements at the DL.

[0189] A relay WTRU may receive resource reselection initialization (RRI) instructions from the network in one or more of the following: namely, DCIs in a PDCCH (e.g., the DCI may further include priority instructions or timing information, from which the WTRU may introduce parameters for resource selection), DL MAC CEs (e.g., a DL MAC CE containing an RRI instruction may be transmitted using a new / dedicated LCID in the header), RRC signaling (e.g., an RRC message containing an RRI instruction may be transmitted as either a configuration message or a single-shot control transmission message), and / or DL ​​control PDUs (e.g., an RRI instruction may be transmitted as an RLC control PDU).

[0190] One or more trigger conditions may exist for a relay WTRU to initiate resource (re)selection. A relay WTRU can perform resource (re)selection to determine a sidelink resource if it receives an RRI instruction and / or if the resource selection criteria are met. For example, resource selection criteria may trigger resource selection when one or more of the following conditions are met: the relay WTRU has no available resources, and / or the relay WTRU has available resources, but such resources cannot accommodate the expected data or the required latency associated with that data.

[0191] For example, if a resource or required latency cannot be accommodated, the priority of the expected data (indicated, for example, in the RRI instruction) may be higher than the priority of the available resources, or its priority may be associated with a latency shorter than the latency associated with the available resources. Alternatively, in the same case where a resource or required latency cannot be accommodated, there may be a mismatch between the size and / or transmission timing (e.g., time slot, periodicity) associated with the expected data and the size and / or timing of the available resources. Then, based on the sidelink resources determined using the information received in the RRI instruction, the relay WTRU can relay the data PDU received at the DL to the remote WTRU.

[0192] Regarding the content of a Resource Reselection Initialization (RRI) instruction received by a relay WTRU, an RRI instruction may be received by the relay WTRU whenever there is a data PDU to be relayed to the remote WTRU, or as a single-shot trigger message to initiate the transmission of multiple data PDUs (e.g., periodic data). An RRI instruction may contain one or more of the following informational elements: the data volume of the data for the remote WTRU, the priority of the DL data to be relayed, PDB-related information, timing information for resource (re)selection, and / or timing information for aligning periodic resources.

[0193] For data volumes destined for remote WTRUs, a relay WTRU may be indicated by the expected data volume in one or more LCHs associated with relayed radio bearers connecting the remote WTRUs and the network via the relay WTRU. For each LCH with data in a buffer, the relay WTRU may be indicated by the data volume (e.g., bit size) and / or identifiers (e.g., LCH identifier (ID), LCG ID, and / or radio bearer ID). For relay WTRUs associated with multiple remote WTRUs, the RRI indication may also indicate data availability for one or more remote WTRUs by including the remote WTRU identifiers (e.g., RNTI) within the same RRI indication.

[0194] Regarding the priority of DL data to be relayed, the relay WTRU may be indicated using the priority associated with the LCH that has data in the buffer for DL ​​transmission through the relay WTRU. The priority may be explicitly indicated in the RRI instruction, or implicitly indicated by the LCH identifier / ID, or the LCG ID associated with the LCH. The relay WTRU can then identify the priority, for example, based on a mapping between the LCH / LCG ID and the priority configured in the relay WTRU. In another example, the priority indicated in the RRI instruction may be associated with a resource (re)selection window size related to a T2 value (e.g., end time in the window size). In this case, the relay WTRU can determine the resource (re)selection window T2 value, for example, based on the priority value in the RRI instruction, and possibly a configured mapping between the priority and the T2 value.

[0195] Regarding PDB-related information, relay WTRUs may be instructed using the estimated remaining time available for the relay WTRU to perform resource scheduling and data transmission on the sidelink to the remote WTRU. The estimated remaining time for performing resource scheduling and transmission on the sidelink may be determined, for example, by subtracting the estimated delay caused by (re)transmission from the E2E PDB to the DL.

[0196] Regarding timing information for resource (re)selection, the relay WTRU may be instructed using first and / or second timing information related to the resource (re)selection window size, where the first timing information may be related to T2 (e.g., end time in the window size) and the second timing information may be related to T1 (e.g., start time in the window size). The relay WTRU can then determine the resource (re)selection window based on the T2 and / or T1 timing information received in the RRI instruction. This timing information may also include, for example, a start time to trigger sensing / measuring / monitoring to autonomously determine a resource and / or initiate resource (re)selection. In another example, the timing information related to the resource (re)selection window size may be instructed as a single value consisting of the window size (e.g., T2-T1). The relay WTRU can then use this single value to perform resource (re)selection.

[0197] Regarding timing information for aligning periodic resources, if a relay WTRU is expected to receive periodic data transmissions from the network and relay the data to a remote WTRU on a sidelink using aligned timing attributes (e.g., applying the same periodicity on the sidelink), the relay WTRU can determine the offset value and periodicity that can be applied, along with the resource (re)selection window size, when performing resource (re)selection for the periodic resource on the sidelink. In this case, the relay WTRU can determine the offset value for initiating periodic transmission on the sidelink based on the processing and / or switching time for transitioning from DL reception to sidelink transmission. The relay WTRU can use the same periodicity indicated in the RRI instruction when performing resource (re)selection to ensure that data reception on DL and data transmission on the sidelink are aligned.

[0198] In one exemplary embodiment, a WTRU (e.g., a relay WTRU) uses instructions received from a remote WTRU and at least one of the following criteria: expected latency on the sidelink, expected latency on the relay WTRU, and / or end-to-end packet delay limit (E2E PDB) related criteria to determine the uplink (UL) Grant It is possible to determine the timing information for using it and instruct the network accordingly.

[0199] A WTRU (e.g., a relay WTRU) can perform one or more steps in such embodiments. The WTRU can receive remote WTRU support instructions in the SCI from a remote WTRU. The remote WTRU support instructions may include data volume in the LCH buffer at the remote WTRU, expected latency to be incurred in the sidelink, and / or priority information. The WTRU can determine timing information as a function of expected transmission latency (L1) in the SL and expected processing latency (L2) in the relay WTRU (e.g., information in the SCI). For example, timing information may be determined as L1 + L2.

[0200] When a WTRU receives a remote WTRU support instruction in the SCI when the E2E PDB-related criteria are met, it can trigger a relay WTRU support instruction. The relay WTRU support instructions include the expected data volume in the LCH buffer associated with the remote WTRU, and the determined timing information (e.g., UL GrantThe E2E PDB-related criteria may include a desired time slot when receiving the signal. The E2E PDB-related criteria may include a trigger relay WTRU support instruction when the determined timing information is less than or equal to a configured latency threshold T (e.g., L1 + L2 ≤ T). The WTRU may select a logical channel group (LCG) to sense the relay WTRU support instruction based on priority (e.g., in the SCI) and the determined timing information (e.g., using a configured mapping between the LCG and the timing information). If the criteria are not met, the relay WTRU may either send an SR to the network using the selected SR configuration associated with the timing, or instruct the remote WTRU that it is unable to satisfy the E2E PDB.

[0201] WTRU is the received UL Grant This allows PDUs received from remote WTRUs to be relayed at UL.

[0202] Figure 4 shows relays based on the determined waiting time. GrantThis is a diagram illustrating an exemplary process for obtaining UL resources. A relay scenario may exist in which a remote WTRU is connected to a relay WTRU connected to a network (e.g., a base station). The relay WTRU can relay data from the remote WTRU to the network. To do this, it may be necessary to obtain UL resources from the network. In 401, the network can send a configuration to the relay WTRU. This configuration information may include relay assistance requirements, which may be some threshold (T). In 402, the remote WTRU can send a remote assistance instruction. This remote assistance instruction may include data volume information (e.g., the data volume at the remote WTRU that may need to be relayed) and the expected latency (L1) on the sidelink between the remote WTRU and the relay WTRU. In 403, the relay WTRU can determine the expected latency (L2) in the relay WTRU based on any latency associated with the data in the relay WTRU that needs to be transmitted (for example, processing or relaying data coming from another remote WTRU or network in a buffer), and any latency associated with the data volume information transmitted from the remote WTRU (for example, the relay WTRU can determine this latency based on the data volume information transmitted from the remote WTRU). In 404, the relay WTRU can determine whether the expected latency (L1) in the sidelink and any latency (L2) in the relay WTRU add up to a sum that meets and / or exceeds a threshold (T) received from the network. The relay WTRU then determines the UL resource Grant A support instruction requesting the UL can be sent to the network. After this request is sent, the network will UL the resource. Grant The relay WTRU can transmit data, and using these resources, it can relay data from the remote WTRU to the network. Each of the aforementioned steps may be treated partially or whole, optional, and may be performed in any order.

[0203] Figure 5 shows relays based on the determined waiting time. Grant This is a flowchart of an exemplary process for obtaining a relay WTRU. In 501, the relay WTRU can receive a relay assistance request configuration from the network. In 502, the relay WTRU can receive a remote assistance instruction from a remote WTRU. In 503, the relay WTRU can determine relay timing information for relaying based on the remote assistance information and / or information about the relay WTRU. In 504, the relay WTRU can send a relay assistance instruction to the network requesting a resource, provided that the determined relay timing meets the threshold from the configuration. In 505, the relay WTRU can send a resource request to the network (e.g., from the network). Grant It can receive. In 506, the relay WTRU is resource Grant Data can be relayed using this method. Each of the aforementioned steps can be treated partially or entirely, may be selective, and may be performed in any order.

[0204] In one exemplary embodiment, a WTRU (e.g., a relay WTRU) sets a resource reselection window (e.g., T2) based on instructions received from the network and triggers resource reselection in advance to relay downlink (DL) data to a remote WTRU.

[0205] Figure 6 is a flowchart of an exemplary process for managing resources for relaying data. In such embodiments, a WTRU (e.g., a relay WTRU) can perform one or more steps. In 601, the WTRU can receive a resource selection initialization instruction. The contents of the resource selection initialization instruction may include the expected data volume for data destined for the remote WTRU, and priority information. For example, such a resource selection initialization instruction may be received in the DCI. In 602, the WTRU can determine a resource reselection window T2 based on the indicated priority and a configured mapping between the priority and T2. In 603, the WTRU can trigger resource reselection when the resource selection criteria are met. The resource selection criteria can trigger resource reselection under the following conditions: that the resource is not currently available, or that the available resources cannot accommodate the expected data due to a mismatch between the expected data size / timing and the available resource size / timing. In 604, the WTRU may, using the determined resources, relay the PDU received at the DL to a remote WTRU via the sidelink. Each of the aforementioned steps may be treated partially or entirely, be selective, and may be performed in any order.

[0206] In one exemplary embodiment, a relay radio transceiver unit (WTRU) can receive sidelink control information (SCI) from a remote WTRU. The SCI may include relay WTRU support instructions, which may include expected latency information. The WTRU can determine timing information based on the expected latency information. The WTRU transmits the remote WTRU support instructions based on the relay WTRU support information, and then the uplink information received from the SCI. Grant This can be used to trigger the relaying of the PDU of a remote WTRU.

[0207] According to one or more embodiments disclosed herein, a remote WTRU can transmit data support instructions to a relay WTRU in a sidelink for relaying along with PDB requirements, and such support instructions may relate to one or more of the following: the content of the remote WTRU support instructions, a method for transmitting the remote WTRU support instructions, a method for determining the resources for transmitting the remote WTRU support instructions, and / or trigger conditions for transmitting the remote WTRU support instructions to the relay WTRU.

[0208] According to one or more embodiments disclosed herein, a remote WTRU operating in Mode 1 can trigger the transmission of a remote WTRU support instruction.

[0209] According to one or more embodiments disclosed herein, a remote WTRU operating in Mode 2 can trigger the transmission of a remote WTRU support instruction.

[0210] According to one or more embodiments disclosed herein, a relay WTRU may transmit an assisting instruction for performing the transmission of data to be relayed, the assisting instruction may relate to one or more of the following: trigger conditions for generating and transmitting a relay WTRU assisting instruction, the content of the relay WTRU assisting instruction to be included by the relay WTRU, and / or a method for determining timing information related to the data to be relayed in the relay WTRU.

[0211] According to one or more embodiments disclosed herein, the relay WTRU can change the prioritization of the data being relayed in order to satisfy the E2E PDB.

[0212] According to one or more embodiments disclosed herein, a relay WTRU operating in mode 1 can receive DL data and sidelink resource scheduling information for a remote WTRU, such as two consecutive DL transmissions having a DL DCI in one transmission and an SL DCI in the other transmission, and / or a single DL transmission having a DL DCI that includes both DL scheduling information and SL scheduling information.

[0213] According to one or more embodiments disclosed herein, a relay WTRU operating in mode 2 can trigger resource reselection based on an initialization instruction received in the DL, which may relate to one or more of the following: namely, triggering conditions for initiating resource (re)selection in the relay WTRU, and / or the content of a resource reselection initialization instruction received by the relay WTRU.

[0214] Any embodiment or example described herein is not intended to be read in isolation from the remainder of the specification. Any embodiment described herein may be read in consideration of other techniques disclosed in other sections of the specification. Any embodiment described herein consists of steps, in which case any step may be treated in part or in whole, may be optional, and may be performed in any order.

[0215] As described herein, the term "upper layer" may refer to one or more layers in a protocol stack, or a specific sublayer within a protocol stack. This protocol stack may consist of one or more layers within a WTRU or network node (e.g., eNB, gNB, server, or other functional entity), where each layer may have one or more sublayers. Each layer / sublayer may perform one or more functions. Each layer / sublayer may communicate directly or indirectly with one or more other layers / sublayers. In some cases, these layers may be numbered, such as Layer 1, Layer 2, and Layer 3. For example, Layer 3 may consist of one or more of the following: namely, Non-Access Layer (NAS), Internet Protocol (IP), and / or Radio Resource Control (RRC). For example, Layer 2 may consist of one or more of the following: These are Packet Data Convergence Control (PDCP), Radio Link Control (RLC), and / or Medium Access Control (MAC). For example, Layer 3 may consist of physical (PHY) layer type operations. The higher the layer number, the higher the layer is relative to other layers (for example, Layer 3 is higher than Layer 1). In some cases, the above examples may be referred to as layers / sublayers themselves, regardless of the layer number, and may be called upper layers as described herein. For example, upper layers may refer to one or more of the following layers / sublayers, from the highest to the lowest: NAS layer, RRC layer, PDCP layer, RLC layer, MAC layer, and / or PHY layer. Any reference to upper layers herein in relation to a process, device, or system will refer to a layer that is higher than the layer of the process, device, or system.In some cases, references to higher layers in this specification may refer to functions or operations performed by one or more layers described herein. In some cases, references to higher layers in this specification may refer to information transmitted or received by one or more layers described herein. In some cases, references to higher layers in this specification may refer to configurations transmitted and / or received by one or more layers described herein.

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

Claims

1. A method performed by a relay wireless transceiver unit (WTRU), wherein the method is Receiving configuration information from a base station, wherein the configuration information includes a relay support threshold, and the relay support threshold is a time threshold. Receiving remote WTRU support information from a remote WTRU via a side link, wherein the remote WTRU support information includes at least an expected waiting time. The condition is that the total time is longer than the relay support threshold, and the total time is determined from the remote WTRU support information. Receiving resource information indicating resource grants from the aforementioned base station, Relaying the data by receiving data from the remote WTRU via the sidelink and transmitting the data to the base station using the grant of the resources, A method that includes this.

2. The method according to claim 1, wherein the remote WTRU support information includes data volume information, the total time includes a first time + a second time, the first time is determined from the expected waiting time of the side link, and the second time is determined from the data volume information.

3. The method according to claim 1, wherein the grant of the resource includes one or more time slots.

4. The method according to claim 1, wherein the configuration information is control information received in control channel transmission.

5. The method according to claim 1, wherein the remote WTRU support information is received in side link control information or side link medium access control (MAC) control element.

6. The method according to claim 1, wherein the resource information indicating the grant of the resource is received in response to the transmission of the support indication.

7. A relay wireless transceiver unit (WTRU), wherein the relay WTRU is Equipped with a processor connected to a transceiver, The processor and transceiver are configured to receive configuration information from a base station, the configuration information includes a relay support threshold, and the relay support threshold is a time threshold. The processor and transceiver are configured to receive remote WTRU support information from a remote WTRU via a sidelink, and the remote WTRU support information includes at least an expected latency. The processor and transceiver are configured to transmit a support indication to the base station on the condition that the total time is longer than the relay support threshold, and the total time is determined from the remote WTRU support information. The processor and transceiver are configured to receive resource information indicating resource grants from the base station. The processor and transceiver are configured to receive data from the remote WTRU and relay the data by using the grant of the resources to transmit the data to the base station. Relay WTRU.

8. The relay WTRU according to claim 7, wherein the remote WTRU support information includes data volume information, the total time includes a first time + a second time, the first time is determined from the expected waiting time of the side link, and the second time is determined from the data volume information.

9. The grant of the resource includes one or more time slots, according to claim 7, for the relay WTRU.

10. The relay WTRU according to claim 7, wherein the configuration information is control information received in control channel transmission.

11. The relay WTRU according to claim 7, wherein the remote WTRU support information is received in the side link control information or side link medium access control (MAC) control element.

12. The relay WTRU according to claim 7, wherein the resource information indicating the grant of the resource is received in response to transmitting the support indication.

13. The relay WTRU according to claim 8, wherein the second time is further determined from the amount of data in the buffer of the relay WTRU.

14. The method according to claim 2, wherein the second time is further determined from the amount of data in the buffer of the relay WTRU.

Images