Method and apparatus for path selection for sidelink communications in wireless network

Abstract

The present disclosure relates to processes, methods, architectures, apparatus, systems, devices, and computer program products for and / or for selecting a relay WTRU from a plurality of candidate relay WTRUs for sidelink communication in a wireless network.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 531260, filed August 7, 2023, which is incorporated herein by reference. Technical Field

[0002] This disclosure relates to processes, methods, architectures, apparatuses, systems, devices, and computer program products for and / or for selecting a relay wireless transmit / receive unit (WTRU) from a plurality of candidate relay WTRUs for sidelink communication in a wireless network. Background Technology

[0003] Multipath relay (where each path corresponds to an indirect path) may involve not only the selection of resources by the remote UE, but also the selection of the path that results in the most efficient use of resources in the current hop and the next hop.

[0004] How resource selection and path selection interact when considering these factors requires further investigation. Summary of the Invention

[0005] In an embodiment, the method implemented in a Wireless Transmit / Receive Unit (WTRU) may include the step of receiving a first message from one or more relay WTRUs, the first message respectively including first information indicating uplink configuration permitted resources. The method may further include the step of receiving a second message from the network, the second message including second information indicating a mapping from sidelink Packet Data Unit (PDU) size to uplink resource size. The method may further include the step of determining, based on the second message, the suitability of the uplink configuration permitted resources of the one or more relay WTRUs for data transmission. The method may further include the step of selecting a relay WTRU among the one or more relay WTRUs based on the determined suitability; and the step of transmitting data to the selected relay WTRU via sidelink transmission.

[0006] Data can be data that can be transmitted. Data can be transmitted to a network.

[0007] The method may further include a step of determining the priority associated with the data, wherein the selection of the relay WTRU is also based on priority. The priority associated with the data may be determined based on the highest logical channel priority of the data. The selection of the relay WTRU may further be based on timing associated with the configuration-granted resources of the selected relay WTRU. Determining applicability may include the uplink allowed size being a threshold amount larger than the sidelink allowed size. Determining applicability may include the uplink allowed size occurring at least / at most a threshold time before the end of the packet's PDU.

[0008] The first information indicating uplink configuration permission resources may include any one of the following: a set of uplink configuration permissions, the timing of the resources in the configuration permissions, and the size of the resources in the configuration permissions.

[0009] Before receiving the first message, the method may also include the step of establishing one or more connections with at least one or more relay WTRUs.

[0010] In an embodiment, a wireless transmit / receive unit (WTRU) including a processor, a transceiver unit, and a storage unit can be configured to receive a first message from one or more relay WTRUs, the first message including first information indicating uplink configuration permitted resources; receive a second message from the network, the second message including second information indicating a mapping from sidelink packet data unit (PDU) size to uplink resource size; determine, based on the second message, the suitability of the uplink configuration permitted resources of the one or more relay WTRUs for data transmission; select a relay WTRU from the one or more relay WTRUs based on the determined suitability; and transmit data to the selected relay WTRU via sidelink transmission.

[0011] Data can be data that can be transmitted. Data can be data that can be transmitted to a network.

[0012] The WTRU can be configured to determine the priority associated with data, and the selection of the relay WTRU is also based on priority. The priority associated with the data can be determined based on the highest logical channel priority of the data.

[0013] The selection of a relay WTRU can also be based on timing associated with the configuration-permitted resources of the selected relay WTRU.

[0014] Determining applicability may include making the uplink allowed size larger than the sidelink allowed size by a certain threshold amount. Determining applicability may also include making the uplink allowed size occur at least / at most within a threshold time before the end of the packet's PDU.

[0015] The first information indicating uplink configuration permission resources may include any one of the following: a set of uplink configuration permissions, the timing of the resources in the configuration permissions, and the size of the resources in the configuration permissions.

[0016] A WTRU can be configured to establish one or more connections with at least one or more relay WTRUs before receiving the first message. Attached Figure Description

[0017] A more detailed understanding can be obtained through the following detailed description given by way of example in conjunction with the accompanying drawings. Like the detailed description, the figures in these drawings are illustrative. Therefore, the drawings and detailed description should not be considered limiting, and other equally valid examples are possible. Furthermore, the same reference numerals ("ref") in the figures denote the same elements.

[0018] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0019] Figure 1B This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0020] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown.

[0021] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0022] Figure 2 This is a diagram showing the hypothetical relative positions of remote WTRUs and relay WTRUs in 3GPP Release 17.

[0023] Figure 3 This is a diagram illustrating the protocol stack of the user plane in the L2 U2N relay architecture of 3GPP.

[0024] Figure 4 This is a diagram illustrating the protocol stack of the control plane in the L2 U2N relay architecture of 3GPP.

[0025] Figure 5 This is a schematic diagram illustrating a scenario in which a remote WTRU can communicate with a wireless network / cell tower via a direct path or by using side links via multiple potential indirect paths.

[0026] Figure 6 This is a flowchart illustrating a process for selecting a relay WTRU from a plurality of candidate relay WTRUs for sidelink communication in a wireless network, according to an embodiment.

[0027] Figure 7 This is a flowchart illustrating the process of selecting sidelink resources for communication between a remote WTRU and the network based on scheduling conditions at a potential relay WTRU, according to an embodiment.

[0028] Figure 8 This is a flowchart illustrating the process of reporting buffer status related to sidelink communication to a wireless network based on relay WTRU scheduling according to an embodiment.

[0029] Figure 9 This is a flowchart illustrating a process, according to an embodiment, for selecting a specific relay WTRU from a plurality of potential relay WTRUs for transmitting multicast data from a remote WTRU.

[0030] Figure 10 This is a flowchart illustrating a process, according to an embodiment, for determining in a wireless transmit / receive unit (WTRU) whether to use sidelink resources or Uu resources for data transmission in response to flexible resource permission.

[0031] Figure 11 This is a flowchart illustrating an example of a method implemented in a WTRU for transmitting data via a relay WTRU. Detailed Implementation

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

[0033] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access this content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero Tail Unique Word DFT Spread Spectrum OFDM (ZT UWDTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0034] like Figure 1AAs shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0035] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), node Bs, eNodeBs, home node Bs, home eNodeBs, gNBs, NRNodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each described as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0036] Base station 114a may be part of RAN 104 / 113, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In an embodiment, 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 a desired spatial direction.

[0037] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0039] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0040] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish air interface 116 using new radio (NR).

[0041] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0042] In other embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0043] For example, Figure 1ABase station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c and 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, it is not required that base station 114b access Internet 110 via CN 106 / 115.

[0044] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A Although not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to connecting to RAN 104 / 113, which may utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0045] CN 106 / 115 can also serve as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0047] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0048] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B While processor 118 and transceiver 120 are described as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0049] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, transmitting / receiving element 122 can be a transmitter / detector, for example, configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0050] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in an embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0051] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

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

[0055] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, and / or humidity sensors.

[0056] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of both the uplink (e.g., for transmitting) and the downlink (e.g., for receiving)) 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 hardware (e.g., a choke) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In embodiments, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of either the uplink (e.g., for transmitting) or the downlink (e.g., for receiving) may be concurrent and / or simultaneous.

[0057] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0058] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

[0059] Each of the eNode-B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the uplink (UL) and / or downlink (DL). Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0060] Figure 1C The CN 106 shown 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 is described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] The MME 162 can connect to each eNode-B 162a, 162b, 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0062] The SGW 164 can connect to each eNode B 160a, 160b, or 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, or 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover; triggering paging when DL data is available for WTRUs 102a, 102b, or 102c; and managing and storing the context of WTRUs 102a, 102b, or 102c.

[0063] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0064] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0065] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0067] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or peer into a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP via it. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peering traffic. Peering traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0068] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of a fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0069] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0070] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration described above can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0071] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS. According to a representative embodiment, 802.11ah can support metering-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain very long battery life).

[0072] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one of the STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example due to STAs (only supporting the 1MHz operating mode) sending to the AP, the entire available band can be considered busy, even if most of the band remains idle and may be available.

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

[0074] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 113 can also communicate with CN 115.

[0075] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0076] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0077] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0078] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink (UL) and / or downlink (DL), network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0079] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although each of the foregoing elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0080] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU (Protocol Data Unit) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases (e.g., 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, etc.). AMF 182a and 182b can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi).

[0081] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0082] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. This interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0083] CN 115 can facilitate communication with other networks. For example, CN 115 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 115 and PSTN 108. Furthermore, CN 115 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c can be connected to local data networks (DNs) 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0084] Given Figure 1A-1D as well as Figure 1A-1D As described in the corresponding descriptions herein, one or all of the functions described for one or more of the 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, SMF183a-b, DN 185a-b, and / or any other device described herein (one or more) may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0085] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform 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 to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing and / or testing purposes that can be performed using over-the-air wireless communication.

[0086] One or more emulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios outside of deployment (e.g., testing) wired and / or wireless communication networks and / or test laboratories to implement testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0087] 3GPP Release 17 has specified sidelink (SL)-based WTRU to network relay. Sidelink relay is introduced to support 5G ProSe UE to network relay (U2N relay) functionality, thereby providing network connectivity for U2N remote WTRUs. Both L2 and L3 U2N relay architectures are supported. Aside from controlling sidelink resources, the L3 U2N relay architecture is transparent to the serving RAN of the U2N relay WTRU.

[0088] The U2N trunk WTRU should be in RRC_CONNECTED state to perform unicast data relay. For L2 U2N trunk operations, two RRC state combinations are supported. First, both the U2N trunk WTRU and the U2N remote WTRU should be in RRCCONNECTED state to perform relay unicast data transmission / reception. Second, the U2N trunk WTRU can be in RRC_IDLE, RRC_INACTIVE, or RRC_CONNECTED state, provided that all U2N remote WTRUs connected to the U2N trunk WTRU are in RRC_INACTIVE or RRC_IDLE state.

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

[0090] A single unicast link is established between an L2 U2N relay WTRU and an L2 U2N remote WTRU. Traffic from the U2N remote WTRU via the given U2N relay WTRU and traffic from the U2N relay WTRU should be separated in different Uu radio link control (RLC) channels on the Uu.

[0091] The basic assumption in Rel17 is that the remote WTRU is outside the coverage area. (OOC), such as Figure 2 As shown.

[0092] Release 17 of the 3GPP specification introduced Layer 2 WTRUs into network relays. The primary use case considered was the case of remote WTRUs outside coverage. However, in Release 18, multipath specification was anticipated. In multipath, it is assumed that the remote WTRU is within coverage, thus allowing the use of Uu paths, SL (relay) paths, or both. The description of the multipath work in Rel-18 is as follows: The benefits and potential solutions for multipath support are investigated to enhance reliability and throughput in the following scenarios [RAN2, RAN3] (e.g., by switching between or simultaneously utilizing multiple paths): A UE uses a direct path and an indirect path via 1) a Layer 2 UE to a network relay, or 2) connects to the same gNB via another UE (where UE-UE interconnection is assumed to be ideal), where the solution for 1) will be reused for 2), without excluding the possibility of excluding parts of the solution unnecessary for the operation of 2). The study of benefits and potential solutions will be completed in RAN#98, which will determine whether / how to begin specification work. The UE to network relay reuse in scenario 1 uses the Rel-17 solution as a baseline. It is assumed that support for Layer 3 UE to network relay in multipath scenarios has no impact on the RAN, and that the work and solutions depend on the progress of SA2.

[0093] Figure 3 and Figure 4 The protocol stacks for the user plane and control plane of the L2 U2N relay architecture are shown separately. For both the cyclic prefix (CP) and user plane (UP) at the PC5 interface and Uu interface, the Side Link Relay Adaptation Protocol (SRAP) sublayer sits above the Radio Link Control (RLC) sublayer. The Uu Serving Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), and RRC terminate between the L2 U2N remote WTRU and gNB, while SRAP, RLC, Media Access Control (MAC), and Physical Layer (PHY) terminate at 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 trunks, the SRAP sublayer above the PC5 hop is used solely for bearer mapping purposes. The SRAP sublayer does not exist above the PC5 hop for relaying L2 U2N remote WTRU messages on the BCCH (Broadcast Control Channel) and PCCH (Paging Control Channel). For L2 U2N remote WTRU messages on SRB0, the SRAP sublayer does not exist above the PC5 hop, but it does exist above the Uu hops on both the DL (Downlink) and UL (Uplink) lines.

[0095] For L2 U2N trunks, for the uplink, the Uu SRAP sublayer supports UL bearer mapping between the ingress PC5 trunk RLC channel used for trunking and the egress Uu trunk RLC channel above the L2 U2N trunk WTRU Uu interface. For uplink trunk services, 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 trunk RLC channel. Furthermore, the Uu SRAP sublayer supports L2 U2N remote WTRU identification for UL services. The identity information of the L2 U2N remote WTRU Uu radio bearer and the local remote UE ID are included in the Uu SRAP header at the UL so that the gNB can associate received packets with the specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU. The PC5 SRAP sublayer at the L2 U2N remote WTRU supports UL bearer mapping between the remote WTRU Uu radio bearer and the egress PC5 trunk RLC channel.

