Methods and apparatus for path selection for sidelink communications in a wireless network

Abstract

This disclosure pertains to procedures, methods, architectures, apparatus, systems, devices, and computer program products for, and / or directed to selecting a relay WTRU from a plurality of candidate relay WTRUs for sidelink communications in a wireless network.

Description

METHODS AND APPARATUS FOR PATH SELECTION FOR SIDELINK COMMUNICATIONS IN A WIRELESS NETWORKCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of US Provisional Patent Application No. 63 / 531,260 filed August 7th, 2023, which is incorporated herein by reference.FIELD OF THE INVENTION

[0002] This disclosure pertains to procedures, methods, architectures, apparatus, systems, devices, and computer program products for, and / or directed to selecting a relay wireless transmit / receive unit (WTRU) from a plurality of candidate relay WTRUs for sidelink communications in a wireless network.BACKGROUND

[0003] Multipath relay, where each path corresponds to an indirect path may involve selection not only of resources by a remote UE, but also of the path which results in the most efficient use of resources on the current hop but next hops as well.

[0004] How the resource selection and path selection interact while taking these factors into account requires further investigation.SUMMARY

[0005] In an embodiment, a method implemented in a wireless transmit / receive unit (WTRU) may comprise a step of receiving, from one or more relay WTRUs, a first message comprising respectively first information indicating uplink configured grant resource. The method may further comprise a step of receiving, from the network, a second message comprising second information indicating a mapping of sidelink packet data unit (PDU) size to uplink resource size. The method may further comprise a step of determining, based on the second message, applicability of the uplink configured grant resource of the one or more relay WTRUs for transmitting data. The method may further comprise a step of selecting a relay WTRU among the one or more relay WTRUs based on the determined applicability; and a step of transmitting, to the selected relay WTRU, via a sidelink transmission, the data.

[0006] The data may be data available for transmission. The data may be available for transmission to the network.

[0007] The method may further comprise a step of determining a priority associated with the data, and wherein selecting the relay WTRU is further based on the priority. The priority associated with the data may be determined based on a highest logical channel priority of the data. Selecting the relay WTRU may be further based on a timing associated with the configured grant resourceof the selected relay WTRU. The determination of the applicability may comprise uplink grant size is larger than the sidelink grant size by a threshold amount. The determination of the applicability may comprise uplink grant size occurs at least / most a threshold time before the end of PDU of a packet.

[0008] The first information indicating uplink configured grant resource may comprise any of a set of uplink configured grants, timing of resources in the configured grants, and size of resources in the configured grants.

[0009] Prior to receive the first message, the method may further comprise a step of establishing one or more connections with the at least one or more relay WTRUs.

[0010] In an embodiment, a wireless transmit / receive unit (WTRU), comprising a processor, a transceiver unit and a storage unit, may be configured to receive, from one or more relay WTRUs, a first message comprising respectively first information indicating uplink configured grant resource; receive, from the network, a second message comprising second information indicating a mapping of sidelink packet data unit (PDU) size to uplink resource size; determine, based on the second message, applicability of the uplink configured grant resource of the one or more relay WTRUs for transmitting data; selecting a relay WTRU among the one or more relay WTRUs based on the determined applicability; and transmit, to the selected relay WTRU, via a sidelink transmission, the data.[Oil] The data may be data available for transmission. The data may be data available for transmission to the network.

[0012] The WTRU may be configured to determine a priority associated with the data, and wherein selecting the relay WTRU is further based on the priority. The priority associated with the data may be determined based on a highest logical channel priority of the data.

[0013] The selection of the relay WTRU may be further based on a timing associated with the configured grant resource of the selected relay WTRU.

[0014] The determination of the applicability may comprise uplink grant size is larger than the sidelink grant size by a threshold amount. The determination of the applicability may comprise uplink grant size occurs at least / most a threshold time before the end of PDU of a packet.

[0015] The first information indicating uplink configured grant resource may comprises any of a set of uplink configured grants, timing of resources in the configured grants, and size of resources in the configured grants.

[0016] The WTRU may be configured to establish one or more connections with the at least one or more relay WTRUs, prior to receive the first message.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] A more detailed understanding may be had from the detailed description below, given by way of example in conjunction with the drawings appended hereto. Figures in such drawings, like the detailed description, are exemplary. As such, the Figures and the detailed description are not to be considered limiting, and other equally effective examples are possible and likely. Furthermore, like reference numerals ("ref.") in the Figures ("FIGs.") indicate like elements, and wherein:

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

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

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

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

[0022] FIG. 2 is diagram illustrating the assumed relative positions of a remote WTRU and a relay WTRU in 3 GPP Release 17;

[0023] FIG. 3 is diagram illustrating the protocol stack for the user plane of the L2 U2N Relay architecture in 3 GPP;

[0024] FIG. 4 is diagram illustrating the protocol stack for the control plane of the L2 U2N Relay architecture in 3 GPP;

[0025] FIG. 5 is a diagram showing a scenario in which a remote WTRU can communicate with a wireless network / cell tower via multiple potential indirect paths using sidelink or via a direct path;

[0026] FIG. 6 is a flowchart illustrating a process for selecting a relay WTRU from a plurality of candidate relay WTRUs for sidelink communications in a wireless network in accordance with embodiments;

[0027] FIG. 7 is a flowchart illustrating a process for selecting sidelink resources for communications between a remote WTRU and a network based on scheduling conditions at the potential relay WTRUs in accordance with embodiments;

[0028] FIG. 8 is a flowchart illustrating a process for reporting buffer status to a wireless network in connection with sidelink communications based on relay WTRU scheduling in accordance with embodiments;

[0029] FIG. 9 is a flowchart illustrating a process for selecting a particular relay WTRU from a plurality of potential relay WTRUs for transmitting groupcast data from a remote WTRU in accordance with embodiments;

[0030] FIG. 10 is a flowchart illustrating a process for determining, in a Wireless Transmit / Receive Unit (WTRU), whether to use sidelink resources or Uu resources for data transmission in response to a flexible resource grant in accordance with embodiments; and

[0031] FIG. 11 is a flowchart illustrating an example of a method, implemented in a WTRU, for transmitting data via a relay WTRU.DETAILED DESCRIPTION

[0032] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail, so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples described, disclosed, or otherwise provided explicitly, implicitly and / or inherently (collectively "provided") herein.

[0033] FIG. 1 A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), singlecarrier FDMA (SC-FDMA), zero-tail unique-word DFT-Spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0034] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a publicswitched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or a “STA”, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0035] The communications systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

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

[0043] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0044] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may be utilizing a NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0048] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

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

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

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

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

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

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

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

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

[0059] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), and the like. As shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0061] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0062] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

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

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

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

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

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

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

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

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

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

[0072] WLAN systems, which may support multiple channels, and channel bandwidths, such as802.1 In, 802.1 lac, 802.1 laf, and 802.1 lah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supportsthe smallest bandwidth operating mode. In the example of 802.1 lah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

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

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

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

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

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

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

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

[0082] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

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

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

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

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

[0087] 3GPP Release 17 has specified Sidelink (SL)-based WTRU to Network Relays. Sidelink relay is introduced to support 5G ProSe UE-to-Network Relay (U2N Relay) function to provide connectivity to the network for U2N Remote WTRU(s). Both L2 and L3 U2N Relay architectures are supported. The L3 U2N Relay architecture is transparent to the serving RAN of the U2N Relay WTRU, except for controlling sidelink resources.

[0088] A U2N Relay WTRU shall be in RRC CONNECTED to perform relaying of unicast data. For L2 U2N Relay operation, two RRC state combinations are supported. In the first, both U2N Relay WTRU and U2N Remote WTRU shall be in RRC CONNECTED to performtransmission / reception of relayed unicast data. In the second, the U2N Relay WTRU can be in RRC IDLE, RRC INACTIVE or RRC CONNECTED as long as all the U2N Remote WTRU(s) that are connected to the U2N Relay WTRU are either in RRC INACTIVE or in RRC IDLE.

[0089] For L2 U2N Relay, the U2N Remote WTRU can only be configured to use resource allocation mode 2 for data to be relayed.

[0090] A single unicast link is established between one L2 U2N Relay WTRU and one L2 U2N Remote WTRU. The traffic of the U2N Remote WTRU via a given U2N Relay WTRU and the traffic of the U2N Relay WTRU shall be separated in different Uu Radio Link Control (RLC) channels over Uu.

[0091] The underlying assumption in Rel 17 is that the remote WTRU is out of coverage?? (OOC), as illustrated in FIG. 2.

[0092] Release 17 of the 3 GPP specifications introduced layer 2 WTRU to network relays. The main use case considered is the case of a remote WTRU that is out of coverage. In Release 18, however, specification of multipath is expected. In multipath, the remote WTRU is assumed to be in coverage, and can therefore utilize either Uu path, SL (relayed) path, or both. The description of the multipath work for Rel 18 is as follows: Study the benefit and potential solutions for multipath support to enhance reliability and throughput (e.g., by switching among or utilizing the multiple paths simultaneously) in the following scenarios [RAN2, RAN3]: A UE is connected to the same gNB using one direct path and one indirect path via 1) Layer-2 UE-to-Network relay, or 2) via another UE (where the UE-UE inter-connection is assumed to be ideal), where the solutions for 1) are to be reused for 2) without precluding the possibility of excluding a part of the solutions which is unnecessary for the operation for 2). Study on the benefit and potential solutions are to be completed in RAN#98 which will decide whether / how to start the normative work. UE-to- Network relay in scenario 1 reuses the Rel-17 solution as the baseline. Support of Layer-3 UE-to- Network relay in multi-path scenario is assumed to have no RAN impact and the work and solutions are subject to SA2 to progress.

[0093] The protocol stacks for the user plane and control plane of L2 U2N Relay architecture are shown in FIGS. 3 and 4, respectively. The Sidelink Relay Adaptation Protocol (SRAP) sublayer is placed above the Radio Link Control (RLC) sublayer for both Cyclic Prefix (CP) and User Plane (UP) at both the PC5 interface and the Uu interface. The Uu Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP) and RRC are terminated between the L2 U2N Remote WTRU and the gNB, while SRAP, RLC, Medium Access Control (MAC) and the Physical(PHY) layers are terminated in each hop (i.e., the link between the L2 U2N Remote WTRU and the L2 U2N Relay WTRU and the link between the L2 U2N Relay WTRU and the gNB).

[0094] For L2 U2N Relay, the SRAP sublayer over PC5 hop is only for the purpose of bearer mapping. The SRAP sublayer is not present over the PC5 hop for relaying the L2 U2N Remote WTRU’s message on BCCH (Broadcast Control Channel) and PCCH (Paging Control Channel). For the L2 U2N Remote WTRU’s message on SRBO, the SRAP sublayer is not present over the PC5 hop, but the SRAP sublayer is present over the Uu hop for both DL (Downlink) and UL (Uplink).

[0095] For L2 U2N Relay, for uplink the Uu SRAP sublayer supports UL bearer mapping between ingress PC5 Relay RLC channels for relaying and egress Uu Relay RLC channels over the L2 U2N Relay WTRU Uu interface. For uplink relaying traffic, the different end-to-end RBs (SRBs or DRBs) of the same Remote WTRU and / or different Remote WTRUs can be multiplexed over the same Uu Relay RLC channel. Also, the Uu SRAP sublayer supports L2 U2N Remote WTRU identification for the UL traffic. The identity information of L2 U2N Remote WTRU Uu Radio Bearer and a local Remote UE ID are included in the Uu SRAP header at UL in order for gNB to correlate the received packets for the specific PDCP entity associated with the right Uu Radio Bearer of a Remote WTRU. The PC5 SRAP sublayer at the L2 U2N Remote WTRU supports UL bearer mapping between Remote WTRU Uu Radio Bearers and egress PC5 Relay RLC channels.

[0096] For L2 U2N Relay, for downlink, the Uu SRAP sublayer supports DL bearer mapping at gNB to map end-to-end Radio Bearer (SRB, DRB) of Remote WTRU into Uu Relay RLC channel over Relay WTRU Uu interface. The Uu SRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end Radio Bearers (SRBs or DRBs) of a L2 U2N Remote WTRU and / or different L2 U2N Remote WTRUs and one Uu Relay RLC channel over the Relay WTRU Uu interface. The Uu SRAP sublayer supports Remote WTRU identification for DL traffic. The identity information of the Remote WTRU Uu Radio Bearer and a local Remote WTRU ID are included into the Uu SRAP header by the gNB at DL in order for the Relay WTRU to map the received packets from the Remote WTRU Uu Radio Bearer to its associated PC5 Relay RLC channel. The PC5 SRAP sublayer at the Relay WTRU supports DL bearer mapping between ingress Uu Relay RLC channels and egress PC5 Relay RLC channels. The PC5 SRAP sublayer at the Remote WTRU correlates the received packets for the specific PDCP entity associated with the right Uu Radio Bearer of a Remote WTRU based on the identity information included in the Uu SRAP header.

[0097] A local remote WTRU ID is included in both the PC5 SRAP header and the Uu SRAP header. The L2 U2N Relay WTRU is configured by the gNB with the local Remote UE ID to be used in the SRAP header. The remote WTRU obtains the local Remote ID from the gNB via Uu RRC messages including RRC Setup, RRCReconfiguration, RRCResume, and RRCReestablishment. Uu DRB(s) and Uu SRB(s) are mapped to different PC5 Relay RLC channels and Uu Relay RLC channels in both PC5 hop and Uu hop.

[0098] It is the gNB responsibility to avoid collision on the usage of a local Remote UE ID. The gNB can update the local Remote UE ID by sending the updated local Remote ID via RRCReconfiguration message to the Relay WTRU. The serving gNB can perform local Remote UE ID update independent of the PC5 unicast link L2 ID update procedure.

[0099] Sidelink supports two scheduling modes - mode 1 and mode 2. For an in-coverage WTRU, the gNB can control whether a WTRU transmits using mode 1 or mode 2.

