Resource selection or reselection for sidelink discontinuous reception operation on multi-hop WTRU to WTRU relays

Abstract

A wireless transmit / receive unit (WTRU) may determine that a sidelink (SL) logical channel is associated with an SL transmission to be relayed to a second RX WTRU by a first RX WTRU. The WTRU may determine a first SL discontinuous reception (DRX) configuration associated with the first RX WTRU and a second SL DRX configuration associated with the second RX WTRU. The first SL DRX configuration may indicate a first activity time, and the second SL DRX configuration may indicate a second activity time. Based on a priority value of the SL logical channel below a threshold, the WTRU may determine an SL resource for the SL transmission based on one or more of a first active time, a second active time, a relay delay associated with the first RX WTRU, or a packet delay budget (PDB) associated with the SL logical channel.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 531133, filed August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous-generation (traditional) mobile communication RATs could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Wireless communication devices can establish communication with other devices and data networks, for example, via access networks such as radio access networks (RAN). Summary of the Invention

[0003] This paper discloses systems, methods, and means for determining sidelink (SL) resources for SL transmission.

[0004] In the example, the Wireless Transmit / Receive Unit (WTRU) can determine the SL logical channel associated with an SL transmission to be relayed from the first RX WTRU to the second RX WTRU. The WTRU can determine a first SL Discontinuous Receive (DRX) configuration associated with the first RX WTRU and a second SL DRX configuration associated with the second RX WTRU. The first SL DRX configuration can indicate a first active time, and the second SL DRX configuration can indicate a second active time. Based on the priority value of the SL logical channel below a threshold, the WTRU can determine the SL resources for the SL transmission based on one or more of the first active time, the second active time, the relay delay associated with the first RX WTRU, or the packet delay budget (PDB) associated with the SL logical channel. The WTRU can then transmit the SL transmission on the SL resources.

[0005] In the example, the first active time can be a first time period associated with a first start time and a first end time, and the second active time can be a second time period associated with a second start time and a second end time. The WTRU can determine the overlapping time period between the first and second time periods. The WTRU can determine the effective active time based on the overlapping time period and the relay delay associated with the first RX WTRU. The WTRU can determine the SL resource within the effective active time. For example, the overlapping time period can begin at the later of the start time of the first and second time periods. The overlapping time period can end at the earlier of the end time of the first and second time periods. The PDB can not exceed the effective active time. The WTRU can determine the SL resource via resource reselection. The WTRU can perform resource reselection based on the determination of the selected SL resource outside the effective active time.

[0006] In the example, the WTRU can determine that data associated with one or more SL logical channels will be included in an SL transmission relayed from the first RX WTRU to the second RX WTRU. If the WTRU determines that data associated with one or more SL logical channels will be included in an SL transmission, it can trigger the WTRU to determine SL resources.

[0007] In the example, the WTRU can determine the SL resource via resource reselection. The WTRU can perform resource reselection based on the determination of the selected SL resource outside of the first active time.

[0008] In the example, the WTRU can establish a PC5 connection with the first RX WTRU. The WTRU can send a message to the first RX WTRU indicating that a PC5 connection will be established with both the first RX WTRU and the second RX WTRU. Attached Figure Description

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

[0010] Figure 1B The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example wireless transmit / receive unit (WTRU) used within the communication system.

[0011] Figure 1C The illustration based on one embodiment can be seen in Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system shown.

[0012] Figure 1DThe illustration based on one embodiment can be seen in Figure 1A The system diagram shows another example RAN and another example CN used in the communication system shown.

[0013] Figure 2 An example of RLC channel configuration in V2X is shown.

[0014] Figure 3 An example user plane protocol stack for L2 WTRU to network relay is shown.

[0015] Figure 4 An example RLC channel configuration procedure in a U2N relay is shown.

[0016] Figure 5 An example architecture for an L2 WTRU to WTRU relay is shown.

[0017] Figure 6 An example of a different SL DRX configuration with two RX WTRUs is shown (case #1).

[0018] Figure 7 An example of a different SL DRX configuration with two RX WTRUs is shown (case #2).

[0019] Figure 8 An example of the effective active time of RX WTRU#2 is shown (case #1).

[0020] Figure 9 An example of the effective active time of RX WTRU#2 (case #2) is shown.

[0021] Figure 10 An example of the effective active time of RX WTRU#2 is shown (case #3).

[0022] Figure 11 An example standard for aligned SL DRX configurations is shown.

[0023] Figure 12 An example is shown for determining SL DRX activity time based on buffer time.

[0024] Figure 13 An example path (re)selection for an SL DRX based on a relay WTRU is shown. Detailed Implementation

[0025] Figure 1AThis diagram illustrates an example communication system 100 that may implement one or more of the disclosed embodiments. 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 such 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 UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), and the like.

[0026] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive 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 will be appreciated that the disclosed embodiments are contemplated to any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d—any of which can be referred to as a “station” and / or “STA”—can be configured to transmit and / or receive wireless signals and can 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0027] 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, such as CN106 / 115, Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controllers, access points (APs), wireless routers, and the like. Although base stations 114a and 114b are each depicted as a single element, it will be appreciated that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0028] Base station 114a may be part of RAN 104 / 113, which 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 for radio services to a specific geographic area, which may be relatively fixed or may change over time. The 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 one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one 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 can be used to transmit and / or receive signals in a desired spatial direction.

[0029] 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.

[0030] 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, and the like. 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 air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​UL Packet Access (HSUPA).

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

[0032] In one 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).

[0033] In one 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 implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Therefore, the air interface utilized 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).

[0034] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (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), GSMEDGE (GERAN), and the like.

[0035] Figure 1A Base station 114b can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 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, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0036] 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, and the like. 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 1AAlthough not shown, it will be understood that RAN 104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, CN106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0037] 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.

[0038] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capability (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 base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0039] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive 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 will be appreciated that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0040] 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, and the like. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables 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 The processor 118 and transceiver 120 are described as separate components, but it will be understood that the processor 118 and transceiver 120 can be integrated together in an electronic package or chip.

[0041] 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 one embodiment, transmitting / receiving element 122 can be, for example, a transmitter / detector 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 will be appreciated that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

[0043] 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 multimode capability. Therefore, transceiver 120 can include multiple transceivers for example enabling WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

[0044] The processor 118 of WTRU 102 can be coupled to and receive user input data from: 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). 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 information from and store data in any suitable type of memory (such as 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, memory stick, secure digital storage (SD) card, and the like. In other embodiments, the processor 118 can access information from and store data in memory that is not physically located on WTRU 102 (such as a server or home computer (not shown)).

[0045] The processor 118 may receive power from the power supply 134 and may be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for 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, and the like.

[0046] 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 the air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0047] 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 videos), 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, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: 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.

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

[0049] 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.

[0050] RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it will 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 one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0051] 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, user scheduling in the UL and / or DL, and the like. Figure 1C As shown, eNode-B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0052] 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 depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0053] The MME 162 can connect to each of the eNode-Bs 160a, 160b, and 160c 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, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and so on. The MME 162 can provide control plane functions for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

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

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

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

[0058] In a representative embodiment, another network 112 may be a WLAN.

[0059] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfacing with a Distributed System (DS) or carry services within and / or out of the BSS to another type of wired / wireless network. Traffic originating outside the BSS destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA destined 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 peer-to-peer traffic. Peer-to-peer traffic can be sent between a source STA and a destination STA (e.g., directly between the source STA and the destination STA) using Direct Link Establishment (DLS). In some representative embodiments, the DLS may 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.

[0060] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) 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, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can listen on the primary channel. If the primary channel is listened to / detected by a particular STA and / or determined to be 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.

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

[0062] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels—this 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 two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0063] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to the operating modes used in 802.11n and 802.11ac, the channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. 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 (e.g., 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 a very long battery life).

[0064] WLAN systems that support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The 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 the STAs that support the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1 MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy, even if most of the band remains idle and can be available.

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

[0066] Figure 1D This diagram illustrates a system diagram of 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.

[0067] RAN 113 may include gNBs 180a, 180b, and 180c, although 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 one embodiment, 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. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, 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 may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, 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).

[0068] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with extendable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ 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 various or extendable lengths of subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or varying absolute durations).

[0069] 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 access to other RANs (e.g., eNode-B160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of 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 act 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.

[0070] 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 UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, and the like. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0071] 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. While each of the foregoing elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0072] AMF 182a and 182b can connect to one or more of 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 WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU102a, 102b, and 102c based on the service types being used by WTRU102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for Machine Type Communication (MTC) access, and / or the like. AMF 182 can provide control plane functions for switching between RAN 113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-APro, and / or non-3GPP access technologies such as WiFi.

[0073] 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 service routes through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, and so on. PDU session types can be IP-based, non-IP-based, Ethernet-based, and so on.