[0096] For L2 U2N trunks, for the downlink, the Uu SRAP sublayer supports DL bearer mapping at the gNB, which maps the end-to-end radio bearers (SRB, DRB) of the remote WTRU to a Uu trunk RLC channel over the trunk WTRU Uu interface. The UuSRAP sublayer supports DL bearer mapping and data multiplexing between multiple end-to-end radio bearers (SRBs or DRBs) of L2 U2N remote WTRUs and / or different L2 U2N remote WTRUs and a single Uu trunk RLC channel over the trunk WTRU Uu interface. The UuSRAP sublayer supports remote WTRU identification for DL ​​services. The identity information of the remote WTRU Uu radio bearer and the local remote WTRU ID are included by the gNB in ​​the Uu SRAP header at the DL, so that packets received by the trunk WTRU from the remote WTRU Uu radio bearer are mapped to its associated PC5 trunk RLC channel. The PC5 SRAP sublayer at the trunk WTRU supports DL bearer mapping between the ingress Uu trunk RLC channel and the egress PC5 trunk RLC channel. The PC5 SRAP sublayer at the remote WTRU, based on the identity information included in the UuSRAP header, associates received packets with the specific PDCP entity associated with the correct Uu radio bearer of the remote WTRU.

[0097] The local remote WTRU ID is included in both the PC5 SRAP header and the Uu SRAP header. The L2 U2N trunk WTRU is configured by the gNB using the local remote UE ID to be used in the SRAP header. The remote WTRU obtains its local remote ID from the gNB via a Uu RRC message, which includes RRCSetup, RRCReconfiguration, RRCResume, and RRCReestablishment. In both PC5 and Uu hops, the Uu DRB and Uu SRB are mapped to different PC5 trunk RLC channels and Uu trunk RLC channels.

[0098] The gNB is responsible for avoiding conflicts in the use of local and remote UE IDs. The gNB can update the local and remote UE ID by sending an updated local and remote ID to the relay WTRU via an RRCReconfiguration message. The serving gNB can perform local and remote UE ID updates independently of the PC5 unicast link L2 ID update process.

[0099] The side link supports two scheduling modes—Mode 1 and Mode 2. For WTRUs within the coverage area, the gNB can control whether the WTRU uses Mode 1 or Mode 2 for transmission.

[0100] In Mode 1 scheduling for sidelink WTRUs available in RRC_CONNECTED, the WTRU receives SL grants directly from the network in the downlink control information (DCI). In this case, the WTRU reports the buffer status of SL data packets grouped by destination indexes (where the destination index corresponds to a unique L2 destination ID or a pair of source / destination L2 IDs). If the SL grant is not available for transmission of waiting data, the WTRU may report an SL SR (scheduling request).

[0101] In Mode 2 scheduling, which can be used by WTRUs in any RRC state or WTRUs outside the coverage area, the WTRU is configured with a resource pool from which it performs autonomous resource selection and scheduling. The WTRU selects resources based on information (i.e., sensing results) transmitted from previous Side Link Control Information (SCI) transmissions by other WTRUs.

[0102] Version 18 of the SL relay handles multipathing, where remote WTRUs can be transmitted via direct Uu paths and indirect paths via WTRUs to network relays.

[0103] Remote WTRUs outside network coverage may also want to leverage the bandwidth and reliability extensions of multipathing. This can be achieved using multiple relay WTRUs acting as different paths. Figure 5 The illustration shows a scenario in which a remote WTRU (which may or may not have a direct path) can communicate via multiple indirect paths using SL or ideal (e.g., wired links, non-3GPP wireless links, two attached / co-located devices with different radios, etc.) connections.

[0104] In Rel18 multipath, dual-connectivity (DC)-based modeling is used, which assumes that WTRU routing (i.e., at the PDCP layer) data is either direct or indirect and does not contain information from the MAC layer (e.g., channel quality, etc.). This assumption is made because the direct path is always considered the primary path of transmission, while the indirect path is used to supplement the direct path transmission.

[0105] In Rel19, multipathing can be extended to assume multiple indirect paths. In this case, the concept of a primary path is irrelevant. Furthermore, since multiple indirect paths are associated with the same MAC entity, data routing to different paths can be performed 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] To realize the full advantages of the MAC layer, MAC-based multipath scheduling mechanisms may need to deviate from the SL relay scheduling paradigm. Specifically, the Rel17 relay paradigm assumes independent SL and Uu scheduling. Specifically, a remote WTRU is scheduled to send data to an L2 relay WTRU via mode 1 or mode 2 (i.e., a regular side link), while the L2 relay WTRU, upon receiving data from the remote WTRU, is scheduled by the network as a normal Uu WTRU.

[0107] Although data from the remote WTRU depends on scheduling over both side links and Uu links, there is little to no interaction between the scheduling mechanisms on each link. This assumption is necessary for several reasons. First, in Rel17, the remote WTRU is assumed to be OOC, and the SL scheduler (remote WTRU) and Uu scheduler (network) are assumed to be non-interactive. While interaction between the remote WTRU and the network via relays is theoretically possible, exchanging scheduling information may not be feasible due to the latency and congestion associated with side links. However, exchanging this information is feasible through more efficient SL transmission, or by using ideal links (for the scenario 2 multipath case). In Rel18 multipath, where IC (within coverage) WTRUs can use direct or indirect paths, interaction between schedulers remains unnecessary because the MAC entities are different, and PDCP routing can fulfill the use case.

[0108] The first issue is how to define MAC-based decision criteria for routing. Conventional DC (i.e., primary path and split bearer threshold) routing decisions based on PDCP are suitable for DC assumptions and bandwidth expansion scenarios involving multiple network schedulers. When using two indirect paths, there may not be a statically configured preferred path. Instead, selection should be more dynamic, based on information at the relay (e.g., in the uplink). Essentially, the selection of the relay WTRU (e.g., for UL transmissions) should be made by the remote WTRU based on which relay WTRU is in a better position to send and receive data to the network. Uu permission at the relay WTRU, relay WTRU buffer wait time, the presence of other higher-priority traffic received by the relay WTRU from other remote WTRUs, etc., are all criteria that the remote WTRU should use to select the relay WTRU for transmission. However, it is necessary to define how to represent this criterion at the remote WTRU and provide it to the remote WTRU in an efficient manner (for both SL and non-3GPP interfaces).

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

[0110] Similarly, if remote WTRU data can reach the same network node via multiple paths, it is not necessary to report BSRs for each destination. Multicast on SLs can be used to improve reliability. Multicast allows a single transmission on a sidelink to reach multiple SL RX WTRUs. In multipath relay scenarios, remote WTRUs can rely on multicast to allow a single transmission to reach multiple relay WTRUs. The relay procedure at the relay WTRU for this situation should be further considered. Regarding Uu / SL multipath, besides being modeled as multiple MAC entities, a limitation of Uu and SL multipath is the explicit separation between SL resources and Uu resources. More efficient multipath scheduling schemes require removing this separation.

[0111] In this disclosure, the interface between the relay and the remote WTRU can be a side link / PC5. The standard procedures for data / control transmission between the relay and the remote WTRU can be used for the exchange of control information, SR / BSR information, permission information, etc., as defined in this disclosure.

[0112] Alternatively, the interface between the relay and remote WTRUs can be an ideal link (e.g., a wired link, a non-3GPP wireless link, two attached / co-located devices with different radios, etc.). Data and control exchange can be transparent to the relay WTRU. Specifically, the remote WTRU can access all information related to SR / BSR triggered by the relay WTRU, or can access Uu permission provided to the relay WTRU by the network. Alternatively, data and control exchange can be through specific transactions defined according to the inter-device interface. For example, the remote WTRU can provide the relay WTRU with a PDU that may have a specified size so that the relay WTRU can provide its relay function. For example, the remote WTRU and the relay WTRU can exchange information such as Uu permission information, SR / BSR, etc., via inter-device control messages, via adaptation layer control messages, etc.

[0113] Any discussion in this disclosure regarding the interaction between remote WTRUs and relay WTRUs can be applied to any of the aforementioned connections. For example, although the solution may refer to SL, the solution can also be applied to transactions of predetermined / defined size between remote WTRUs and relay WTRUs.

[0114] In this disclosure, any discussion of the interaction between a remote WTRU and a relay WTRU in the context of a relay WTRU relaying data from a remote WTRU to the network (and vice versa) can also be applied to the context of multiple cooperating WTRUs operating in the context of WTRU aggregation.

[0115] The relay WTRU can send SR / BSR information to the remote WTRU.

[0116] Scheduling at the remote WTRU can utilize SR / BSR information from the relay WTRU. The relay WTRU can send SR / BSR information in sidelink messages (e.g., SCI, SL MAC CE, etc.). Alternatively, the relay WTRU can send SR / BSR information in inter-device control messages, which can be used for communication between WTRUs with ideal / wired / non-3GPP connections. Alternatively, the remote WTRU can check for the occurrence of SR / BSR transmissions by the relay WTRU by monitoring UL transmissions from the relay WTRU, querying the relay WTRU's transmission buffer, or similar techniques applicable to situations where the remote and relay WTRUs have ideal connections.

[0117] The Uu SR / BSR information of the relay WTRU may include: the timing and / or triggering of the Uu SR; the priority of the triggered Uu SR; the timing of the 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 remote WTRU and / or other remote WTRUs; the calculated capacity as defined herein; and an indication of when the calculated capacity is above / below a threshold or defined amount, or changes by a threshold or defined amount.