[0100] In mode 1 scheduling, which can be used for a sidelink WTRU in RRC CONNECTED, a WTRU receives SL grants directly from the network in Downlink Control Information (DCI). In this case, the WTRU reports buffer status for SL data grouped by a destination index (where a destination index corresponds to a unique L2 destination ID or pair of source / destination L2 IDs). The WTRU can report SL SR (Scheduling Request) if a SL grant is not available for transmission of the pending data.

[0101] In mode 2 scheduling, which can be used by a WTRU in any RRC state, or a WTRU which is out of coverage, a WTRU is configured with a resource pool from which it performs autonomous resource selection and scheduling. Resources are selected by the WTRU based on information in previous Sidelink Control Information (SCI) transmissions by other WTRUs (i.e. sensing results).

[0102] Release 18 work on SL relay handles multipath where the remote WTRU can transmit via a direct Uu path and an indirect path via a WTRU to network relay.

[0103] A remote WTRU which is out of network coverage may want to take advantage of bandwidth and reliability extensions of multipath as well. This can be achieved with multiple relay WTRUs serving as different paths. FIG. 5 shows such a scenario, where the remote WTRU (which may or may not have a direct path) can communicate via multiple indirect paths using a SL or ideal (e.g., a wired link, a non-3GPP wireless link, two attached / collocated devices having different radios, etc.) connection.

[0104] In Rell8 multipath, Dual Connectivity (DC)-based modeling is used, which assumes the WTRU routes (i.e., at the PDCP layer) data only either direct or indirect without information from the MAC layer (e.g., channel quality, etc.). This assumption is made considering that the directpath is always considered the primary path for transmission, and the indirect path is used to supplement direct path transmission.

[0105] In Rell9, multipath may be extended to assume multiple indirect paths. In this case, the concept of primary path is not relevant. In addition, since the multiple indirect paths are associated with the same MAC entity, data routing to the different paths may be done at the MAC layer rather than the PDCP layer. Specifically, more dynamic routing decisions can be made at the MAC layer based on resource availability.

[0106] A multipath scheduling mechanism based on MAC layer may require a deviation from the SL relay scheduling paradigm for the full advantages of the MAC layer to be achieved. Specifically, the Rell7 relaying paradigm assumes independent SL and Uu scheduling. Specifically, a remote WTRU is scheduled via mode 1 or mode 2 (i.e., legacy sidelink) to transmit data to a L2 relay WTRU and the L2 relay WTRU, upon reception of data from the remote WTRU, is scheduled as a normal Uu WTRU by the network.

[0107] Although data from the remote WTRU depends on scheduling over both sidelink and Uu links, the scheduling mechanisms on each link have little / no interaction. This assumption was required for a number of reasons. First, in Rell7, the remote WTRU was assumed to be OOC, and the SL scheduler (the remote WTRU) and Uu scheduler (the network) were assumed to not interact. Although interaction between the remote WTRU and the network via the relay is possible in theory, exchanging scheduling information may not be feasible due to the latency and congestion associated with sidelink. However, with more efficient SL transmissions, or the use of an ideal link (for the case of scenario 2 multipath) exchange of this information is feasible. In Rell8 multipath, where an IC (In Coverage) WTRU could use the direct or indirect path, interaction between schedulers is still not needed since the MAC entities are different and PDCP routing can achieve the use case.

[0108] A first issue is how to define MAC-based decision criteria for route selection. PDCP -based routing decision based legacy DC (i.e., primary path and split bearer threshold) is tailored to DC assumption of multiple network schedulers and to the case of bandwidth extension. When two indirect paths are used, there may not be one statically configured preferred path. Instead, selection (e.g., in the uplink) should be made more dynamically based on information at the relay. In essence, the selection of the relay WTRU (e.g., for UL transmission) should be done by the remote WTRU based on which relay WTRU is in better position to send the received data to the network. Uu grants at the relay WTRU, relay WTRU buffering latency, presence of other higher priority traffic received by the relay WTRU to other remote WTRUs, etc. are all criteria that should beused by the remote WTRU to select the relay WTRU for a transmission. However, how to represent this criteria at the remote WTRU and provide it to the remote WTRU in an efficient manner (both for a SL interface and a non-3GPP interface) needs to be defined.

[0109] Another issue is SL LCP and BSR (Buffer Status Report) may need to be redesigned. In legacy sidelink, Link Control Protocol (LCP) operates per destination. Specifically, the WTRU first selects a L2 destination ID to use in the grant, and the grant is filled with data from those logical channels only. In the multiple indirect case for multipath, all data can be sent to the network via any relay. Therefore, the SL LCHs (Logic Channels) created for each end-to-end bearer can be treated equally from the SL LCP perspective. However, depending on the adaptation layer multiplexing configured at the relay WTRUs, these SL logical channels may be mapped to a single Uu LCH belonging to a specific WTRU. SL LCP may need to take such factors into account.

[0110] Similarly, BSR need not be reported per destination if the remote WTRU data can take multiple paths to the same network node. Groupcast on SL can be used to improve reliability. Groupcast allows a single transmission on sidelink to reach multiple SL RX WTRUs. In the multipath relaying scenario, a remote WTRU could rely on groupcast to allow a single transmission to reach multiple relay WTRUs. The relaying procedure for this case at the relay WTRU should be further considered. With regard to Uu / SL Multipath, one limitation of Uu and SL multipath, in addition to the modeling as multiple MAC entities, is the clear separation between SL resources and Uu resources. A more efficient multipath scheduling scheme would require that this separation be removed.[OHl] In this disclosure, the interface between the relay and remote WTRU may be sidelink / PC5. Legacy procedures for data / control transmission between the relay and remote WTRU may be used for exchange of control information, SR / BSR information, grant information, etc., defined in this disclosure.

[0112] Alternatively, the interface between the relay and the remote WTRU may be an ideal link (e.g., a wired link, a non-3GPP wireless link, two attached / collocated devices having different radios, etc.). Exchange of data and control may be transparent to the relay WTRU. Specifically, the remote WTRU may have access to all information related to SR / BSR triggered by the relay WTRU or have access to the Uu grants provided by the network to the relay WTRU. Alternatively, exchange of data and control may be through specified transactions defined as per an inter-device interface. For example, a remote WTRU may provide PDUs, possibly of a specified size, to the relay WTRU for the relay WTRU to provide its relaying functionality. For example, a remoteWTRU and a relay WTRU may exchange information such as Uu grant information, SR / BSR, etc. via inter-device control messages, via adaptation layer control messages, etc.

[0113] In this disclosure, any discussion concerning the interaction between the remote WTRU and the relay WTRU may be applicable to any of the above connections. For example, although a solution may mention a SL, the solution may also be applicable to a transaction between the remote WTRU and the relay WTRU of a pre-determined / defined size.

[0114] In this disclosure, any discussion concerning the interaction between a remote WTRU and a relay WTRU in the context of the relay WTRU relaying data from the remote WTRU to the network (and vice versa) may furthermore apply in the context of multiple collaborative WTRUs operating in the context of WTRU aggregation.

[0115] A relay WTRU may send SR / BSR information to a remote WTRU

[0116] Scheduling at the remote WTRU may make use of SR / BSR information from the relay WTRU. The relay WTRU may send SR / BSR information in a sidelink message (e.g., SCI, SL MAC CE, etc.). Alternatively, the relay WTRU may send SR / BSR information in an inter-device control message that can be used to communicate between WTRUs having ideal / wired / non-3GPP connection. Alternatively, the remote WTRU may check the occurrence of SR / BSR transmission by a relay WTRU, either by monitoring UL transmissions by the relay WTRU, querying the transmission buffers of a relay WTRU, or similar techniques that can be applicable to the case where the remote and relay WTRU(s) have an ideal connection.

[0117] Uu SR / BSR information of the relay WTRU may comprise: the timing and / or trigger of a Uu SR; the priority of the triggered Uu SR; the timing of a Uu BSR transmission; the buffer status of one or more Uu LCHs at the relay WTRU; the amount / proportion of the buffer status at the relay WTRU associated with the said remote WTRU and / or other remote WTRUs; a computed capacity, as defined herein; an indication of when the computed capacity is above / below a threshold or a defined amount, or changes by a threshold or a defined amount