[0074] UPF 184a and 184b can be connected via an N3 interface to one or more gNBs 180a, 180b, and 180c in RAN 113. This N3 interface provides WTRU 102a, 102b, and 102c with access to a packet-switched network (such as 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, providing mobility anchoring, and so on.

[0075] CN 115 can facilitate communication with other networks. For example, CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting 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 one embodiment, WTRUs 102a, 102b, and 102c may be connected to local DNs 185a and 185b via the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and data networks (DNs) 185a and 185b.

[0076] Given Figures 1A-1D and Figures 1A-1D The corresponding descriptions herein regarding one or more of the functions of WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein 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.

[0077] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more 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 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 purposes and / or can perform tests using over-the-air wireless communication.

[0078] One or more emulation devices may perform one or more functions (including all functions) but are not implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios in a test laboratory and / or in non-deployed (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more emulation devices may be test devices. 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).

[0079] This paper discloses systems, methods, and means for determining sidelink (SL) resources for SL transmission.

[0080] In the example, the Wireless Transmit / Receive Unit (WTRU) can determine the SL logical channel associated with an SL transmission to be relayed from the first RX WTRU to the second RX WTRU. The WTRU can determine a first SL Discontinuous Receive (DRX) configuration associated with the first RX WTRU and a second SL DRX configuration associated with the second RX WTRU. The first SL DRX configuration can indicate a first active time, and the second SL DRX configuration can indicate a second active time. Based on the priority value of the SL logical channel below a threshold, the WTRU can determine the SL resources for the SL transmission based on one or more of the first active time, the second active time, the relay delay associated with the first RX WTRU, or the packet delay budget (PDB) associated with the SL logical channel. The WTRU can then transmit the SL transmission on the SL resources.

[0081] In the example, the first active time can be a first time period associated with a first start time and a first end time, and the second active time can be a second time period associated with a second start time and a second end time. The WTRU can determine the overlapping time period between the first and second time periods. The WTRU can determine the effective active time based on the overlapping time period and the relay delay associated with the first RX WTRU. The WTRU can determine the SL resource within the effective active time. For example, the overlapping time period can begin at the later of the start time of the first and second time periods. The overlapping time period can end at the earlier of the end time of the first and second time periods. The PDB can not exceed the effective active time. The WTRU can determine the SL resource via resource reselection. The WTRU can perform resource reselection based on the determination of the selected SL resource outside the effective active time.

[0082] In the example, the WTRU can determine that data associated with one or more SL logical channels will be included in an SL transmission relayed from the first RX WTRU to the second RX WTRU. If the WTRU determines that data associated with one or more SL logical channels will be included in an SL transmission, it can trigger the WTRU to determine SL resources.

[0083] In the example, the WTRU can determine the SL resource via resource reselection. The WTRU can perform resource reselection based on the determination of the selected SL resource outside of the first active time.

[0084] In the example, the WTRU can establish a PC5 connection with the first RX WTRU. The WTRU can send a message to the first RX WTRU indicating that a PC5 connection will be established with both the first RX WTRU and the second RX WTRU.

[0085] This document discloses systems, methods, and means for determining side link (SL) resources for UE-to-UE (U2U) relays by a TX radio transmit-receive unit (WTRU) (e.g., a source WTRU) and / or for determining triggering SL resource (re)selection based on the activity time associated with a first RX WTRU and a second RX WTRU (e.g., the activity time associated with the first RX WTRU and the activity time associated with the second RX WTRU).

[0086] In the example, a WTRU (e.g., a TX WTRU) may receive configuration information associated with one or more SL logical channels, which are associated with SL transmissions associated with a second RX WTRU (e.g., SL transmissions to be sent to the second RX WTRU via a first RX WTRU). The WTRU may receive activity times (e.g., indications of preferred activity times) from both the first and second RX WTRUs; for example, receiving activity times associated with the first RX WTRU from the first RX WTRU, and for the second RX WTRU, receiving activity times associated with the second RX WTRU. For example, the first RX WTRU may be a relay WTRU. The second RX WTRU may be, for example, a target WTRU. The WTRU may configure or determine SL discontinuous reception (DRX) configurations (e.g., activity times) for the first RX WTRU and / or the second RX WTRU. For example, the WTRU may receive delays associated with relaying (e.g., forwarding) from the first RX WTRU. The WTRU can determine the effective active time associated with the second RX WTRU (e.g., a modified active time) based on the active time associated with the second RX WTRU and the delay associated with the relay. For example, the effective active time of the second RX WTRU could be the active time of the second RX WTRU offset from the delay associated with the relay. In the example, the active time associated with the first RX WTRU could be the preferred active time received from the first RX WTRU, and the active time associated with the second RX WTRU could be the preferred active time received from the second RX WTRU.

[0087] The WTRU can determine one or more SL resources based on the active time associated with the first RX WTRU and the effective active time associated with the second RX WTRU, for example, for SL data associated with one or more SL logical channels. In an example, the WTRU can perform SL resource selection (e.g., trigger SL resource selection) based on the active time associated with the first RX WTRU and the effective active time associated with the second RX WTRU. SL resource selection may include the determination of one or more SL resources. The determined one or more SL resources can be used (e.g., by the first RX WTRU and / or the WTRU) to transmit SL data associated with one or more SL logical channels. For example, the WTRU can notify (e.g., send or indicate) one or more SL resources to the first RX WTRU and / or the second RX WTRU, and the first RX WTRU can use one or more SL resources to send (e.g., forward) SL transmissions including SL data associated with one or more SL logical channels to the second RX WTRU. For example, the WTRU can trigger SL resource selection under conditions that SL data is about to be transmitted. For example, the WTRU can determine that the triggering condition for performing SL resource selection has been met, and / or determine one or more SL resources based on the determination that the triggering condition for performing SL resource selection has been met. For example, given that the SL data used for transmission is associated with one or more SL logical channels, the WTRU may determine one or more SL resources during the active time of the first RXWTRU and the effective active time of the second RXWTRU based on the triggering of SL resource selection (e.g., when SL resource selection is triggered), wherein the one or more SL logical channels are associated with SL transmissions associated with the second RXWTRU (e.g., SL transmissions to be sent to the second RXWTRU via the first RXWTRU).

[0088] The WTRU can establish a PC5 connection with the first RX WTRU and the second RX WTRU via the first RX WTRU. The WTRU can receive configuration information indicating the priority threshold (e.g., reselection) of one of the one or more SL logical channels associated with the SL transmission (e.g., from the first RX WTRU to the second RX WTRU) associated with the second RX WTRU.

[0089] Under conditions where SL resource (re)selection is triggered by SL data associated with one or more SL logical channels (e.g., SL data from one or more SL logical channels associated with an SL transmission associated with a second RX WTRU (e.g., via the first RX WTRU to the second RX WTRU), the WTRU can determine whether to trigger SL resource (re)selection. For example, if the currently (re)selected SL resource is within the active time of the first RX WTRU and the effective active time of the second RX WTRU, it is determined that SL resource (re)selection should not be triggered and the currently (re)selected SL resource should be maintained. If the currently (re)selected SL resource is outside the active time of the first RX WTRU, it is determined that SL resource (re)selection should be triggered. If the currently (re)selected SL resource is within the active time of the first RX WTRU and outside the effective active time of the second RX WTRU, the SL resource (re)selection is determined to be triggered if the priority value of the SL data is lower than the priority threshold (e.g., the configured threshold) and the remaining packet delay budget (PDB) is within the effective active time of the second RX WTRU. If the priority value of the SL data is equal to or higher than the priority threshold or the remaining PDB is not within the effective active time of the second RX WTRU, the SL resource (re)selection is determined not to be triggered and the currently (re)selected SL resource is maintained.

[0090] This document discloses systems, methods, and means for selecting a destination associated with a sidelink (SL) logical channel during the execution of a logical channel prioritization (LCP) procedure, for example, based on the activity time associated with a first RXWTRU and a second RXWTRU (e.g., the activity time associated with the first RXWTRU and the activity time associated with the second RXWTRU).

[0091] In the example, a WTRU (e.g., a TX WTRU) can receive configuration information associated with one or more SL logical channels, which are associated with an SL transmission to be sent via a first RX WTRU to a second RX WTRU. The WTRU can obtain priority thresholds (e.g., reselection) for the configuration of one or more SL logical channels (e.g., each of the one or more SL logical channels) associated with the SL transmission to be sent via the first RX WTRU to the second RX WTRU. The WTRU can receive delays associated with relaying (e.g., forwarding) from the first RX WTRU. The WTRU can obtain (e.g., receive or determine) the active time associated with the first RX WTRU and the active time (or validity time) associated with the second RX WTRU. The first RX WTRU can be a relay WTRU. The second RX WTRU can be a target WTRU. The WTRU can configure SL discontinuous reception (DRX) configurations (e.g., active times) for the first RX WTRU and / or the second RX WTRU. For the selected SL grant, the WTRU can determine the SL destination and(one or more) SL logical channels to be included in the Media Access Control (MAC) Protocol Data Unit (PDU) associated with the selected SL grant, for example, based on one or more of the activity time associated with the first RX WTRU, the activity time (or validity time) associated with the second RX WTRU, or a configured priority threshold. For example, the WTRU can use the selected SL grant to transmit SL data to the first RX WTRU.

[0092] For example, if SL data is available from one of one or more SL logical channels associated with an SL transmission to be sent via the first RX WTRU to the second RX WTRU, the selected SL license is available during the activity periods of the first and second RX WTRUs, and the priority values ​​of one or more SL logical channels (e.g., the priority values ​​of the SL logical channels) are lower than a configured priority threshold, the WTRU can select a destination associated with the first RX WTRU and include data from the SL logical channels(s) associated with the SL transmission to the second RX WTRU, for example, before other SL logical channels. If data is not available from one or more SL logical channels associated with an SL transmission to be sent via the first RX WTRU to the second RX WTRU, the selected SL license is not available during the activity periods of the first and second RX WTRUs, and the priority values ​​of one or more SL logical channels(s) are equal to or higher than a configured priority threshold, the WTRU can select a destination with the SL logical channels(s) having the highest priority and include SL data from the SL logical channels according to priority order.

[0093] The WTRU can establish a PC5 connection with the first RX WTRU and the second RX WTRU via the first RX WTRU. The activity time associated with the first RX WTRU can be the preferred activity time received from the first RX WTRU. The activity time associated with the second RX WTRU can be the preferred activity time received from the second RX WTRU.

[0094] This document discloses systems, methods, and means for determining the alignment of the RX WTRU by the TX radio transmit-receive unit (WTRU) (e.g., source WTRU) based on the end-to-end (E2E) packet delay budget (PDB) and / or the delay of the relay based on SL data, such as side link (SL) discontinuous reception (DRX) configuration (e.g., on-time, SL DRX period).

[0095] A WTRU (e.g., a TX WTRU) can receive the activity time associated with a first RX WTRU and a second RX WTRU (e.g., the activity time associated with the first RX WTRU and the activity time associated with the second RX WTRU). The first RX WTRU can be a relay WTRU, and the second RX WTRU can be a target WTRU. The WTRU can receive configuration information from the base station indicating the latency of a relay dependent on channel occupancy rate (CBR) (e.g., the maximum latency of a CBR-dependent relay). The WTRU can determine the packet delay budget (PDB) for end-to-end (E2E) delivery (e.g., the minimum PDB) based on a Quality of Service (QoS) profile (e.g., a QoS profile mapped to the corresponding sidelink radio bearer (SLRB)) (e.g., a QoS profile mapped to each SLRB). The WTRU can determine the SLDRX configuration of one or more (e.g., each) aligned RX WTRUs (e.g., the SL DRX configuration of the first RX WTRU and / or the second RX WTRU). In the example, the WTRU can select the SL DRX period and the on-time duration such that (SL DRX period - on-time duration) < (minimum PDB for E2E transmission - maximum delay of the relay). The WTRU can transmit aligned SL DRX configurations to one or more (e.g., each) RX WTRUs (e.g., the first RX WTRU and / or the second RX WTRU).

[0096] The WTRU can establish a PC5 connection with the first RX WTRU and the second RX WTRU via the first RX WTRU. The activity time associated with the first RX WTRU can be a preferred activity time received from the first RX WTRU, and the activity time associated with the second RX WTRU can be a preferred activity time received from the second RX WTRU.

[0097] This document discloses systems, methods, and means for determining the activity time and updated / modified sidelink (SL) discontinuous reception (dRX) configuration of a second RX WTRU (e.g., a target WTRU) based on measured average buffer time variations by a first RX radio transmit-receive unit (WTRU) (e.g., a relay WTRU).

[0098] A first RX WTRU (e.g., a relay WTRU) can establish PC5 connections with a TX WTRU (e.g., a source WTRU) and a second RX WTRU (e.g., a target WTRU) via the first RX WTRU, such as a PC5 connection with the TX WTRU and a PC5 connection with the second RX WTRU. The first RX WTRU can receive an SL DRX configuration that includes a set of buffer times (e.g., on-duration times) associated with one or more (e.g., each) active times (e.g., a first active time). The first RX WTRU can measure the buffer time (e.g., average buffer time), for example, as the time between the reception of a Protocol Data Unit (PDU) and the transmission of the PDU (to the next hop). The first RX WTRU can obtain a threshold for the configuration associated with changes in buffer time (e.g., changes in average buffer time). The first RX WTRU can perform subsequent transmissions based on the measured (e.g., average) buffer time. For example, the first RX WTRU can determine whether to use the second active time for subsequent transmissions based on the measured (e.g., average) buffer time and the configured threshold, and perform subsequent transmissions based on the determination of whether the second active time is used for subsequent transmissions.

[0099] In the example, if the measured (e.g., average) buffer time change exceeds a configured threshold, the first RXWTRU can select a second active time (e.g., on duration) associated with the second RXWTRU based on the measured (e.g., average) buffer time and the received SL DRX configuration, send an updated / modified SL DRX configuration including the second active time to the second RXWTRU, and send subsequent transmissions to the second RXWTRU using the second active time.

[0100] This document discloses systems, methods, and means for determining a path (e.g., a direct or indirect path) by a TX wireless transmit-receive unit (WTRU) (e.g., a source WTRU) based on the activity time of an RX WTRU (e.g., a relay WTRU).

[0101] A WTRU (e.g., a TX WTRU) can establish a PC5 connection with an RX WTRU via a first RX WTRU. An RX WTRU can be a relay WTRU. A WTRU can send a Side Link (SL) Discontinuous Receive (DRX) configuration to an RX WTRU. A WTRU can receive a Channel Occupancy Rate (CBR) threshold for path (re)selection configuration. A WTRU can determine whether to use an indirect path or a direct path (e.g., for uplink (UL) transmission) based on the activity time associated with the SL DRX configuration, such as when data is triggered via a split bearer on a multipath in one or more SL logical channels associated with a UL transmission (e.g., using one or more Uu transmissions and / or one or more SL transmissions).

[0102] In the example, the use of a direct path can be determined under the following conditions: outside of the activity time associated with the SL DRX configuration, the latency associated with an indirect path (e.g., indirect transport) does not meet End-to-End Quality of Service (E2EQoS), and the measured CBR value is higher than (or equal to) the configured CBR threshold. The use of an indirect path can be determined under the following conditions: during the activity time associated with the SLDRX configuration, the latency associated with an indirect path meets E2E QoS, and the measured CBR value is lower than the configured CBR threshold. The WTRU can transmit data based on the determined indirect or direct path (e.g., via UL or SL).

[0103] WTRU can perform SL DRX operations.

[0104] V2X (e.g., NR V2X) can support one or more of the following SL DRX: unicast, multicast, and / or broadcast. For example, one or more parameters can be defined for the SL (e.g., parameters similar to those of the Uu (e.g., the radio interface between the UE and the base station), such as on-time duration, inactivity timer, retransmission timer, and / or period) to determine the SL activity time of the SLDRX. During the SL activity time, the WTRU can perform sidelink control information (SCI) monitoring on data reception (e.g., a first-level SCI on the physical SL control channel (PSCCH) and a second-level SCI on the physical sidelink shared channel (PSSCH)). The WTRU can skip monitoring of data reception of the SCI during the SL DRX inactivity time.

[0105] The active time of an RX WTRU (e.g., the SL active time of an RX WTRU) may include one or more times during which one or more of its applicable SL on duration timers, SL inactivity timers, or SL retransmission timers (e.g., for any of unicast, multicast, or broadcast) are running. In some examples, the time slots associated with periodic transmissions of a TX WTRU (e.g., periodic transmissions announced by the TX WTRU) and / or the time during which the WTRU expects a CSI report, for example, after a CSI request (e.g., for unicast), can be considered the active time of the RX WTRU. The time of the unicast link establishment procedure and / or the time of PC5-Radio Resource Control (RRC) reconfiguration using the initial SL DRX configuration procedure can be considered the active time of the RX WTRU.

[0106] A TX WTRU (e.g., a source WTRU) may maintain a set of timers (e.g., a set of SL DRX timers in one or more RX WTRUs corresponding to each pair of source / destination L2 IDs for unicast or destination L2 IDs for multicast / broadcast). When data is available for transmission to one or more RX WTRUs configured with SL DRX, the TX WTRU may, for example, consider (e.g., the activity time of one or more RX WTRUs determined by the timers maintained at the TX WTRU) to select resources.

[0107] SL DRX can be used for unicast. For unicast, for example, SL DRX can be configured for each pair of source Layer 2 identity (L2 ID) and destination L2 ID.

[0108] WTRUs can maintain a set of SLDRX timers for one direction (e.g., each direction) for each pair of source L2 IDs and destination L2 IDs. For example, in the access layer (AS) layer, the SLDRX configuration for a pair of source / destination L2 IDs for one direction can be negotiated between WTRUs. For an SL DRX configuration in one or more directions (e.g., each direction), where one WTRU is a TX WTRU and the other is an RX WTRU, one or more of the following can be applied: the RX WTRU can send auxiliary information to the TX WTRU (e.g., which includes one or more of the following: its expected SL start duration timer, SL DRX start offset, and SLDRX period), and the mode 2 TX WTRU can use it to determine the SL DRX configuration of the RX WTRU; the TX WTRU (e.g., in RRC_IDLE / RRC_INACTIVE / Out of Coverage (OOC), or in the RRC_CONNECTED state and using mode 2 resource allocation) can determine the SL DRX configuration of the RX WTRU (e.g., regardless of whether auxiliary information is provided); for a TX WTRU in the RRC_CONNECTED state and using mode 1 resource allocation (e.g., the source WTRU), the SL DRX configuration of the RX WTRU can be determined by the base station (e.g., the serving gNB of the TX WTRU); the TX WTRU can send the SL DRX configuration to the RX WTRU that will be used by the RX WTRU; RX WTRU can accept or reject SL DRX configurations.

[0109] In the example, when the TX WTRU is in the RRC_CONNECTED state and using mode 1 resource allocation, the TX WTRU can report received auxiliary information or received SL DRX configuration rejection information to the base station (e.g., its serving gNB that supports SL DRX), and can send the SL DRX configuration to the RX WTRU, for example, when it receives the SL DRX configuration from the gNB in ​​dedicated RRC signaling. When the RX WTRU is in the RRC_CONNECTED state and using mode 1 resource allocation, the RX WTRU can report the received SL DRX configuration to the base station (e.g., its serving gNB that supports SL DRX), such as alignment(s) for Uu and SL DRX configuration(s).

[0110] One or more of the following can be supported in unicast: SL enable persistent timer, SL inactivity timer, SL HARQ RTT timer, and / or SL HARQ retransmission timer. For example, at the RX WTRU, one or more SLHARQ RTT timers and / or one or more SL HARQ retransmission timers can be maintained for each SL process. For example, in addition to the (pre)configured values ​​of one or more of these timers (e.g., each), the SL HARQ RTT timer value can be derived from the retransmission resource timing when the SCI indicates more than one transport resource. For example, the SL HARQ RTT timer can be set to different values ​​to support both HARQ-enabled and HARQ-disabled transports.

[0111] SL DRX Media Access Control (MAC) control elements (CEs) can be introduced for SL DRX operations (e.g., only in unicast).

[0112] An example logical channel prioritization (LCP) procedure can be implemented. If sl-BWP-DiscPoolConfig or sl-BWP-DiscPoolConfigCommon is not configured, the MAC entity (e.g., for each SCI corresponding to a new transmission) can select a destination associated with one of unicast, multicast, and broadcast, i.e., if SL DRX is applied to the destination, it is during the SL activity time of the SL transmission timing, and among one or more (e.g., all) logical channels that meet the following conditions, have a MAC CE and at least one of the logical channels with the highest priority, and one or more MAC CEs (if any) for the SL grant associated with the SCI: SL data is available for transmission; SBj>0, in the presence of one or more (e.g., any) logical channels with SBj>0; sl-configuredGrantType1Allowed (if configured) is set to true if the SL grant is configured for grant type 1; and sl-AllowedCG-List (if configured) includes the grant index of the configuration associated with the SL grant; and / or if PSFCH is not configured for the SL grant associated with the SCI, sl-HARQ-FeedbackEnabled is set to disabled. If multiple destinations have logical channels that satisfy one or more (e.g., all) of the above conditions with the same highest priority, or if multiple destinations have MAC CE and / or logical channels that satisfy all of the above conditions with the same priority as MAC CE, then it can be determined which destination to select among them.

[0113] The RLC channel configuration program in V2X can be used.

[0114] Vehicle-to-everything (V2X) (e.g., NR V2X) may support one or more configuration procedures of unicast, multicast, and / or broadcast. In one or more (e.g., all) cases, the TX WTRU may determine the SL bearer configuration (e.g., one or more of Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), MAC, etc. configuration parameters) based on, for example, the QoS profile of a QoS flow initiated by the upper layer of the TXWTRU.

[0115] The determination of the bearer configuration can depend on, for example, the RRC state of the TX WTRU. When the TX WTRU is in the RRC_IDLE / RRC_INACTIVE state or out of network coverage (OOC), the WTRU can obtain the bearer configuration for use from the System Information Block (SIB) or the pre-configuration, respectively. The SIB / pre-configuration can contain a list of bearer configurations (e.g., an exhaustive list of bearer configurations to be used for each QoS profile). If the QoS profile is not included in the SIB / pre-configuration, the WTRU can use the default bearer configuration and / or map the QoS flow to the default bearer. For RRC_CONNECTED WTRU(s), the WTRU(s) can (e.g., when initiating the flow) send the QoS profile of the QoS flow to the network and can receive the bearer configuration of the QoS flow, for example, from dedicated RRC signaling.

[0116] In Mode 1, the network can manage the scheduling of resources for the TX WTRU (e.g., to meet latency requirements for each transmission). In Mode 2, since the WTRU performs the scheduling, latency management can be built into the resource selection procedure. For example, when data triggers the resource selection procedure, the WTRU can select one or more resources using a resource selection window (e.g., a resource selection window defined by the PDB of the highest priority data available for transmission). This allows the latency requirements associated with that data to be met. For example, the network may not participate in defining the PDB (e.g., in a logical channel) because the PDB can be determined based on the QoS profile (e.g., known to the TX WTRU from the QoS profile). Figure 2 An example of RLC channel configuration in V2X is shown.

[0117] The RLC channel configuration program in a User-to-Network (U2N) relay can be used. Figure 3 An example user plane protocol stack for L2 WTRU(s) to network relay is shown.

[0118] For a Uu (e.g., a regular Uu), the WTRU can receive bearer configuration(s) from the network, for example, in dedicated RRC signaling. In some examples, for a WTRU to a network relay, the network can configure (e.g., requires configuration) not only the End-to-End Service Data Adaptation Protocol (SDAP) and the PDCP to the remote WTRU, but also the Sidelink Relay Adaptation Protocol (SRAP) at the remote WTRU and the relay WTRU and RLC (and one or more layers (e.g., MAC / PHY) below the RLC at the remote WTRU). For example, the network can use dedicated Radio Resource Control (RRC) signaling to perform the configuration because (e.g., the remote WTRU, except that it communicates with the network via the relay) can be treated as a normal WTRU in the Uu. For example, the remote WTRU can use dedicated signaling (e.g., an RRC reconfiguration message) to receive its Data Radio Bearer (DRB) configuration, for example, as it does in the Uu, except that it receives it via the Relay Signalling Radio Bearer (SRB).

[0119] In a WTRU-to-network relay, the network can configure (e.g., needs to configure) an adaptation layer (e.g., SRAP). The SRAP at the relay WTRU can handle the multiplexing of one or more PC5 RLC channels to Uu RLC channels (on the uplink) and vice versa (on the downlink). For example, the network can multiplex one or more PC5-RLC channels in the uplink to the same Uu RLC channel. Based on this mapping, the adaptation layer can perform routing, for example, when packets are received at the relay WTRU.

[0120] For WTRU to network relay (e.g., and particularly for one or more transmissions on SL), the remote WTRU can be in Mode 2 (e.g., by definition). For one or more UL transmissions, the delay associated with the transmission (one or more) of the remote WTRU can include an SL portion and a Uu portion (e.g., composed of an SL portion and a Uu portion). The network can control the delay of the Uu portion, and the WTRU (e.g., via resource selection) can control the SL portion. Some coordination can be used or required (e.g., given that the network controls the delay on the Uu portion, and the WTRU controls the SL portion) such that the sum of the delays satisfies the PDB associated with the packet. For example, the PDB associated with the packet can give an end-to-end delay, and in some examples, it may not be used to determine the resource selection window (e.g., as it does in V2X). For this purpose, the network can configure PDB segmentation (e.g., the network can provide a PDB for the resource selection procedure in Mode 2 for each SL relayed by the relay to the remote WTRU). Figure 4 A sample RLC channel configuration procedure in a U2N relay is shown.

[0121] WTRU to WTRU relays can be used in one or more examples in this article. Figure 5 An example architecture for an L2 WTRU to WTRU relay is shown. In a WTRU to WTRU relay, one or more (e.g., any one) of the WTRUs involved (e.g., source WTRU(s), destination WTRU(s), and (one or more) relays) may be within or outside coverage and may be in any RRC state.

[0122] In an example (e.g., the current 3GPP specification), the TX WTRU (e.g., the source WTRU) can determine the SL DRX configuration associated with the RX WTRU. The SL DRX configuration can include one or more parameters related to the SL active time (e.g., on-time duration, SLDRX cycle, etc.). During the configured SL active time, the RX WTRU can perform SCI monitoring on SL data reception. In some examples, the RX WTRU can skip monitoring of SL data reception during SL DRX cycles outside of the configured SL active time (e.g., inactive time).

[0123] In U2U trunking operations, a source WTRU (e.g., a TX WTRU) can establish one or more links (e.g., PC5 unicast links) via RX WTRU#1 to RX WTRU#1 (e.g., a trunk WTRU) and RX WTRU#2 (e.g., a destination WTRU). RX WTRU#1 can perform SL data trunking operations from the source WTRU to the destination WTRU (e.g., from the TX WTRU to RX WTRU#2). If multiple RX WTRUs (e.g., RX WTRU#1 and RX WTRU#2) are associated with different SL DRX configurations, one or more delays may occur in some instances (e.g., one or more additional delays, such as one or more delays for one or more different SLDRX configurations or one or more delays due to one or more different SL configurations, trunking delays, etc.). For example, the source WTRU can select SL resources during the active time of RX WTRU#1 and RX WTRU#2, or adjust the SL DRX configuration for RX WTRU to avoid such delays(one or more). Figure 6 An example of a different SL DRX configuration associated with two RX WTRUs is shown (case #1). Figure 6 Link 602 is shown as a first link (e.g., link #1) and link 604 is shown as a second link (e.g., link 2). The first and second links can be associated with different SL DRX configurations. For example, in Figure 6 In this configuration, the first SL DRX configuration 606 (SL DRX configuration #1) can be associated with link 1, and the second SL DRX configuration 608 (e.g., SL DRX configuration #2) can be associated with link 2. One or more delays may occur on link 602. Figure 7 An example of a different SLDRX configuration with two RX WTRUs is shown (case #2). Figure 7 Link 702 is shown as a first link (e.g., link #1) and link 704 is shown as a second link (e.g., link 2). The first and second links can be associated with different SL DRX configurations. For example, in... Figure 7 In this configuration, the first SL DRX configuration 706 (e.g., SL DRX configuration #1) can be associated with link 1, and the second SL DRX configuration 708 (e.g., SL DRX configuration #2) can be associated with link 2. One or more delays may occur on link 704.

[0124] Delays may occur on one or more of the first or second links. For example, in case #1, delays may occur on link 1 (e.g., the link between the source WTRU (e.g., the TX WTRU) and the U2U trunk WTRU). In case #2, delays may occur on link 2 (e.g., the link between the U2U trunk WTRU and the target WTRU).

[0125] Resource selection and / or resource reselection associated with U2U trunk operations can be performed. For example, a TX WTRU (e.g., a source WTRU) can determine the SL resource for U2U trunk operations and / or determine the trigger for SL resource (re)selection based on the activity time of RX WTRU#1 and / or the activity time of RX WTRU#2.

[0126] A sample resource selection procedure can be used. A TX WTRU (e.g., a source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (a target WTRU) via RX WTRU#1. In the example, a WTRU can establish a PC5 connection with a first RX WTRU. The WTRU can send a message to the first RX WTRU instructing the establishment of a PC5 connection associated with both the first and second RX WTRUs. For example, when SL data is triggered from a TX WTRU and the triggered SL logical channel's SL data (e.g., according to configuration) is associated with RX WTRU#1 and RX WTRU#2, the TX WTRU can instruct RX WTRU#1 to establish a link (e.g., PC5) for data relay with RX WTRU#2. This could also be an indication of WTRU-to-WTRU relay (e.g., establishing a PC5 connection with both the first and second RX WTRUs).

[0127] The TX WTRU can be configured with one or more SL logical channels, which are associated with SL transmissions from RX WTRU#1 to RX WTRU#2. In the example, the TX WTRU can determine that an SL logical channel is associated with an SL transmission to be relayed from the first RX WTRU to the second RX WTRU.

[0128] The TX WTRU can be configured with a priority threshold (e.g., a threshold associated with resource reselection) for each of the SL logical channels (e.g., each of the SL logical channels) associated with the SL transport via RX WTRU#1 to RX WTRU#2.

[0129] The TX WTRU can receive preferred activity times from RX WTRU#1 and RX WTRU#2. The TX WTRU can configure SL DRX configurations (e.g., activity times) for RX WTRU#1 and RX WTRU#2. In the example, the TX WTRU can determine a first SL DRX configuration associated with the first RX WTRU and a second SL DRX configuration associated with the second RX WTRU. The first SL DRX configuration can indicate a first activity time, and the second SL DRX configuration can indicate a second activity time.

[0130] For example, the TX WTRU may receive the delay of a relay (e.g., forwarding) from the RX WTRU#1. The TX WTRU can determine the effective active time (e.g., the effective active time of the RX WTRU#2 is the active time of the RX WTRU#2, which is time-shifted by the delay of that relay). If one or more SL resource selections are triggered (e.g., when one or more SL resource selections are triggered), then if the SL data used for transmission is associated with one or more SL logical channels, the TX WTRU can determine one or more SL resources during the active time and effective active time of the RX WTRU#1, which are associated with the SL transmission via the RX WTRU#1 to the RX WTRU#2.

[0131] Resource (re)selection checks can be performed. In the example, based on the priority value of the SL logical channel below a threshold, the WTRU can determine the SL resource for SL transmission based on one or more of the following: first active time, second active time, relay delay associated with the first RX WTRU, or PDB associated with the SL logical channel. For example, if SL data and SL data from one or more configured SL logical channels associated with the SL transmission via RX WTRU#1 to RX WTRU#2 trigger SL resource (re)selection, the TX WTRU can determine whether to trigger SL resource re)selection by one or more of the following: if the (re)selected resource is within the active time of RX WTRU#1 and the effective active time of RX WTRU#2, the TX WTRU can maintain the current SL resource. If the (re)selected resource is outside the active time of RX WTRU#1, then the WTRU (e.g., TX WTRU) can trigger a resource (re)selection; if the (re)selected resource is within the active time of RX WTRU#1 but outside the effective active time of RX WTRU#2, then the WTRU can trigger a resource (re)selection or retain the current SL resource. For example, if the priority value of the SL data is below the configured threshold and the remaining PDB is within the effective active time of RX WTRU#2, then the WTRU can trigger a resource (re)selection. If the priority value of the SL data is not below the configured threshold, or the remaining PDB is not within the effective active time of RX WTRU#2, then the WTRU can retain the current SL resource.

[0132] LCP enhancements associated with U2U relays can be performed. For example, a TX WTRU (e.g., a source WTRU) can select a destination associated with an SL logical channel during the execution of an LCP procedure based on the activity time of one or more RX WTRUs (e.g., RX WTRU#1 and RX WTRU#2).

[0133] A TX WTRU (e.g., a source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (e.g., a destination WTRU) via RX WTRU#1. The TX WTRU can be configured with one or more SL logical channels associated with SL transmissions from RX WTRU#1 to RX WTRU#2. The TX WTRU can be configured with priority thresholds (e.g., priority thresholds for each of the SL logical channels) for the SL logical channels associated with SL transmissions from RX WTRU#1 to RX WTRU#2. The TX WTRU may receive delays, for example, from a relay (e.g., forwarding) from RX WTRU#1. The TX WTRU can obtain (e.g., receive or determine) preferred active times from RX WTRU#1 and RX WTRU#2. The TX WTRU can configure (e.g., active times) SL DRX configurations (e.g., active times) for RX WTRU#1 and RX WTRU#2. For a selected SL grant, the TX WTRU can determine the SL destination and one or more SL logical channels to include in the MACPDU used for granting, as one or more of the following: If data is available from one of the SL logical channels associated with an SL transport via RX WTRU#1 to RX WTRU#2, and the selected SL grant is active during the activity periods of both RX WTRU#1 and RX WTRU#2, and the priority value of one or more SL logical channels is lower than a configured priority threshold, then the TX WTRU can select the destination associated with RX WTRU#1 and include data from (one or more) SL logical channels associated with the SL transport to RX WTRU#2 first, before other SL logical channels; otherwise, the TX WTRU can select the destination with (one or more) SL logical channels with the highest priority and include SL data from the SL logical channels in priority order. The TX WTRU can use the selected grant to transmit SL data to RX WTRU#1.

[0134] SL DRX configuration alignment can be based on PDB and / or relay latency. For example, a TX WTRU (e.g., a source WTRU) can determine the aligned SL DRX configuration (e.g., on-time duration, SL DRX cycle) for an RX WTRU. The aligned SL DRX configuration can also be determined based on the E2EPDB of the SL data and / or the latency of one or more relays.

[0135] A TX WTRU (e.g., a source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (e.g., a target WTRU) via RX WTRU#1. The TX WTRU can receive preferred active time from RX WTRU#1 and preferred active time from RX WTRU#2, respectively. The TX WTRU can be configured by the network, for example, with a maximum relay latency dependent on the CBR. The TX WTRU can determine the minimum PDB for E2E delivery, for example, based on or according to a QoS profile mapped to one or more (e.g., each) sidelink radio bearers (SLRBs). The TX WTRU can determine the SL DRX configuration for one or more alignments (e.g., each RX WTRU) using one or more of the following conditions: the TX WTRU can select the SL DRX period and on-time duration, for example, such that (SL DRX period - on-time duration) < (minimum PDB for E2E delivery - maximum relay latency). TX WTRU can transfer (one or more) aligned SL DRX configurations to RX WTRU (e.g., each RX WTRU).

[0136] Activity time can be determined based on buffer time. For example, the activity time of an RX WTRU (e.g., a relay WTRU) and different (e.g., new or modified) SLDRX configurations can be determined based on the measured average buffer time variation.

[0137] A WTRU (e.g., a relay WTRU, such as RX WTRU#1) can establish a PC5 connection with a TX WTRU (e.g., a source WTRU) and an RX WTRU#2 (e.g., a destination WTRU) via RX WTRU#1. The WTRU can receive an SL DRX configuration that includes a set of buffer times associated with one or more (e.g., each) active times (e.g., on-time durations). The WTRU can measure the average buffer time as the time between receiving a PDU and transmitting that PDU to the next hop. The WTRU can be configured with a threshold for variations in the average buffer time. If the measured average buffer time variation exceeds a configured threshold, the WTRU may select the active time (e.g., on-duration) associated with the RX WTRU#2 based on the measured buffer time and the received SL DRX configuration, send a different SL DRX configuration to the RX WTRU#2 (e.g., a new SL DRX configuration or an updated / modified SL DRX configuration), and / or perform one or more subsequent transfers to the RX WTRU#2 based on a different active time (e.g., a new active time or an updated / modified active time).

[0138] Path selection can be performed based on the SL DRX of one or more U2N trunks. For example, the TX WTRU (e.g., the source WTRU) can determine the path (e.g., a direct path or an indirect path) based on the activity time of the RX WTRU (e.g., the trunk WTRU).

[0139] A TX WTRU (e.g., a source WTRU) can establish a PC5 connection with an RX WTRU#1 (e.g., a relay WTRU). The TX WTRU can configure an SL DRX configuration for the RX WTRU. The TX WTRU can be configured with a CBR threshold for path (re)selection. The TX WTRU can determine the indirect or direct path for the uplink transmission, for example, when triggering data (e.g., new data) in one or more SL logical channels associated with uplink transmissions via separate bearers on multiple paths (e.g., using Uu transmission or SL transmission): If RX WTRU#1 is outside of its active period, and if the delay of the indirect transmission does not meet E2E QoS, and if the measured CBR value is higher than the configured CBR threshold, the TX WTRU can determine the direct path. If RX WTRU#1 is within its active period, and if the delay of the indirect transmission meets E2E QoS, and if the measured CBR value is lower than the configured CBR threshold, the TX WTRU can determine the indirect path. The TX WTRU can transmit data via the uplink or SL based on the determined path.

[0140] One or more of the following aspects may apply to one or more examples in this article.

[0141] In one or more examples in this paper, for simplicity, a U2U trunk with two RX WTRUs can be used. These examples can be applied to other scenarios with more than two RX WTRUs. For example, one or more examples in this paper can be applied to and / or extended to scenarios with N multi-RX WTRUs#N (N>2) with multi-hop U2U (N>2) trunks.

[0142] For example, the expected SL DRX configuration of one or more (e.g., all) RX WTRUs can be notified (e.g., known) to the source WTRU (e.g., TX WTRU) via SL WTRU auxiliary information. In the example, under conditions or circumstances where the source WTRU (e.g., TX WTRU) can know the expected SL DRX configuration (e.g., on-time, SL DRX period) of one or more (e.g., all) RX WTRUs via SL WTRU auxiliary information, the source WTRU can consider the received expected(one or more) SL DRX configurations, for example, when the source WTRU determines the SL DRX of the RX WTRU (e.g., when the source WTRU determines the SL DRX of the RX WTRU, it considers the received expected SL DRX configuration).

[0143] One or more SL logical channels can be configured.

[0144] A TX WTRU (e.g., a source WTRU) can be configured with SL bearer mapping via, for example, an SRAP sublayer. In the example, when a TX WTRU (e.g., a source WTRU) is configured with SL bearer mapping via an SRAP sublayer, the SRAP sublayer can perform end-to-end U2U bearer mapping. For example, the PC5SRAP sublayer at an L2 U2N remote WTRU can support UL bearer mapping between end-to-end Uu radio bearers and / or egress PC5 relay RLC channels of the L2 U2N remote WTRU. The PC5-SRAP sublayer can perform bearer mapping for WTRUs (e.g., source WTRU to RX WTRU#1 and RX WTRU#1 to RX WTRU#2) and / or data multiplexing of end-to-end radio bearers (e.g., SRBs or DRBs) for U2U relays.

[0145] In an SRAP sublayer configuration based on SL logical channels, a source WTRU (e.g., TX WTRU) can be configured with one or more SL logical channels and / or associated with one or more SL transmissions of multiple receivers (e.g., RX WTRU#1 and / or RX WTRU#2). Assuming the source WTRU can be connected to a multi-hop network with multiple RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N), the source WTRU can be configured with one or more SL logical channels and / or associated with one or more SL transmissions of multiple receivers (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N).

[0146] The source WTRU may receive configurations of one or more SL logical channels, for example, via cell-specific RRC messages or dedicated RRC messages, or (pre)configured messages (e.g., pre-configured with one or more SL logical channels). The source WTRU may receive a configuration list of one or more SL logical channels associated with SL transmissions, as one or more of the following: one or more SL logical channels from the source WTRU to RX WTRU#1 and associated SL transmissions; one or more SL logical channels from the source WTRU via RX WTRU#1 to RX WTRU#2 and associated SL transmissions; ...; and one or more SL logical channels from the source WTRU via RX WTRU#1 to RX WTRU#N-1 to RX WTRU#N and associated SL transmissions.

[0147] Delays may occur in a trunk. In a U2U trunk, a TX WTRU (e.g., a source WTRU) can establish a PC5-RRC connection with an RX WTRU#1 (e.g., a trunk WTRU), and / or can establish a PC5-RRC connection with an RX WTRU#2 (e.g., a target WTRU) via an RX WTRU#1.

[0148] In a U2U trunk, an additional delay can be considered between the TX WTRU (e.g., the source WTRU) and RX WTRU #2 via RX WTRU #1. For example, when the TX WTRU transmits SL data to RX WTRU #1 (e.g., the trunk WTRU), RX WTRU #1 can, for example, forward the received SL data to RX WTRU #2 (e.g., the destination WTRU) after receiving the transmitted SL data. The latency value (e.g., milliseconds) of the relay from TX WTRU to RX WTRU#2 via RX WTRU#1 may include one or more of the following: forwarding delay from RX WTRU#1 to RX WTRU#2; and / or propagation delay (e.g., TX WTRU (e.g., source WTRU) -> RX WTRU#1 -> RX WTRU#2); and / or retransmission delay based on NACK (e.g., MAC, RLC) (e.g., TX WTRU (e.g., source WTRU) -> RX WTRU#1; and / or RX WTRU#1 -> RX WTRU#2); and / or decoding and / or processing delay in RX WTRU#1 and / or RX WTRU#2 (e.g., receiving the first-level SCI and the second-level SCI and PSSCH).

[0149] The relay delay can be configured for the TX WTRU (e.g., the source WTRU).

[0150] In the example, the TX WTRU can receive the relay's delay values ​​(e.g., maximum and / or minimum values) from the RX WTRU#1. The RX WTRU#1 can determine the relay's delay (e.g., based on the RX WTRU#1's capabilities, the Side Link Discovery Reference Signal Received Power (SD-RSRP), and the distance (e.g., the distance between RX WTRU#1 and RX WTRU#2)). Based on the received delay values, the TX WTRU can determine the relay's E2E delay.

[0151] In the example, the TX WTRU can receive the relay's delay values ​​(e.g., maximum and / or minimum values) from one or more RX WTRUs (e.g., RX WTRU#N). The RX WTRU#N can determine the relay's delay (e.g., based on the RX WTRU#N's capabilities, SD-RSRP, and distance (e.g., the distance between RX WTRU#N and RX WTRU#N+1)). Based on the received delay values, the TX WTRU can determine the relay's E2E delay.

[0152] In the example, the TX WTRU can be configured with a relay delay value as the time for relaying from the network (e.g., a maximum and / or minimum value). The delay value can be associated with one or more relay WTRU operations. For example, the network can configure the relay delay value via a cell-specific message or a dedicated RRC message.

[0153] In the example, the TX WTRU can be configured with the relay's delay as an offset value (e.g., a maximum and / or minimum value). The delay offset value can be associated with one or more relay WTRUs. The TX WTRU can be configured with the offset value (e.g., for the TX WTRU). For example, the network can configure the offset value, for example, via a cell-specific message or a dedicated RRC message, or the TX WTRU can be (pre)configured (e.g., the source WTRU).

[0154] The latency value (e.g., milliseconds) of a relay (e.g., in an example extending to N RX WTRUs) may include one or more of the following: forwarding delay from RX WTRU#1 to RX WTRU#N; and / or propagation delay (e.g., TX WTRU (e.g., source WTRU) -> RX WTRU#1 -> RX WTRU#2 -> RX WTRU#N); and / or retransmission delay based on NACK (e.g., MAC of RLC) (e.g., TX WTRU (e.g., source WTRU) -> RX WTRU#1; and / or RX WTRU#1 -> RX WTRU#2; and / or RXWTRU#N-1 -> RX WTRU#N); and / or decoding and / or processing delays in RX WTRU#1, RX WTRU#2, and / or RX WTRU#N (e.g., receiving the first-level SCI and the second-level SCI and PSSCH).

[0155] In one or more examples in this document, "network" may include gNB or NG-RAN. "SL LC" and "sidelink logical channel" may be used interchangeably in one or more examples in this document. "A priority" and "SL priority" may be used interchangeably in one or more examples in this document.

[0156] Resource (re)selection for U2U trunks can be performed. For example, a TX WTRU (e.g., a source WTRU) can determine the SL resource for U2U trunks and / or determine the trigger for SL resource (re)selection, for example, based on the activity time of one or more RX WTRU#1 and RX WTRU#2.

[0157] Resource selection can be performed. A TX WTRU (e.g., a source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (e.g., a destination WTRU) via RX WTRU#1. A TX WTRU can be configured with one or more SL logical channels associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2. A priority threshold (e.g., reselection) can be configured for one or more (e.g., each) of the SL logical channels associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2. A TX WTRU can receive one or more preferred active times from RX WTRU#1 and RX WTRU#2. A TX WTRU can configure one or more SL DRX configurations (e.g., active times) for RX WTRU#1 and RX WTRU#2. A TX WTRU may receive delays from a relay (e.g., forwarding) from RX WTRU#1. The TX WTRU can determine the effective active time of RX WTRU#2 as the active time of RX WTRU#2 offset from the delay of the relay in time.

[0158] If one or more SL resource selections are triggered (e.g., when one or more SL resource selections are triggered), the TX WTRU can determine one or more SL resources during the active time of RX WTRU#1 and the effective active time of RX WTRU#2 (e.g., if the SL data to be transmitted is associated with one or more SL logical channels, which are associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2).

[0159] Resource (re)selection checks can be performed. In the example, if SL resource (re)selection is triggered by SL data, and the SL data comes from one or more configured SL logical channels associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2, then TX WTRU can determine whether to trigger SL resource re)selection according to one or more of the following: if the (re)selected resource is within the active time of RX WTRU#1 and the valid active time of RX WTRU#2, then TX WTRU can maintain the current SL resource; if the (re)selected resource is outside the active time of RX WTRU#1, then TX WTRU can trigger resource (re)selection; if the (re)selected resource is within the active time of RX WTRU#1 and outside the valid active time of RX WTRU#2, then if the priority value of the SL data is below the configured threshold and the remaining PDB is within the valid active time of RX WTRU#2, then TX WTRU can trigger resource (re)selection, and otherwise, TX WTRU can maintain the current SL resource.

[0160] The configurations described in one or more examples in this document can be used. Based on one or more examples in this document (e.g., examples regarding the configuration of SL logical channels), the TX WTRU can be configured with (e.g., by receiving configuration information) one or more SL logical channels. Based on one or more examples in this document (e.g., examples regarding relay delay), the TX WTRU can be configured with (e.g., by receiving configuration information) relay delay.

[0161] Resource selection based on activity time can be associated with certain logical channels (e.g., bound to a specific logical channel). For example, if an SL logical channel is associated with a trunk RX WTRU, SL resources can be selected for SL transmission of data associated with the SL logical channel based on the activity time(s) associated with one or more RX WTRUs(s).

[0162] When SL resource selection is triggered (e.g., by the arrival of SL data), the TX WTRU (e.g., the MAC layer) can request a subset of SL resources for PSCCH and / or PSSCH transmissions from the PHY layer (e.g., the TX WTRU's). For example, it can be determined that SL data is available (e.g., for SL transmission), and SL resource selection can be performed based on this determination. The WTRU (e.g., the physical layer (PHY)) can receive, for example, the SL DRX activity time for the destination from the WTRU's MAC layer. For example, it can receive the SL DRX configuration associated with the target RX WTRU, and / or the SL DRX configuration can indicate the SL DRX activity time.

[0163] When determining the set (e.g., a subset) of SL resources for a TX WTRU (e.g., in the case where an SL DRX is configured for an RX WTRU), the TX WTRU may take into account the activity time of the RX WTRU. For example, the TX WTRU may determine the SL resources based on the activity time of the RX WTRU. In some examples, if the TX WTRU can select one or more SL resources, for example, for SL transmissions(one or more) outside the active time of the RX WTRU, the RX WTRU may not receive SL data transmitted via (one or more) SL transmissions (e.g., because the RX WTRU can skip monitoring of transmitted SL data during the period outside the active time (e.g., PSCCH / PSSCH transmissions). In the examples, the period outside the active time can include the time before the start of the active time and the time after the end of the active time. In the examples, when data is available on certain logical channels, the TX WTRU (e.g., the source WTRU) may consider the active time of multiple WTRUs (e.g., two or more WTRUs) in the resource selection. Certain SL logical channels (e.g., specific SL logical channels) may be configured for transmissions(one or more) via U2U relays. When SL data is available for transmissions(one or more) on these SL logical channels, the TX WTRU may receive SL data transmitted via one or more (e.g., all) RX WTRUs. Within one or more of the WTRU's active time (e.g., slot / subframe), one or more SL resources for one or more SL transmissions are determined (e.g., selected). For example, if an SL DRX configuration is configured for an RX WTRU(s) (e.g., an RX WTRU for all destinations), the TX WTRU can determine the SL resources for one or more SL transmissions based on the active time of the RXWTRU(s).For example, the TX WTRU may be based on one or more activity times (e.g., according to one or more activity times associated with one or more SL logical channels from the SRAP layer as described in one or more examples herein) as one or more of the following: when SL resource selection is triggered by SL data associated with one or more SL logical channels, the TX WTRU may determine one or more SL resources based on the activity time of RX WTRU#1, which is associated with one or more SL transmissions to RX WTRU#1; and / or, when SL resource selection is triggered by SL data associated with one or more SL logical channels, the TX WTRU may determine one or more SL resources based on the activity times of RX WTRU#1 and RX WTRU#2, which are associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2.

[0164] The effective SL activity time can be used to determine SL resources. In the example, RX WTRU#2 can be associated with the effective SL activity time. When SL resource selection is triggered by SL data associated with (e.g., belonging to / from) one or more SL logical channels, TX WTRU can determine one or more SL resources based on the effective activity time (e.g., the effective activity time associated with RX WTRU#1 and RX WTRU#2), which are associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2 (e.g., one or more SL logical channels are configured to relay one or more SL transmissions via RX WTRU#1 to RX WTRU#2). For example, the effective activity time can be determined based on the activity time associated with RX WTRU#1, the activity time associated with RX WTRU#2, and the relay delay. When SL data is transmitted from TX WTRU to RX WTRU#2 via RX WTRU#1 (e.g., as a relay WTRU), the relay delay can be taken into account when determining the effective activity time (e.g., as the effective activity time of RX WTRU#2).

[0165] In some examples, delays (e.g., due to a relay from RX WTRU#1) may affect the activity time of RX WTRU#2. For example, if the SL resource can be determined from the end of the activity time of RX WTRU#1 (e.g., the end of both the activity times of RX WTRU#1 and RX WTRU#2), then the activity time of RX WTRU#2 may end before the data relayed from RX WTRU#1 to RX WTRU#2 is received by RX WTRU#2 (e.g., the activity time of RX WTRU#2 may end, and RX WTRU#2 may not receive data due to relay delays). For example, the effective activity time (e.g., the effective activity time of RX WTRU#2) can be determined as the activity time taking into account the delay of the relay from RX WTRU#1 to RX WTRU#2. For example, the effective activity can be determined at least based on the overlap time of the activity times of RX WTRU#1 and RX WTRU#2 and the relay delay (e.g., excluding the relay delay from the end of the activity time of RX WTRU#2 within the overlap time). In the example, the first activity time can be a first time interval associated with a first start time and a first end time, and the second activity time can be a second time interval associated with a second start time and a second end time. The WTRU can determine the overlapping time interval between the first and second time intervals. The WTRU can determine the valid activity time based on the overlapping time interval and the relay delay associated with the first RX WTRU. For example, the overlapping time interval can begin at the later of the start time of the first and second time intervals. The overlapping time interval can end at the earlier of the end time of the first and second time intervals. In some examples, the valid activity time (e.g., the valid activity time of RXWTRU#2) can be the overlapping time interval (e.g., equal to the overlapping time interval) or it can be a time interval shorter than the overlapping time intervals of RXWTRU#1 and RX WTRU#2 (e.g., as...). Figure 9 As shown in the image).

[0166] For example, the TX WTRU may use one or more of the following to determine the effective active time (e.g., the effective active time of RXWTRU#2). In the example (e.g., case #1), when the active time of RX WTRU#1 (e.g., on-time duration) and the active time of RX WTRU#2 end simultaneously, the TX WTRU may select an overlapping time period associated with the active time of RX WTRU#1 and the active time of RX WTRU#2, and / or then exclude the relay delay from the end of the active time of RX WTRU#2. Figure 8 An example of the effective active time of RX WTRU#2 is shown (case #1). For example... Figure 8As shown, the overlapping time period ends at time 804, and the effective activity time ends at time 802. The difference between time 802 and time 804 is the relay delay.

[0167] In an example (e.g., case #2), when the activity time (e.g., on-duration) of RX WTRU #1 is later than the end of the activity time of RX WTRU #2, TX WTRU can choose the overlapping time period associated with the activity time of RX WTRU #1 and the activity time of RX WTRU #2, and / or then exclude the delay of the relay from the end of the activity time of RX WTRU #2. Figure 9 An example of the effective active time of RX WTRU#2 (case #2) is shown. Figure 9 As shown, the overlapping time period ends at time 904, and the effective activity time ends at time 902. The difference between time 902 and time 904 is the relay delay.

[0168] In an example (e.g., case #3), when the activity time (e.g., on-duration) of RX WTRU #1 is earlier than the end of the activity time of RX WTRU #2, TX WTRU can select an overlapping time period associated with the activity time of RX WTRU #1 and the activity time of RX WTRU #2. Figure 10 An example of the effective activity time of RX WTRU#2 is shown (case #3). For example... Figure 10 As shown, the overlapping time period ends at time 1004, which is the same time as the end of the effective activity period.

[0169] Resource (re)selection can be performed. In the example, the TX WTRU (e.g., the source WTRU) can be (pre)configured with a priority threshold to determine SL resource reselection. Based on the priority values ​​of SL logical channels below the threshold, the TX WTRU can perform resource (re)selection. The network can configure the priority threshold (e.g., via cell-specific messages or dedicated RRC messages to the TX WTRU), or it can (pre)configure the TX WTRU.

[0170] In some examples, when the conditions for resource reselection are met (e.g., when SL resource selection is triggered as a result of TX resource (re)selection checks), the TX WTRU (e.g., the source WTRU) can determine one or more SL resources for (with one or more) SL transmissions (e.g., by performing resource reselection). If the conditions for resource reselection are not met, the TX WTRU may not trigger SL resource reselection. According to one or more examples as described herein, if SL resource (re)selection is triggered by SL data associated with one or more SL logical channels associated with (one or more) SL transmissions via RX WTRU#1 to RX WTRU#2, the TX WTRU may or may not trigger SL resource (re)selection.

[0171] The TX WTRU can determine to perform a (re)selection of SL resources for one or more of the following reasons: if the (re)selected SL resource is outside the active time of RX WTRU#1 (e.g., RX WTRU#1 is the destination of the TX WTRU); or if the (re)selected resource is within the active time of RX WTRU#1 and outside the effective active time of RX WTRU#2 (e.g., if the priority value of the SL data is lower than a (pre)configured threshold (e.g., the priority value is less than the configured threshold (indicating higher priority)) and / or if the remaining PDB is less than the effective active time of RX WTRU#2). In the example, the TX WTRU can determine that the first SL resource that has been selected is outside the effective active time of RX WTRU#2 (and has the active time of RX WTRU#1). The TX WTRU can determine that the priority value of the SL logical channel is lower than the configured threshold. The TX WTRU can determine that the remaining PDB is within the effective active time of RX WTRU#2. The TX WTRU can select a second SL resource for transmitting data associated with the SL logical channel based on the determination that the first SL resource is outside the effective active time of the RX WTRU#2, the determination that the priority value of the SL logical channel is lower than a configured threshold, and the determination that the remaining PDB is within the effective active time of the RX WTRU#2 (e.g., by performing SL resource reselection).

[0172] TX WTRU may determine to retain the currently selected (one or more) SL resources (e.g., not to perform SL resource (re)selection) under one or more of the following conditions: if the (re)selected resource is within the active and valid active time of RX WTRU#1 (e.g., the valid active time of RX WTRU#2); or if the (re)selected resource is within the active time of RX WTRU#1 and outside the valid active time of RX WTRU#2, and if the priority value of the SL data is higher than a configured threshold (e.g., the priority value is greater than a configured threshold (indicating a lower priority)) and / or if the remaining PDB is less than the valid active time of RX WTRU#2.

[0173] The resource (re)selection procedure can be extended to multi-hop U2U trunks.

[0174] In the example, a TX WTRU (e.g., a source WTRU) can perform SL resource selection for several RX WTRUs. For example, a TX WTRU can be connected to a multi-hop with multiple RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N). Assuming a TX WTRU can be connected to a multi-hop with multiple RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N), if the SL resource selection is triggered by SL data belonging to / from one or more SL logical channels associated with one or more SL transports from RX WTRU#1 to RX WTRU#N-1 to RX WTRU#N (e.g., configured according to one or more examples in this document, such as examples of configuration regarding SL logical channels), then the TX WTRU can determine one or more SL resources based on the activity time of one or more (e.g., all) RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N). In this scenario, the TX WTRU may perform the following behaviors: In some examples, the TX WTRU (e.g., the source WTRU) may perform SL resource selection until the TX WTRU can determine one or more SL resources with one or more (e.g., all) WTRUs having active times (e.g., including valid active times). When the TX WTRU may not be able to determine one or more SL resources with active times (e.g., including valid active times) for (e.g., all) RX WTRUs (e.g., from RX WTRU#2 to RX WTRU#N), the TX WTRU may, for example, report to the RRC layer (e.g., one or more destinations of the RX WTRU). The TX WTRU may release (or reconfigure) one or more SL DRX configurations associated with one or more reported or being reported destinations.

[0175] One or more LCP enhancements can be implemented for U2U relays. For example, a TX WTRU (e.g., a source WTRU) can select a destination associated with one or more SL logical channels during the execution of an LCP procedure based on the activity time of one or more RX WTRUs (e.g., RX WTRU#1, RX WTRU#2).

[0176] In the example, the TX WTRU (e.g., the source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (e.g., a destination WTRU) via RX WTRU#1. The TX WTRU can be configured with one or more SL logical channels associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2. The TX WTRU can be configured with priority thresholds for one or more (e.g., each) of the SL logical channels associated with one or more SL transmissions via RX WTRU#1 to RX WTRU#2. The TX WTRU may receive delays, for example, from a relay (e.g., a forwarding) from RX WTRU#1. The TX WTRU can receive one or more preferred active times from RX WTRU#1 and RX WTRU#2. The TX WTRU can configure one or more SL DRX configurations (e.g., one or more active times) for RX WTRU#1 and RX WTRU#2. For an SL grant (e.g., a selected SL grant), the TX WTRU may determine one or more SL destinations and / or one or more SL logical channels to include in the MAC PDU used for granting, as one or more of the following: If data is available from one of the SL logical channels associated with one or more transmissions via RX WTRU#1 to RX WTRU#2, and the selected SL grant is active during one or more of the activity times of both RX WTRU#1 and RX WTRU#2, and the priority value of one or more of the SL logical channels is lower than a configured priority threshold, then the TX WTRU may select one or more destinations associated with RX WTRU#1 and include data from the SL logical channels associated with one or more transmissions to RX WTRU#2 first, before other SL logical channels; otherwise, the TX WTRU may select one or more destinations with the highest priority SL logical channel and include SL data from the SL logical channels in priority order. The TX WTRU may use the selected grant to transmit SL data to RX WTRU#1.

[0177] The configurations shown in one or more examples in this article can be used. Based on one or more examples in this article, the TX WTRU can be configured with one or more SL logical channels. Based on one or more examples in this article, the TX WTRU can be configured with relay delays.

[0178] You can use one or more priority thresholds for one or more SL logical channels.

[0179] In the example, the TX WTRU (e.g., the source WTRU) can be (pre-)configured with a threshold for the SL priority of one or more (e.g., each) SL logical channels (e.g., SL logical channels associated with one or more transmissions to RX WTRU#1 (or via RX WTRU#1 to RX WTRU#2). For example, the network can configure one or more thresholds for the SL priority of the TX WTRU via a cell-specific message or a dedicated RRC message to the TX WTRU, or the TX WTRU can be (pre-)configured. When SL data is available from one or more SL logical channels associated with one or more transmissions via RX WTRU#1 to RX WTRU#2, the configured priority value can be used (e.g., advantageously used) to prioritize the SL logical channels associated with one or more transmissions to RX WTRU#2 (e.g., due to relay delays).

[0180] One or more LCP enhancements can be implemented.

[0181] In the example, after selecting one or more SL grants (e.g., on an SL), the TX WTRU can perform LCP on the selected one or more SL grants. The TX WTRU can determine the destination associated with RX WTRU#1 and / or primarily include SL data from one or more SL logical channels (e.g., configuration from the SRAP layer in one or more examples herein) associated with a transport to RX WTRU#2 when one or more of the following conditions are met: if the SL data is available from one or more SL logical channels associated with one or more transports via RX WTRU#1 to RX WTRU#2; and if the selected SL grant is within the active time of one or more of both RX WTRU#1 and RX WTRU#2 (e.g., the effective active time of RX WTRU#2); and whether a threshold for SL priority is (pre-)configured, and the SL priority value of one or more SL logical channels is lower than the (pre-)configured threshold.

[0182] When one or more (e.g., all) of the above conditions are met, for example, for the selected SL grant, the TXWTRU may prioritize one or more SL logical channels associated with one or more transmissions to RX WTRU#2. Before including other SL logical channels, the TX WTRU may first include SL data from the SL logical channels associated with one or more transmissions to RX WTRU#2, while also including SLMAC PDUs with the selected SL grant (e.g., selecting the SL logical channel). When one or more (e.g., all) of the above conditions are met, the TX WTRU may prioritize selecting RXWTRU#1 as the destination over other destinations where higher-priority data may be available. If one of the above conditions is not met, the TX WTRU may determine to select the SL logical channel with the highest SL priority and / or include data from the SL logical channels in order of SL priority (e.g., via a conventional SL LCP without enhancement).

[0183] One or more LCP enhancements can be extended to multi-hop U2U trunks.

[0184] In the example, after selecting one or more SL grants, the TX WTRU can perform LCP on the selected one or more SL grants. The TX WTRU can determine the destination associated with RX WTRU#1 and / or primarily include SL data from the SL logical channels associated with one or more transmissions from RX WTRU#2 to RX WTRU#N when one or more of the following conditions are met: if the data is available from one or more SL logical channels and associated with one or more SL transmissions from TX WTRU to RX WTRU#N via RX WTRU#1 to RX WTRU#N; and if the selected SL grant is within one or more of the active times (e.g., the effective active time of RXWTRU#2) of one or more (e.g., all) of the RX WTRUs; and whether a threshold for SL priority is (pre-)configured, and the SL priority value of the SL data is lower than that threshold (e.g., the (pre-)configured threshold).

[0185] When one or more SL grants satisfy one or more of the conditions (e.g., all of them), the TX WTRU may prioritize the SL logical channels associated with one or more transmissions to RX WTRU#2, while including SL MAC PDUs in the selected one or more SL grants. For example, before including other SL logical channels, the TX WTRU may first include SL data from the SL logical channels associated with one or more transmissions to RX WTRU#N (e.g., N=2 / 3 / 4 / … / N) (e.g., if available). If one of the above conditions is not met, the TX WTRU may determine to select the SL logical channel with the highest SL priority and / or include data from the SL logical channels in order of SL priority (e.g., via conventional SLLCP without enhancement).

[0186] SL DRX alignment can be based on PDB and / or relay latency. For example, a TX WTRU (e.g., a source WTRU) can determine the aligned SL DRX configuration (e.g., on-time, SL DRX cycle, etc.) for an RX WTRU. Alternatively, the aligned SL DRX configuration can be determined based on the E2EPDB of the SL data and / or relay latency.

[0187] In the example, a TX WTRU (e.g., a source WTRU) can establish a PC5 connection with RX WTRU#1 (e.g., a relay WTRU) and RX WTRU#2 (e.g., a target WTRU) via RX WTRU#1. The TX WTRU can receive preferred active times from RX WTRU#1 and RX WTRU#2 respectively. The TX WTRU can be configured by the network with CBR-dependent relay latency (e.g., maximum CBR-dependent relay latency). The TX WTRU can determine the minimum PDB for E2E delivery, for example, based on a QoS profile mapped to one or more (e.g., each) SLRBs. The TX WTRU can determine the aligned SL DRX configuration for one or more (e.g., each) RX WTRUs using one or more of the following conditions: The TX WTRU can select the SL DRX period and / or on-time duration such that the following condition is satisfied (e.g., SL DRX period - on-time duration) < (minimum PDB for E2E delivery - maximum relay latency). The TX WTRU can transfer (one or more) aligned SL DRX configurations to one or more (e.g., each) of the RX WTRUs.

[0188] In some examples, a TX WTRU (e.g., a source WTRU) can perform one or more SL DRX alignments in a centralized manner for one or more (e.g., all) RX WTRUs (e.g., RX WTRU#1, RX WTRU#2). When SL data is triggered (e.g., periodically), a TX WTRU can determine the SL DRX configuration of one or more alignments for one or more (e.g., a DRX configuration for a single alignment indicating the on-time duration, SL DRX period, etc.) for one or more (e.g., all) RX WTRUs.

[0189] The configurations shown in one or more examples in this article can be used. Based on one or more examples in this article, the TX WTRU can be configured with one or more SL logical channels. Based on one or more examples in this article, the TX WTRU can be configured with relay delays.

[0190] Delays that depend on the CBR can be configured.

[0191] In the example, the TX WTRU (e.g., the source WTRU) can be configured with a mapping of delays that depend on the CBR (e.g., a set of maximum delays, e.g., one or more of the maximum delays), where the relay is associated with each CBR value. This mapping can be applied to relay operations (e.g., per hop). This mapping can be applied to multi-hop relays.

[0192] For example, the TX WTRU can be configured with a CBR-dependent delay via a cell-specific message or a dedicated RRC message to the TX WTRU, or the TX WTRU can be (pre)configured, or the TX WTRU can be derived from or derived from the RX WTRU#1 based on switched capability signaling. Based on the (pre)configured CBR-dependent delay, the TX WTRU (e.g., the source WTRU) can determine, for example, the maximum delay of the trunk associated with a measured CBR value. To this end, the RX WTRU#1 can pass a measured CBR value (e.g., between RX WTRU#1 and RX WTRU#2, or from RX WTRU#1 to RX WTRU#2) to the TX WTRU. The TX WTRU can then determine the maximum delay of the trunk based on the CBR.

[0193] The TX WTRU can use one or more of other factors to determine latency (e.g., relay latency). For example, the TX WTRU can be configured with a mapping between SL-RSRP and latency. The TX WTRU can receive latency from the relay WTRU (e.g., in a PC5-RRC message). The relay WTRU can determine relay latency based on (e.g., at the adaptation layer) the number of ingress / egress RLC channels and / or the QoS (e.g., PBR) configured for one or more (e.g., each) RLC channels.

[0194] The standard SL DRX configuration can be used.

[0195] In the example, when SL data is triggered for SL transmission, the TX WTRU can determine the aligned SL DRX configuration. For example, the TX WTRU can determine the SL DRX configuration (e.g., on-time duration, SL DRX period) by taking into account relay delay. The TX WTRU can determine the PDB of the SL transmission based on the SL data of one or more configured SL logical channels (e.g., configurations from the SRAP layer in one or more examples herein, such as those described in the examples regarding the configuration of SL logical channels). The TX WTRU can determine the minimum PDB for E2E delivery (e.g., from source WTRU to destination WTRU) based on one or more of the following: the SL data for which the PDB can be determined based on a QoS profile (e.g., milliseconds) (e.g., which the TX WTRU can learn from the QoS profile); the QoS profile can be mapped to one or more (e.g., each) configured SL radio bearers (e.g., which SL radio bearers are associated with the SL logical channel); and, for example, the SL logical channel can be associated with an SL transmission from source WTRU to destination WTRU (E2E).

[0196] To perform SL DRX alignment, the TX WTRU may consider the SL DRX period and / or on-time duration based on, for example, the determined minimum PDB for E2E transmission and / or the determined maximum delay of the relay. The TX WTRU may determine the maximum delay of the relay using measured CBR values. The TX WTRU may determine the SLDRX configuration (e.g., on-time duration) for alignment for one or more (e.g., each) RX WTRUs. The TX WTRU may determine the SLDRX configuration (e.g., on-time duration, SL DRX period) for SL transmission when the following condition is met: (SLDRX period - on-time duration) < (minimum PDB for E2E transmission - maximum delay of the relay).

[0197] Figure 11 An example standard for aligned SL DRX configurations is shown.

[0198] If an aligned SL DRX configuration is received (e.g., when receiving an aligned SL DRX configuration), then one or more (e.g., all) RX WTRUs can be configured with (e.g., the same single) aligned SL DRX configurations.

[0199] TX WTRUs (e.g., source WTRUs) can also be configured with offsets for one or more (e.g., each) of the RX WTRUs in the DRX configuration. For example, the offset in the DRX configuration can represent the delay of a relay as determined as described in one or more examples herein. TX WTRUs can use incremental offsets (e.g., offsets that increase based on the delay of the relay associated with the RX WTRU) of one or more (e.g., each) of the RX WTRUs associated with a multi-hop configuration.

[0200] WTRU can use one or more fallback SL DRX configurations (e.g., fallback to one or more traditional SLDRX configurations).

[0201] In the example, based on specific conditions, such as the following condition being met, the TX WTRU may not configure the aligned SL DRX configuration to the RX WTRU (or may not be configured as the aligned SL DRX configuration to the RX WTRU): (SL DRX cycle - on-duration) < (minimum PDB for E2E transfer - maximum delay with RX WTRU#1 relay).

[0202] In some examples, based on the conditions described above, the TX WTRU may not perform SL DRX alignment. The TX WTRU may configure one or more SL DRX configurations for each (e.g., every) RX WTRU (or each destination) (e.g., RX WTRU#1, RX WTRU#2) via, for example, a fallback SLDRX configuration (e.g., a traditional SL DRX configuration).

[0203] One or more aligned SL DRX configurations can be extended to multi-hop U2U trunks.

[0204] In the example, a TX WTRU (e.g., a source WTRU) can perform SL DRX alignment against several RX WTRUs. The TX WTRU can be connected to a multi-hop network with multiple RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N). Assuming the TX WTRU can be connected to a multi-hop network with multiple RX WTRUs (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N), in this case, the relay delay from the TX WTRU to the target WTRU may be accumulated and / or increased (e.g., due to the number of hops / RX WTRU (e.g., relay WTRU)), for example, the relay delay with RX WTRU#1 + the relay delay with RX WTRU#2 + the relay delay with RX WTRU#3 + ... + the relay delay with RX WTRU#N. The relay delay of multiple RX WTRUs can be configured based on one or more examples in this document (e.g., examples regarding relay delay) (e.g., one or more offsets).

[0205] In some examples, based on specific conditions, such as the following conditions being met, a TX WTRU may not be configured with an aligned SL DRX configuration to one or more (e.g., all) RX WTRUs (or may not be configured with an aligned SL DRX configuration to one or more (e.g., all) RX WTRUs): (SL DRX cycle - on-duration) < (minimum PDB for E2E transmission - maximum delay for relaying with multiple RX WTRUs).

[0206] WTRU can fall back to one or more SL DRX configurations (e.g., one or more traditional SL DRX configurations).

[0207] In the example, based on the conditions above, the TX WTRU may not perform SL DRX alignment. The TX WTRU may not configure one or more SLDRX configurations for each RX WTRU (or each destination) (e.g., RX WTRU#1, RX WTRU#2, ..., RX WTRU#N). The TX WTRU may not configure (e.g., any) SL DRX configurations for one or more (e.g., all) RXWTRUs.

[0208] Activity time can be determined based on buffer time. For example, the activity time of an RX WTRU (e.g., a relay WTRU) and one or more different SL DRX configurations (e.g., one or more new SL DRX configurations or one or more updated / modified SL DRX configurations) can be determined, for example, based on the measured average buffer time variation.

[0209] A WTRU (e.g., a relay WTRU) can establish a PC5 connection with a TX WTRU (e.g., a source WTRU) and an RX WTRU (e.g., a destination WTRU) via RX WTRU#1. The WTRU can receive an SL DRX configuration that includes a set of buffer times associated with one or more (e.g., each) active times (e.g., on-time durations). The WTRU can measure the average buffer time as the time between the reception of a PDU and the transmission of that PDU to the next hop. The WTRU can be configured with a threshold for variations in the average buffer time. If the measured average buffer time changes to a value higher than the configured threshold, one or more of the following may occur: the WTRU may select the active time (e.g., on-duration) associated with RX WTRU#2, for example, based on the measured buffer time and / or the received SLDRX configuration; the WTRU may send a different SL DRX configuration (e.g., a new SL DRX configuration or an updated / modified SLDRX configuration) to RX WTRU#2; the WTRU may perform one or more subsequent transmissions to RX WTRU#2 based on a different active time (e.g., a new active time or an updated / modified active time). Figure 12 An example is shown for determining SL DRX activity time based on buffer time.

[0210] In the example, RX WTRU#1 (e.g., a relay WTRU) can perform one or more SL DRX alignments for RX WTRU#2 (e.g., the next hop) in a distributed manner within a hop (e.g., between RXWTRU#1 and RX WTRU#2). The relay WTRU can determine the SL DRX configuration (e.g., the new active time) to send to the RX WTRU based on the DRX configuration received from the previous WTRU and / or its currently measured buffer time (e.g., dynamically changing).

[0211] One or more SL DRX configurations can be based on buffer time.

[0212] In the example, RX WTRU#1 (e.g., a relay WTRU) can (e.g., during the establishment of a PC5-RRC connection with TX WTRU and RX WTRU#1) receive the SL DRX configuration of RX WTRU#2 from TX WTRU (e.g., a source WTRU). The SL DRX configuration may include a set of buffer times (e.g., average measurement buffer times) associated with one or more (e.g., each) active times of RX WTRU#2 (e.g., a target WTRU). For example, a set of expected buffer times associated with RX WTRU#1 (e.g., buffer times may include or may be the time between the reception of a PDU and the transmission of that PDU to the next hop).

[0213] In some examples, RX WTRU#1 can transmit an SLDRX configuration with buffer times and (one or more) related thresholds to align RX WTRU#2 with the buffer times of RX WTRU#1 and / or the activity time of RX WTRU#2. For example, RX WTRU#1 can request this alignment during PC5-RRC connection setup. For example, RX WTRU#1 can request when an SL transmission (e.g., due to the buffer time of RX WTRU#1) fails.

[0214] RX WTRU#1 can be configured with a threshold for the average buffer time variation (e.g., milliseconds) of one or more active times of RX WTRU#2. For example, this threshold can indicate the allowable average buffer time variation of one or more active times of RX WTRU#2.

[0215] You can select another activity time for RX WTRU#2.

[0216] In the example, when the measured average buffer time change exceeds a configured threshold, RX WTRU#1 can select another active time (e.g., an on duration, an inactive timer, a retransmission timer, a period, etc.) and / or send a different active time (e.g., a new active time or an updated / modified active time) to RX WTRU#2, based on the SL DRX configuration associated with (e.g., each) active time. In some examples, RX WTRU#1 can select another active time based on a time gap between timestamps. For example, a gap can be derived between the timestamp of PDU reception and the timestamp of PDU transmission to RX WTRU#2.

[0217] After selecting an alternative active time for RX WTRU#2, RX WTRU#1 can send a different DRX configuration (e.g., a new DRX configuration or an updated / modified DRX configuration) (or incremental signaling) to RX WTRU#2. RX WTRU#1 can transmit indications (e.g., incrementally) via signaling or message transmission, such as indications in PHY signaling, fields in MAC CE, or messages in RRC messages (e.g., PC5-RRC messages). When the measured average buffer time exceeds a threshold, RX WTRU#1 can select a longer active time for RX WTRU#2 (e.g., longer than the current active time). Based on the updated / modified SLDRX configuration, RX WTRU#2 can receive SL data from RX WTRU#1 during the active time.

[0218] In some examples, RX WTRU#1 can receive a set of DRX configurations from RX WTRU#2 with corresponding buffer times from TX WTRU. RX WTRU#1 can send a DRX configuration (e.g., a specific DRX configuration) associated with the currently measured buffer time to RX WTRU#2 (e.g., during initial configuration, or based on changes in the measured buffer time, e.g., when the measured buffer time changes)). In some examples, RX WTRU#1 can receive a DRX configuration (e.g., a single DRX configuration) for RX WTRU#2 from TX WTRU. RX WTRU#1 can be configured by the network using rules for modifying the received configuration based on its currently measured buffer time. When the buffer time changes, RX WTRU#1 can send a different DRX configuration (e.g., a new DRX configuration or a modified DRX configuration) to RX WTRU#2 by applying the configured rules to the DRX configuration received from TX WTRU.

[0219] You can select another activity time for RX WTRU#N.

[0220] In the example, RX WTRU#N-1 can receive the SL DRX configuration of RX WTRU#N, and the SL DRX configuration can include a set of buffer times (e.g., average measurement buffer times) associated with each (e.g., each) activity time of RX WTRU#N (e.g., when RX WTRU#N-1 can receive the SL DRX configuration of RX WTRU#N, the SL DRX configuration can include a set of buffer times associated with each activity time of RX WTRU#N).

[0221] In some examples, when the measured average buffer time of an active time (e.g., on-duration) changes beyond a configured threshold, RX WTRU#N-1 may, for example, select another active time (e.g., on-duration, inactive timer, retransmission timer, period, etc.) to go to / for RX WTRU#N based on the SL DRX configuration associated with (e.g., each) active time.

[0222] Path selection can be based on the SL DRX of the U2N trunk. For example, the TX WTRU (e.g., the source WTRU) can determine the path (e.g., a direct path or an indirect path) based on the activity time of the RXWTRU (e.g., the trunk WTRU).

[0223] In the example, a TX WTRU (e.g., a source WTRU) can establish a PC5 connection with an RX WTRU#1 (e.g., a relay WTRU). The TX WTRU can configure an SL DRX configuration to the RX WTRU. The TX WTRU can be configured with a CBR threshold for path (re)selection. If data (e.g., new data) in one or more SL logical channels associated with uplink transmissions via separate bearers (e.g., using Uu or SL transmissions) on a multipath is triggered (e.g., when data in one or more SL logical channels associated with uplink transmissions via separate bearers (e.g., using Uu or SL transmissions) on a multipath is triggered), the TX WTRU may determine the indirect or direct path of the uplink transmission based on one or more of the following: if RX WTRU#1 is outside of active time, and if the delay of the indirect transmission does not meet E2E QoS, and if the measured CBR value is higher than the configured CBR threshold, the TX WTRU may determine the direct path; if RX WTRU#1 is active time, and if the delay of the indirect transmission already meets E2E QoS, and if the measured CBR value is lower than the configured CBR threshold, the TX WTRU may determine the indirect path. The TX WTRU may transmit data via UL or SL based on the determined path.

[0224] U2N relay operations can be performed on multiple paths.

[0225] In U2N trunk operations, the TX WTRU (e.g., the source WTRU) can support multipath operations (e.g., a direct path to the network or an indirect path to the network via the trunk WTRU). For SL transmissions via the indirect path, the TX WTRU can establish a PC5-RRC connection with the trunk WTRU. For UL transmissions via the direct path, the TX WTRU can receive one or more uplink configurations via the network (e.g., the direct path).

[0226] The TX WTRU may be configured with one or more UL and / or SL logical channels associated with indirect and / or direct UL transmissions: one or more SL logical channels associated with (one or more) SL transmissions; and / or one or more UL logical channels associated with (one or more) UL transmissions; and / or one or more UL / SL logical channels associated with (one or more) UL transmissions via the relay WTRU (e.g., via (one or more) uplink transmissions with separate bearers on a multipath).

[0227] When SL data (e.g., new SL data) is triggered in one or more UL / SL logical channels associated with one or more uplink transmissions via a relay WTRU (e.g., via a separate bearer on a multipath), the TX WTRU can determine the direct or indirect path for the SL data of the triggered SL transmission(s).

[0228] CBR thresholds can be used for path (re)selection.

[0229] In the example, the TX WTRU (e.g., the source WTRU) can be configured with a CBR threshold for path (re)selection. The network can configure the CBR threshold, for example, via a cell-specific message or a dedicated RRC message to the TX WTRU, or the TX WTRU can be (pre)configured. Based on the (pre)configured CBR threshold, the TX WTRU can determine an indirect or direct path. For example, when the measured CBR value is lower than the preconfigured CBR threshold, the TX WTRU can determine an indirect path. For example, when the measured CBR value is higher than the configured CBR threshold, the TX WTRU can determine a direct path.

[0230] E2E delays can be considered for path (re)selection.

[0231] In the example, the TX WTRU may determine the minimum PDB for E2E delivery (e.g., from source WTRU to target WTRU) as one or more of the following: the PDB (e.g., milliseconds) may be determined based on a QoS profile (e.g., the TX WTRU may know from the QoS profile); the QoS profile may be mapped to one or more (e.g., each) configured SL radio bearers; and (one or more) SL radio bearers may be associated with SL logical channels (e.g., SL logical channels may be associated with SL transports from source WTRU to target WTRU (E2E)).

[0232] Path (re)selection can be based on one or more conditions.

[0233] In the example, when SL data (e.g., new SL data) is triggered in one or more UL / SL logical channels associated with one or more uplink transmissions via a relay WTRU (e.g., via a separate bearer on a multipath), for the triggered UL transmission, the TX WTRU may determine to (re)select a direct path if one or more of the following conditions are met: if the RX WTRU#1 is outside the active time of the triggered transmission; and if the delay of the indirect transmission does not meet E2EQoS; and if the measured CBR value is higher than the configured CBR threshold.

[0234] In some examples, when SL data (e.g., new SL data) is triggered in one or more UL / SL logical channels associated with uplink transmissions (one or more) via a relay WTRU (e.g., via a separate bearer on a multipath), for the triggered UL transmission, the TX WTRU may determine to (re)select an indirect path if one or more of the following conditions are met: if the RX WTRU#1 is active within the time of the triggered transmission; if the delay of the indirect transmission meets E2E QoS; and if the measured CBR value is below the configured CBR threshold.

[0235] If the TX WTRU is unable to determine a direct or indirect path due to the failure to meet the above conditions, the TX WTRU may perform one or more of the following operations: the TX WTRU may maintain the current path (e.g., the indirect or direct path); or the TX WTRU may select a path based on the measured RSRP signal value (e.g., SL-SS Reference Received Power (SS-RSRP) or SL-Channel State Information Reference Signal (CSI-RS) from the Synchronization Block (SSB) / Physical Broadcast Channel (PBCH) or from the Physical Side Link Broadcast Channel (PSBCH)), and for example, if the measured UuRSRP value is higher than the measured SL-RSRP value, the TX WTRU may determine a direct path, and if the measured UuRSRP value is lower than the measured SL-RSRP value, the TX WTRU may determine an indirect path. Figure 13 An example path (re)selection for an SL DRX based on a relay WTRU is shown. The UEs in one or more examples (e.g., those shown in one or more figures herein) can be interchangeably referred to as WTRUs.

[0236] Although the features and elements described above are described in specific combinations, each feature or element may be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0237] While the implementations described herein may consider 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to this scenario and can be applied to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and can also be applied to other wireless systems. For example, although the system has been described with reference to 3GPP, 5G, and / or NR network layers, the contemplated embodiments extend beyond implementations using specific network layer technologies. Similarly, potential implementations extend to some or all types of service layer architectures, systems, and embodiments. The technologies described herein can be applied independently and / or in combination with other resource configuration technologies.

[0238] The processes described herein can be implemented in computer programs, software, and / or firmware, which are incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or 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, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROMs and / or DVDs. The processor associated with the software can be used to implement a radio frequency transceiver for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0239] It should be understood that the entity performing the processes described herein can be a logical entity that can be implemented in the form of software (e.g., computer-executable instructions), which is stored in the memory of a mobile device, network node, or computer system and executed on the processor of the mobile device, network node, or computer system. That is, these processes can be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a mobile device and / or network node (e.g., a node or computer system), which execute the processes in discussion when executed by the node's processor. It should also be understood that any transmission and reception processes shown in the figures can be executed by the node's communication circuitry under the control of the node's processor and the computer-executable instructions (e.g., software) it executes.

[0240] The various techniques described herein can be implemented in combination with hardware or software, or, as appropriate, with a combination of both. Therefore, embodiments and apparatuses of the subject matter described herein, or certain aspects or portions thereof, can take the form of program code (e.g., instructions) embodied in a tangible medium including any other machine-readable storage medium, wherein when the program code is loaded into and executed by a machine such as a computer, that machine becomes an apparatus for practicing the subject matter described herein. In the case where the program code is stored on a medium, it is possible that the program code in question is stored on one or more media that collectively perform the actions in question; that is, one or more media together contain the code for performing the actions, but—in the case where more than one single medium exists—it is not required that any particular portion of the code be stored on any particular medium. In the case of executing program code on a programmable device, the computing device typically includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs can be implemented or utilize the processes described in connection with the subject matter described herein, for example, by using APIs, reusable controls, or the like. Such programs are preferably implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, if desired, one or more programs can be implemented in assembly language or machine language. In any case, the language can be a compiled or interpreted language, combined with a hardware implementation.

[0241] While the example embodiments may relate to utilizing aspects of the subject matter described herein within the context of one or more independent computing systems, the subject matter described herein is not limited thereto, but can be implemented in conjunction with any computing environment, such as a networked or distributed computing environment. Furthermore, aspects of the subject matter described herein can be implemented in or across multiple processing chips or devices, and storage can similarly be implemented across multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as motor vehicles and aircraft.

[0242] In describing preferred embodiments of the subject matter of this disclosure, as illustrated in the figures, specific terminology has been used for clarity. However, the claimed subject matter is not intended to be limited to the specific terminology chosen so far, and it should be understood that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: The side link (SL) logical channel is associated with the SL transmission to be relayed from the first RX WTRU to the second RX WTRU; Determine a first SL discontinuous reception (DRX) configuration associated with the first RX WTRU and a second SL DRX configuration associated with the second RX WTRU, wherein the first SL DRX configuration indicates a first active time and the second SL DRX configuration indicates a second active time; Based on the priority value of the SL logical channel below a threshold, the SL resources for the SL transmission are determined based on the first active time, the second active time, the relay delay associated with the first RX WTRU, and the packet delay budget (PDB) associated with the SL logical channel; and The SL transmission is sent on the SL resource.

2. The WTRU of claim 1, wherein the first active time is a first time period associated with a first start time and a first end time, and the second active time is a second time period associated with a second start time and a second end time, and wherein the processor is further configured to: Determine the overlapping time period between the first and second time periods; and The effective activity time is determined based on the overlapping time period and the relay delay associated with the first RX WTRU, wherein the SL resource is determined to be within the effective activity time.

3. The WTRU of claim 2, wherein the overlapping time period begins at the later of the start time of the first time period and the start time of the second time period, and ends at the earlier of the end time of the first time period and the end time of the second time period.

4. The WTRU according to claim 2, wherein the PDB does not exceed the effective activity time.

5. The WTRU of claim 2, wherein the SL resource is determined via resource reselection, and the processor is further configured to perform the resource reselection based on the determination of the selected SL resource outside the effective active time.

6. The WTRU of claim 1, wherein the processor is further configured to determine that data associated with one or more SL logical channels will be included in an SL transmission relayed through the first RX WTRU to the second RX WTRU, wherein the determination of the SL resource is triggered by determining that data associated with the one or more SL logical channels will be included in the SL transmission.

7. The WTRU of claim 1, wherein the SL resource is determined via resource reselection, and the processor is further configured to perform the resource reselection based on the determination of the selected SL resource outside the first active time.

8. The WTRU of claim 1, wherein the processor is further configured to: Establish a PC5 connection with the first RX WTRU; and Send a message to the first RX WTRU indicating that a PC5 connection will be established with the first RX WTRU and the second RX WTRU.

9. A method performed by a wireless transmit / receive unit (WTRU), comprising: The side link (SL) logical channel is associated with the SL transmission to be relayed from the first RX WTRU to the second RX WTRU; Determine a first SL discontinuous reception (DRX) configuration associated with a first RX WTRU and a second SL DRX configuration associated with a second RX WTRU, wherein the first SL DRX configuration indicates a first active time and the second SL DRX configuration indicates a second active time; Based on the priority value of the SL logical channel below a threshold, the SL resources for the SL transmission are determined based on the first active time, the second active time, the relay delay associated with the first RX WTRU, and the packet delay budget (PDB) associated with the SL logical channel; and The SL transmission is sent on the SL resource.

10. The method of claim 9, wherein the first activity time is a first time period associated with a first start time and a first end time, and the second activity time is a second time period associated with a second start time and a second end time, and wherein the method further comprises: Determine the overlapping period between the first and second time periods; and The effective activity time is determined based on the overlapping time period and the relay delay associated with the first RX WTRU, wherein the SL resource is determined to be within the effective activity time.

11. The method of claim 10, wherein the overlapping time period begins at the later of the start time of the first time period and the start time of the second time period, and ends at the earlier of the end time of the first time period and the end time of the second time period.

12. The method of claim 10, wherein the PDB does not exceed the effective activity time.

13. The method of claim 10, wherein the SL resource is determined via resource reselection, and the method further comprises performing resource reselection based on the determination of the selected SL resource outside of its effective active time.

14. The method of claim 9, further comprising determining that data associated with one or more SL logical channels will be included in an SL transmission relayed through the first RX WTRU to the second RX WTRU, wherein the determination of the SL resource is triggered by determining that data associated with the one or more SL logical channels will be included in the SL transmission.

15. The method of claim 9, wherein the SL resource is determined via resource reselection, and the method further comprises performing the resource reselection based on the determination of the selected SL resource outside the first active time.

Images