[0118] Uu SR / BSR information may be sent to a remote WTRU based on some triggers or events associated therewith (e.g., (1) when a Uu SR / BSR is triggered by a relay WTRU; (2) when a BSR is triggered / transmitted under certain conditions that relate to the amount of report data associated with the remote WTRU, other remote WTRUs, or all relay data; (3) when a state transition occurs at a relay WTRU (e.g., the relay WTRU transitions to the RRC_CONNECTED state); and (4) when a first BSR is triggered / transmitted after the relay WTRU receives data associated with one of the aforementioned factors from a remote WTRU (or other remote WTRU).

[0119] The relay WTRU can send Uu permission information to the remote WTRU.

[0120] Uu permission information from the relay can be sent to the remote WTRU. For example, the relay WTRU can send configuration permission mode / information to the remote WTRU in the PC5-RRC. Alternatively, the relay WTRU can use SCI transport, MAC CE, or similar means to send an indication of the presence of dynamic permission on the Uu.

[0121] A relay WTRU can forward / relay Uu permission information to a remote WTRU. For example, a relay WTRU can encapsulate DCI messages within SL SCI or inter-device control messages.

[0122] The remote WTRU can decode DCI and / or RRC messages destined for the relay WTRU to determine the presence and / or timing of Uu authorization. For example, a C-RNTI can be provided to the remote WTRU, which can be used to decode Uu authorization applicable to the relay WTRU.

[0123] The relay WTRU may be configured with specific triggers for sending Uu permission information to the remote WTRU, such as (1) configuration / modification of Uu configuration permission configuration at the relay WTRU, and (2) reception of Uu dynamic permission at the relay WTRU, which may be associated with specific characteristics defined herein, may have specific sizes / timings to make it suitable for the relay, and may have specific SL LCH restrictions to make it suitable for the relay.

[0124] The relay WTRU can send QoS information to the remote WTRU.

[0125] QoS information can be sent from the relay WTRU to the remote WTRU. This can include any of the following: (1) adaptation layer configuration; (2) mapping of SL LCH to Uu LCH; (3) mapping of SL priority of SL LCH to the corresponding Uu LCH; (4) MAC layer parameters configured for any Uu LCH, such as (priority, PBR (priority bit rate), GBR (guaranteed bit rate), and average packet size); and (5) transient information associated with the data buffered in the Uu LCH, such as the Bj value (defined in the LCP algorithm in the 3GPP specification to track the amount of priority data to be included in the permission) or other values ​​associated with the Uu LCP procedure.

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

[0127] The relay WTRU can send one or more of the above information in connection with another piece of information.

[0128] In one solution related to the aforementioned information elements, the relay WTRU can send an indication / information to the remote WTRU when a condition associated with another piece of information is met.

[0129] For example, when the Uu BSR at the relay WTRU meets one or more conditions (e.g., below a threshold), the relay WTRU can forward the Uu permission information to the remote WTRU. This may be useful, for example, in notifying the remote WTRU that a Uu permission exists (which can be used by the remote WTRU to transmit Uu data via SL or an ideal link), in which case the permission is available and will not be used by the relay WTRU for the services of other remote WTRUs or for its own services.

[0130] For example, when a relay WTRU is configured with one or more configuration permissions, the relay WTRU may send its BSR information to a remote WTRU (e.g., periodically, or possibly based on some triggers described herein), which may be associated with one or more LCHs.

[0131] In a multipath system with multiple indirect paths, a transmission can be performed on any relay WTRU (e.g., on an SL-permitted path or via a non-3GPP link). To ensure optimal selection, a path decision can be made after the MAC PDU is created (i.e., after the SL LCP). This decision is made using the latest channel / relay information. Specifically, the remote WTRU can first perform packet construction (e.g., for the SL LCP in scenario 1) and use information from the relay WTRUs to determine which relay WTRU to send the MAC PDU to.

[0132] The remote WTRU can determine the intended relay WTRU (e.g., L2 ID) for transmitting the SL MAC PDU based on the Uu CG (Configuration Grant) information and the priority / size of the MAC PDU received from multiple relay WTRUs.

[0133] In the example embodiment, the remote WTRU: (i) can connect to multiple relay WTRUs (e.g., via PC5-RRC), (ii) can determine the priority associated with data that can be transmitted via any of multiple paths through different relay WTRUs (e.g., the maximum LCH priority of the data that can be transmitted), (iii) can receive Uu configuration permission resource information from each of the multiple relay WTRUs (e.g., a set of Uu configuration permissions, timing of each resource, resource size), (iv) can receive a mapping from the network of SL MAC PDU size to the effective Uu resource size, (v) can receive / select SL permissions (e.g., using mode 1 or mode 2), and (vi) can generate packets of a specific size (e.g., SL MAC) by multiplexing data from multiple SL LCHs into packets (e.g., using the SL LCP procedure). (vii) The suitability of the configured permitted resource can be determined based on the network configuration mapping associated with the timing / size of the Uu configured permitted resource relative to the SL data (e.g., the Uu permitted size is a threshold amount larger than the SL permitted size; e.g., the Uu permitted size occurs at least / at most a threshold time before the end of the PDU of the packet). (viii) The relay / path for transmitting packets to the network can be determined based on the suitability criteria, the timing and / or size of the Uu configured permitted resource for each relay WTRU, and / or the priority / SL RSRP (reference signal received power): e.g., selecting the relay WTRU with the earliest applicable Uu permitted resource for high priority data (priority > threshold), e.g., selecting the relay with the maximum applicable Uu permitted resource for low priority data, e.g., sending the maximum SL RSRP to the relay WTRU when there is no applicable Uu permitted resource, etc. (ix) Data in the SL permitted resource can be sent to the selected relay / path.

[0134] The remote WTRU can identify the relay WTRU used for transmission.

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

[0136] First factor: QoS associated with the transmission of the remote WTRU, such as one or more of the following: (i) SL LCH priority / configuration, for example, at a given time, or based on other conditions herein, a specific SL LCH priority may be allowed to be transmitted through one or a subset of the relay WTRUs; as another example, each SL LCH may be configured with a set of allowed / disallowed relay WTRUs. For example, if the PDU includes data from a specific SL LCH, the WTRU may be allowed to send data to the relay based on the allowed / disallowed relays of that specific LCH; (ii) PDB (Packet Delay Budget), Remaining PDB, etc., for example, if the PDB associated with the PDU is higher / lower than a threshold, the remote WTRU may select a specific relay based on one or more other conditions; (iii) PBR, GBR, or similar, for example, the remote WTRU may select the relay WTRU for transmission based on similar rate requirements of PBR, GBR, or SL LCH, possibly compared with another condition herein, or possibly based on information received from the relay WTRU.

[0137] The second factor: the timing of Uu permission associated with each relay WTRU: For example, a remote WTRU may select a relay WTRU for transmitting PDUs on the SL based on the presence of Uu permission and / or knowledge of the timing associated with Uu permission, for example, with the following conditions: (a) the permitted relay is the first / last to appear in time, possibly within a configured time window, and (b) the permitted relay falls within a specific time period (e.g., the PDB of a packet).

[0138] The third factor: the size of the Uu allowance associated with each relay WTRU: (i) For example, a remote WTRU can select a relay WTRU based on whether the Uu allowance is large enough for the SL PDU, which is based on: (a) the remote WTRU can be configured with the Uu allowance size required for a given number / range of SL PDUs, and can select a relay WTRU allocated a sufficiently large Uu allowance; (b) the remote WTRU can be configured with the Uu allowance size required for any data associated with the SL LCH, and can select a relay WTRU with a Uu allowance at least as large as the required Uu allowance size; (c) the remote WTRU can determine the required Uu allowance size for a particular SL PDU based on information provided by the network and / or the relay WTRU, such as the MCS, encoding, etc., and the number of information bits transmitted in the SL PDU. The remote WTRU can select a relay WTRU with a Uu allowance at least large enough for the data in the SL PDU. (ii) As another example, the remote WTRU can select a relay WTRU with the maximum / minimum available Uu allowance. (iii) As another example, a remote WTRU can select a relay WTRU with a Uu allowance whose size is most similar to the SL allowance, SL data size, SL PDU size or similar parameters based on any Uu size determination mechanism described herein.

[0139] Fourth factor: Other properties associated with Uu grants: (i) For example, a remote WTRU may select a relay WTRU based on the properties of a Uu grant, possibly where such a Uu grant is an upcoming Uu grant, or has a (pre)configured or (pre)defined timing relationship with an SL grant or SL PDU configuration, such as: (a) low latency / high priority Uu grant, as indicated in the DCI; (b) the carrier or carrier nature used for grant (e.g., granted versus ungranted); (c) the nature of the duration of the grant (e.g., multi-TTI grant); (d) the nature of the repeat / retransmission mode of the grant; (e) whether the grant is a configured grant or a dynamic grant; (f) whether the grant is a configured type 1 or type 2 grant; and (g) the periodicity of the configured grant, possibly compared to the periodicity of the SL. (ii) For example, a remote WTRU may select a relay WTRU based on the presence of a configured grant resource on the Uu within a time window relative to the SL transmission.

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

[0141] The sixth factor: the buffer status provided by each relay WTRU to the network and / or remote WTRUs. For example, a remote WTRU may determine which relay WTRU to send a PDU to based on the buffer status of the relay WTRU. This may include any of the following: (i) the amount of data and / or the presence of data waiting at the relay WTRU, possibly for a specific Uu LCH; (ii) the amount of data and / or the presence of data waiting at the relay WTRU whose Uu priority is higher than a threshold or higher than a value determined based on another factor in this document; (iii) the amount of data and / or the presence of data waiting at the relay WTRU received from other remote WTRUs (in addition to the aforementioned remote WTRU); (iv) the amount of data and / or the presence of data at the relay WTRU whose PDB is lower than a threshold.

[0142] The seventh factor: the timing of the SR / BSR sent to the network by each relay WTRU. For example, a remote WTRU may determine which relay WTRU to send a PDU to based on when the relay WTRU triggered the SR / BSR, possibly compared to another timing event associated with the PDU itself. (a) For example, a remote WTRU may send a PDU to the relay WTRU that last triggered the SR / BSR transmission, (b) for example, a remote WTRU may send a PDU to a relay WTRU that sent an SR / BSR at least and / or at most the configured amount of time before the remote WTRU constructed the PDU.

[0143] The eighth factor: HARQ (Hybrid Automatic Repeat Request) feedback status from the relay WTRU. For example, a remote WTRU may determine which relay WTRU to send a PDU to based on the status of the HARQ feedback received from the relay WTRU (which may be in response to a previous transmission made to that relay WTRU), such as: (a) the remote WTRU may select the relay WTRU that generated a HARQ ACK from its last transmission; (b) the remote WTRU may select the relay WTRU with the lowest consecutive HARQ DTX (Interrupted Transmission) counter (used for measuring SL RLF (Radio Link Failure)); (c) the remote WTRU may prioritize the relay WTRU where HARQ feedback is enabled or enabled for the most recent previous transmission.

[0144] Ninth Factor: SL Measurement / Conditions. For example, a remote WTRU can determine the trunk WTRU used for PDU transmission based on SL measurements such as SL CQI (Channel Quality Indicator), SL RSRP, SL CBR (Channel Occupancy Rate), SL CR (Channel Occupancy Rate), etc. A remote WTRU can send packets to the trunk WTRU with the highest SL RSRP. A remote WTRU can select any trunk with an SL RSRP above a threshold.

[0145] The tenth factor: Uu measurement / conditions. For example, a remote WTRU can determine the relay WTRU that sends the PDU based on Uu measurements such as Uu RSRP, Uu CQI, etc. A remote WTRU can send packets to the relay WTRU with the highest Uu RSRP. A remote WTRU can select any relay with a Uu RSRP higher than a threshold.

[0146] The eleventh factor: Location information. For example, a remote WTRU can determine the relay WTRU that sends the PDU based on the location information of the relay WTRU and / or the remote WTRU. The remote WTRU can send packets to the relay WTRU closest to it. As long as the distance to the relay WTRU is below a configured threshold, the remote WTRU can send packets to the relay WTRU.

[0147] The twelfth factor: gNB / cell relationship. For example, a remote WTRU can determine the relay WTRU that sends the PDU based on the relationship between the cell / gNB covered by the remote WTRU and the cell / gNB to which the relay WTRU is connected. The remote WTRU can send packets to relay WTRUs connected to the same cell / gNB, possibly for only some data.

[0148] The thirteenth factor: power margin. For example, a remote WTRU can determine whether to transmit on Uu based on the relative power margin of the relay WTRU and the remote WTRU itself.

[0149] The remote WTRU can receive information related to the above factors from the relay WTRU.

[0150] Without loss of generality, a remote WTRU can use a combination of the above conditions to determine whether to transmit the PDU directly via Uu or via a relay WTRU. For example, this could be done in a context where flexible permission is used (as described in conjunction with Example 5).

[0151] The trunk WTRU can be configured with permissions to allow / restrict trunk services.

[0152] In one example embodiment, the relay WTRU may be configured with permission to allow / restrict relay services, which may have certain specific characteristics, such as: (i) QoS (e.g., priority, PDB) of data associated with the remote WTRU; (ii) SL LCH configured to the remote WTRU; (iii) timing of SL permission relative to Uu permission; (iv) SL measurement / condition; (v) size of SL permission or SL transmission; (vi) location information; (vii) gNB / cell relationship.

[0153] For example, a relay WTRU can be configured to allow transmission of relay data from a remote WTRU if the data's SL priority is higher than a threshold.

[0154] For example, a trunk WTRU can be configured to allow transmission of trunk data from a remote WTRU if the trunk includes data associated with or not associated with one or more specific SL LCHs.

[0155] For example, a relay WTRU can be configured to allow transmission of relay data from a remote WTRU if the SL RSRP for the remote WTRU is above a threshold.

[0156] For example, a relay WTRU can be configured to allow the transmission of relay data from a remote WTRU if the distance to the remote WTRU is below a threshold.

[0157] For example, a relay WTRU can be configured to allow transmission of relay data from a remote WTRU if the time between the SL permission and the Uu permission carrying the relay data is higher or lower than a threshold.

[0158] For example, a relay WTRU can be configured to allow transmission of relay data from a remote WTRU if the remaining PDB of the data is below a threshold.

[0159] For example, a relay WTRU can be configured to allow the transmission of relay data from the remote WTRU if the remote WTRU cell is the same as the relay WTRU cell.

[0160] Relay selection is based on SL LCH constraints.

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

[0162] For example, a remote WTRU can be assigned (or selected) an SL permission for transmission to a specific trunk WTRU (the selected trunk WTRU). The remote WTRU can select the trunk WTRU based on any of the factors described above. Alternatively, the trunk WTRU can be indicated in the SL permission from the network. During SL LCP, the remote WTRU can select only data from the SL LCH permitted for the specific trunk WTRU. This permitted SL LCH can be based on any of the factors described above and depends on the (pre)configured SL LCH. As non-restrictive examples: (i) if the relay WTRU selected for SL permission has Uu RSRP < threshold, then any data from SL LCHs not permitted by relay WTRUs with Uu RSRP < threshold is excluded; (ii) if the relay WTRU selected for SL permission has Uu RSRP > threshold, then any data from SL LCHs not permitted by relay WTRUs with Uu RSRP > threshold is excluded; (iii) if the relay WTRU selected for SL permission is controlled by a cell / gNB different from the remote WTRU, then any data from SL LCHs not permitted by relay WTRUs controlled by a cell / gNB different from the remote WTRU is excluded; (iv) if the relay WTRU selected for SL permission has an upcoming Uu permission that is above / below the threshold in size, then any data from SL LCHs not permitted by the upcoming Uu permission that is above / below the threshold in size is excluded; (v) if the relay WTRU selected for SL permission has an upcoming Uu permission as a configured permission resource, then any data from SL LCHs not permitted when the upcoming Uu permission is a configured permission resource is excluded. (vi) Any data from the LCH if the selected trunk WTRU for SL permission has a BSR higher than the threshold, then exclude any data from the SL LCH from the trunk WTRU with a BSR higher than the threshold; (vii) If the selected trunk WTRU for SL permission has already reported an SR / BSR within the configuration window of SL permission, then exclude any data from the SL LCH from the trunk WTRU that has already reported an SR / BSR; (viii) If the selected trunk WTRU for SL permission has a Uu permission that occurs within the (pre)configuration time window of SL permission timing, then exclude any data from the SL LCH from the trunk WTRU with a Uu permission that occurs within the (pre)configuration time window of SL permission timing; (ix) The other factors described above for determining the trunk WTRU may also be used for SL LCH restrictions.

[0163] Select a relay based on the applicable upcoming Uu permission.

[0164] In one embodiment, a remote WTRU can select a relay WTRU based on its knowledge of the Uu permission of the relay WTRU, which satisfies some applicability criteria associated with the PDU to be sent to the relay WTRU. For example, if the relay WTRU has applicable Uu permission, the remote WTRU can select the relay WTRU. For example, the remote WTRU can select any relay WTRU with applicable Uu permission. For example, the remote WTRU can select the relay WTRU with the maximum number of applicable permissions.

[0165] This standard can take the form of restrictions configured for Uu permission. For example, if a remote WTRU can send a PDU to two different relay WTRUs that have Uu permission available within a time window, the remote WTRU can choose a relay WTRU whose Uu permission does not restrict the transmission of data in the PDU from the remote WTRU to the relay WTRU.

[0166] This standard can take the form of a Uu allowance's timing and / or size, which may be relative to an SL allowance or the amount of data transmitted within an SL allowance. Specifically, an applicable Uu allowance can be one that satisfies any or a combination of the following: (i) The Uu allowance occurs within a time period / window relative to the timing of the SL allowance, the PDB of the data included in the SL allowance, etc. For example, the Uu allowance occurs no later than the end-to-end wait time of the data in the PDB or SL allowance. For example, the Uu allowance occurs no earlier than the relay wait time, which can be indicated by the relay, calculated by the remote WTRU based on the data indicated by the relay, or configured by the network. (ii) The size of the Uu allowance is sufficient to carry the relay SL PDU. For example, the remote WTRU may be configured with a mapping table or mapping function that maps the number of information bits in the SL PDU to the required Uu allowance size. A Uu allowance is considered applicable if the Uu allowance size is at least as large as the required Uu allowance size. For example, a remote WTRU can calculate the size of its required Uu permission (if it needs to send information from the SL permission on its own Uu interface) and can determine whether the relay WTRU's Uu permission is applicable based on whether the Uu permission is at least that size. Furthermore, the remote WTRU can be configured with conversion functions, scaling factors, etc., to convert between its own Uu permission size and the relay WTRU's Uu permission size. This functionality can be based on any information provided by the relay WTRU herein.

[0167] For example, a remote WTRU can select a relay WTRU because of the availability of applicable Uu permission for relay WTRUs.

[0168] A relay can use one or more of the decision factors described above to select between different relay WTRUs with applicable Uu permission. Different factors and combinations of factors can be used to select between relays with available applicable Uu permission.

[0169] Specifically: (i) if one factor is satisfied, the remote WTRU may select a trunk WTRU with applicable Uu permission (if any); (ii) if one factor is satisfied, the remote WTRU may preferentially select a trunk WTRU with applicable Uu permission; (iii) if the first factor is satisfied, the remote WTRU may select a trunk WTRU with applicable Uu permission that maximizes the second factor, and if the first factor is not satisfied, the remote WTRU may select a trunk WTRU with applicable Uu permission that maximizes the third factor; (iv) in the absence of any trunk WTRU with applicable Uu permission, one or more factors may be used / preferred in trunk selection; (v) in the absence of any trunk WTRU with applicable Uu permission, one or more trunk restrictions may be applied.

[0170] Example selection decision based on applicability criteria.

[0171] In one example embodiment, a remote WTRU can receive (e.g., in PC5-RRC) a set of Uu configuration permissions from each of its attached relay WTRUs. The remote WTRU can generate SL PDUs within SL permissions, or generate data transactions / bursts to be sent to the relay WTRUs. The remote WTRU can determine a set of applicable Uu permissions from a set of Uu permission instances based on the SL permissions of the data transactions / bursts. The remote WTRU can also select applicable Uu permissions (and thus select a relay WTRU) based on priority and SL RSRP (if present). Specifically, if the priority associated with the highest priority SL LCH in the data multiplexed to be delivered to the relay WTRU is higher than a threshold (e.g., high-priority data), the remote WTRU can select the relay WTRU with the earliest applicable Uu permission. Alternatively, if the priority is less than or equal to the threshold (e.g., low-priority data), the remote WTRU can select the relay WTRU with the largest applicable Uu permission. In the absence of applicable Uu permission, the remote WTRU can select the trunk WTRU with the highest SL RSRP, if such a measurement exists or if the link between the remote WTRU and the trunk WTRU is SL. Alternatively, the remote WTRU can select a trunk WTRU that has already sent a Uu SR / BSR to the network.

[0172] An alternative to Implementation 1 is that the remote WTRU adjusts the allowed SL size (e.g., in Mode 2) to the amount of data that each relay can reliably transmit at a given time. In this case, when the SL LCP is performed by the remote WTRU, it takes into account the relay WTRU information (i.e., the "capacity" of the relay WTRU).

[0173] The remote WTRU determines the amount of data to be sent to the relay at a given time (e.g., on SL permission) based on the Uu buffer status information of the relay WTRU and the QoS of the Uu LCH.

[0174] In an example embodiment, the remote WTRU can receive (e.g., in an SL RRC message) QoS information associated with each Uu LCH configured at the relay WTRU (e.g., the PBR associated with each Uu LCH mapped to the SL LCH) from multiple relay WTRUs. The remote WTRU can also receive (e.g., in an SCI message or an adaptation layer control message) buffer status information from multiple relay WTRUs, including, for example, the amount of data waiting to be transmitted associated with each Uu logical channel. If the remote WTRU has more than a threshold of data waiting to be transmitted based on the SL PBR (e.g., Bj > 0), the remote WTRU can select a relay WTRU available at the remote WTRU for transmitting data that was not selected when there was data waiting to be transmitted (e.g., Bj > 0) (e.g., based on SL and / or Uu conditions), and can determine the maximum allowed amount of data (relay capacity) to be transmitted to the relay WTRU, for example, based on 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 number of data waiting at the remote WTRU, the remote WTRU can select the resource for SL permission based on the determined amount (e.g., using mode 2). Otherwise, the remote WTRU can select the resource for SL permission for all data waiting to be transmitted (e.g., Bj>0) (e.g., using mode 2), can populate the SL permission with SL data of Bj>0 using the SL LCP, and can send the data in the SL permission to the relay WTRU.

[0175] The remote WTRU can determine the amount of data it can reliably send to the relay WTRU.

[0176] In one embodiment, a remote WTRU can determine the amount of data associated with data awaiting transmission in its own buffer, and the remote WTRU can reliably transmit that amount of data via a relay WTRU at a given time or during a given time period. In one example, a remote WTRU can determine the amount of data for a specific relay WTRU. Alternatively, remote WTRUs can collectively determine the amount of data across all available relay WTRUs. Or, a remote WTRU can determine a potentially relay WTRU-specific amount of data for each of its Uu bearers or SL LCHs.

[0177] The remote WTRU can determine the amount of data associated with the relay WTRU based on information received from the relay WTRU. This can be any of the information mentioned above. Specifically, the remote WTRU can receive QoS information and / or BSR information and / or Uu permission information, and can use a combination of these information to determine the amount of data that can be reliably sent to the relay WTRU. Furthermore, the remote WTRU can use any of the above factors, possibly in addition to 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 can determine the amount and send it to the remote WTRU.

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

[0179] In one example embodiment, trunk capacity can be determined based on the PBR of one or more Uu LCHs. For example, a remote WTRU can determine trunk capacity based on the PBR configured at the trunk WTRU for a Uu LCH. For example, trunk capacity can be determined as the sum of the PBRs of any Uu LCH to which the trunk will be configured to use that trunk. For example, trunk capacity associated with a remote WTRU bear of a particular trunk can be determined as the sum of the PBRs configured at the trunk WTRU to which the remote WTRU Uu bear is mapped at the trunk WTRU.

[0180] In another example embodiment, trunk capacity can be determined based on the buffer state of one or more Uu LCHs. For example, trunk capacity can be a function of the Uu BSR provided by the trunk WTRU. For example, a remote WTRU can calculate the capacity that may be associated with a particular remote WTRU Uu bearer as a (pre)configured amount minus the amount in the Uu BSR corresponding to the Uu LCH mapped to the remote WTRU Uu bearer. For example, the remote WTRU can be (pre)configured by the network or predefined using a mapping table that maps trunk WTRU Uu BSRs to trunk capacity.

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

[0182] A relay WTRU can indicate capacity changes / events to a remote WTRU.

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

[0184] Remote WTRUs can make scheduling decisions using relay capacity or changes in relay capacity.

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

[0186] The remote WTRU can perform any of the following: (i) determine which relay(s) to send data to. For example, the remote WTRU can select a relay WTRU with the maximum relay capacity. For example, the remote WTRU can select any relay WTRU with a capacity greater than a defined amount, which may be related to the remote WTRU's own buffer state, the remote WTRU's own PBR / Bj or other LCP quantity, the remote WTRU's own SL allowable size, etc. (ii) determine how much available data to send to a given relay WTRU. For example, the remote WTRU can send a certain amount of data, which is limited by the capacity of the relay WTRU. (iii) determine the number of relays to use. For example, the remote WTRU can determine the number of relays to select based on whether the capacity of a relay is below (e.g., average) the remote WTRU's buffer state. For example, the remote WTRU can determine the number of attached relay WTRUs to which the remote WTRU will route data (possibly for Uu bearers) based on the capacity provided by each relay WTRU. (iv) determine whether to use a direct link or an indirect link to send data. For example, if the attached trunk's capacity is higher than a defined amount, the remote WTRU can use a direct link. (v) Determine whether to trigger an RRC connection. For example, if the attached trunk's capacity is higher than a defined amount, a remote WTRU in an IDLE / INACTIVE state can initiate an RRC connection. (vi) Determine SL resource selection behavior. For example, the remote WTRU can determine the amount of SL resources to select based on the attached trunk's capacity. For example, the remote WTRU can select the maximum number of SL resources determined based on the attached trunk's capacity. For example, the remote WTRU can trigger SL resource reselection when the capacity indicated by the trunk WTRU changes, possibly if the capacity changes by a certain amount. For example, as described above, the remote WTRU can trigger SL resource reselection (or determine the amount of resources to select) based on forwarded Uu permission information from the trunk WTRU. (vii) Determine the size of data transactions with respect to peer (e.g., trunk) WTRUs. For example, the remote WTRU can limit the size of data transactions to the indicated capacity. (viii) Determine the amount of data included in the SL grant or data transactions concerning the peer WTRU, which may be associated with a specific SL LCH or end-to-end bearer (e.g., as part of an LCP procedure). For example, when a remote WTRU performs an SL LCP, the remote WTRU may include up to a maximum amount of data from one or more SL LCHs in the grant, which is determined from the capacity of one or more attached relay WTRUs.

[0187] Remote WTRUs can use relay capacity values / indicators during the relay prioritization process.

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

[0189] The relay prioritization process for determining the amount of data transmitted to each relay WTRU: In normal operation, the SL and Uu WTRUs perform an LCP procedure to determine how much data can be used to populate the allowance for transmissions associated with one or more LCHs. The WTRU starts at the highest priority LCH and includes the amount of data equivalent to the PBR for that LCH in the MAC PDU associated with the allowance before including data from the next highest priority LCH, and so on.

[0190] In the new relay prioritization process, the remote WTRU can determine which relay(s) are used for data at the remote WTRU buffer based on the prioritization of the relays according to the capacity information received from each relay WTRU.

[0191] In one example, when the buffer state 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 LCH), or at some periodic moment, the remote WTRU may trigger a resource selection process that may include first determining how much data to transmit (e.g., on SL or via a non-3GPP interface) to each of the multiple relay WTRUs. The remote WTRU may select the first relay WTRU based on: (i) (pre)configured priority (e.g., selecting the relay WTRU assigned the highest priority); (ii) UuRSRP (e.g., selecting the relay WTRU with the highest Uu RSRP); (iii) Uu permitted availability, e.g., selecting the relay WTRU with the largest amount of Uu resources available in the form of configured permits, e.g., selecting the relay WTRU with the largest amount of Uu permitted within a time window (e.g., the PDB of data associated with the remote WTRU); (iv) selection by the previous relay WTRU of the remote WTRU, e.g., selecting a relay WTRU that was not previously selected by the remote WTRU, e.g., selecting the relay WTRU that was the most recently selected relay WTRU by the remote WTRU during any prioritization process, e.g., selecting any relay WTRU that was not selected during the current instance of the relay WTRU prioritization process; (v) Uu at the relay WTRU. BSR, for example, selects the relay WTRU with the minimum buffer state, which may be associated with one or more LCHs (e.g., a higher priority bearer or SL LCH at a remote WTRU mapped by the relay WTRU to a given Uu LCH).