[0118] Uu SR / BSR information may be sent to the remote WTRU based on some trigger or event associated with such (for example: (1) upon trigger of the Uu SR / BSR by the relay WTRU; (2) upon trigger / transmission of a BSR meeting certain conditions related to the amount of data reported associated with the said remote WTRU, other remote WTRUs, or overall relayed data; (3) upon state transition at the relay WTRU (e.g., transition by the relay WTRU to RRC CONNECTED state); and (4) upon trigger / transmission of the first BSR following reception, by the relay WTRU, of data from the remote WTRU (or other remote WTRUs) associated with some factor described above.

[0119] A relay WTRU may send Uu grant information to a remote WTRU

[0120] Uu grant information from a relay may be sent to a remote WTRU. For example, a relay WTRU may send configured grant patten / information to a remote WTRU in PC5-RRC. Alternatively, a relay WTRU may send an indication of the presence of a dynamic grant on Uu using an SCI transmission, a MAC CE, or similar means.

[0121] A relay WTRU may forward / relay Uu grant information to a remote WTRU. For example, a relay WTRU may encapsulate a DCI message in a SL SCI, or an inter-device control message.

[0122] A remote WTRU may decode DCI and / or RRC messages intended for the relay WTRU to determine the presence and / or timing of Uu grants. For example, a remote WTRU may be provided with a C-RNTI that can be used to decode the Uu grants applicable to the relay WTRU.

[0123] A relay WTRU may be configured with specific triggers for sending the Uu grant information to the remote WTRU, such as (1) configuration / modification of a Uu configured grant configuration at the relay WTRU and (2) reception of a Uu dynamic grant at the relay WTRU, possibly associated with specific characteristics defined herein, possibly having specific size / timing making it applicable for relaying, possibly having specific SL LCH restrictions making it applicable for relaying.

[0124] A relay WTRU may send QoS information to a remote WTRU

[0125] QoS information may be sent by a relay WTRU to a remote WTRU. This may consist of any of: (1) adaptation layer configuration; (2) mapping of the SL LCH to Uu LCH; (3) mapping of the SL priority of a SL LCH to the corresponding Uu LCH; (4) MAC layer parameters configured for any of the Uu LCHs, such as (priority, PBR (Prioritized Bit Rate), GBR (Guaranteed Bit Rate), and average packet size); and (5) instantaneous information associated with data buffered in the Uu LCHs such as Bj value (defined in the LCP algorithm in the 3 GPP specification for keeping track of the amount of prioritized data to be included in a grant) or other value associated with Uu LCP procedure.

[0126] Similar aspects related to the exchange of buffer status between the remote WTRU and relay WTRU apply also to QoS information.

[0127] A relay WTRU may send one or more of the above information conditioned on a condition related to another information

[0128] In one solution related to the information elements described above, a relay WTRU may transmit an indication / information to a remote WTRU when a condition associated with another information is satisfied.

[0129] For example, a relay WTRU may forward Uu grant information to a remote WTRU when the Uu BSR at the relay WTRU satisfies some condition(s) (e.g., below a threshold). For example, this may be useful in informing a remote WTRU of the presence of a Uu grant (usable for transmission of Uu data via SL or ideal link by the remote WTRU) when such a grant is available and would not be used by the relay WTRU for other remote WTRU’s or for its own traffic.

[0130] For example, a relay WTRU may send the remote WTRU its BSR information (e.g., periodically, or possibly upon some triggers described herein), possible associated with one or more LCH, when the relay WTRU is configured with one or more configured grant.

[0131] In multipath with multiple indirect paths, a transmission (e.g., on a SL grant, or via non- 3GPP link) can be performed to any relay WTRU. To ensure the best is chosen, a path decision can be made after the creation of the MAC PDU (i.e., after SL LCP). This uses the most up to date channel / relay information for making the decision. Specifically, the remote WTRU can perform packet construction first (e.g., SL LCP for scenario 1), and use information from the relay WTRUs to decide which relay WTRU to send the MAC PDU to.

[0132] A remote WTRU may determine the intended relay WTRU (e.g., the L2 ID) for transmission of a SL MAC PDU based on the Uu CG (configured grant) information received from multiple relay WTRU’s and the priority / size of the MAC PDU.

[0133] In an exemplary embodiment, a remote WTRU: (i) may be connected to multiple relay WTRUs (e.g., via PC5-RRC), (ii) may determine a priority associated with data available for transmission via any of multiple paths through different relay WTRUs (e.g., the largest LCH priority of data available for transmission), (iii) may receive, from each of the multiple relay WTRUs, the Uu configured grant resource information (e.g., the set of Uu configured grants, timing of each resource, resource size), (iv) may receive, from the network, a mapping of SL MAC PDU size to effective Uu resource size, (v) may receive / select a SL grant (e.g., using mode 1 or mode 2), (vi) may generate a packet of a specific size (e.g., a SL MAC PDU) by multiplexing data from multiple SL LCHs into the packet (e.g., using SL LCP procedure), (vii) may determine the applicability of a configured grant resource based on the network configured mapping associated with timing / size of Uu configured grant resource compared with the SL data (e.g., Uu grant size is larger than the SL grant size by some threshold amount; e.g., Uu grant size occurs at least / most a threshold time before the end of PDU of the packet), (viii) may determine a relay / path for transmission of the packet to the network based on the applicability criteria, the timing and / or size of the Uu configured grant resources of each relay WTRUs, and / or the priority / SL RSRP (Reference Signal Received Power): e.g., choose the relay WTRU with the earliest applicable Uugrant for high priority data (priority > threshold), e.g., choose the relay with the largest applicable Uu grant for low priority data, e.g., in the absence of any applicable Uu grants, send to the relay WTRU with the largest SL RSRP, etc. , may (ix) transmit data in the SL grant to the selected relay / path

[0134] A remote WTRU may determine the relay WTRU to use for a transmission

[0135] In one embodiment, a remote WTRU may determine the relay WTRU for a transmission of a PDU (e.g., a MAC PDU), or the relay WTRU that will be the intended recipient of the data in a SL grant, based on one or a combination of the following factors:

[0136] First factor: QoS associated with the remote WTRU’s transmission, such as one or more of the following: (i) SL LCH priority / configuration, as an example, a specific SL LCH priority may be allowed to be sent over one or a subset of relay WTRUs, possibly at a given time, or based on other conditions herein, as another example, each SL LCH may be configured with a set of allowed / not allowed relay WTRUs. For example, if a PDU contains data from a specific SL LCH, the WTRU may be allowed to transmit data to a relay based on the allowed / not allowed relays for the specific LCH; (ii) PDB (Packet Delay Budget), remaining PDB, etc., as an example, if the PDB associated with a PDU is above / below a threshold, the remote WTRU may select a specific relay, possibly based on one or more other conditions; (iii) PBR, GBR, or similar, as an example, the remote WTRU may select a relay WTRU for transmission based on the PBR, GBR, or similar rate requirement of a SL LCH, possibly compared to another condition herein, possibly based on information received from a relay WTRU.

[0137] Second factor: Timing of the Uu grant(s) associated with each relay WTRU: For example, the remote WTRU may select a relay WTRU for transmission of a PDU on SL based on knowledge of the presence of and / or timing associated with a Uu grant, such as, conditions related to: (a) the relay having the grant occurring the first / last in time, possibly over a configured time window, (b) The relay having a grant which falls within a specific time period (e.g., PDB of the packet).

[0138] Third factor: Size of the Uu grant(s) associated with each relay WTRU: (i) For example, the remote WTRU may select a relay WTRU based on whether a Uu grant is large enough for the SL PDU based on: (a) the remote WTRU may be configured with a required Uu grant size for a given number / range of SL PDU size, and may select the relay WTRU which has a large enough Uu grant allocated, (b) the remote WTRU may be configured with a required Uu grant size for any data associated with a SL LCH, and may select the relay WTRU which has a Uu grant which is at least as large as the required Uu grant size, (c) the remote WTRU may determine a required Uu grant size for a specific SL PDU based on MCS, coding, etc. information provided by the networkand / or the relay WTRU, and number of information bits transmitted in the SL PDU. The remote WTRU may select the relay WTRU which has a Uu grant which is at least large enough for the data in the SL PDU. (ii) As another example, the remote WTRU may select the relay WTRU with the largest / smallest Uu grant available, (iii) As another example, the remote WTRU may select the relay WTRU having the Uu grant whose size is the most similar to the SL grant, SL data size, SL PDU size, or similar parameter, based on any of the Uu size determination mechanisms described herein.

[0139] Fourth factor: Other property associated with Uu grant: (i) for example, the remote WTRU may select a relay WTRU based on a property of the Uu grant, possibly where such Uu grant is an upcoming Uu grant, or has a (pre)configured or (pre)defined timing relationship with the SL grant or SL PDU construction, such as: (a) low latency / high priority Uu grant, as indicated in DCI, (b) carrier or nature of the carrier for the grant (e.g., licensed vs unlicensed), (c) properties of the time duration of the grant (e.g., Multi-TTI grant), (d) properties of the repetition / retransmission pattern of the grant, (e) whether the grant is a configured grant, or dynamic grant, (f) whether the grant is a configured type 1 or type 2 grant, (g) the periodicity of the configured grant, possibly in comparison to SL periodicity, (ii) for example, the remote WTRU may select a relay WTRU based on the presence of a configured grant resource on Uu within a time window relative to the SL transmission.

[0140] Fifth factor: Size of the SL grant or amount of data in the transmission, (i) For example, the remote WTRU may select a relay WTRU based on whether the SL grant is above / below a threshold size, (ii) For example, the remote WTRU may select a relay WTRU based on whether the number of bits included in the SL PDU is above / below a threshold .

[0141] Sixth factor: buffer status provided by each relay WTRU to the network and / or remote WTRU. For example, a remote WTRU may determine the relay WTRU to which to transmit a PDU based on the buffer status of the relay WTRU. This may include any of (i) the amount of data and / or presence of data pending at the relay WTRU, possibly for a specific Uu LCH; (ii) the amount of data and / or presence of data pending at the relay WTRU for which the Uu priority is above a threshold, or above some value determined based on another factor herein; (iii) the amount of data and / or presence of data pending at the relay WTRU which was received from other remote WTRU’s (other than the said remote WTRU); (iv) the amount of data and / or presence of data at the relay WTRU for which the PDB is below a threshold.

[0142] Seventh factor: Timing of the SR / BSR sent by each relay WTRU to the network. For example, a remote WTRU may determine the relay WTRU to which to transmit a PDU based onwhen the relay WTRU triggers SR / BSR, possibly in comparison to another timing event associated with the PDU itself, (a) For example, the remote WTRU may transmit the PDU to the relay WTRU that last triggered transmission of SR / BSR, (b) for example the remote WTRU may transmit the PDU to the relay WTRU that transmitted SR / BSR at least and / or at most a configured amount of time prior to the construction, by the remote WTRU, of the PDU.

[0143] Eighth factor: HARQ (Hybrid Automatic Repeat Request) feedback status from the relay WTRU. For example, a remote WTRU may determine the relay WTRU to which to transmit a PDU based on the status of HARQ feedback reception from the relay WTRU, possibly in response to previous transmissions made to that relay WTRU, for example: (a) the remote WTRU may choose the relay WTRU from which the last transmission generated a HARQ ACK; (b) the remote WTRU may choose the relay WTRU for which the consecutive HARQ DTX (Discontinue Transmission) counter (used for measurements of SL RLF (Radio Link Failure)) is a minimum; (c) the remote WTRU may prioritize the relay WTRU in which HARQ feedback is enabled, or was enabled for a recent previous transmission.

[0144] Nineth factor: SL measurements / conditions. For example, a remote WTRU may determine the relay WTRU for a transmission of a PDU based on SL measurements such as SL CQI (Channel Quality Indicator), SL RSRP, SL CBR (Channel Busy Ratio), SL CR (Channel Occupancy Rate], etc. The remote WTRU may transmit a packet to the relay WTRU having the maximum SL RSRP. The remote WTRU may select any relay having SL RSRP above a threshold.

[0145] Tenth factor: Uu measurements / conditions. For example, a remote WTRU may determine the relay WTRU to send the PDU based on Uu measurements such as Uu RSRP, Uu CQI, etc. The remote WTRU may transmit a packet to the relay WTRU having the maximum Uu RSRP. The remote WTRU may select any relay having Uu RSRP above a threshold.

[0146] Eleventh factor: positioning information. For example, a remote WTRU may determine the relay WTRU to send the PDU based on the positioning information of the relay WTRU and / or remote WTRU. The remote WTRU may transmit a packet to the relay WTRU that is closest to the remote WTRU. The remote WTRU may transmit a packet to a relay WTRU as long as the distance to the relay WTRU is below a configured threshold.

[0147] Twelfth factor: gNB / cell relationship. For example, a remote WTRU may determine the relay WTRU to send the PDU based on the relationship between the cell / gNB that the remote WTRU is in coverage with, and the cell / gNB to which the relay WTRU is connected. The remote WTRU may transmit a packet to the relay WTRU connected to the same cell / gNB, possibly for only some of the data.

[0148] Thirteenth factor: Power headroom. For example, a remote WTRU may determine the relay WTRU, or whether to send on Uu, based on the relative power headroom of the relay WTRUs and the remote WTRU itself

[0149] A remote WTRU may receive information associated with the above factors from the relay WTRU.

[0150] Without loss of generality, a remote WTRU may use a combination of the above conditions to determine whether to transmit a PDU via Uu directly, or via a relay WTRU. For example, such may be in the context of using a flexible grant (as described in connection with embodiment 5).

[0151] Relay WTRU may be configured with a grant allowing / restricting relayed traffic

[0152] In one example embodiment, a relay WTRU may be configured with a grant allowing / restricting relayed traffic, possibly where such relayed traffic has some specific property(ies), such as: (i) the QoS (e.g., priority, PDB) of the data associated with the remote WTRU; (ii) the SL LCH configured to the remote WTRU; (iii) the timing of the SL grant compared to the Uu grant; (iv) the SL measurements / conditions; (v) the size of the SL grant or SL transmission; (vi) positioning information; (vii) gNB / cell relationship

[0153] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the SL priority of the data is above a threshold.

[0154] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the relay contains data which is associated / not associated with one or more particular SL LCHs.

[0155] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the SL RSRP with the remote WTRU is above a threshold.

[0156] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the distance to the remote WTRU is below a threshold.

[0157] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the time between the Uu grant and SL grant carrying the relayed data is above / below a threshold.

[0158] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the remaining PDB of the data is below a threshold.

[0159] For example, a relay WTRU may be configured with a grant which is allowed for transmission of relayed data from a remote WTRU if the remote WTRU cell is the same as the relay WTRU cell.

[0160] Selection of a relay based on a SL LCH restriction

[0161] In one example embodiment, a remote WTRU may be configured with a SL LCH restriction associated with a relay WTRU. Such restriction may be determined based on any of the factors described above.

[0162] For example, a remote WTRU may be assigned (or select) a SL grant for transmission to a specific relay WTRU (the selected relay WTRU). The relay WTRU may be selected by the remote WTRU based on any of the factors described above. Alternatively, the relay WTRU may be indicated in the SL grant from the network. During SL LCP, the remote WTRU may select only data from SL LCHs which are allowed for the specific relay WTRU. Such allowed SL LCHs may be based on any of the above factors and tied to the SL LCH based on (pre)configuration. As nonlimited examples: (i) if the selected relay WTRU for the SL grant has Uu RSRP < threshold, exclude any data from a SL LCH not allowed with relay WTRUs having Uu RSRP < threshold; (ii) if the selected relay WTRU for the SL grant has Uu RSRP > threshold, exclude any data from a SL LCH not allowed with relay WTRUs having Uu RSRP > threshold; (iii) if the selected relay WTRU for the SL grant is controlled by a different cell / gNB compared than the remote WTRU, exclude any data from a SL LCH not allowed with relay WTRUs under the control of different cell / gNB than the remote WTRU; (iv) if the selected relay WTRU for the SL grant has an upcoming Uu grant that is above / below a threshold in size, exclude any data from a SL LCH not allowed with upcoming Uu grants that are above / below a threshold in size; (v) if the selected relay WTRU for the SL grant has an upcoming Uu grant that is a configured grant resource, exclude any data from a SL LCH not allowed when upcoming Uu grants are a configured grant resource; (vi) if the selected relay WTRU for the SL grant has a BSR that is above a threshold, exclude any data from a SL LCH not allowed with relay WTRUs having BSR above a threshold; (vii) if the selected relay WTRU for the SL grant has reported SR / BSR within a configured window of the SL grant, exclude any data from a SL LCH not allowed with relay WTRUs having reported SR / BSR; (viii) if the selected relay WTRU for the SL grant has a Uu grant which occurs within a (pre)configured time window of the SL grant timing, exclude any data from a SL LCH not allowed with relay WTRUs having Uu grants which occur within (pre)configured time window of the SL grant timing; (ix) other factors for determination of the relay WTRU described above also can be used for the SL LCH restriction.

[0163] Selection of a relay based on an applicable upcoming Uu grant

[0164] In one embodiment, a remote WTRU may select a relay WTRU based on the knowledge of a Uu grant to that relay WTRU which meets some applicability criteria associated with the PDU to be sent to the relay WTRU. For example, a remote WTRU may select a relay WTRU if the relay WTRU has an applicable Uu grant. For example, a remote WTRU may select any relay WTRUs having an applicable Uu grant. For example, a remote WTRU may select the relay WTRU having the largest number of applicable grants.

[0165] Such criteria may be in the form of a restriction configured for the Uu grant. For example, if the remote WTRU can send the PDU to two different relay WTRUs having a Uu grant available within a time window, the remote WTRU may select the relay WTRU for which the Uu grant does not restrict transmission of the data in the PDU being sent from the remote WTRU to the relay WTRU.

[0166] Such criteria may be in the form of the timing and / or size of the Uu grant, possibly with respect to the SL grant or amount of data transmitted in the SL grant. Specifically, an applicable Uu grant may be a Uu grant for which any or a combination of the following is satisfied: (i) the Uu grant occurs within a time period / window, relative to the timing of the SL grant, the PDB of the data included in the SL grant, or similar. For example, the Uu grant occurs no later than the PDB or end-to-end latency of the data in the SL grant For example, the Uu grant occurs no earlier than a relaying latency, which may be indicated by the relay, computed by the remote WTRU based on data indicated by the relay, or configured by the network, (ii) The size of the Uu grant is sufficient to carry the relayed SL PDU. For example, a remote WTRU may be configured with a mapping table or mapping function which maps the number of information bits in the SL PDU to a required Uu grant size. If the Uu grant size is at least as large as the required Uu grant size, the Uu grant can be considered as applicable. For example, a remote WTRU may compute the size of the Uu grant it may require (if it were to transmit the information in the SL grant on its own Uu interface), and may determine whether the Uu grant of a relay WTRU is applicable based on whether the Uu grant is at least this size. In addition, the remote WTRU may be configured with a translation function, scale factor, or similar, to convert between its own Uu grant size and a relay WTRU’s Uu grant size. Such function may be based on any of the information provided by the relay WTRU herein.

[0167] For example, a remote WTRU may select a relay WTRU due to the presence of an applicable Uu grant for the relay WTRU.

[0168] A relay may use one or more of the decision factors described above to select between different relay WTRU’s each having an applicable Uu grant. Different factors and combination of factors may be used for selecting between relays with an applicable Uu grant available.

[0169] Specifically: (i) if a factor is satisfied, the remote WTRU may select a relay WTRU with an applicable Uu grant, if one is present; (ii) if a factor is satisfied, the remote WTRU may prioritize selection of a relay WTRU with an applicable Uu grant; (iii) if a first factor is satisfied, the remote WTRU may select a relay WTRU with applicable Uu grant that maximizes a second factor, and if it the first factor is not satisfied, the remote WTRU may select a relay WTRU with applicable Uu grant that maximizes a third factor; (iv) one or more factors may be used / prioritized in relay selection in the absence of any relay WTRUs with applicable Uu grants; (v) one or more relay restrictions may be applied in the absence of any relay WTRUs with applicable Uu grants.

[0170] Example selection decisions based on applicability criteria

[0171] In one example embodiment, a remote WTRU may receive (e.g., in PC5-RRC), the set of Uu configured grants from each of its attached relay WTRUs. The remote WTRU may generate a SL PDU in a SL grant, or generate a data transaction / burst to be sent to a relay WTRU. The remote WTRU may determine, from the set of Uu grant instances, the set of applicable Uu grants based on the SL grant of data transaction / burst. The remote WTRU may further select the applicable Uu grant (and by consequence, relay WTRU) based on priority and SL RSRP (if present). Specifically, if the priority associated with the highest priority SL LCH multiplexed into the data to be delivered to the relay WTRU is above a threshold (e.g., high priority data), the remote WTRU may select the relay WTRU having the earliest applicable Uu grant. Alternatively, if the priority is less than or equal to a threshold (e.g., low priority data), the remote WTRU may select the relay WTRU having the largest applicable Uu grant. In the absence of an applicable Uu grant, the remote WTRU may select the relay WTRU with the largest SL RSRP, if such measurements exist or if the link between the remote WTRUs and the relay WTRUs is SL. Alternatively, the remote WTRU may select the relay WTRU that has transmitted Uu SR / BSR to the network.

[0172] An alternative approach to embodiment 1 is for the remote WTRU to tailor the SL grant size (e.g., in mode 2) to an amount of data that each relay can reliably transmit at a given time. In this case, when SL LCP is performed by the remote WTRU, it considers relay WTRU information (i.e., the “capacity” of the relay WTRU).

[0173] A remote WTRU determines the amount of data to be transmitted to a relay (e.g., on a SL grant) at a given time based on Uu buffer status information and QoS of Uu LCHs of the relay WTRUs.

[0174] In an exemplary embodiment, a remote WTRU may receive (e.g., in SL RRC message), from multiple relay WTRUs, QoS information associated with each Uu LCH configured at the relay WTRU (e.g., a PBR associated with each Uu LCH mapped to the SL LCHs). The remote WTRU may receive (e.g., in an SCI message, or adaptation layer control message), from multiple relay WTRUs, buffer status information, including, e.g., an amount of data pending for transmission associated with each Uu logical channel. If the remote WTRU has data pending for transmission based on the SL PBR (e.g., Bj > 0) that is above a threshold, the remote WTRU may select a relay WTRU for transmission of data available at the remote WTRU (e.g., based on SL and / or Uu conditions) that has not been selected yet while there was pending data for transmission (e.g., Bj > 0), and may determine a maximum allowable amount of data to transmit to the relay WTRU (relay capacity), e.g., as a function of 1) the PBR associated with the mapped Uu LCH at the relay WTRU and / or 2) the buffer status of that Uu LCH. If the determined maximum amount is less than the amount of data pending at the remote WTRU, the remote WTRU may select resources for a SL grant for the determined amount (e.g., using mode 2). Otherwise, the remote WTRU may select resources for a SL grant for all data pending (e.g., Bj > 0) for transmission (e.g., using mode 2), may fill the SL grant with SL data for which Bj > 0 using SL LCP, and may transmit the data in the SL grant to the relay WTRU.