[0192] After selecting a relay WTRU, the remote WTRU can allocate the amount of data awaiting transmission based on the relay's receive / determined capacity. For example, the remote WTRU can allocate the smaller of the data available for transmission and the relay capacity to the relay WTRU. For example, the remote WTRU can allocate the smaller of the data available for transmission and the relay capacity as a function of (e.g., scaled by the number of relay WTRUs). For example, the remote WTRU can allocate the smaller of the data available for transmission and the relay capacity, up to the maximum value of the maximum SL resource allocation size of the SL CR. The allocation of the amount of data associated with a relay can cause the remote WTRU to: (i) select the SL resources to be transmitted to the relay, where the resource amount is determined by the allocation, and (ii) send the determined amount of data to the selected relay WTRU (e.g., using inter-device transfer).

[0193] The remote WTRU can select a subsequent relay WTRU and repeat the above process for 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 state at the remote WTRU is below the configured threshold.

[0194] The remote WTRU grants permission to perform the LCP procedure for each relay WTRU instruction.

[0195] In another example process, a remote WTRU can receive an indication from a relay WTRU of an upcoming Uu permission (e.g., a configuration permission) assigned to that relay WTRU. The remote WTRU can then initiate an LCP procedure associated with the data available at the remote WTRU and the permission provided by the relay WTRU. The conventional LCP procedure can be implemented with any of the following differences: (i) when selecting the highest priority SL-LCH or Uu bearer at a remote WTRU with data available for inclusion in the permission, the remote WTRU can, for example, select from a subset of logical channels or bearers allowed to be routed via a specific relay based on the network configuration of the bearer or adaptation layer, wherein some LCHs at the remote WTRU may be allowed to be transmitted only via a subset of the relay WTRU, for example, based on Uu BSR information from the relay WTRU, for example, if the Uu BSR associated with a specific Uu LCH is greater than a threshold, the remote WTRU cannot select the SL LCH or Uu bearer mapped to the Uu LCH of that relay WTRU for the LCP procedure associated with the permission from that relay WTRU, for example, based on capacity information from the relay WTRU, the relay WTRU can indicate that all remote WTRU logical channels that may be associated with a specific priority cannot be routed via that relay WTRU; (ii) when determining the SL-LCH from the remote WTRU When dealing with the amount of data carried by an LCH or Uu bearer, where the data may be part of the LCP process at the remote WTRU, the remote WTRU may include the amount of data up to the PBR of the bearer configured at the remote WTRU, but the amount of data may also be limited based on, for example, the PBR of the Uu LCH at the relay WTRU to which the bearer of the remote WTRU is mapped. For example, the remote WTRU may fill allowances up to the maximum / minimum value of the PBR configured in the adaptation layer for the bearer of the remote WTRU and the Uu LCH of the relay WTRU to which the bearer of the remote WTRU is mapped, for example, from the BSR of the relay WTRU associated with the Uu LCH to which the bearer of the remote WTRU is mapped. For example, for each level of the BSR at the relay WTRU, or whenever the BSR at the relay WTRU is above a threshold, the remote WTRU can reduce the PBR configuration amount; (iii) instead of using the LCP procedure to determine the content of the MAC PDU, the remote WTRU can use a modified LCP procedure to: (a) determine the content to be transferred between the remote WTRU and the relay WTRU, (b) determine the size of the SL resource permission selected by the remote WTRU (e.g., for the remote WTRU in mode 1), and (c) determine the amount of data to be transferred directly by the remote WTRU via Uu. For example, the remote WTRU can perform the LCP procedure for each relay WTRU permission (e.g., configuration permission) that occurs within the time window of the remote WTRU's LCP procedure instance.Any remaining data at the remote WTRU (potentially exceeding the PBR) can be transmitted by the remote WTRU via Uu. For example, the remote WTRU can initiate an LCP procedure on a direct Uu permission, which is done by first performing an LCP procedure on each relay WTRU Uu permission (e.g., possibly where such permission falls within a specific time window of the Uu permission provided to the remote WTRU) to determine the amount of data to be sent to each relay WTRU (e.g., via inter-device transfer). The remote WTRU can then execute the LCP procedure.

[0196] Regarding the LCP procedure at the remote WTRU that considers both the remote WTRU Uu permission and the relay WTRU Uu permission. In one embodiment, the remote WTRU may consider multiple permissions (Uu permission and one or more permissions associated with the relay WTRU) to perform the LCP procedure.

[0197] A remote WTRU may perform LCP by considering a combination of its own Uu privileges and any Uu privileges of one or more relay WTRUs. The remote WTRU may consider any Uu privileges of the relay WTRU falling within a specified / defined time window, possibly relative to its own Uu privileges, or the remote WTRU may be configured with a relationship between privileges. During the LCP procedure, the remote WTRU may perform any one or a combination of the following: (i) determine the LCHs that its priority data will be transmitted on its own Uu privileges and the relay's Uu privileges, based on any of the factors described herein (e.g., the factors mentioned above for path selection after LCP). Specifically, when performing the LCP procedure for a particular privilege (either the remote WTRU's own Uu privilege or one of the relay WTRU's Uu privileges), the highest priority LCH with the data available for transmission is selected, considering only the LCHs that will be transmitted on that particular Uu privilege. For example, if the priority of an LCH is above a threshold, the remote WTRU's Uu privilege is used. For example, if the priority of the LCH is higher than a threshold, the earliest of the remote WTRU's Uu permission and the relay WTRU's Uu permission is used. For example, if the QoS-related conditions associated with the LCH are met / not met, the remote WTRU's own Uu permission is used; otherwise, the relay WTRU's Uu permission is used, for example, if the LCH is configured with a specific GBR, if the PDB is lower than a threshold, for example, if the PBR is higher than a threshold, etc. For example, if the remote WTRU is configured in power-saving mode and the LCH is configured to be power-sensitive, the relay WTRU's Uu permission is used for that LCH. For example, if the remote WTRU's power margin is lower than a threshold, the relay WTRU's Uu permission is used to satisfy a certain QoS condition or a subset of LCHs configured in this way. (ii) Prioritized data (e.g., data higher than Bj for each LCH) is sent in one permission (preferred permission), and the remaining data is sent in other permissions. (iii) A relay WTRU grant includes only prioritized data (i.e., data above Bj for each LCH), while a remote WTRU grant may include both prioritized and non-prioritized data (i.e., additional data for LCHs that can be transmitted but when Bj < 0). (iv) When considering how much data to include in a grant, the grant is considered as a single grant, while taking a portion of the size of the relay WTRU's Uu grant, where that portion may be any function of a quantity provided by the relay WTRU and described herein (e.g., the relay WTRU BSR). (v) When the remote WTRU has determined the data to 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 of the solutions and / or decision criteria described above can also be applied to this scenario, where the choice of relay to send TB (transmission block) can be replaced by the choice of permission (belonging to the remote WTRU or to the relay WTRU).

[0199] Regarding the LCP procedure applicable to a similar group of cooperative WTRUs or remote WTRUs that also have Uu connections, in one embodiment, a single LCP procedure may be performed together by multiple WTRUs on a single Uu permission (e.g., a remote WTRU and multiple relay WTRUs, or a group of cooperative WTRUs).

[0200] In an alternative embodiment, all data available for transmission at all WTRUs associated with all LCHs of each WTRU can be collectively considered for the LCP procedure. Specifically, a MAC PDU can be generated and populated with data from multiple WTRUs, starting from the highest priority LCH and proceeding up to the PBR of the LCH, until the PBRs of all LCHs associated with each WTRU (remote or relay) are satisfied. After this, if additional space exists in the allowance, more (non-prioritized) data is retrieved from the highest priority LCH (across all WTRUs) until data becomes available in the WTRU buffer. Using this alternative, the MAC PDU may include (e.g., as part of a header or control information section) an indication of the WTRU to which each data portion belongs.

[0201] In another alternative, a specific permission can be used for data transmission associated with only a single WTRU. Once a WTRU is selected, it can perform a regular LCP procedure with its own data permission. The selection of a WTRU can be based on any one or a combination of the following: (i) selecting the WTRU with the highest priority available data, (ii) selecting the WTRU with the largest data volume and a priority higher than the available threshold or exceeding the PBR (i.e., the logical channel Bj is the largest among other WTRUs with a priority higher than the threshold), (iii) selecting the WTRU with the least recent transmission among the permissions available to all WTRUs, (iv) selecting the WTRU that would result in the transmission of the largest amount of prioritized data (Bj>0) among all WTRUs when the permission is used, and (v) selecting the WTRU that will fully or to the maximum extent utilize the permission.

[0202] In another alternative, for a specific permission, a WTRU (remote or relay) can take precedence over other WTRUs. For example, permission can be prioritized for WTRUs based on information in the DCI. Specifically, if a permission is addressed to a particular WTRU, that permission can be prioritized for data associated with that WTRU. For permission granted to a specific WTRU, the LCP procedure may operate using any one or a combination of the following: (i) LCHs with Bj>0 are first served to the preferred WTRU, followed by LCHs with Bj>0 to non-preferred WTRUs, potentially in order of LCH priority across WTRUs, potentially in one WTRU (further prioritizing) before another; (ii) once all LCHs with Bj>0 have been served, the remaining portion of the permission may be used only for additional data from the preferred WTRU (if available); and (iii) once all LCHs with Bj>0 have been served, the remaining portion of the permission may be used first for available data from the preferred WTRU, and then only if the permission has additional space may the LCHs of other non-preferred WTRUs be served (possibly in order of LCH priority across all non-preferred WTRUs, or possibly by serving one WTRU at a time).

[0203] For coverage scenarios using a similar mode 1 operation, the network typically knows the amount of data sent to each destination using the SL BSR. For multipath, if the WTRU decides how much data to send to each relay, this information needs to be provided in the BSR.

[0204] Remote WTRUs can determine the amount of data (e.g., L2 ID) to be reported to each relay based on buffer status / QoS reported by multiple different relay WTRUs.

[0205] In an example embodiment, the remote WTRU: (i) can receive (e.g., in an SL RRC message) QoS information associated with each Uu LCH configured in the relay WTRU (e.g., the PBR associated with each UuLCH mapped to the SL LCH), (ii) can receive (e.g., in an SCI message or an adaptation layer control message) Uu buffer status information from multiple relay WTRUs, including the amount of data waiting to be transmitted associated with each Uu logical channel, (iii) can determine the SL buffer status reported in the SL BSR for each L2 destination ID based on the Uu buffer status of each relay WTRU and the priority of the data, for example, reporting a zero SL BSR for an L2 ID associated with a relay having a Uu BSR above a threshold, for example, reporting an SL BSR for an L2 ID associated with a relay proportional to the Uu BSR provided by the relay, for example, reporting an SL BSR for an L2 ID associated with a relay not exceeding the priority and / or Uu-BSR related threshold, (iv) can be obtained by including each L2 associated with each relay WTRU The amount of data determined by the ID is used to send the SL BSR to the network (i.e., on Uu).

[0206] Remote WTRUs can report Uu BSRs on a per-relay path basis.

[0207] In one embodiment, a remote WTRU having data available for transmission via potentially multiple relay WTRUs can report a BSR to the network for each L2 destination ID associated with the SL. Specifically, the remote WTRU can determine the amount of pending data transmission associated with its Uu bearer for each L2 destination associated with the relay WTRU. This alternative can be used when the remote / relay connection is via SL PC5.

[0208] In another alternative, the remote WTRU can report a BSR (e.g., C-RNTI) for each relay WTRU ID. In this scenario, the BSR MAC CE, along with the LCH or LCG (Logical Channel Group) ID, can indicate the amount of data to be sent to each relay WTRU (possibly associated with this LCH or LCG ID). The BSR format can be constructed as: (i) LCG1–WTRU1 (representing the data associated with LCG1 to be sent via WTRU1), (ii) LCG1–WTRU2 (representing the data associated with LCG1 to be sent via WTRU2), etc.

[0209] Alternatively, the remote WTRU can determine which LCH or LCG will be transmitted via which relay WTRU based on the LCH or LCG level. Specifically, the WTRU can notify the network (e.g., in a separate message such as a UL MAC CE or UL RRC message) of the mapping between the LCG / LCH and the relay WTRU. The WTRU can make such a decision based on the standards discussed herein and notify the network. Alternatively, the network can provide this mapping to the remote WTRU (e.g., in a DL MAC CE or DL ​​RRC message). In this case, since the network already knows the mapping between the LCG and the relay WTRU, the BSR can be constructed as in a conventional system. This alternative can be used when the remote / relay connection is via an ideal or non-3GPP link.

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

[0211] In another scenario, WTRUs can share LCG / LCH, in which case the standard BSR format can be used because each BSR reports the data available at all WTRUs associated with the LCH / LCG.

[0212] In this last alternative, a BSR can be reported by: (i) the WTRU with the largest amount of reported data, (ii) the WTRU with the best Uu conditions (e.g., in certain channel measurements such as RSRP, CQI, etc.), (iii) the WTRU with the largest power margin, (iv) the WTRU with permission to report a BSR, (v) the WTRU that last triggered the SR, and (vi) the WTRU that is delegated (e.g., via network message) as the WTRU that reports the BSR.

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

[0214] First information item: Uu BSR obtained from the relay WTRU. In one embodiment, the remote WTRU can determine the amount / part of data to be reported by each relay WTRU based on the Uu BSR obtained from each relay WTRU. Specifically, the remote WTRU can use any of the BSR-related information mentioned above to determine the amount of data to be reported for each relay WTRU. For example, the remote WTRU can report according to any of the following rules: (i) if the Uu BSR of a relay WTRU that may be associated with a particular LCH / LCG is higher than a threshold, then report zero BSR for the LCH / LCG mapped by the adapter layer to the corresponding Uu LCH / LCG for that relay WTRU; (ii) report the amount in the BSR for each remote WTRU that is proportional (or inversely proportional) to the Uu BSR reported / received from the relay WTRU, possibly according to each LCH / LCG mapped via the adapter layer to the corresponding remote WTRU LCH / LCG; (iii) report BSRs associated with a particular relay that do not exceed a configured threshold. Specifically, for each Uu BSR amount reported by a trunk WTRU, a remote WTRU can be configured with a corresponding threshold maximum amount to report per trunk WTRU. A remote WTRU can report any amount of its BSR associated with a trunk WTRU, as long as that amount does not exceed the configured threshold. This threshold can also be configured by priority, by LCH / LCG, or depending on other criteria in this document (specifically, the criteria defined above for path selection). Specifically, if a trunk WTRU's Uu BSR is above the threshold, then the BSR reported by the remote WTRU and associated with that trunk should be below the threshold.