[0175] A remote WTRU may determine an amount of data it can reliably transmit to a relay WTRU

[0176] In one embodiment, a remote WTRU may determine an amount of data, associated with data pending for transmission in its own buffers, that the remote WTRU can reliably transmit via a relay WTRU, possibly at a given time, or during a given period of time. In one example, a remote WTRU may determine the amount of data for a specific relay WTRU. Alternatively, a remote WTRU may collectively determine an amount of data across all usable relay WTRUs. Alternatively, a remote WTRU may determine an amount of data, possibly specific to a relay WTRU, for each of its Uu bearers or SL LCHs.

[0177] The remote WTRU can determine the amount of data associated with a relay WTRU based on information received from the relay WTRU. Such may be any information described above. Specifically, the remote WTRU may receive QoS information and / or B SR information and / or Uu grant information and may use a combination of such information to determine the amount of datathat can be reliably sent to the relay WTRU. Additionally, the remote WTRU may use any of the factors described above, possibly in addition to the information from the relay WTRU, to determine the amount of data that can be reliably sent to the relay WTRU. Without loss of generality, the relay WTRU may determine the amount and send it to the remote WTRU.

[0178] In this section, relay capacity may refer to the amount of data determined by the remote WTRU.

[0179] In one example embodiment, the relay capacity may be determined from the PBR of one or more Uu LCHs. For example, the remote WTRU may determine the relay capacity as a function of the PBR configured for the Uu LCHs at the relay WTRU. For example, the relay capacity may be determined as the sum of the PBR of the Uu LCHs to which the relay maps any remote WTRU bearers that are configured to use that relay. For example, the relay capacity associated with a remote WTRU bearer for a specific relay may be determined as the sum of the PBRs configured at the relay WTRU of the Uu LCHs to which the remote WTRU Uu bearer is mapped to at the relay WTRU.

[0180] In another example embodiment, the relay capacity may be determined from the buffer status of one or more Uu LCHs. For example, the relay capacity may be a function of the Uu BSR provided by the relay WTRU. For example, the remote WTRU may compute the capacity, possibly associated with a specific remote WTRU Uu bearer, as some (pre)configured amount minus the amount in the Uu BSR corresponding to the Uu LCHs mapped to the remote WTRU Uu bearer. For example, the remote WTRU may be (pre)configured by the network or predefined with a mapping table that maps relay WTRU Uu BSR to relay capacity.

[0181] In another example embodiment, the relay WTRU may compute its capacity and provide it to the remote WTRU explicitly (e.g., using SL SCI, SL MAC CE, inter device control signal, etc.). Specifically, the relay WTRU may utilize its buffer status to determine the capacity value to send to each remote WTRU. For example, the relay WTRU may compute the capacity, potentially per Uu LCH, as the PBR configured for the Uu LCH minus the current buffer status of the Uu LCH, or some function of PBR and BSR. For example, the relay WTRU may compute the capacity, potentially per Uu LCH, as the PBR configured for the Uu LCH minus the average buffer status of the Uu LCH over a configured time period.

[0182] A relay WTRU may indicate a change / event in capacity to a remote WTRU

[0183] In one embodiment, a relay WTRU may indicate a change in the capacity, or a related event associated with capacity, BSR, PBR, or similar parameters, and may indicate such event to a remote WTRU. For example, a relay WTRU may send an indication to a remote WTRU when:(i) the computed capacity falls above / below a configured threshold, potentially, the relay WTRU may receive such threshold from the remote WTRU (and it may be derived from the remote WTRU buffer status and / or bearer QoS requirements); (ii) the computed capacity changes by a specified amount (e.g., by at least a configured threshold amount); (iii) the Uu BSR, possibly associated with one or more Uu LCHs, reaches / exceeds a configured threshold amount; (iv) he Uu BSR, possibly associated with one or more Uu LCHs, is below a configured threshold amount; (v) he Uu BSR goes above or below an amount computed based on the PBR, for example: (a) the Uu BSR for a LCH is above the PBR for that LCH, (b) the Uu BSR for a LCH reaches a configured percentage of the PBR, (c) the Uu BSR for a LCH associated with relaying of (possibly one or more other) remote WTRUs reaches a threshold, a configured percentage of the PBR, etc.

[0184] A remote WTRU may use relay capacity or change in relay capacity for scheduling decisions

[0185] A remote WTRU may use the relay capacity for scheduling decisions related to data to be transmitted at the remote WTRU, for example, based on one or a combination of the following: (i) the computed relay capacity; (ii) relay indication or event / change; (iii) any information provided by the relay WTRU and described above, such as grant information / indication, BSR information / indication, QoS information, or combination of such; (iv) data available for transmission at the remote WTRU (potentially, in addition to QoS requirements of that data)

[0186] A remote WTRU may perform any of the following: (i) decide / determine which relay(s) the remote WTRU selects to send data to. For example, a remote WTRU may select the relay WTRU with the largest relay capacity. For example, a remote WTRU may select any relay WTRU which has a capacity above a defined amount, where such amount may be related to the remote WTRU’s own buffer status, the remote WTRU’s own PBR / Bj or other LCP quantities, the remote WTRU’s own SL grant size, etc. (ii) Determine how much of the available data to send to a given relay WTRU. For example, a remote WTRU may send an amount of data that is limited to a function of the relay WTRU’s capacity, (iii) Determine the number of relays to use. For example, a remote WTRU may determine the number of relays to select based on whether the capacity of one relay is lower (e.g., on average) than the remote WTRU buffer status. For example, a remote WTRU may determine the number of attached relay WTRUs that the remote WTRU will route data to (possibly for a Uu bearer) based on the capacity provided by each relay WTRU. (iv) Determine whether to use a direct or indirect link to send data. For example, a remote WTRU may use the direct link if the capacity of the attached relay(s) is above a defined amount, (v) Determine whether to trigger an RRC connection. For example, a remote WTRU in IDLE / INACTIVE mayinitiate an RRC connection if the capacity of the attached relay(s) is above a defined amount, (vi) Determine the SL resource selection behavior. For example, a remote WTRU may determine the amount of SL resources to select based on the capacity of the attached relay(s). For example, a remote WTRU may select a maximum number of SL resources determined from the capacity of the attached relay(s). For example, a remote WTRU may trigger SL resource reselection upon change in the capacity indicated by a relay WTRU, possibly if the capacity changes by a certain amount. For example, a remote WTRU may trigger SL resource reselection (or determine the amount of resources to select) based on forwarded Uu grant information from the relay WTRU, as described above, (vii) Determine the size of the data transaction with a peer (e.g., relay) WTRU. For example, a remote WTRU may limit the size of the data transaction to the indicated capacity, (viii) Determine the amount of data to include in a SL grant or a data transaction with the peer WTRU, possibly associated with a specific SL LCH, or end to end bearer (e.g., as part of the LCP procedure). For example, when a remote WTRU performs SL LCP, the remote WTRU may include, in the grant, up to a maximum amount of data from one or more SL LCHs that is determined from the capacity of one or more attached relay WTRUs.

[0187] A remote WTRU may use relay capacity value / indications during Relay prioritization procedure

[0188] In one embodiment, a remote WTRU may use the relay capacity, capacity indications from the relay WTRU, or other similar information or indication associated with quantities, described above, during execution of SL LCP procedure or a similar relay prioritization procedure. Specifically, a remote WTRU may use such information / indication when: (i) determining the amount of data from one or more SL LCH to include in a SL grant initially (e.g., equivalent of a PBR or Bj value); (ii) determining the amount of data from one or more SL LCH to include in a SL grant following satisfying the PBR of all LCHs with data available for transmission; (iii) determining the highest priority SL LCH or the first SL LCH to select when including data into a SL grant to satisfy the PBR of an LCH; (iv) determining which LCH or whether to select an LCH to include data into a grant after the PBR of all LCHs has been satisfied by the grant; (v) determining the amount of data available for transmission at the remote WTRU, possibly associated with a PBR or similar Bj value, that is transmitted to each relay WTRU.

[0189] Relay prioritization procedure to determine the amount of data transmitted to each relay WTRU: a SL and Uu WTRU in legacy performs LCP procedure to determine how to fill a grant using the data available for transmission associated with one or more LCHs. The WTRU starts with the highest priority LCH, and includes, in the MAC PDU associated with the grant, an amountof data for that LCH that is equivalent to the PBR before including data from the next highest priority LCH, and so on.

[0190] In a new relay prioritization procedure, a remote WTRU may determine which relay(s) to use for data at the remote WTRU buffers based on prioritization of relays based on capacity information received from each of the relay WTRUs.

[0191] In one example, when the buffer status at the remote WTRU reaches a specific threshold amount, when the PBR at the remote WTRU reaches a specific threshold amount (e.g., when Bj > threshold or any / all LCHs), or at some periodic time instance, the remote WTRU may trigger a resource selection procedure which may consist of first determining how much data to transmit (e.g., on SL or via a non-3GPP interface) to each of multiple relay WTRUs. The remote WTRU may select a first relay WTRU based on: (i) (pre)configured priority (e.g., select the relay WTRU assigned the highest priority); (ii) Uu RSRP (e.g., select the relay WTRU with the highest Uu RSRP); (iii) Uu grant availability, e.g., select the relay WTRU with the largest amount of Uu resources available in the form of configured grant, e.g., select the relay WTRU with the largest amount of Uu grant within a time window (e.g., the PDB of the data associated with the remote WTRU); (iv) previous relay WTRU selection by the remote WTRU, e.g., select the relay WTRU that was not previously selected by the remote WTRU, e.g., select the relay WTRU that was the least recent relay WTRU selected by the remote WTRU during any prioritization procedure, e.g., select any relay WTRU that was not selected during the current instance of the relay WTRU prioritization procedure; (v) Uu BSR at the relay WTRU, e.g., select the relay WTRU with the smallest buffer status, possibly associated with one or more LCHs (e.g., the higher priority bearer or SL LCH at the remote WTRU that is mapped to a given Uu LCH by the relay WTRU)

[0192] Following selection of a relay WTRU, the remote WTRU may allocate an amount of data pending for transmission based on the received / determined capacity for that relay. For example, the remote WTRU may allocate the lesser of the data available for transmission and the relay capacity to that relay WTRU. For example, the remote WTRU may allocate the lesser of the data available for transmission and a function of the relay capacity (e.g., scaled by the number of relay WTRUs) to that relay WTRU. For example, the remote WTRU may allocate the lesser of the data available for transmission and the relay capacity, up to a maximum of the maximum SL resource allocation size of SL CR. Allocation of an amount of data associated with the relay may result in the remote WTRU: (i) selecting SL resources for transmission to that relay, where the amount of resources is determined by the allocation, and (ii) sending the determined amount of data to the selected relay WTRU (e.g., using an inter-device transfer)

[0193] The remote WTRU may select a subsequent relay WTRU and repeat the above procedure with the subsequent relay WTRU as long as data is available for transmission at the remote WTRU, possibly where PBR or Bj > 0, or the buffer status at the remote WTRU is below a configured threshold.

[0194] Remote WTRU performs LCP procedure on grants indicated by each relay WTRU

[0195] In another example procedure, a remote WTRU may receive, from a relay WTRU, an indication of an upcoming Uu grant (e.g., a configured grant) allocated to that relay WTRU. The remote WTRU may initiate an LCP procedure associated with the data available at the remote WTRU and the grant provided by the relay WTRU. Legacy LCP procedure may be implemented with any of the following differences: (i) when selecting the highest priority SL-LCH or Uu bearers at the remote WTRU with data available to include in the grant, the remote WTRU may select from a subset of the logical channels or bearers that are allowed to be routed via the specific relay, e.g., based on network configuration of the bearers or adaptation layer, where certain LCHs at the remote WTRU may be allowed to be sent only via a subset of relay WTRUs, e.g., based on Uu BSR information from the relay WTRU, for example, if the Uu BSR associated with a specific Uu LCH is larger than a threshold, the remote WTRU cannot select the SL LCHs or Uu bearers which are mapped to that relay WTRU’s Uu LCH for LCP procedure associated with the grant from that relay WTRU, e.g., based on capacity information from the relay WTRU, the relay WTRU may indicate that all remote WTRU logical channels potentially associated with a specific priority cannot be routed via that relay WTRU; (ii) when determining the amount of data from a SL LCH or Uu bearer at the remote WTRU with data available to include as part of the LCP procedure at the remote WTRU, the remote WTRU may include an amount of data, up to the PBR of the bearer configured at the remote WTRU, but may also limit the amount of data based on: e.g., the PBR of the Uu LCH at the relay WTRU to which the remote WTRU’s bearer is mapped. For example, the remote WTRU may fill the grant up to the maximum / minimum of the PBR configured for the remote WTRU’s bearer and the relay WTRU’s Uu LCH to which the remote WTRU bearer is mapped to in the adaptation layer, e.g., the BSR from the relay WTRU associated with a Uu LCH to which the remote WTRU’s bearer is mapped. For example, the remote WTRU may reduce the PBR by a configured amount for each level of BSR at the relay WTRU, or as long as the BSR at the relay WTRU is above a threshold; (iii) rather than using LCP procedure to determine the contents of a MAC PDU, the remote WTRU may employ the modified LCP procedure to: (a) determine the contents of the inter-device transfer from the remote WTRU to the relay WTRU, (b) determine the size of the SL resource grant selected by the remote WTRU (e.g., for a remoteWTRU in mode 1), (c) determine the amount of data to be transmitted by the remote WTRU directly via Uu. For example, the remote WTRU may perform LCP procedure on each of the relay WTRU grants (e.g., configured grants) which occurs within a time window performance of the remote WTRU’s LCP procedure instance. Any remaining data at the remote WTRU, possibly exceeding the PBR, may be transmitted by the remote WTRU over Uu. For example, the remote WTRU may initiate LCP procedure on a direct Uu grant by first performing LCP procedure on each of the relay WTRU Uu grants (e.g., possibly where such grants fall within a specific time window of the Uu grant provided to the remote WTRU) to determine an amount of data to send to each relay WTRU (e.g., via inter-device transfer). The remote WTRU may then perform the LCP procedure.

[0196] About LCP procedure at the remote WTRU considering both remote WTRU Uu grants and relay WTRU Uu grants. In one embodiment, a remote WTRU may perform an LCP procedure considering multiple grants (Uu grant and one or more grants associated with relay WTRUs).

[0197] A remote WTRU may perform LCP considering the combined resources in its own Uu grant and any Uu grants of one or more relay WTRUs. A remote WTRU may consider any Uu grants of relay WTRUs that fall within a specified / defined time window, possibly relative to its own Uu grant, or the remote WTRU may be configured with a relationship between the grants. During LCP procedure, the remote WTRU may perform any or a combination of the following: (i) determine the LCHs whose prioritized data will be sent on its own Uu grant and on the relay(s)’ s Uu grant(s) based on any of the factors described herein (e.g., based on factors, discussed above, for path selection following LCP). Specifically, when performing the LCP procedure for a specific grant (the remote WTRU’s own Uu grant or one of the relay WTRU’s Uu grants), select the highest priority LCH with data available for transmission, considering only the LCHs that will be sent on that specific Uu grant. For example, if the priority of the LCH is above a threshold, use the remote WTRU’s Uu grant. For example, if the priority of the LCH is above a threshold, use the earliest of the remote WTRU’s Uu grant and the relay WTRU Uu grants For example, if a QoS related condition associated with the LCH is met / not met, use the remote WTRU’s own Uu grant, otherwise, use a relay WTRU’s Uu grant, e.g., if the LCH is configured with a specific GBRIf the PDB is below a threshold, e.g., if the PBR is above a threshold, etc. For example, if the remote WTRU is configured in power savings mode and the LCH is configured as power savings sensitive, use the relay WTRU’ s Uu grant for that LCH. For example, if the remote WTRU power headroom is below a threshold, use the relay WTRU’s Uu grant for a subset of the LCHs that satisfy some QoS condition or are configured as such, (ii) Send the prioritized data (e.g., data thatis above Bj of each LCH) in one grant (the prioritized grant) and the remaining data in other grants, (iii) Include only prioritized data (i.e., data that is above Bj of each LCH) in the relay WTRU grants, while the remote WTRU’s grants can contain both prioritized and non-prioritized (i.e., additional data for a LCH that is available for transmission but when Bj < 0) data, (iv) When considering how much data to include in the grants, consider the grants as a single grant while taking a fraction of the size of the relay WTRU’s Uu grant, where the fraction may be any function of a quantity provided by the relay WTRU and described herein (e.g., relay WTRU BSR). (v) When the remote WTRU has decided the data that will be sent on the relay WTRU’s Uu grant, the remote WTRU may perform an inter-device transaction to send the data to the relay WTRU.

[0198] Furthermore, any solution and / or decision criteria, described above, may apply to this scenario also, where selection of the relay to transmit a TB (Transport Block) to may be replaced with selection of a grant (belonging to the remote WTRU or belonging to a relay WTRU).

[0199] About group-like LCP procedure applicable to collaborative WTRUs or a remote WTRU having also a Uu connection, in one embodiment, a single LCP procedure may be performed by multiple WTRUs together on a single Uu grant (e.g., a remote WTRU and multiple relay WTRUs, or a group of collaborative WTRUs).

[0200] In one alternative embodiment, all of the data available for transmission at all WTRUs associated with all LCHs of each WTRU may be considered collectively for the LCP procedure. Specifically, a MAC PDU may be generated and filled with data from multiple WTRUs, starting with the highest priority LCH and up to the PBR of the LCH, until the PBR of all LCHs associated with each of the WTRUs (remote or relay) is satisfied. Following this, if there is additional space in the grant, further (non-prioritized) data from the highest priority LCH (across all WTRUs) is then taken, up to the data available in the WTRUs buffers. With such an alternative, the MAC PDU may include (e.g., as part of the header or control information) an indication of the WTRU to which each portion of data belongs.

[0201] In another alternative, a specific grant may be used for the transmission of data associated with only a single WTRU. Once the WTRU is selected, the WTRU may perform legacy LCP procedure on the grant with its own data. Selection of the WTRU may be based on any or a combination of the following: (i) select the WTRU having data available with the highest priority, (ii) select the WTRU having the largest amount of data with priority above a threshold available, or exceeding the PBR (i.e., Bj for the logical channel is the largest among other WTRUs with priority above the threshold), (iii) select the WTRU that was the least recent to transmit in a grant that is usable by all WTRUs, (iv) select the WTRU that will result in transmission of the maximumamount of prioritized data (Bj>0) among all the WTRUs when using the grant, (v) select the WTRU that will utilize the grant fully or to the maximum amount.

[0202] In another alternative, a WTRU (remote or relay) may be prioritized over other WTRUs for a specific grant. The grant may prioritize a WTRU based on information in the DCI, for example. Specifically, if the grant is addressed to a specific WTRU, the grant may be prioritized for the data associated with that WTRU. For a grant prioritized for a specific WTRU, LCP procedure may be run using any or a combination of the following: (i) the LCHs with Bj>0 are first served for the prioritized WTRU, following which, the LCHs with Bj>0 for the non-prioritized WTRU are served, potentially in order of LCH priority across WTRUs, potentially in one WTRU (further prioritized) before another WTRU, (ii) once all LCHs with Bj>0 are served, the remainder of the grant may be used only for additional data (if available) from the prioritized WTRU, and (iii) once all LCHs with Bj>0 are served, the remainder of the grant may first be used for the prioritized WTRU’s available data, and then only if the grant has additional space, LCHs of other non-prioritized WTRUs can be served (possibly in order of LCH priority across all non-prioritized WTRUs or possibly by serving one WTRU at a time).

[0203] For the in coverage case using mode 1 -like operation, the network is usually aware of the amount of data to be transmitted to each destination using SL BSR. For multipath, if the WTRU decides how much data to be sent to each relay, this information needs to be provided in BSR.

[0204] A remote WTRU may determine the amount of data to report for each path (e.g., L2 ID) to different relays based on buffer status / QoS reported by multiple different relay WTRUs.

[0205] In an exemplary embodiment, a remote WTRU:(i) may receive (e.g., in SL RRC message), from multiple relay WTRUs, QoS information associated with each Uu LCH configured at the relay WTRU (e.g., a PBR associated with each Uu LCH mapped to the SL LCHs), (ii) may receive (e.g., in an SCI message, or adaptation layer control message), from multiple relay WTRUs, Uu buffer status information, including an amount of data pending for transmission associated to each Uu logical channel, (iii) may determine the SL buffer status reported in SL BSR for each L2 destination ID based on the Uu buffer status of each relay WTRU and the priority of the data, e.g., Report zero SL BSR for a L2 ID associated with a relay that has Uu BSR above a threshold, e.g., Report a SL BSR for a L2 ID associated with a relay that is proportional to Uu BSR provided by the relay, e.g., Report a SL BSR for a L2 ID associated with a relay that does not exceed a priority and / or Uu-BSR dependent threshold, (iv) may transmits SL BSR to the network (i.e., on Uu) by including the determined amount of data for each L2 ID associated with each relay WTRU.

[0206] A remote WTRU may report Uu BSR per relay path

[0207] In one embodiment, a remote WTRU with data available for transmission via potentially multiple relay WTRUs may report BSR to the network per L2 destination ID associated with SL. Specifically, the remote WTRU may determine an amount of data pending for transmission associated with its Uu bearers for each L2 destination associated with a relay WTRU. Such alternative may be used in the case where the remote / relay connection is via SL PC5.

[0208] In another alternative, a remote WTRU may report BSR per relay WTRU ID (e.g., C- RNTI). In such a scenario, the BSR MAC CE may indicate, along with the LCH or LCG (Logic Channel Group) ID, the amount of data (potentially associated with such LCH or LCG ID) that will be transmitted to each relay WTRU. The BSR format may be structured as: (i) LCG1 - WTRU1 (representing the data associated with LCG1 that will be sent via WTRU1), (ii) LCG1 - WTRU2 (representing the data associated with LCG1 that will be sent via WTRU2), etc.

[0209] Alternatively, a remote WTRU may decide, based on a LCH or LCG level, which LCH or LCG will be sent via which relay WTRU. Specifically, the WTRU may inform the network (e.g., in a separate message such as an UL MAC CE or UL RRC message) of the mapping between LCG / LCH and relay WTRU. The WTRU may make such decision based on the criteria discussed herein and inform the network. Alternatively, the network may provide such mapping (e.g., in a DL MAC CE or DL RRC message) to the remote WTRU. In such case, the BSR may be structured as in legacy systems, since the network is already aware of the mapping between LCG and relay WTRU. Such alternative may be used in the case where the remote / relay connection is via ideal or non-3GPP link.

[0210] In another alternative, a WTRU (remote or relay) may report BSR associated with data in its own buffers as well as data in the buffers associated with other WTRUs (e.g., other relay WTRUs, or collaborative WTRUs). In one case, each WTRU may have its own LCH / LCG and the data is associated with a WTRU and corresponding LCH / LCG. The BSR format may be structured as: (i) LCG1 - WTRU1 (representing the data associated with LCG1 generated by WTRU1), (ii) LCG2 - WTRU1 (representing the data associated with LCG2 generated by WTRU1), (iii) LCG1 - WTRU2 (representing the data associated with LCG1 generated by WTRU2), etc.

[0211] In another case, the WTRUs may share LCGs / LCHs, in which case, legacy BSR format can be used as each BSR reports data available at all WTRUs associated with the LCH / LCG.

[0212] In this last alternative, BSR may be reported: (i) by the WTRU having the largest amount of data to report, (ii) by the WTRU having the best Uu conditions (e.g., in terms of some channel measurements such as RSRP, CQI, etc.), (iii) by the WTRU having the largest power headroom,(iv) by the WTRU having a grant to report the BSR in, (v) by the WTRU that triggered the SR last, (vi) by the WTRU that is delegated (e.g., by a network message) as the WTRU to report BSR.

[0213] About deetrmination of data per relay path, when determining an amount of data associated with each relay path (e.g., per L2 ID or per C-RNTI), a remote WTRU may use any or a combination of the following items of information.

[0214] First item of information: Uu BSR obtained from the relay WTRU. In one embodiment, a remote WTRU may determine the amount / portion of data to report per relay WTRU based on the Uu BSR obtained from each relay WTRU. Specifically, the remote WTRU may use any of the BSR-related information described above to determine an amount of data reported for each relay WTRU. For example, the remote WTRU may report according to any of the following rules: (i) if the Uu BSR for a relay WTRU, possibly associated with a specific LCH / LCG, is above a threshold, report zero for the BSR associated with that relay WTRU for LCHs / LCGs which are mapped to the corresponding Uu LCH / LCGs by the adaptation layer; (ii) report an amount in BSR for each remote WTRU that is proportional (or inversely proportional) to the Uu BSR reported / received from the relay WTRU, potentially per LCH / LCG that is mapped via the adaptation layer to the corresponding remote WTRU LCH / LCG; (iii) report a BSR associated with a specific relay which does not exceed a configured threshold. Specifically, for each Uu BSR amount reported by the relay WTRU, the remote WTRU may be configured with a corresponding threshold maximum amount to report per relay WTRU. The remote WTRU may report any amount of its BSR that is associated with a relay WTRU, as long as the amount does not exceed the configured threshold. Such threshold may further be configured per priority, per LCH / LCG, or be dependent on other criteria herein (particularly the criteria, defined above, for path selection). Specifically, if the Uu BSR of the relay WTRU is above a threshold, the BSR reported by the remote WTRU and associated to that relay should be below a threshold.