[0215] Second information item: Permission information received from the relay WTRU. In one embodiment, the remote WTRU can determine the amount / part of data to be reported by each relay WTRU based on the permission information from each relay WTRU. As a non-limiting example: (i) the remote WTRU can associate a portion of the BSR with the relay WTRU, which is proportional to the configured permission resources at the relay WTRU; (ii) if the amount of Uu resources used for the relay WTRU (e.g., in configured permission) is higher than a threshold, the remote WTRU can associate a portion of the BSR with that relay WTRU; (iii) the remote WTRU can receive permission indications (e.g., dynamic permission) from the relay WTRU. For example, the relay WTRU can forward Uu permission to the relay WTRU. The remote WTRU can then consider the presence of permission when calculating the BSR associated with that relay WTRU. Specifically, when reporting a BSR associated with a relay WTRU, a remote WTRU can subtract an amount related to the allowable size from its buffer status; (iv) a remote WTRU can determine whether to report any BSR associated with a relay WTRU based on whether the relay WTRU recently reported a Uu BSR to the network. For example, when a relay WTRU reports a Uu BSR, a remote WTRU can cancel the BSR (or remove the buffer status associated with the relay WTRU from its BSR report), which may be after the remote WTRU has indicated data availability to the relay WTRU.

[0216] The third information item: QoS information received from the relay WTRU and / or associated with data from the remote WTRU. In one embodiment, the remote WTRU may determine the amount / part of data to be reported by each relay WTRU based on the QoS information from the relay WTRU, possibly in conjunction with BSR and / or permission, to determine the buffer status reported by the remote WTRU associated with each relay WTRU. For example: (i) the remote WTRU may determine the 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 the maximum buffer status attributable to the relay WTRU, which is proportional to the PBR of the LCH / LCG mapped by the adaptation layer at the remote WTRU; (ii) the remote WTRU may be configured with limits / rules for reporting its BSR amount to each relay, which are QoS-dependent. For example, the relay WTRU may indicate to the remote WTRU whether data mapped to a particular Uu LCH should be associated with the relay WTRU. For example, if the GBR associated with a remote WTRU is higher or lower than the configured amount, which may depend on the GBR of the mapped Uu LCH at the relay WTRU, the remote WTRU may or may not report the amount associated with the relay WTRU for the logical channel.

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

[0218] Regarding the remote WTRU triggering SR based on information associated with the relay WTRU, in (e.g., similar) embodiments, the information related to the above aspects can be used to determine when the remote WTRU triggers SR.

[0219] In one example, a remote WTRU can use Uu BSR information from a relay WTRU to determine whether to trigger a SR. For instance, if the reported Uu BSR from the relay WTRU is higher than a threshold, the remote WTRU might trigger an SR when it receives higher-priority data available for transmission, even if the BSR has not yet been reported by the remote WTRU. Alternatively, a remote WTRU might trigger a BSR if one or more relay WTRUs fail to send a Uu BSR to the network, possibly within a defined time period after data arrives at the remote WTRU and / or after the remote WTRU indicates such data arrival to the relay WTRU.

[0220] In another solution, the remote WTRU can trigger the SR based on Uu permission information associated with the relay WTRU. For example, the remote WTRU can trigger the SR based on whether at least one relay WTRU has an assigned Uu permission, which may occur within a defined time period from the arrival of the data at the remote WTRU. For example, if the Uu permission assigned to the relay WTRU is not available to the remote WTRU, for example due to an indication from the relay WTRU, or other conditions related to the selection of the relay path described above, the remote WTRU can trigger the SR.

[0221] A remote WTRU can send the same data to multiple paths simultaneously, instead of sending data to a single path, because each path has a first hop (SL), and SL transmissions can be multicast. The relay WTRU can then decide whether to forward the data—that is, the relay WTRU can perform path selection.

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

[0223] In the example embodiment, the relay WTRU: (i) may have pre-configured Physical Side Link Feedback Channel (PSFCH) timings in the resource pool for use by itself and other relay WTRUs; (ii) may have pre-configured priorities (e.g., timing based on PSFCH resources; e.g., the earlier the PSFCH, the higher the priority); (iii) may receive multicast transmissions on the SL from remote WTRUs, intended for multiple relay WTRUs; and (iv) if the relay WTRU successfully decodes the transmissions on the SL, then the relay WTRU (a) may receive multicast transmissions on its own PSFCH resources. (a) Sending an ACK; (b) Decoding the PSFCH of other relay WTRUs; (c) If the conditions associated with decoding the PSFCH from other relay WTRUs are met, such as if the PSFCH from other relay WTRUs indicates that fewer than N relay WTRUs with higher priority have sent ACKs, or if no relay WTRU configured to send an ACK has sent an ACK, the packet can be forwarded to the Uu link; if the conditions are not met, it can discard the packet without forwarding it on the Uu link; (v) If the relay WTRU does not decode the packet. The relay WTRU can send a NACK on its own PSFCH resource.

[0224] The relay WTRU can receive PSFCH timings from other WTRUs.

[0225] A trunk WTRU can be configured with a set of PSFCH timings associated with other trunk WTRUs serving a particular remote WTRU. Specifically, each remote WTRU can be served by a set of trunk WTRUs (in a multipath), and these trunk WTRUs can all receive PSFCHs configured for their own SL HARQ ACK transmissions and SL transmissions of other trunk WTRUs. In one option, a trunk WTRU can explicitly receive a set of PSFCH timings associated with each remote WTRU. Each PSFCH timing in the set can be reserved for transmissions of HARQ feedback associated with transmissions from the remote WTRU to each trunk WTRU (including itself). In another option, a trunk WTRU can be configured with a set of parameters (e.g., the number of PSFCH sets, the number of PSFCH resources in the sets, etc.) that allow the trunk WTRU to determine the timing of other trunk WTRUs' PSFCH resources relative to its own PSFCH resources. For example, given a current routine procedure for determining the PSFCH resources (timing relative to data transmission resources) of an SL WTRU, a relay WTRU can be configured with rules (e.g., frequency difference relative to its own PSFCH resources, timing difference relative to its own PSFCH resources, etc.) for determining the corresponding PSFCH resources of other relay WTRUs serving the same remote WTRU. For example, a relay WTRU can receive (e.g., in RRC signaling) the number of serving relay WTRUs, the ordering of the relay WTRUs, etc. For example, in the case of a group of cooperating WTRUs, a specific WTRU in the group can receive the number of WTRUs in the group, the ordering within the group (e.g., an explicit ordering number), etc.

[0226] The relay WTRU can receive UL / DL timings from other WTRUs.

[0227] Similar to PSFCH resources, WTRUs or relay WTRUs within a group of general cooperative WTRUs can receive (e.g., in an RRC configuration) information about other WTRUs in the group (e.g., the number of WTRUs, the index within the group, WTRU-specific indexes, etc.). WTRUs can use this configuration to determine resources associated with UL transmissions or DL ​​receptions, such as SRS resources associated with that WTRU within a set of SRS resources for the WTRU group, or Physical Uplink Control Channel (PUCCH) resources associated with that WTRU within a set of SRS resources for the WTRU group, such as UL-permitted portions provided within the permission granted to the WTRU group, such as CSI-RS, SSB, etc., within a set of reference signal transmissions intended for the entire group. WTRUs can also use this configuration to determine the mechanism for calculating new WTRU IDs. For example, a WTRU can determine a new WTRU ID based on its own WTRU ID (e.g., Cell Radio Network Temporary Identifier (C-RNTI)) and / or the group WTRU ID and / or the number of WTRUs in the group and / or the member IDs within the group. For example, when a regular ID is applied to a WTRU group, the WTRU can use the new WTRU ID to access resources / functions specific to that WTRU within the group. The WTRU can also use this configuration to determine the mechanism for calculating security keys. For example, the WTRU can use a public key and group information configured to it to derive a WTRU-specific key within a relay / cooperative WTRU group. The WTRU can further use this configuration to determine the mechanism for timing actions that may be relative to other WTRUs in the group. For example, the WTRU can determine the timing of actions (performing measurements, sending messages, initiating procedures, starting timers, etc.) based on the configured WTRU details and group information received in the RRC.

[0228] (For example, a relay) WTRU action may depend on another (relay) WTRU performing the same action.

[0229] In one embodiment, actions related to receiving, transmitting, measuring, forwarding, etc., at a WTRU (e.g., a WTRU that is part of a cooperative group or a relay WTRU) may depend on whether one or more other WTRUs within the group have performed such actions. Such actions may include, but are not limited to, any conventional Uu or SL actions, such as: transmission of measurement reports, transmission of CQI reports, transmission of group SR / BSR and / or reporting BSR, transmission of SRS, transmission of WTRU auxiliary information, transmission of capability information, initiation of unicast links on SL, transmission of discovery messages, triggering SL resource selection, forwarding of relay packets received by a group of relay WTRUs, permitted reception / decoding, reception / transmission of RRC messages, execution of procedures (e.g., Uu RLF, SL RLF, beam management, beam failure detection, etc.), transmission of HARQ feedback, and any other Uu / SL transmissions or procedures.

[0230] In one embodiment, the WTRU can determine whether to execute the send / receive / procedure based on which WTRU(s) have already performed the procedure or indicated their intention or readiness to perform the procedure. The WTRU can monitor transmissions from other WTRUs to determine if the procedure is being performed by another WTRU. Alternatively, the WTRU can monitor transmissions from other WTRUs to determine the intention / readiness to perform the procedure (e.g., where the intention / readiness to perform the procedure can be reflected by transmissions). The WTRU can then determine whether to execute the procedure based on the determination that other WTRUs have already performed the same procedure, or based on the intentions of multiple WTRUs to perform the procedure and / or some arbitration rule. Finally, according to another alternative, the WTRU can directly transmit (e.g., in inter-device transactions) information about the execution or intention / readiness of the procedure.

[0231] WTRUs may determine arbitration rules based on any one or a combination of the following: (i) Network configuration. For example, as defined herein, WTRUs may prioritize or order WTRUs in a group (e.g., a group of relay WTRUs) based on a network configuration index or order. Alternatively, WTRUs may implicitly derive this order based on other network configurations (e.g., UE ID, reference signal location, etc.), for example, using a relative order of resources configured separately for the group (e.g., PSFCH resources—WTRUs with the earliest PSFCH resources have the highest priority). Based on this prioritization, WTRUs may determine whether to execute a procedure based on this priority rule. (ii) Upper-layer (e.g., NAS) configuration. For example, member IDs may be assigned to WTRUs by the upper layer for prioritization in arbitration rules. (iii) Radio quality. For example, WTRUs may determine their priority in arbitration rules based on radio quality (e.g., Uu RSRP, SL RSRP, etc.) measured by the WTRU compared to measurements from other WTRUs. For example, WTRUs with higher measurements may be considered to have higher priority. (iv) Buffer state. For example, a WTRU can determine its priority in arbitration rules based on its buffer status (waiting or reported). For example, a WTRU with a larger buffer status, possibly associated with a specific logical channel or priority, may be given a lower priority. (v) Relay load. For example, a WTRU can determine its priority in arbitration rules based on the amount of data still at the WTRU that needs to be relayed. (vi) Power headroom reporting. For example, a WTRU can determine its priority based on its power headroom. For example, a WTRU with a larger power headroom may be associated with a higher priority. (vii) Capacity. For example, a WTRU can derive its priority based on its capacity, possibly relative to other WTRUs in the group. (viii) WTRU location (possibly relative to a reference point). For example, a WTRU closer to a (possibly configured) reference point may be considered to have a higher priority.

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

[0233] In another potential arbitration rule, it can take action if the priority of the WTRU (as defined herein) is above a threshold, where the threshold represents the amount used to derive the priority (e.g., load, RSRP, etc.).

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

[0235] In another potential arbitration rule, if the WTRU is the first WTRU to indicate its intention / preparation to perform an action, then the WTRU may perform that action.

[0236] In another potential arbitration rule, a WTRU can execute an action if it is the first WTRU with a priority above a threshold to perform an action or an intention / preparation to perform an action.

[0237] The relay WTRU forwards remote WTRU transmissions based on HARQ feedback received from another relay WTRU.

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

[0239] A relay WTRU can successfully decode a packet and report a HARQ ACK to a remote WTRU on its own PSFCH resource. Alternatively, a relay WTRU may not decode the packet and report a HARQ NACK. When a relay WTRU successfully decodes a packet, it can also determine whether to forward the packet to the next hop (e.g., the Uu interface) or discard the packet based on HARQ feedback received from other relay WTRUs configured in the same group. As a non-limiting example, (i) a relay WTRU may forward packets if no other relay WTRU transmits a HARQ ACK report to the remote WTRU on the SL, a relay WTRU may forward packets if no other higher-priority relay WTRU transmits a HARQ ACK report to the remote WTRU on the SL, a relay WTRU may forward packets if at most N (e.g., an integer determined by network configuration or based on QoS) relay WTRUs have already transmitted a HARQ ACK report to the remote WTRU on the SL, and a relay WTRU may forward packets if at most N higher-priority relay WTRUs have already transmitted a HARQ ACK report to the remote WTRU SL.

[0240] Permission to a remote WTRU is always for SL or Uu, because Uu and SL resources are statically separated by the concept of a network resource pool. If a WTRU is given control to use UL resources for SL or Uu transports, then the remote WTRU is allowed to be scheduled more flexibly to use direct or indirect paths more efficiently.

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

[0242] In an embodiment, the remote WTRU (i) may receive a permission indicating that transmission using SL or Uu is permitted in a resource (e.g., in DCI), and (ii) may determine, based on one or more conditions, whether to use the permission for UL transmission or SL transmission of multipath data (i.e., data associated with a bearer configured to be transmitted via a direct or indirect path). The one or more conditions may be any one or more of the following: (a) the remaining latency of the multipath data satisfying a certain threshold compared to the timing of the permission; (b) the Uu RSRP measurement satisfying the threshold; (c) the SL RSRP measurement satisfying the threshold; (d) the proximity of the timing of other SL or Uu permissions provided to the WTRU (e.g., the time interval relative to a previously received permission on SL or Uu) satisfying the threshold; (e) and so on. The remote WTRU (iii) may create a TB and, based on this determination, transmit the TB on the received permission using an SL (e.g., the Physical Control Channel (PSCCH) and Physical Side Link Shared Channel (PSSCH) or UL Physical Uplink Shared Channel (PUSCH)).

[0243] WTRU can accept flexible resource permissions.

[0244] The WTRU can receive permissions identified as flexible resource permissions (e.g., permissions that, based on the WTRU's judgment, can be used for SL or Uu transmissions). Such permissions can be received in the DCI. For example, a flag or a new DCI format can be used to indicate a permission that can be flexibly (based on the WTRU's judgment) used for SL or Uu transmissions. Alternatively, the WTRU can be configured with (pre-)configured or predetermined rules to determine which permissions(s) are flexible. For example, the WTRU can receive a configuration of permissions and determine that every Nth permission in the configuration is a flexible resource permission. For example, the amount of flexible permissions can be based on the bearer configuration of remote WTRUs in a multipath (e.g., the number of segmented bearers can determine the number / density of flexible permissions).

[0245] WTRU can use flexible resource permissions for SL or Uu transports.

[0246] In one embodiment, a WTRU (e.g., a remote WTRU in a multipath) can use flexible resource permission for either Uu or SL transport. Specifically, if the remote WTRU decides to use permission for SL transport, the WTRU can use the SL-related information in the DCI to perform SCI transport, followed by PSSCH transport. On the other hand, if the remote WTRU decides to use permission for UL transport, the WTRU can use the format indicated in the DCI to perform PUSCH / PUCCH transport. The WTRU can determine its use of flexible resource permission based on certain rules / conditions. The WTRU can determine whether to use flexible resource permission for Uu or SL transport based on one or a combination of the following (e.g., comparison of measurements, combination of conditions, etc.): (i) QoS of the data. For example, the conditions herein can be configured by priority, bearer, LCH, etc. For example, data with a specific priority / QoS / bearer can be configured to always be sent; (ii) Measurements on Uu. For example, if the Uu RSRP is higher than a threshold, the WTRU sends a Uu PDU; (iii) Measurements on SL. For example, if the CBR is higher than a threshold, the WTRU sends a Uu PDU. For example, if the SL RSRP of at least one relay WTRU is likely to be higher than a threshold, the WTRU sends an SL PDU; (iv) the waiting time of the indirect path. For example, if the estimated / indicative waiting time of the indirect path (e.g., from the relay WTRU) is lower than a threshold, the WTRU may send an SL PDU; (v) the type of indirect path. For example, the conditions in this document (e.g., which condition is used, which threshold is used, etc.) may be specific to whether the WTRU is connected to an SL indirect path or a non-3GPP indirect path; (vi) the number of indirect paths. For example, if the number of indirect paths that may satisfy another condition is higher than a threshold, the WTRU may send an SL PDU; (vii) other SL / Uu transmissions planned by the remote WTRU. For example, if resources are available within N time slots of planned SL transmissions, SL grants, etc., the WTRU may send an SL PDU; (viii) relay WTRU resource / grant information. For example, if the relay WTRU has an upcoming Uu grant that can be used by the relay WTRU, the remote WTRU may send an SL PDU. For example, one or more conditions related to the permission information at the relay WTRU discussed above can be used to determine whether the remote WTRU sends an SLPDU; (ix) Relay WTRU BSR information. For example, one or more conditions related to the permission information at the relay WTRU discussed above can be used to determine whether the remote WTRU sends an SLPDU. For example, if the relay BSR is above a threshold, the remote WTRU can send a Uu PDU; (x) Relay WTRU QoS information.For example, one or more conditions related to QoS information at the relay WTRU discussed above can be used to determine whether the remote WTRU sends an SL PDU. For example, if the data the remote WTRU is about to send will exceed the PBR (or current Bj) of the corresponding Uu LCH of the relay WTRU, then the remote WTRU may send a Uu PDU; (xi) Relay WTRU capacity. For example, one or more conditions related to relay capacity discussed above can be used to determine whether the remote WTRU sends an SL PDU. For example, if the relay capacity is above a threshold, then the remote WTRU may send a Uu PDU; (xii) Relay WTRU SL DRX cycle. For example, if permission falls within the relay WTRU's SL DRX cycle, then the remote WTRU may send a Uu PDU; (xiii) Permission size. For example, the remote WTRU may, based on the permission size, potentially combine other conditions to determine whether to send an SL PDU or a Uu PDU within a permissioned period. For example: (a) If the allowed size is higher than a threshold, the WTRU can use a first condition to determine whether to send an SL PDU or a Uu PDU; if the allowed size is lower than the threshold, the WTRU can use a second condition to determine whether to send an SL PDU or a Uu PDU; (b) The WTRU can determine the number of information bits that can be included in the transmission (e.g., by comparing SL and Uu transmissions), and can make its decision based on that determination: if the SL transmission allows for the transmission of more bits, then the SL transmission is performed; if the Uu / SL transmission allows for the transmission of prioritized data (i.e., Bj > 0), then the Uu / SL transmission is performed; (xiv) Uu power margin. For example, if the Uu power margin is lower than a threshold, then the SL PDU is sent.

[0247] Without loss of generality, any of the conditions described above for path selection can also be used to determine flexible permitted use.

[0248] Once the permitted transmission type is determined, WTRU can implement LCP restrictions.

[0249] After deciding whether to use resources for SL or Uu transport, the WTRU can, as a result of this decision, restrict the LCHs included in the grant. For example, some LCHs can be configured to be transported only on SL-only and / or Uu-only grants, rather than on flexible grants. For example, each WTRU LCH can be configured with a specific type. For flexible grants, if the WTRU first selects a type of LCH, it can select only subsequent LCHs of the same type. For example, each LCH can be configured with restrictive conditions (conditions associated with whether LCH selection for a grant is allowed) depending on whether the flexible grant is for SL or Uu transport. If the grant is for SL transport, a first condition can be used; if the grant is for Uu transport, a second condition can be used.

[0250] Figure 6 This is a flowchart illustrating an example process by which a remote WTRU selects a relay WTRU from multiple candidate relay WTRUs for sidelink communication in a wireless network, as described above. The flowchart shows an example embodiment from the perspective of the remote WTRU.

[0251] In step 601, the remote WTRU establishes connections with multiple candidate relay WTRUs.

[0252] In step 603, the remote WTRU determines the priority of the data it wants to transmit to the network. For example, the priority can be determined based on the highest priority of the data available for transmission to the network.

[0253] Next, in step 605, the remote WTRU receives information from each candidate relay WTRU regarding the Uu configuration permitted resources at that WTRU.

[0254] In step 607, the remote WTRU determines the suitability of the candidate relay WTRU's configuration and permitted resources for transmitting data to the network.

[0255] In step 609, the remote WTRU receives from the network a mapping of the size of the data that the remote WTRU wants to send to the network to the size of the Uu configuration allowed resources of the relay WTRU candidate.

[0256] In step 611, the remote WTRU selects one of the candidate relay WTRUs based on suitability determination and data priority. For example, this might involve comparing the size of the data to be transmitted with the size of the permitted Uu resources at the candidate relay WTRU.

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

[0258] Figure 7This is a flowchart illustrating the process, from the perspective of the WTRU, of selecting sidelink resources for communication between the remote WTRU and the network based on scheduling conditions at a potential relay WTRU, as described above.

[0259] In step 701, the remote WTRU receives QoS information associated with the Uu logical channel (LCH) configured at each of the plurality of potential relay WTRUs.

[0260] In step 703, the remote WTRU receives a BFI from each of the multiple potential relay WTRUs, including the amount of data waiting to be transmitted associated with each UuLCH.

[0261] In step 705, the remote WTRU determines that it has more than a threshold of data waiting to be transmitted.

[0262] In step 707, the remote WTRU selects one of a plurality of relay WTRUs that has not yet been selected for sidelink transmission of waiting data for the WTRU while data is waiting.

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

[0264] If the maximum allowed data volume of the selected relay WTRU is less than the amount of data waiting to be transmitted at the remote WTRU, the process proceeds from step 709 to step 711, where the remote WTRU selects resources for sidelink permission based on the determined maximum allowed data volume.

[0265] On the other hand, if the determined maximum allowed data amount is greater than or equal to the data amount waiting to be transmitted, the process proceeds from step 709 to step 713, in which the remote WTRU selects resources for sidelink permission for all data waiting to be transmitted at the remote WTRU.

[0266] Then, the process proceeds from step 711 or 713 to step 715, where the remote WTRU populates the side link permission with the selected data.

[0267] Finally, in step 715, the remote WTRU sends the selection data in the side link permission to the selected relay WTRU.

[0268] Figure 8 This is a flowchart illustrating an example process, as described above, of reporting buffer status related to sidelink communication to a wireless network based on relay WTRU scheduling from the perspective of a remote WTRU.

[0269] In step 801, the remote WTRU receives QoS information associated with the Uu logical channel (LCH) configured at the associated relay WTRU from each of the plurality of relay WTRUs.

[0270] In step 803, the remote WTRU receives buffer status information (BFI) from each of the multiple relay WTRUs. The BFI includes the amount of data waiting to be transmitted associated with the Uu LCH of the associated relay WTRU.

[0271] In step 805, the remote WTRU determines the amount of data to be transmitted to each relay WTRU based on the Uu buffer status of each relay WTRU received in the BSI of each relay and the priority of the data available for transmission to the remote WTRU.

[0272] Finally, in step 807, the remote WTRU sends an SL BSR to the network, which reports the amount of data it intends to send through each relay WTRU.

[0273] Figure 9 This is a flowchart illustrating an example process, as described above, of a relay WTRU determining whether to relay multicast transmission data from a remote WTRU to the network, from the perspective of the relay WTRU.

[0274] In step 901, the relay WTRU receives multicast SL transmissions from the 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 multicast SL transmission.

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

[0278] On the other hand, if the relay WTRU successfully decodes the multicast SL transmission, the process proceeds from step 905 to step 909, in which the relay WTRU sends an ACK to the remote WTRU.

[0279] Next, in step 911, the relay WTRU receives and decodes any acknowledgments from any other relay WTRU for the multicast SL transmission. This can be done, for example, by reading any information received on the PSFCH.

[0280] Next, in step 913, the relay WTRU determines whether the ACK / NACK of other WTRUs meets the conditions indicating whether the relay WTRU needs to forward multicast SL data to the network (or the packet can be dropped because at least one other relay WTRU is processing it). Example conditions may include any one or more of the following: (1) the decoded acknowledgment from other relay WTRUs indicates that fewer than a predetermined number of other relay WTRUs have acknowledged the multicast SL transmission, and (2) no other relay WTRU configured with a higher priority than this WTRU has acknowledged the multicast SL transmission (again, in this case, the relay WTRU will forward the data to the network).

[0281] Therefore, if other ACK / NACK conditions are met, the process 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 other ACK / NACK conditions are not met, the process proceeds from step 913 to step 917, where the relay WTRU discards the data.

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

[0284] In step 1001, the WTRU receives a resource permission from the wireless network for transmitting data to the network. This permission instructs the WTRU to use the permitted resources for sidelink transmission or Uu transmission.

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

[0286] Finally, in step 1005, based on the decision, the WTRU uses the permitted resources for SL or Uu (e.g., uplink) to send data.

[0287] refer to Figure 11A method 1100 for transmitting data via a relay WTRU, implemented in a WTRU, may include a first step in which the WTRU may receive 1110 a first message from one or more relay WTRUs, each first message including first information indicating uplink configuration permission resources. The first information indicating uplink configuration permission resources may include any one of a set of uplink configuration permissions, the timing of resources in the configuration permissions, and the size of resources in the configuration permissions. Prior to receiving the first message, the WTRU may establish one or more connections with at least one or more relay WTRUs.

[0288] Method 1100 may include the step of receiving a second message 1120 from the network, the second message including second information indicating a mapping from sidelink PDU size to uplink resource size.

[0289] Method 1100 may include steps in which the WTRU can determine, based on a second message, the suitability of uplink configuration permitted resources of one or more relay WTRUs for transmitting data. This data may be data available for transmission. The determination of suitability may include the uplink permitted size being larger than the sidelink permitted size by a certain threshold amount. The determination of suitability may include the uplink permitted size occurring at least / at most a threshold time before the end of the packet's PDU.