[0215] Second item of information: Grant information received from the relay WTRU. In one embodiment, a remote WTRU may determine the amount / portion of data to report per relay WTRU based on grant information from each relay WTRU. As non-limited examples :(i) a remote WTRU may associate a portion of BSR to a relay WTRU that is proportional to the configured grant resources at the relay WTRU; (ii) a remote WTRU may associate a portion of BSR to a relay WTRU above a configured threshold, if the amount of Uu resources (e.g., in configured grants) for that relay WTRU is above a threshold; (iii) a remote WTRU may receive an indication of a grant (e.g., a dynamic grant) from the relay WTRU. For example, the relay WTRU may forward a Uu grant to the relay WTRU. The remote WTRU may then take into account the presence of thegrant in computing the BSR associated with that relay WTRU. Specifically, the remote WTRU may subtract an amount related to the size of the grant from its buffer status when reporting the BSR associated with the relay WTRU; (iv) a remote WTRU may determine whether or not to report any BSR associated with a relay WTRU based on whether the relay WTRU recently reported Uu BSR to the network. For example, a remote WTRU may cancel a BSR (or may remove the buffer status associated with a relay WTRU from its BSR report) when the relay WTRU reports Uu BSR, possibly following an indication of data availability made by the remote WTRU to the relay WTRU.

[0216] Third item of information: QoS information received from the relay WTRU and / or associated with the remote WTRU data. In one embodiment, a remote WTRU may determine the amount / portion of data to report per relay WTRU based on QoS information from the relay WTRU, possibly in combination with BSR and / or grants, to determine the buffer status reported by the remote WTRU associated with each relay WTRU. For example: (i) the remote WTRU may determine a maximum buffer status associated with each relay WTRU based on the PBR of the Uu LCH / LCG at the relay WTRU. Specifically, the remote WTRU may report a maximum buffer status attributed to the relay WTRU that is proportional to the PBR of the LCH / LCG to which an LCH / LCG at the remote WTRU is mapped by the adaptation layer; (ii) the remote WTRU may be configured with a restriction / rule for reporting an amount of its BSR to each relay that depends on QoS. For example, the relay WTRU may indicate to the remote WTRU whether data mapped to a specific Uu LCH should associated with the relay WTRU or not. For example, the remote WTRU may or may not report an amount associated with a relay WTRU for a logical channel if the GBR associated with the remote WTRU is above / below a configured amount, which may depend on the GBR of the mapped Uu LCH at the relay WTRU.

[0217] Fourth item of information: Capacity. In one embodiment, the measured capacity discussed herein may be used to determine the BSR reported by the remote WTRU associated with each relay WTRU. For example, a remote WTRU may report an amount up to the capacity for a specific relay WTRU. For example, a remote WTRU may first determine a preferred relay WTRU (using decision criteria described herein for selecting a relay WTRU) and may report a buffer status up to the capacity of that relay WTRU associated with that relay WTRU in BSR. The remaining BSR may be reported associated with the other relay WTRUs in a similar manner. In another example, a remote WTRU may report an amount of its buffer status associated with each relay WTRU that is proportional (or inversely proportional) to the capacity associated with that relay WTRU. Inanother embodiment, combinations of the quantities of BSR, QoS, and grants from the relay WTRU can be used to determine the portion of BSR associated with each relay WTRU.

[0218] About remote WTRU triggering SR based on information associated with relay WTRU, in an (e.g., similar) embodiment, information related to aspects, described above, may be used to determine when a remote WTRU triggers SR.

[0219] In one example, a remote WTRU may use Uu BSR information from the relay WTRU to determine whether to trigger SR. For example, if the reported Uu BSR from a relay WTRU is above a threshold, the remote WTRU may trigger SR, possibly upon reception of higher priority data available for transmission and in the case where BSR was not yet reported by the remote WTRU. For example, a remote WTRU may trigger BSR if one or more relay WTRU has not sent Uu BSR to the network, possibly for a determined period of time following the arrival of data at the remote WTRU and / or the indication from the remote WTRU to the relay WTRU of the arrival of such data.

[0220] In another solution, a remote WTRU may trigger SR based on Uu grant information associated with the relay WTRUs. For example, a remote WTRU may trigger SR based on whether or not at least one relay WTRU has an allocated Uu grant, possibly occurring within a determined period of time from the arrival of data at the remote WTRU. For example, a remote WTRU may trigger SR if the Uu grants allocated at the relay WTRU are not usable by the remote WTRU, for example, due to indication by the relay WTRU, or other conditions related to selection of a relay path described above.

[0221] Rather than sending data to a single path, a remote WTRU could send the same data simultaneously to multiple paths since each path has a first hop which is SL, and SL transmission can be groupcast. The relay WTRU can then decide whether or not to forward that data - i.e., path selection can be done by the relay WTRUs.

[0222] The relay WTRU may determine whether to forward or drop a packet received from a remote WTRU based on HARQ feedback received from one or more other relay WTRUs.

[0223] In an exemplary embodiment, a relay WTRU: (i) may be pre-configured with the Physical Sidelink Feedback Channel (PSFCH) occasions in the resource pool to be used by itself and other relay WTRUs, (ii) may be pre-configured with a priority (e.g., based on the timing of the PSFCH resources; for instance, the earlier the PSFCH, the higher the priority), (iii) may receive a groupcast transmission on SL from a remote WTRU intended for multiple relay WTRUs, (iv) if the relay WTRU successfully decodes the transmission on SL, then the relay WTRU, (a) may transmit an ACK on its own PSFCH resource, (b) may decode the PSFCH of the other relay WTRUs, (c) mayforward the packet to the Uu link, if a condition associated with decoding of PSFCH from other relay WTRUs is satisfied, e.g., if PSFCH from other relay WTRUs indicate that less than N relay WTRUs of higher priority sent ACKs, e.g., if none of the relay WTRUs configured as higher priority transmitted an ACK, it may drop the packet without forwarding it on the Uu link if the condition is not satisfied, (v) If the relay WTRU does not decode the packet. The relay WTRU may transmit NACK on its own PSFCH resource.

[0224] A relay WTRU may receive PSFCH occasions of other WTRUs

[0225] A relay WTRU may be configured with a set of PSFCH occasions associated with other relay WTRUs which serve a particular remote WTRU. Specifically, each remote WTRU may be served (in multipath) by a set of relay WTRUs, and these relay WTRUs may all receive configuration of PSFCH for their own SL HARQ ACK transmissions, as well as the SL transmissions of the other relay WTRUs. In one option, a relay WTRU may explicitly receive a set of PSFCH occasions associated with each remote WTRU. Each PSFCH occasion in the set may be reserved for transmission of HARQ feedback associated with transmissions by the remote WTRU to each relay WTRU, including itself. In another option, a relay WTRU may be configured with a set of parameters (e.g., number of PSFCH sets, number of PSFCH resources in a set, etc.), which allows the relay WTRU to determine the timing of the PSFCH resources of other relay WTRUs relative to its own PSFCH resource. For example, given the current legacy procedure for determining a SL WTRU’s own PSFCH resource (relative to the timing of the data transmission resource), a relay WTRU may be configured with a rule for determining the corresponding PSFCH resources of other relay WTRUs serving that same remote WTRU (e.g., frequency difference relative to the relay’s own PSFCH resource, timing difference relative to the relay’s own PSFCH resource, etc.). For example, the relay WTRU may receive (e.g., in RRC signaling) a number of serving relay WTRUs, an ordering of the relay WTRUs, etc. For example, in the case of a set of collaborative WTRUs, a specific WTRU in a set of collaborative WTRUs may receive a number of WTRUs in the set, an ordering in the set (e.g., an explicit order number), etc.

[0226] A relay WTRU may receive UL / DL occasions of other WTRUs

[0227] In a similar fashion as per PSFCH resources, a relay WTRU or a WTRU in a generic set of collaborative WTRU may receive (e.g., in RRC configuration) information about the set of other WTRUs (e.g., the number of WTRUs, the index within the set of WTRUs, a WTRU specific index, etc.). A WTRU may use such configuration to determine a resource associated with UL transmission or DL reception, e.g., an SRS resource associated with that WTRU, among the set of SRS resources for the group of WTRUs, e.g., a Physical Uplink Control Channel (PUCCH)resource associated with that WTRU, among the set of SRS resources for the group of WTRUs, e.g., a portion of an UL grant, within a grant provided to the group of WTRUs, e.g., CSI-RS, SSB, etc., within the set of reference signal transmissions intended for the entire group. The WTRU may further use such configuration to determine a mechanism to compute a new WTRU ID. For example, a WTRU may determine a new WTRU ID as a function of its own WTRU ID (e.g., Cell Radio Network Temporary Identifier (C-RNTI)) and / or a group WTRU ID and / or the number of WTRUs in the group and / or a member ID within the group. For example, a WTRU may use the new WTRU ID to access resources / functions specific to that WTRU in the group, when legacy IDs are applied to the group of WTRUs. The WTRU may further use such configuration to determine a mechanism to compute a security key. For example, a WTRU may derive a WTRU specific key within a group of relays / collaborative WTRUs using a common key as well as the group information configured to it. The WTRU may further use such configuration to determine a mechanism to determine the timing of an action, possibly relative to other WTRUs in the group. For example, a WTRU may determine the timing of an action (performing a measurement, transmitting a message, starting a procedure, starting a timer, etc.) based on the WTRU specific of configuration received in RRC and the group information.

[0228] A (e.g., relay) WTRU action may be contingent on another (Relay) WTRU performing that same action.

[0229] In one embodiment, an action related to reception, transmission, measurement, forwarding, etc. at one WTRU (e.g., a relay WTRU or a WTRU that is part of a collaborative group) may be contingent on whether one or a number of other WTRUs within that group have already performed such action. Such action may include, but not be limited to, any legacy Uu or SL action such as: transmission of a measurement report, transmission of a CQI report, transmission of SR / BSR and / or reporting BSR of the group, transmission of SRS, transmission of WTRU assistance information, transmission of capability information, initiation of a unicast link on SL, transmission of a discovery message, triggering SL resource selection, forwarding of a relayed packet received by a set of relay WTRUs, reception / decoding of a grant, reception / transmission of an RRC message, performance of a procedure (e.g., Uu RLF, SL RLF, beam management, beam failure detection, etc.)., transmission of HARQ feedback, and any other Uu / SL transmission or procedure

[0230] In one embodiment, a WTRU may determine whether to perform a transmission / reception / procedure based on which WTRU(s) have already performed such procedure or indicated their intent or readiness to perform such procedure. The said WTRU may monitor for transmissions from other WTRUs to determine the performance of a procedure byanother WTRU. Alternatively, the said WTRU may monitor transmissions from other WTRUs to determine the intent / readiness to perform such procedure (e.g., in the case where the intent / readiness of performing a procedure can be reflected through a transmission). A WTRU may then determine whether to perform a procedure based on determination of other WTRUs having performed the same procedure, or based on the intent from multiple WTRUs to perform such procedure and / or some arbitration rule. Finally, in accordance with another alternative, the WTRUs may communicate directly (e.g., in inter-device transactions) information about the performance or intent / readiness to perform a procedure.

[0231] A WTRU may determine an arbitration rule based on any or a combination of: (i) network configuration. For example, a WTRU may assign a prioritization or ordering of the WTRUs in a group (e.g., set of relay WTRUs) based on a network configured index or order, as defined herein. Alternatively, the WTRU may implicitly derive such order based on other network configurations (e.g., UE ID, reference signal location, etc.), for example, using the relative order of the resources configured for the individually for the group (e.g., PSFCH resources - the WTRU with the earliest PSFCH resource has the highest priority). Based on such prioritization, a WTRU may determine whether to perform a procedure based on such prioritization rules, (ii) Upper layer (e.g., NAS) configuration. For example, a WTRU may be assigned by upper layers with a member ID used for prioritization in an arbitration rule, (iii) Radio quality. For example, a WTRU may determine its priority in an arbitration rule based on the radio quality (e.g., Uu RSRP, SL RSRP, etc.) measured by the WTRU compared to measurements from other WTRUs. For example, a WTRU with a higher measurement may be considered to have higher priority, (iv) Buffer status. For example, a WTRU may determine its priority in an arbitration rule based on the buffer status (either pending or reported) at the WTRU. For example, a WTRU with a larger buffer status, potentially associated with a specific logical channel or priority, may be given a lower priority, (v) Relaying load. For example, a WTRU may determine its priority in an arbitration rule based on the amount of data still at the WTRU that requires relaying, (vi) Power headroom reporting. For example, a WTRU may determine its priority based on its power headroom. For example, a WTRU with larger power headroom may be associated with a higher priority, (vii) Capability. For example, a WTRU may derive a priority based on capability, possibly relative to other WTRUs in the group, (viii) WTRU location (potentially relative to some reference point). For example, a WTRU that is closer to a reference point (potentially configured) may be considered to have higher priority.

[0232] In one potential WTRU arbitration rule, a WTRU may perform an action if less than N WTRUs (potentially configured) with higher priority have already performed the action or have indicated their intent / readiness to perform the action.

[0233] In another potential arbitration rule, a WTRU may perform an action if its priority (as defined herein) is above a threshold, where such threshold represents a quantity used to derive the priority (e.g., load, RSRP, etc.).

[0234] In another potential arbitration rule, a WTRU may perform an action if no other WTRU has already performed such action.

[0235] In another potential arbitration rule, a WTRU may perform an action if it was the first WTRU to indicate its intent / readiness to perform that action.

[0236] In another potential arbitration rule, a WTRU may perform an action if it was the first WTRU having a priority above a threshold to perform the action or to indicate its intent / readiness to perform an action.

[0237] Relay WTRU forwards a remote WTRU transmission based on HARQ feedback received from another relay WTRU