[0290] Method 1100 may include the step of selecting a 1140th relay WTRU from one or more relay WTRUs based on determined suitability. The selection of the relay WTRU may further be based on timing associated with the configuration-permitted resources of the selected relay WTRU. The method may also include the step of determining a priority associated with data for the WTRU, and the selection of the relay WTRU may further be based on priority. The priority associated with the data may be determined based on the highest logical channel priority of the data.

[0291] Method 1100 may include the step of sending 1150 data to a selected relay WTRU via a side link transmission.

[0292] While features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. This disclosure is not limited to the specific embodiments described herein, which are intended to illustrate various aspects. It will be apparent to those skilled in the art that many modifications and changes can be made without departing from its spirit and scope. Unless expressly provided, no element, action, or instruction used in the description of this application should be construed as critical or essential to the invention. Based on the foregoing description, functionally equivalent methods and apparatuses within the scope of this disclosure will be apparent to those skilled in the art, in addition to those listed herein. Such modifications and changes are intended to fall within the scope of the appended claims. This disclosure is limited only by the terms of the appended claims and the full scope of their equivalents. It should be understood that this disclosure is not limited to any particular method or system.

[0293] For simplicity, the foregoing embodiments are discussed in terms of the terminology and structure of devices with infrared capabilities (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (e.g., sound waves).

[0294] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and not for limitation. As used herein, the term “video” or the term “image” can refer to any one of a snapshot, a single image, and / or multiple images displayed on a time-based basis. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” and its abbreviation “HMD” can represent or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device with wireless and / or wired capabilities (e.g., tetherable) configured with some or all of the architecture and functions of a WTRU; (iii) a device configured with fewer than all the architecture and functions of a WTRU that supports wireless and / or wired connections; or (iv) and so on. References Figure 1A-1D Details of an example WTRU, which may represent any WTRU described herein, are provided. As another example, the various embodiments disclosed above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized, and some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive, realistic experience.

[0295] Furthermore, the methods provided herein can be implemented in computer programs, software, or firmware, which are contained in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in WTRUs, UEs, terminals, base stations, RNCs, MMEs, EPCs, AMFs, or any host.

[0296] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various embodiments that can be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source, such as a battery, which provides any suitable voltage.

[0297] Furthermore, in the embodiments provided above, references to processing platforms, computing systems, controllers, and other devices, including processors, are mentioned. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to actions and symbolic representations of operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be referred to as “executed,” “computer-executed,” or “CPU-executed.”

[0298] Those skilled in the art will understand that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. Electrical systems represent data bits that can lead to the eventual conversion or reduction of electrical signals and are held in storage locations within the memory system, thereby reconfiguring or otherwise altering the CPU's operation and other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the embodiments are not limited to the platforms or CPUs described above, and other platforms and CPUs may support the provided methods.

[0299] Data bits may also be stored on computer-readable media, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems. Computer-readable media may include cooperative or interconnected computer-readable media that reside exclusively on the processing system or are distributed across multiple interconnected processing systems, and may be located locally or remotely within the processing system. It should be understood that the embodiments are not limited to the aforementioned memories, and other platforms and memories may support the provided methods.

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

[0301] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software is often (but not always; in some cases, the choice between hardware and software may become important) a design choice representing a cost-efficiency trade-off. Various means can be used to implement the processes and / or systems and / or other technologies described herein (e.g., hardware, software, and / or firmware), and the preferred means can vary depending on the context of the deployment process and / or system and / or other technologies. For example, if the implementer determines that speed and accuracy are paramount, the implementer may choose a primarily hardware and / or firmware-based tool. If flexibility is paramount, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0302] The foregoing detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Within the scope of such block diagrams, flowcharts, and / or examples, which include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by various hardware, software, firmware, or virtually any combination thereof. In embodiments, several portions of the subject matter described herein can be implemented using application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be implemented, in whole or in part, equivalently in an integrated circuit, 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 circuitry and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will understand that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually perform the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media, such as floppy disks, hard disks, CDs, DVDs, digital magnetic tapes, computer memory, etc.; and transmission-type media, such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.).

[0303] Those skilled in the art will recognize that it is common practice in the field to describe devices and / or processes in the manner set forth herein and then integrate such described devices and / or processes into data processing systems using engineering practice. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable number of experiments. Those skilled in the art will recognize that a typical data processing system typically includes one or more of the following: a system unit housing, a video display device, a memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, a computing entity such as an operating system, drivers, a graphical user interface and applications, one or more interactive devices such as a touchpad or screen, and / or a control system including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). A typical data processing system can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0304] The topics described herein sometimes illustrate different components included within or connected to different other components. It should be understood that the architectures described in this way are merely examples, and many other architectures can indeed be implemented to achieve the same functionality. Conceptually, any arrangement of components that achieve the same functionality is effectively “associated” to achieve the desired function. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to achieve the desired function, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be so associated can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operational coupling include, but are not limited to, physically matable and / or physically interactive components and / or wirelessly interactive and / or logically interactive components.

[0305] Regarding the use of virtually any plural and / or singular terms in this document, those skilled in the art can appropriately translate them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural substitutions may be clearly illustrated herein.

[0306] Those skilled in the art will understand that, generally, the terms used herein, particularly those used in the appended claims (e.g., the body of the appended claims), are generally intended to be "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "at least having," the term "comprising" should be interpreted as "including but not limited to," etc.) and / or "permitted" terms (e.g., the term "is" and / or the term "is" can be interpreted as "may" and / or "may," the term "involves" can be interpreted as "may involve" and / or "may involve," the term "receive" can be interpreted as "may receive" and / or "may receive"). The term "support" can be interpreted as "can support" and / or "may support", the term "interlock" can be interpreted as "can interlock" and / or "may interlock", "belonging to transmission" can be interpreted as "can transmit" and / or "may transmit", the term "send" can be interpreted as "can send" and / or "may send", the term "not involved" (and / or similar) can be interpreted as "may not involve" and / or "may not involve", the term "not receive" (and / or similar) can be interpreted as "may not receive" and / or "may not receive", the term "not supported" (and / or similar) can be interpreted as "may not support" and / or "may not support", the term "not" can be interpreted as "not supported" and / or "may not support", and the term "not" can be interpreted as "not supported". The term "connect" (and / or similar) can be interpreted as "may not connect" and / or "may not connect," the term "not transmit" (and / or similar) can be interpreted as "may not transmit" and / or "may not transmit," the term "not send" (and / or similar) can be interpreted as "may not send" and / or "may not send," and so on. Those skilled in the art will further understand that if a particular number of claims is intended to be included, such intention will be expressly stated in the claims, and if such statement is not made, such intention does not exist. For example, when only one item is intended, the term "single" or similar language may be used. For the purpose of aiding understanding, the appended claims below... And / or the description herein may include the use of introductory phrases “at least one” and “one or more” to introduce a claim recitation. However, the use of such phrases should not be construed as implying that a claim recitation introduced by the indefinite article “a” or “an” limits any particular claim that includes such an introductory claim recitation to including only one embodiment of such a recitation, even when the same claim includes the introductory phrase “one or more” or “at least one” and the indefinite article such as “a” or “an” (e.g., “a” and / or “an” should be interpreted as meaning “at least one” or “one or more”). The same applies to the use of definite articles used to introduce a claim recitation.Furthermore, even if the specific number described in the introduced claims is explicitly stated, those skilled in the art will recognize that such a description should be interpreted as indicating at least the number described (e.g., the simple description of "two descriptions" without other modifiers indicates at least two descriptions, or two or more descriptions). Moreover, when using conventions such as "at least one of A, B, and C," this structure is generally intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). When using conventions such as "at least one of A, B, or C," this structure is generally intended to enable those skilled in the art to understand the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having a single A, a single B, a single C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). Those skilled in the art will further understand that, whether in the specification, claims, or drawings, any separate word and / or phrase representing two or more alternative terms should be understood to include the possibility of including one term, any one term, or both terms. For example, the phrase “A or B” will be understood to include the possibility of including “A” or “B” or “A and B”. Furthermore, as used herein, the term “any” followed by a list of multiple items and / or multiple item categories is intended to include, individually or in combination with other items and / or other item categories, “any,” “any combination,” “any plurality,” and / or “any combination of plurality.” Furthermore, as used herein, belonging to a “set” is intended to include any number of items, including zero. Furthermore, as used herein, the term “numerical” is intended to include any number, including zero. And the term “plural” as used herein is intended to be synonymous with “plural.”

[0307] Furthermore, in cases where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any single member or subgroup of the Markush Group.

[0308] As those skilled in the art will understand, for any and all purposes, such as providing a written description, all scopes disclosed herein also include any and all possible subscopes and combinations thereof. Any listed scope can be readily considered adequately descriptive and capable of dividing the same scope into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily decomposed into a lower third, a middle third, and an upper third, etc. Those skilled in the art will also understand that all language, such as “up to,” “at least,” “greater than,” “less than,” etc., includes the listed numbers and refers to a scope that can subsequently be decomposed into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual member. Thus, for example, a group having 1-3 units means a group having 1, 2, or 3 units. Similarly, a group having 1-5 units means a group having 1, 2, 3, 4, or 5 units, and so on.

[0309] Furthermore, the claims should not be construed as being limited to the provided order or elements unless otherwise stated. Additionally, the use of the term "means for..." in any claim is intended to refer to... The claim format is either device plus function, and any claim without the term "device for..." is not so.

[0310] For example, suitable processors include general-purpose processors, special-purpose processors, conventional processors, digital signal processors (DSPs), multiple microprocessors, one or more microprocessors associated with a DSP core, controllers, microcontrollers, application-specific integrated circuits (ASICs), application-specific standard products (ASSPs); field-programmable gate array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machine.

[0311] WTRU can be used in conjunction with hardware and / or software-implemented modules, including software-defined radio (SDR) and other components such as cameras, camera modules, video phones, speakerphones, vibration devices, speakers, microphones, TV transceivers, hands-free headsets, keyboards, Bluetooth® modules, FM radio units, near field communication (NFC) modules, liquid crystal display (LCD) units, organic light-emitting diode (OLED) display units, digital music players, media players, video game player modules, internet browsers, and / or any wireless local area network (WLAN) or ultra-wideband (UWB) modules.

[0312] Although various embodiments have been described with reference to the communication system, it is conceivable that these systems can be implemented in software on a microprocessor / general-purpose computer (not shown). In some embodiments, the functionality of one or more of the various components can be implemented in software that controls the general-purpose computer.

[0313] Furthermore, although the invention has been described and illustrated herein with reference to specific embodiments, the invention is not limited to the details shown. Rather, various modifications to the details may be made within the scope of the claims without departing from the invention.

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receive a first message from one or more relay WTRUs, the first message including first information indicating that the uplink configuration allows resources; Receive a second message from the network, the second message including second information indicating a mapping from sidelink packet data unit (PDU) size to uplink resource size; Based on the second message, determine the suitability of uplink configuration permission resources for transmitting data for one or more relay WTRUs; Based on the determined applicability, select a relay WTRU from one or more relay WTRUs; and Data is transmitted to the selected relay WTRU via a side link.

2. The method according to claim 1, wherein the data is data that can be transmitted.

3. The method of claim 1, wherein the data is data that can be transmitted to a network.

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

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

6. The method of claim 1, wherein the selection of the relay WTRU is further based on timing associated with the configuration-permitted resources of the selected relay WTRU.

7. The method of claim 1, wherein determining the applicability includes the uplink allowable size being a threshold amount greater than the sidelink allowable size.

8. The method of claim 1, wherein the determination of applicability includes the uplink allowance size occurring at least / at most a threshold time before the end of the packet's PDU.

9. The method of claim 1, wherein the first information indicating uplink configuration permission resources includes any one of the following: a set of uplink configuration permissions, the timing of the resources in the configuration permissions, and the size of the resources in the configuration permissions.

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

11. A wireless transmit / receive unit (WTRU) comprising a processor, a transceiver unit, and a storage unit, and configured to: Receive a first message from one or more relay WTRUs, the first message including first information indicating that the uplink configuration allows resources; Receive a second message from the network, the second message including second information indicating a mapping from sidelink packet data unit (PDU) size to uplink resource size; Based on the second message, determine the suitability of uplink configuration permission resources for transmitting data for one or more relay WTRUs; Based on the determined applicability, select a relay WTRU from one or more relay WTRUs; and Data is transmitted to the selected relay WTRU via a side link.

12. The WTRU of claim 11, wherein the data is data that can be transmitted.

13. The WTRU of claim 11, wherein the data is data that can be transmitted to a network.

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

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

16. The WTRU of claim 11, wherein the selection of the relay WTRU is further based on timing associated with the configuration-permitted resources of the selected relay WTRU.

17. The WTRU of claim 11, wherein the determination of applicability includes an uplink allowable size that is a threshold amount greater than the sidelink allowable size.

18. The WTRU of claim 11, wherein the determination of applicability includes the uplink allowable size occurring at least / at most a threshold time before the end of the packet's PDU.

19. The WTRU of claim 11, wherein the first information indicating uplink configuration permission resources includes any one of the following: a set of uplink configuration permissions, the timing of the resources in the configuration permissions, and the size of the resources in the configuration permissions.

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

Images