[0238] In one example embodiment of the above concepts, a relay WTRU may be configured with a set of PSFCH resources for monitoring transmissions of other relay WTRUs in response to a remote WTRU transmission, where such remote WTRU is served by potentially multiple relay WTRUs. A remote WTRU may perform transmission (e.g., data, control) to all of the serving relay WTRUs either simultaneously (e.g., in a SL broadcast transmission) or individually.

[0239] A relay WTRU may successfully decode the packet and report HARQ ACK to the remote WTRU on its own PSFCH resource. Alternatively, a relay WTRU may not decode the packet and report HARQ NACK. A relay WTRU, when it successfully decodes a packet, may further determine whether to forward the packet to the next hop (e.g., the Uu interface) or drop the packet based on reception of HARQ feedback from the other relay WTRUs configured in the same group. As non-limited examples, (i) a relay WTRU may forward the packet if no other relay WTRU has yet to report HARQ ACK to the remote WTRU transmission on SL, a relay WTRU may forward the packet if no other higher priority relay WTRU has yet to report HARQ ACK to the remote WTRU transmission on SL, a relay WTRU may forward the packet if at most N (e.g., an integer number configured by the network or determined based on QoS) relay WTRUs have already reported HARQ ACK to the remote WTRU transmission on SL, and a relay WTRU may forward the packet if at most N higher priority relay WTRUs have reported HARQ ACK to the remote WTRU SL transmission.

[0240] Grants to a remote WTRU have always been either SL or Uu because the Uu resources and SL resources are statically separated by the network using the concept of resource pools. If the WTRUs are given control to use the UL resources for either SL transmission or Uu transmission, it allows the remote WTRU to be scheduled more flexibly to use either direct or indirect paths more efficiently.

[0241] In an embodiment, a remote WTRU may receive a flexible SL / UL grant from the network and determine whether to use the grant for SL transmission (via the relayed path) or UL transmission (via the direct path).

[0242] In an embodiment, a remote WTRU (i) may receive a grant (e.g., in DCI) indicating that transmission using either SL or Uu is allowed in the resource, (ii) may determine, based on one or more conditions, whether to use the grant for UL or SL transmission of multipath data (i.e., data associated with a bearer configured for transmission via either direct or indirect paths). The one or more conditions may be any one or more of the following: (a) remaining latency of the multipath data meeting some threshold compared to the timing of the grant, (b) Uu RSRP measurements meeting a threshold, (c) SL RSRP measurements meeting a threshold, (d) time proximity with other SL or Uu grants provided to the WTRU (e.g., the time gap relative to previously received grant on SL or Uu) meeting a threshold, (e) etc.. The remote WTRU (iii) may create the TB and transmits it on the received grant using SL (e.g., Physical Control Channel (PSCCH) and Physical Sidelink Shared Channel (PSSCH) or UL Physical Uplink Shared Channel (PUSCH) based on the determination

[0243] A WTRU may receive a flexible resource grant

[0244] A WTRU may receive a grant which is identified as a flexible resource grant (e.g., can be used for either a SL transmission or a Uu transmission at the WTRU’s discretion). Such a grant may be received in DCI. For example, a flag or a new DCI format may be used to indicate a grant which can be used flexibly (at the discretion of the WTRU) as either a SL transmission or a Uu transmission. Alternatively, a WTRU may be configured with (pre)configured or predetermined rules to determine which grant(s) are flexible. For example, a WTRU may receive a configured grant configuration, and may determine that every Nth grant in the configured grant configuration is a flexible resource grant. For example, the amount of flexible grants may be based on the bearer configuration of a remote WTRU in multipath (e.g., number of split bearers may determine the number / density of flexible grants).

[0245] A WTRU may use a flexible resource grant for either SL transmissions or Uu transmissions

[0246] In one embodiment, a WTRU (e.g., a remote WTRU in multipath) may use a flexible resource grant for either Uu or SL transmission. Specifically, if a remote WTRU decides to use a grant for SL transmission, the WTRU may perform transmission of SCI followed by PSSCH transmission, using SL-related information in the DCI. On the other hand, if the remote WTRU decides to use a grant for UL transmission, the WTRU may perform transmission of PUSCH / PUCCH using the format indicated in the DCI. A WTRU may determine its usage for a flexible resource grant based on certain rules / conditions. A WTRU may determine whether to use a flexible resource grant for Uu or SL transmission based on one or a combination of the following (e.g., comparison of measurements, combination of conditions, etc.): (i) QoS of data. For example, conditions herein may be configured per priority, bearer, LCH, etc. For example, data of specific priority / QoS / bearers may be configured to always be transmitted; (ii) measurements on Uu. For example, if the Uu RSRP is above a threshold, the WTRU transmits a Uu PDU; (iii) measurements on SL. For example, if the CBR is above a threshold, the WTRU transmits a Uu PDU. For example, if the SL RSRP, possibly of at least one relay WTRU, is above a threshold, the WTRU transmits a SL PDU; (iv) latency of the indirect path. For example, if the estimated / indicated (e.g., from the relay WTRU) latency of the indirect path is below a threshold, the WTRU may transmit a SL PDU; (v) type of the indirect path. For example, conditions herein (e.g., which condition to use, which threshold to use, etc.) may be particular to whether the WTRU is connected to a SL indirect path or a non-3GPP indirect path; (vi) number of indirect paths. For example, if the number of indirect paths, possibly satisfying another condition, is above a threshold, the WTRU may transmit a SL PDU; (vii) other SL / Uu transmission planned by the remote WTRU. For example, the WTRU may transmit a SL PDU if the resource is within N slots of a planned SL transmission, a SL grant, etc.; (viii) relay WTRU resources / grant information. For example, the remote WTRU may transmit a SL PDU if the relay WTRU has an upcoming Uu grant that is usable by the relay WTRU. For example, one or more of the conditions discussed herein above related to grant information at the relay WTRU may be used to determine whether the remote WTRU transmits a SL PDU; (ix) relay WTRU BSR information. For example, one or more of the conditions discussed herein above related to grant information at the relay WTRU may be used to determine whether the remote WTRU transmits a SL PDU. For example, if the relay BSR is above a threshold, the remote WTRU may transmit a Uu PDU; (x) relay WTRU QoS information. For example, one or more of the conditions discussed herein above related to QoS information at the relay WTRU may be used to determine whether the remote WTRU transmits a SL PDU. For example, if the data to be transmitted by the remote WTRU would exceed the PBR (or current Bj) of the corresponding UuLCH of the relay WTRU, the remote WTRU may transmit a Uu PDU; (xi) relay WTRU capacity. For example, one or more of the conditions discussed herein above related to relay capacity may be used to determine whether the remote WTRU transmits a SL PDU. For example, if the relay capacity is above a threshold, the remote WTRU may transmit a Uu PDU; (xii) relay WTRU’s SL DRX cycle. For example, if the grant falls in the relay WTRU’s SL DRX cycle, the remote WTRU may transmit a Uu PDU; (xiii) grant size. For example, the remote WTRU may determine whether to transmit a SL PDU or a Uu PDU in the grant based on the grant size, potentially in combination with other conditions. For example: (a) if the grant size is above a threshold, the WTRU may use a first condition to determine whether to transmit a SL PDU or a Uu PDU, and if the grant size is below a threshold, the WTRU may use a second condition to determine whether to transmit a SL PDU or a Uu PDU; (b) The WTRU may determine the number of information bits that can be included in the transmission (e.g., comparing a SL transmission and a Uu transmission) and may base its decision on that determination: if the SL transmission allows the transmission of more bits, perform a SL transmission, perform a Uu / SL transmission if the Uu / SL transmission allows the prioritized data (i.e., Bj>0) to be transmitted; (xiv) Uu power headroom. For example, if the Uu power headroom is below a threshold, transmit a SL PDU.

[0247] Without loss of generality, any condition described above for selection of the path may be used also for determining the usage of the flexible grant.

[0248] A WTRU may implement LCP restrictions once the transmission type on a grant is determined.

[0249] Following decision of the use of a resource for a SL transmission or a Uu transmission, a WTRU may restrict the LCHs included in the grant as a consequence of such decision. For example, some LCHs may be configured to be transmitted only over SL-only grants and / or Uu- only grants, but not on flexible grants. For example, each of the WTRUs LCHs may be configured with a specific type. For a flexible grant, if the WTRU first selects a LCH of one type, the WTRU may only select LCHs of the same type following that. For example, each LCH may be configured with restrictive conditions (conditions associated with whether or not to allow the LCH to be selected for the grant) which depend on whether the flexible grant is used for SL or Uu transmission. If the grant is used for SL transmission, a first condition may be used, and if the grant is used for Uu transmission, a second condition may be used.

[0250] FIG. 6 is a flowchart illustrating an exemplary process for a remote WTRU to select a relay WTRU from a plurality of candidate relay WTRUs for sidelink communications in a wirelessnetwork as described hereinabove. The flowchart illustrates an exemplary embodiment from the perspective of the remote WTRU.

[0251] At step 601, the remote WTRU establishes connections with a plurality of candidate relay WTRUs.

[0252] At step 603, the remote WTRU determines a priority of the data that it has for transmission to the network. For example, the priority may be determined based on the highest priority of the data available for transmission to the network.

[0253] Next, at step 605, the remote WTRU receives from each candidate relay WTRU information about the Uu configured grant resources at that WTRU.

[0254] At step 607, the remote WTRU determines the suitability of the configured Uu grant resources of the candidate relay WTRUs for transmitting the data to the network.

[0255] At step 609, the remote WTRU receives from the network a mapping of the size of the data that the remote WTRU wants to transmit to the network to the size of the Uu configured grant resources of the relay WTRU candidates.

[0256] At step 611, the remote WTRU selects one of the candidate relay WTRUs based on the suitability determination and the priority of the data. This might involve, for instance, a comparison of the size of the data for transmission to the size of the granted Uu resources at the candidate relay WTRUs.

[0257] Finally, at step 613, the remote WTRU transmits the data to the selected candidate relay WTRU.

[0258] FIG. 7 is a flowchart illustrating a process for selecting sidelink resources for communications between a remote WTRU and a network based on scheduling conditions at the potential relay WTRUs as described hereinabove as viewed from the perspective of the WTRU.

[0259] In step 701, a remote WTRU receives, from each of multiple potential relay WTRUs, QoS information associated with a Uu Logical Channel (LCH) configured at that relay WTRU.

[0260] In step 703, the remote WTRU receives, from each of the multiple potential relay WTRUs, BFI, including an amount of data pending for transmission associated with each Uu LCH.

[0261] In step 705, the remote WTRU determines that it has an amount of data that is pending for transmission that exceeds a threshold.

[0262] In step 707, the remote WTRU selects one of the multiple relay WTRUs that has not been selected while the data was pending for sidelink transmission of the WTRU’s pending data.

[0263] In step 709, the remote WTRU determines a maximum allowable amount of data to transmit to the selected relay WRTU based on the QoS information and the BFI. For example, this may be determined as a function of the associated PBR minus the associated BFI.

[0264] If the determined maximum allowable amount of data for the selected relay WTRU is less than the amount of data pending for transmission at the remote WTRU, flow proceeds from step 709 to step 711, where the remote WTRU selects resources for a Sidelink grant for the determined maximum allowable amount of data.

[0265] If, on the other hand, the determined maximum allowable amount of data is greater than or equal to the amount of data pending for transmission, flow proceeds from step 709 to step 713, where the remote WTRU selects resources for a Sidelink grant for all of the data pending for transmission at the remote WTRU.

[0266] From either step 711 or 713, flow then proceeds to step 715, where the remote WTRU fills a sidelink grant with the selected data.

[0267] Finally, in step 715, the remote WTRU transmits the selected data in the sidelink grant to the selected relay WTRU.

[0268] FIG. 8 is a flowchart illustrating an exemplary process for reporting buffer status to a wireless network in connection with sidelink communications based on relay WTRU scheduling as described hereinabove as viewed from the perspective of the remote WTRU.

[0269] In step 801, the remote WTRU receives, from each of multiple relay WTRUs, QoS information associated with a Uu Logical Channel (LCH) configured at the associated relay WTRU.

[0270] In step 803, the remote WTRU receives, from each of the multiple relay WTRUs, Buffer Status Information (BFI), the BSI including an amount of data pending for transmission associated with a Uu LCH of the associated relay WTRU.

[0271] In step 805, the remote WTRU determines an amount of data to transmit to each relay WTRU based on a Uu buffer status of each relay WTRU received in the BSI of each relay and a priority level of the data that is available for transmission at the remote WTRU.

[0272] Finally, in step 807, the remote WTRU transmits a SL BSR to the network, the SL BSR reporting the amount of data at the remote WTRU that it intends to transmit via each of the relay WTRUs.

[0273] FIG. 9 is a flowchart illustrating an exemplary process for a relay WTRU to determine whether or not to relay groupcast transmission data from a remote WTRU to the network as described hereinabove as viewed from the perspective of the relay WTRU.

[0274] In step 901, a relay WTRU receives a groupcast SL transmission from a remote WTRU.

[0275] In step 903, the relay WTRU attempts to decode the transmission.

[0276] In step 905, the relay WTRU determines whether it has successfully decoded the groupcast SL transmission.

[0277] If not, flow proceeds to step 907, where the relay WTRU sends s NACK back to the remote WTRU and the process ends.

[0278] If, on the other hand, the relay WTRU successfully decodes the groupcast SL transmission, flow instead proceeds from step 905 to step 909, in which the relay WTRU transmits an ACK to the remote WTRU.

[0279] Next, in step 911, the relay WTRU receives and decodes any acknowledgements of the groupcast SL transmission by any other relay WTRUs. This may be done, for instance, by reading any information received on a PSFCH.

[0280] Next, in step 913, the relay WTRU determines if the ACKs / NACKs of the other WTRUs meet a condition indicative of whether or not this relay WTRU needs to forward the groupcast SL data to the network (or can drop the packet because at least one other relay WTRU is handling it). Exemplary condition may include any one or more of (1) the decoded acknowledgements from the other relay WTRUs indicate that less than a predetermined number of the other relay WTRUs acknowledged the groupcast SL transmission and (2) no other relay WTRU configured with a higher priority than the WTRU acknowledged the groupcast SL transmission (also, in which case, this relay WTRU will forward the data to the network).

[0281] Thus, if the other ACK / NACKs meet the condition, flow proceeds from step 913 to step 915, in which the relay WTRU forwards the data to the network on its Uu link with the network.

[0282] On the other hand, if the other ACK / NACKs do not meet the condition, flow instead proceeds from step 913 to step 917, in which the relay WTRU drops the data.

[0283] FIG. 10 is a flowchart illustrating an exemplary process for determining, in a Wireless Transmit / Receive Unit (WTRU), whether to use sidelink resources or Uu resources for data transmission in response to a flexible resource grant as described hereinabove as viewed from the perspective of the WTRU.

[0284] In step 1001, a WTRU receives a resource grant from a wireless network for transmission of data to the network, the grant indicating that the WTRU may use the granted resources for either sidelink transmission or Uu transmission.

[0285] In step 1003, the WTRU determines whether to use the granted resources for SL or Uu data transmission based on a condition. In one embodiment, the condition may be a predeterminedrelationship between remaining latency of the data to be transmitted and the timing of the grant. In another embodiment, the condition may be whether the RSRP of a Uu link with the network meets a threshold. In yet another embodiment, the condition may be whether the RSRP of a sidelink with a relay WTRU meets a threshold.

[0286] Finally, in step 1005, the WTRU transmits data using the granted resources for either SL or Uu (e.g., uplink) according to the decision.

[0287] Referring to FIG. 11, a method 1100, implemented in a WTRU, for transmitting data via a relay WTRU, may comprise a first step wherein the WTRU may receive 1110, from one or more relay WTRUs, a first message comprising respectively first information indicating uplink configured grant resource. The first information indicating uplink configured grant resource may comprise any of a set of uplink configured grants, timing of resources in the configured grants, and size of resources in the configured grants. Prior to receive the first message, the WTRU may establish one or more connections with the at least one or more relay WTRUs.

[0288] The method 1100 may comprise a step wherein the WTRU may receive 1120, from a network, a second message comprising second information indicating a mapping of sidelink PDU size to uplink resource size.

[0289] The method 1100 may comprise a step wherein the WTRU may determine 1130, based on the second message, applicability of the uplink configured grant resource of the one or more relay WTRUs for transmitting data. The data may be data available for transmission. The data may be data available for transmission to the network. The determination of the applicability may comprise uplink grant size is larger than the sidelink grant size by a threshold amount. The determination of the applicability may comprise uplink grant size occurs at least / most a threshold time before the end of PDU of a packet.

[0290] The method 1100 may comprise a step wherein the WTRU may select 1140 a relay WTRU among the one or more relay WTRUs based on the determined applicability. Selecting the relay WTRU may be further based on a timing associated with the configured grant resource of the selected relay WTRU. The method may further comprise a step wherein the WTRU may determine a priority associated with the data, and wherein selecting the relay WTRU may be further based on the priority. The priority associated with the data may be determined based on a highest logical channel priority of the data.

[0291] The method 1100 may comprise a step wherein the WTRU may transmit 1150, to the selected relay WTRU, via a sidelink transmission, the data.

[0292] Although features and elements are provided above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from its spirit and scope, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly provided as such. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It is to be understood that this disclosure is not limited to particular methods or systems.

[0293] The foregoing embodiments are discussed, for simplicity, with regard to the terminology and structure of infrared capable devices, i.e., infrared emitters and receivers. However, the embodiments discussed are not limited to these systems but may be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0294] It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used herein, the term “video” or the term “imagery” may mean any of a snapshot, single image and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms “user equipment” and its abbreviation “UE”, the term “remote” and / or the terms “head mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a number of embodiments of a WTRU; (iii) a wireless-capable and / or wired-capable (e.g., tetherable) device configured with, inter alia, some or all structures and functionality of a WTRU; (iii) a wireless-capable and / or wired-capable device configured with less than all structures and functionality of a WTRU; or (iv) the like. Details of an example WTRU, which may be representative of any WTRU recited herein, are provided herein with respect to FIGs. 1 A-1D. As another example, various disclosed embodiments herein supra and infra are described as utilizing a head mounted display. Those skilled in the art will recognize that a device other than the head mounted display may be utilized and some or all of the disclosure and various disclosed embodiments can be modified accordingly without undue experimentation. Examples of suchother device may include a drone or other device configured to stream information for providing the adapted reality experience.

[0295] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, 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 in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, MME, EPC, AMF, or any host computer.

[0296] Variations of the method, apparatus and system provided above are possible without departing from the scope of the invention. In view of the wide variety of embodiments that can be applied, it should be understood that the illustrated embodiments are examples only, and should not be taken as limiting the scope of the following claims. For instance, the embodiments provided herein include handheld devices, which may include or be utilized with any appropriate voltage source, such as a battery and the like, providing any appropriate voltage.

[0297] Moreover, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices that include processors are noted. These devices may include at least one Central Processing Unit (“CPU”) and memory. In accordance with the practices of persons skilled in the art of computer programming, reference to acts and symbolic representations of operations or instructions may be performed by the various CPUs and memories. Such acts and operations or instructions may be referred to as being “executed”, “computer executed” or “CPU executed”.

[0298] One of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU’s operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to or representative of the databits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs and that other platforms and CPUs may support the provided methods.

[0299] The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile (e.g., Random Access Memory (RAM)) or non-volatile (e.g., Read-Only Memory (ROM)) mass storage system readable by the CPU. The computer readable medium may include cooperating or interconnected computer readable medium, which exist exclusively on the processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories and that other platforms and memories may support the provided methods.

[0300] In an illustrative embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0301] There is little distinction left between hardware and software implementations of aspects of systems. The use of hardware or software is generally (but not always, in that in certain contexts the choice between hardware and software may become significant) a design choice representing cost versus efficiency tradeoffs. There may be various vehicles by which processes and / or systems and / or other technologies described herein may be effected (e.g., hardware, software, and / or firmware), and the preferred vehicle may vary with the context in which the processes and / or systems and / or other technologies are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may opt for a mainly hardware and / or firmware vehicle. If flexibility is paramount, the implementer may opt for a mainly software implementation. Alternatively, the implementer may opt for some combination of hardware, software, and / or firmware.

[0302] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, or examples may be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In an embodiment, several portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors(DSPs), and / or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, may be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing medium used to actually carry out the distribution. Examples of a signal bearing medium include, but are not limited to, the following: a recordable type medium such as a floppy disk, a hard disk drive, a CD, a DVD, a digital tape, a computer memory, etc., and a transmission type medium such as a digital and / or an analog communication medium (e.g., a fiber optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

[0303] Those skilled in the art will recognize that it is common within the art to describe devices and / or processes in the fashion set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those having skill in the art will recognize that a typical data processing system may generally include one or more of a system unit housing, a video display device, a memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computational entities such as operating systems, drivers, graphical user interfaces, and applications programs, one or more interaction devices, such as a touch pad or screen, and / or control systems including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0304] The herein described subject matter sometimes illustrates different components included within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures may be implementedwhich achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Hence, any two components herein combined to achieve a particular functionality may be seen as “associated with” each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated may also be viewed as being “operably connected”, or “operably coupled”, to each other to achieve the desired functionality, and any two components capable of being so associated may also be viewed as being “operably couplable” to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0305] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0306] It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.) and / or “permissive” terms (e.g., the term “is” and / or the term “are” may be interpreted as “may” and / or “might”, the terms ”"refer(s)" may be interpreted as "may refer" and / or "might refer", the terms "receive(s)" may be interpreted as "may receive" and / or "might receive", the terms "support(s)" may be interpreted as "may support" and / or "might support", the terms "interface(s)" may be interpreted as "may interface" and / or "might interface", the terms "transmit(s)" may be interpreted as "may interface" and / or "might interface", "may transmit" and / or "might transmit", the terms "send(s)" may be interpreted as "may send" and / or "might send", the terms "does not refer" (and / or the like) may be interpreted as "may not refer" and / or "might not refer", the terms "does not receive" (and / or the like) may be interpreted as "may not receive" and / or "might not receive", the terms "does not support" (and / or the like) may be interpreted as "may not support" and / or "might not support", the terms "does not interface" (and / or the like) may be interpreted as "may not interface" and / or "might not interface", the terms "does not transmit" (and / or the like) may be interpreted as "may not transmit" and / or "might not transmit", the terms "does not send" (and / or the like) may be interpreted as "may not send" and / or"might not send", etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is intended, the term "single" or similar language may be used. As an aid to understanding, the following appended claims and / or the descriptions herein may include usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim including such introduced claim recitation to embodiments including only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to "at least one of A, B, and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, and C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). In those instances where a convention analogous to "at least one of A, B, or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B, or C" would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Further, the terms "any of followed by a listing of a plurality of items and / or a plurality of categories of items, as used herein, are intended to include "any of," "any combination of," "any multiple of," and / or "any combination of multiples of the items and / or the categories of items, individually or in conjunction with other items and / or other categories of items. Moreover, as used herein, the term "set" is intended toinclude any number of items, including zero. Additionally, as used herein, the term "number" is intended to include any number, including zero. And the term "multiple", as used herein, is intended to be synonymous with "a plurality".

[0307] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual member or subgroup of members of the Markush group.

[0308] As will be understood by one skilled in the art, for any and all purposes, such as in terms of providing a written description, all ranges disclosed herein also encompass any and all possible subranges and combinations of subranges thereof. Any listed range can be easily recognized as sufficiently describing and enabling the same range being broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein may be readily broken down into a lower third, middle third and upper third, etc. As will also be understood by one skilled in the art all language such as "up to," "at least," "greater than," "less than," and the like includes the number recited and refers to ranges which can be subsequently broken down into subranges as discussed above. Finally, as will be understood by one skilled in the art, a range includes each individual member. Thus, for example, a group having 1-3 cells refers to groups having 1, 2, or 3 cells. Similarly, a group having 1-5 cells refers to groups having 1, 2, 3, 4, or 5 cells, and so forth.

[0309] Moreover, the claims should not be read as limited to the provided order or elements unless stated to that effect. In addition, use of the terms "means for" in any claim is intended to invoke 35 U.S.C. §112, T] 6 or means-plus-function claim format, and any claim without the terms "means for" is not so intended.

[0310] Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs); Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and / or a state machine.

[0311] The WTRU may be used in conjunction with modules, implemented in hardware and / or software including a Software Defined Radio (SDR), and other components such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a Near Field Communication (NFC) Module, a liquid crystal display(LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and / or any Wireless Local Area Network (WLAN) or Ultra Wide Band (UWB) module.

[0312] Although the various embodiments have been described in terms of communication systems, it is contemplated that the systems may be implemented in software on microprocessors / general purpose computers (not shown). In certain embodiments, one or more of the functions of the various components may be implemented in software that controls a general- purpose computer.

[0313] In addition, although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.

Claims

CLAIMS1. A method implemented in a wireless transmit / receive unit (WTRU) the method comprising: receiving, from one or more relay WTRUs, a first message comprising respectively first information indicating uplink configured grant resource; receiving, from a network, a second message comprising second information indicating a mapping of sidelink packet data unit (PDU) size to uplink resource size; determining, based on the second message, applicability of the uplink configured grant resource of the one or more relay WTRUs for transmitting data; selecting a relay WTRU among the one or more relay WTRUs based on the determined applicability; and transmitting, to the selected relay WTRU, via a sidelink transmission, the data.

2. The method of claim 1, wherein the data are data available for transmission.

3. The method of claim 1, wherein the data are data available for transmission to the network.

4. The method of claim 1, comprising determining a priority associated with the data, and wherein selecting the relay WTRU is further based on the priority.

5. The method of claim 4, wherein the priority associated with the data is determined based on a highest logical channel priority of the data.

6. The method of claim 1, wherein selecting the relay WTRU is further based on a timing associated with the configured grant resource of the selected relay WTRU.7 The method of claim 1, wherein the determination of the applicability comprises uplink grant size is larger than the sidelink grant size by a threshold amount.

8. The method of claim 1, wherein the determination of the applicability comprises uplink grant size occurs at least / most a threshold time before the end of PDU of a packet.

9. The method of claim 1, wherein the first information indicating uplink configured grant resource comprises any of a set of uplink configured grants, timing of resources in the configured grants, and size of resources in the configured grants.

10. The method of claim 1, comprising, prior to receiving the first message, establishing one or more connections with the at least one or more relay WTRUs.

11. A wireless transmit / receive unit (WTRU), comprising a processor, a transceiver unit and a storage unit, and configured to:receive, from one or more relay WTRUs, a first message comprising respectively first information indicating uplink configured grant resource; receive, from a network, a second message comprising second information indicating a mapping of sidelink packet data unit (PDU) size to uplink resource size; determine, based on the second message, applicability of the uplink configured grant resource of the one or more relay WTRUs for transmitting data; select a relay WTRU among the one or more relay WTRUs based on the determined applicability; and transmit, to the selected relay WTRU, via a sidelink transmission, the data.

12. The WTRU of claim 11, wherein the data are data available for transmission.

13. The WTRU of claim 11, wherein the data are data available for transmission to the network.

14. The WTRU of claim 11, configured to determine a priority associated with the data, and wherein selecting the relay WTRU is further based on the priority.

15. The WTRU of claim 14, wherein the priority associated with the data is determined based on a highest logical channel priority of the data.

16. The WTRU of claim 11, wherein selecting the relay WTRU is further based on a timing associated with the configured grant resource of the selected relay WTRU.17 The WTRU of claim 11, wherein the determination of the applicability comprises uplink grant size is larger than the sidelink grant size by a threshold amount.

18. The WTRU of claim 11, wherein the determination of the applicability comprises uplink grant size occurs at least / most a threshold time before the end of PDU of a packet.

19. The WTRU of claim 11, wherein the first information indicating uplink configured grant resource comprises any of a set of uplink configured grants, timing of resources in the configured grants, and size of resources in the configured grants.

20. The WTRU of claim 11, configured to, prior to receipt of the first message, establish one or more connections with the at least one or more relay WTRUs.

Images