Methods, architectures, apparatuses, and systems for performing discontinuous reception on sidelink

Abstract

To disclose methods and apparatus using V2X enhancements to perform discontinuous reception.SOLUTION: In an embodiment, a method implemented by a first WTRU, for a device-to-device (D2D) communication between the first WTRU and a second WTRU. The method may include any of comprising receiving, from the second WTRU, D2D control information comprising :(1) first information indicating one or more first transmission resources reserved for transmission of the D2D communication and (2) second information indicating if at least one second transmission resource is reserved for retransmission of the D2D communication; determining a sleeping period for the first WTRU that ends prior to a reception time of the retransmission of the D2D communication, where the sleeping period is based on the second information; and receiving the retransmission of the D2D communication, after an end of the determined sleeping period.SELECTED DRAWING: Figure 7

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of (i) U.S. Provisional Patent Application No. 63 / 159792, filed March 11, 2021, and (ii) U.S. Provisional Patent Application No. 63 / 185747, filed May 7, 2021, each of which is incorporated herein by reference.

[0002] FIELD Embodiments disclosed herein relate generally to wireless communications, such as methods, apparatus, and systems that perform discontinuous reception (DRX) using V2X extensions. [Background technology]

[0003] The 5G specifications include provisions for DRX to conserve energy in the WTRU. The main purpose of DRX is to reduce battery consumption when (e.g., when) there is no uplink or downlink data to be processed by the wireless transmit / receive unit (WTRU). Therefore, the WTRU can enter a sleep mode in which the RF interface is in a low-power or off mode. When traffic related to the WTRU is expected, the mobile unit can power up to process messages.

[0004] Vehicle communication is a communication mode in which WTRUs can communicate directly with each other. There are two scenarios for V2X (Vehicle to Everything) operation: (a) an in-coverage scenario where the WTRU starts transmitting and receiving V2X messages with assistance from the network, and (b) an out-of-coverage scenario where the WTRU starts transmitting and receiving V2X messages using some pre-configured parameters.

[0005] V2X communication is supported in Release 14 LTE and is inspired by previous work on device-to-device (D2D) communication. V2X communication services can consist of four different types: (i) V2V (Vehicle to Vehicle): Vehicle WTRUs can communicate directly with each other. (ii) V2I (Vehicle to Infrastructure): A vehicular WTRU can communicate with a roadside unit / eNode B (RSU / eNB). (iii) V2N (Vehicle to Network): A vehicular WTRU can communicate with a core network. (iv) V2P (Vehicle to Pedestrian): A vehicular WTRU can communicate with a WTRU that has special conditions, such as low battery capacity. [Brief explanation of the drawings]

[0006] A more detailed understanding may be had from the following detailed description, taken by way of example in conjunction with the accompanying drawings. The figures in such drawings, like the detailed description, are examples. Therefore, the figures and detailed description should not be considered limiting, as other equally effective examples are possible and likely. Moreover, like reference numerals ("references") in the figures indicate like elements. [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an example WTRU that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] Shows a non-roaming 5G system architecture for PC5 communication and Uu-based V2X communication. [Figure 3] 1 illustrates an exemplary establishment of a secure Layer 2 link via PC5. [Figure 4A] 1 shows an example timing diagram for hybrid automatic repeat request (HARQ) round trip time (RTT) timers and retransmission timers. [Figure 4B] 1 shows an example timing diagram for hybrid automatic repeat request (HARQ) round trip time (RTT) timers and retransmission timers. [Figure 4C] 1 shows an example timing diagram for hybrid automatic repeat request (HARQ) round trip time (RTT) timers and retransmission timers. [Figure 5] FIG. 10 is a flow diagram of a procedure including determining a sidelink monitoring time for a WTRU. [Figure 6] 1 illustrates an example method implemented by a first WTRU for sidelink (eg, D2D) communication between a first WTRU and a second WTRU. [Figure 7] FIG. 10 shows a further example of a method implemented by a first WTRU for D2D communication between a first WTRU and a second WTRU. [Figure 8] FIG. 10 shows a further example of a method implemented by a first WTRU for D2D communication between a first WTRU and a second WTRU. [Figure 9]FIG. 10 shows a further example of a method implemented by a first WTRU for D2D communication between a first WTRU and a second WTRU. [Figure 10] FIG. 10 shows a further example of a method implemented by a first WTRU for D2D communication between a first WTRU and a second WTRU. DETAILED DESCRIPTION OF THE INVENTION

[0007] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. It will be understood, however, that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. Although various embodiments are described and / or claimed herein in which apparatuses, systems, devices, etc. and / or any elements thereof perform operations, processes, algorithms, functions, etc. and / or any portions thereof, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any elements thereof are configured to perform any operations, processes, algorithms, functions, etc. and / or any portions thereof.

[0008] Exemplary Communication System The methods, apparatus, and systems provided herein are well suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with reference to Figures 1A-1D, in which various elements of the network may utilize, perform, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatus, and systems provided herein.

[0009] 1A is a system diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of 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 (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0010] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may include (or be) user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain contexts), a consumer electronic device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0011] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as, for example, the CN 106 / 115, the Internet 110, and / or the network 112. By way of example, the base station 114a, 114b may be any of a base transceiver station (BTS), a Node-B (NB), an eNodeB (eNB), a Home Node-B (HNB), a Home eNodeB (HeNB), a gNodeB (gNB), a NR Node-B (NR NB), a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0012] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

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

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

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

[0017] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0018] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), or the like.

[0019] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as, for example, a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA 2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish either a small cell, a pico cell, or a femto cell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0020] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that employs any of GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or Wi-Fi radio technologies.

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

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

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

[0024] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated into an electronic package or chip, for example.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0038] The SGW 164 may be connected to each of the eNodeBs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as fixing the user plane during inter-eNodeB handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

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

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

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

[0043] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (e.g., directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to herein as an "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In one representative embodiment, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0045] High throughput (HT) STAs may, for example, use 40 MHz wide channels for communication via a combination of a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

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

[0047] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., only for) specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0048] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) configuration can depend on the state of the primary channel. For example, if the primary channel is busy due to STAs (that only support 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

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

[0050] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 113 may also communicate with the CN 115.

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

[0052] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may be different for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time).

[0053] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeBs 160a, 160b, 160c may act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0054] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0055] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the foregoing elements is shown 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 the CN operator.

[0056] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182, 182b to customize the CN support of the WTRUs 102a, 102b, 102c, for example, based on the type of service being utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

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

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

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

[0060] 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to any of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other elements / devices described herein may be performed by one or more emulation elements / devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0062] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0063] The examples provided herein do not limit the applicability of the subject matter to other wireless technologies that may use the same or different principles as may be applied, for example.

[0064] As described herein, a WTRU may be an example of a UE, and therefore the terms UE and WTRU may be used interchangeably herein.

[0065] As used herein, the term WTRU is also used generically to identify a device on which one or more V2X applications are running. A V2X application server (V2X AS) may be located in the network and may interface with V2X applications installed in the WTRU. A V2X control function (CF) may handle authentication and provisioning of V2X devices. This may include, for example, V2X policy and / or parameter configuration for the WTRU. The V2X CF functionality may be handled in the PCF. V2X inter-WTRU communication may be based on two modes of operation: an operation mode over the Uu reference point and an operation mode over the PC5 reference point.

[0066] V2X communication over the PC5 reference point may be a type of ProSe communication (e.g., D2D communication). One-to-one ProSe direct communication may be achieved by establishing a secure Layer 2 link over PC5 between two WTRUs, and is often referred to as unicast communication (e.g., the communication may involve two peers).

[0067] FIG. 2 shows a non-roaming 5G system architecture for PC5 and Uu-based V2X communications. As seen in FIG. 2, some examples of the V2X WTRU 102 may be vehicular WTRUs (WTRU 102b and WTRU 102c) or pedestrian WTRUs (WTRU 102a). V2X communications may occur between two pedestrian WTRUs. V2X communications may also occur between a mobile WTRU 102a, 102b, and / or 102c and a fixed / stationary WTRU 102c (e.g., a Road Side Unit (RSU) or other fixed device). Communications between the WTRU 102b or 102c (vehicles) and the WTRU 102a (pedestrian) may be referred to as V2P communications, and communications between the WTRU 102b (vehicles) and the WTRU 102c (vehicles) may be referred to as V2V communications. As shown in Figure 2, both V2V and V2P communications can occur over the PC5 interface, and the message frequency, power, and other characteristics of V2V communications can differ from V2P-type communications.

[0068] Referring to FIG. 2, the V2X communication network 200 may include a DN 185 executing / running one or more V2X applications, a first vehicle (e.g., vehicular WTRU 102b) executing one or more V2X applications, a second vehicle (e.g., vehicular WTRU 102c) executing one or more V2X applications, a pedestrian (e.g., pedestrian / V2P WTRU 102a) executing one or more V2X applications, a stationary / fixed device (e.g., stationary WTRU 102d) executing one or more V2X applications, the NG-RAN 104, and the CN 106. The CN 106 may include an AMF 182, an SMF 183, a UPF 184, a DN 185, a unified data management (UDM) 186 which may be paired with a user data repository (UDR, not shown), a policy and control function (PCF) 187, a network exposure function (NEF) 188, and / or an application function (AF) 189. The WTRUs 102 (e.g., the vehicular WTRU 102b, the vehicular WTRU 102c, the pedestrian WTRU 102a, and / or the stationary WTRU 102d) may communicate using a PC5 interface (e.g., PC5 communication). The V2X applications running on the WTRUs 102 (e.g., the vehicular WTRU 102b, the vehicular WTRU 102c, the pedestrian WTRU 102a, and / or the stationary WTRU 102d) may communicate using a V5 interface. The vehicular WTRU 102b and the stationary WTRU 102d may communicate with the NG-RAN 104 using the Uu interface. The NG-RAN 104 may communicate with the AMF 182 of the CN 106 using the N2 interface and with the UPF 184 of the CN 106 using the N3 interface. The DN 185 may be internal to the CN 106 or may interface with the NG-RAN 104 using the N6 interface.The UPF 184 and the SMF can communicate using the N4 interface.

[0069] A V2P WTRU 102a supporting V2P applications transmits messages including V2P application information. The V2P application information may be transmitted by a WTRU supporting vehicular V2X applications, such as pedestrian warnings, or by a WTRU supporting V2X applications associated with vulnerable road users, such as vehicular warnings. 3GPP transport of messages including / containing V2P application information may include direct transport between WTRUs 102 and / or transport between WTRUs via infrastructure supporting V2X communications (e.g., RSUs, application servers, etc.), e.g., due to limited direct communication range. As described herein and based on the architecture of FIG. 2, the vehicular-type WTRUs 102b / 102c and the pedestrian-type WTRU 102a may be supported by V2X. Other functions specific to the pedestrian-type WTRU 102a, carried by pedestrian users, cyclists, etc., may also be supported by V2X. A special resource selection mechanism (e.g., partial sensing or random selection) for the pedestrian-type WTRU 102a may be utilized in PC5 communications. Generally, there are no optimizations for the pedestrian-type WTRU 102a, which has power and computational limitations compared to the vehicular WTRUs 102b / 102c. It is desirable to support V2X utilization for vulnerable road users (VRUs) and thus provide enhancements in related aspects (e.g., power saving, etc.).

[0070] V2X Resource Allocation in LTE LTE defines two operating modes for V2X communication. In Mode 3, the network provides the WTRU with a scheduling assignment for V2X sidelink (SL) transmissions. In Mode 4, the WTRU autonomously selects resources from a configured / preconfigured resource pool. Furthermore, V2X LTE defines two types of resource pools: a receive pool that is monitored to receive V2X transmissions and / or a V2X transmit pool that the WTRU uses to select transmission resources in Mode 4. The transmit pool is not used by a WTRU configured for Mode 3. A resource pool defines a subset of subframes and / or resource blocks available for either sidelink transmission or sidelink reception. Sidelink communication may be half-duplex and / or the WTRU may be configured with multiple transmit and / or receive resource pools.

[0071] In LTE, the resource pool is semi-statically signaled to the WTRU via radio resource control (RRC) signaling. In Mode 4, the WTRU uses sensing before selecting resources from the transmission pool configured by RRC. LTE V2X does not support dynamic reconfiguration of the resource pool. The pool configuration can be signaled via (e.g., only via) the system information block (SIB) and / or dedicated RRC signaling. As used herein with respect to NR V2X with DRX, a resource pool may include a set of resources used in V2X communications. A receive (RX) resource pool defines the resources that a WTRU should monitor. A transmit (TX) resource pool defines the resources that a WTRU can use for transmission. Not all resources in the sidelink can be used for transmission or reception. Here, the RX resource pool may also be referred to as the RX pool and / or the TX resource pool may also be referred to as the TX pool.

[0072] NR V2X access technology The Third Generation Partnership Project (3GPP) includes a next-generation radio system called NR, which is expected to support many use cases, including enhanced Mobile Broadband (eMBB) and / or ultra-high reliability and / or low latency communications (URLLC).

[0073] 3GPP can support enhanced V2X (eV2X) communications in NR systems. eV2X in NR is expected to support new services for both safety and / or non-safety scenarios, such as sensor sharing, autonomous driving, vehicle platooning, and remote driving. Different eV2X services may have different performance requirements and / or may require 3 ms latency in some scenarios.

[0074] NR V2X can support two modes of operation: Mode 1 and / or Mode 2. Mode 1 is based on LTE V2X Mode 3 operation. For example, the network can schedule SL resources via downlink control information (DCI) signaling in the downlink (DL), and / or the WTRU can apply received resource reservations to SL transmissions. Mode 2 can use LTE Mode 4 as a baseline for semi-persistent scheduling. In Mode 4, the WTRU can autonomously select and / or reserve resources from a configured resource pool. In one example, the configured resource pool can be a pre-configured resource pool. The autonomous resource reservation can be based on WTRU sensing to identify available candidate resources.

[0075] New use cases for NR V2X NR V2X is expected to support new use cases as defined in the 3GPP standard, in particular the following use cases:

[0076] Vehicle Platooning. Vehicle platooning allows vehicles to dynamically form groups that travel together. All vehicles in the platoon receive periodic data from the lead vehicle to maintain platoon operation. This information allows for very small distances between vehicles, e.g., very small gap distances in terms of time (less than 1 second). In platooning applications, trailing vehicles can be autonomous.

[0077] Advanced Driving. Advanced driving enables semi- or fully automated driving. Longer inter-vehicle distances are envisioned. Each vehicle and / or RSU shares data from its local sensors with nearby vehicles, so vehicles can adjust their trajectory or maneuver. Furthermore, each vehicle shares its driving intentions with nearby vehicles. The benefits of this use case group are safer driving, collision avoidance, and / or increased traffic efficiency.

[0078] Extended Sensors. Extended sensors enable the exchange of raw or processed data collected through local sensors or live video data between vehicles, RSUs, pedestrian devices, and / or V2X application servers. Vehicles can enhance their awareness of their surroundings beyond what their own sensors can detect and / or gain a more holistic view of the local situation.

[0079] Remote Driving. Remote driving allows a remote driver or V2X application to operate a remote vehicle for passengers who are unable to drive themselves or for remote vehicles in hazardous environments. Cloud computing-based driving can be used in cases where there is limited variation and / or the route is predictable, such as in public transportation. Additionally, access to cloud-based backend service platforms can also be considered in this use case group.

[0080] QoS in NR V2X 3GPP uses a QoS model for NR V2X. In Release 14 V2X, documented in TS 23.285, QoS over PC5 is supported using ProSe per-packet priority (PPPP). The application layer can mark packets with PPPP to indicate the requested QoS level. Specific extensions have been added, for example, by allowing the packet delay budget (PDB) to be derived from PPPP.

[0081] The new QoS requirements for NR V2X are described, for example, in TS 22.186. New performance key performance indicators (KPIs) were specified using the following parameters: -payload (bytes), -Transmission rate (messages / second), - Maximum end-to-end latency (ms), - Reliability (%), -data rate (Mbps), -Minimum required communication range (meters).

[0082] Note that the same set of service requirements can be applied to both PC5-based V2X communication and / or Uu-based V2X communication, and these QoS characteristics can be well expressed using the 5G QoS indicator (5QI) defined in TS 23.501.

[0083] One possibility is to establish a unified QoS model for PC5 and / or Uu, e.g., using 5QI also for V2X communication over PC5, allowing the application layer to indicate QoS requirements in a consistent way regardless of the link used.

[0084] Considering a 5GS V2X-capable WTRU, there are three different types of traffic: broadcast, multicast, and / or unicast. For unicast type traffic, the same QoS model as for Uu can be utilized, e.g., each unicast link can be treated as a bearer and / or each unicast link can be associated with a QoS flow. All QoS characteristics and / or additional parameters of data rate defined in 5QI can be applied. Furthermore, minimum (e.g., required) communication range can be treated as an additional parameter specifically for PC5 usage. Similar considerations apply to multicast traffic, since it can be treated as a special case of unicast, e.g., when multiple recipients of the traffic are defined.

[0085] For broadcast traffic, there is no concept of a bearer. Therefore, each message can have different characteristics depending on the application requirements. In that case, 5QIs should be used in a similar way to PPPP / ProSe per-packet reliability (PPPR), e.g., tagging each packet. 5QIs can represent all characteristics required for PC5 broadcast operation (e.g., latency, priority, reliability, etc.). A group of 5QIs specific to V2X broadcast (e.g., VQI) can be defined for PC5 usage.

[0086] The PC5 QoS parameters are negotiated during the establishment of the point-to-point communication procedure, so for example the point-to-point communication establishment procedure defined in TS 23.303 is extended to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation procedure, the same QoS is used in both directions.

[0087] WTRUs involved in one-to-one communication (e.g., D2D communication) negotiate PC5 QoS parameters during the link establishment procedure, as shown in Figure 3. Message 1 is a Direct Communication Request (DCR) message, and message 2 is an Authentication and Establishment of security association message. In message 1, UE-1 (e.g., WTRU-1) sends a Direct Communication Request message to UE-2 (e.g., WTRU-2) to trigger mutual authentication. This message includes the requested PC5 QoS parameters. In message 2, UE-2 (e.g., WTRU-2) initiates the mutual authentication procedure. UE-2 (e.g., WTRU-2) includes the accepted PC5 QoS parameters in a response message.

[0088] DRX in NR Uu CONNECTED mode DRX is designated for power saving in NR Uu for WTRUs in RRC_CONNECTED state. DRX is based on a configured schedule of wake-up times in the WTRU. If the WTRU receives physical downlink control channel (PDCCH) scheduling during the wake-up time, it remains awake for a certain period of time until no further scheduling is received. The WTRU may be configured with any of the following example parameters: -drx-onDurationTimer: Duration at the start of a DRX cycle, -drx-SlotOffset: Delay before starting drx-onDurationTimer, -drx-InactivityTimer: duration after a PDCCH opportunity in which the PDCCH indicates a new UL or DL transmission of the MAC entity; -drx-RetransmissionTimerDL (per DL Hybrid ARQ (HARQ) process excluding broadcast processes): maximum duration before receiving a DL retransmission, -drx-RetransmissionTimerUL (per UL HARQ process): Maximum duration until receiving a grant for UL retransmission, drx-LongCycleStartOffset: Long DRX cycle and / or drx-StartOffset defining the subframes in which the long DRX cycle and short DRX cycle start, -drx-ShortCycle(optional): Short DRX cycle, -drx-ShortCycleTimer (optional): Duration that the WTRU follows a short DRX cycle; -drx-HARQ-RTT-TimerDL (per DL HARQ process excluding broadcast process): the minimum duration before which a DL allocation for HARQ retransmission is expected by the MAC entity, -drx-HARQ-RTT-TimerUL (per UL HARQ process): The minimum duration before a grant for a UL HARQ retransmission is expected by the MAC entity.

[0089] A DRX configured WTRU determines the active time (the time the WTRU actively monitors the PDCCH) based on one of the following: If the DRX cycle is set (for example, when set), the active time includes the following times: - the drx-onDurationTimer or the drx-InactivityTimer or the drx-RetransmissionTimerDL or the drx-RetransmissionTimerUL or the ra-ContentionResolutionTimer (e.g. as described in Section 5.1.5 of Release 14) is running, or A scheduling request has been sent and is pending on the physical uplink control channel (PUCCH) (e.g., as described in clause 5.4.4 of Release 14); and / or - after successful reception of a random access response to a preamble not selected by the MAC entity (e.g. as described in clause 5.1.4 of Release 14), no PDCCH indicating a new transmission addressed to the MAC entity's cell radio network temporary identifier (C-RNTI) has been received.

[0090] Partial Sensing and / or Random Selection in LTE V2X Another power saving mechanism introduced in LTE V2X (used by pedestrian WTRUs) was the aspect of partial sensing. With partial sensing, the WTRU can be configured by higher layers with a minimum number of candidate subframes within the resource selection window [T1, T2], with specific subframes selected by the WTRU implementation. The WTRU can perform sensing on subframes (e.g., only on subframes) within the sensing window that are an integer number of reserved periods from the candidate subframes, thus reducing the amount of resources the WTRU needs to perform sensing on within the sensing window.

[0091] Another possibility for a pedestrian WTRU is to perform random selection on the resource pool. If the resource pool is configured to allow random selection, the WTRU can perform resource selection during the sensing procedure without considering the sensing results.

[0092] SL communication has some differences from Uu scheduling that can cause problems for the DRX concept approach implemented by Uu. - Signaling control information (SCI)-based indications for retransmissions are used. Specifically, in SL, one SCI may indicate resources for additional transmissions and / or further retransmissions in a HARQ process, and the transmissions and / or retransmissions may not be consecutive in time. The execution of the HARQ RTT timer and / or retransmission timer may (e.g., should) take into account such SCI indications. A transmission may have HARQ enabled or disabled, in which case the timeline for HARQ feedback is different. For a transmission with HARQ enabled, the RX WTRU (e.g., WTRU 102) may transmit a physical sidelink feedback channel (PSFCH) (similar to Uu). For a transmission with HARQ disabled, the RX WTRU (e.g., WTRU 102) may not transmit HARQ feedback on the PSFCH. This may affect the definition of the timers for the HARQ process. Specifically, in Uu, the HARQ RTT may start at the last symbol / slot of the transmission carrying DL HARQ feedback. However, in the sidelink, the WTRU may not transmit the PSFCH (e.g., always) for various reasons (e.g., HARQ disabled, UL / SL prioritization). Depending on whether mode 1 or mode 2 is used, the minimum microsleep / DRX time may be different. Although the SCI may indicate scheduled retransmission times for a HARQ process, events at the TX WTRU (e.g., WTRU 102) may cause these times to change. Specifically, the TX WTRU (e.g., WTRU 102) may perform preemption of retransmission resources, for example, due to a transmission by a higher priority WTRU. Specifically, the TX WTRU (e.g., WTRU 102) may perform reselection, for example, due to the UL being prioritized higher than the SL. Specifically, the TX WTRU (e.g., WTRU 102) may not be able to immediately indicate (in the SCI) all retransmission resources (e.g., send a signal indicating all retransmission resources), for example, due to a channel busy ratio (CBR).

[0093] Method for Sidelink DRX Timer 1. How to define the active time for SL retransmission The (e.g., TX or RX) WTRU may have a mechanism for determining the duration of microsleep / DRX following a transmission or retransmission, e.g., for a HARQ process, which depends on the SL characteristics. This may be modeled to use a HARQ RTT timer (similar to Uu), whereby the start of such timer represents the start of a potential microsleep / DRX opportunity (whereby the WTRU does not monitor an active PSCCH without (e.g., assuming that) other timers defining activity (e.g., inactivity timer, retransmission timer, etc.) running). A HARQ RTT timer may be configured for each SL HARQ process. The microsleep / DRX opportunity may end if (e.g., when) the HARQ RTT timer expires and / or if a retransmission timer (or similar timer representing activity) is started. Alternatively, the WTRU may be configured with an explicit period or set of resources (e.g., a set of slots for SL events) for microsleep / DRX, and / or an explicit period or set of resources (e.g., a set of slots for SL events) to be active, for example, for each SL HARQ process. Each of the following embodiments may be applicable to either option. Furthermore, "HARQ RTT timer" and / or "HARQ RTT time" are used interchangeably to refer to the microsleep / DRX time of a HARQ process, regardless of whether this time is explicitly implemented using a timer (as in Uu). Furthermore, HARQ RTT time / timer refers to the SL HARQ RTT timer in this disclosure.

[0094] 1.1 Determining the HARQ RTT Timer Start Time The RX WTRU (eg, WTRU 102) may start the HARQ RTT timer at a point in time (eg, the following slot, or some specified following slots) based on either: - Receiving SCI and / or data of that HARQ process, When decoding a MAC PDU associated with a HARQ process, For example, at the time of or after a scheduled retransmission by a TX WTRU (e.g., WTRU 102) indicated in a previous SCI. - determining the decoding result (ACK or NACK) associated with the reception; - transmitting HARQ feedback associated with the received data; - A (pre)set or predefined time following reception of SCI and / or data of that HARQ process; Such (pre)set or pre-defined times may be defined, for example, based on minimum WTRU capabilities; and / or Do not start the HARQ RTT timer at all and / or start the retransmission timer of the HARQ process directly, for example.

[0095] a) The RX WTRU (e.g., WTRU 102) may decide to start the HARQ-RTT at different times depending on the characteristics of the SL. The (e.g., RX) WTRU (e.g., WTRU 102) may determine when to start the HARQ RTT (timer) differently depending on the SL characteristics or conditions. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer at one time point under a first characteristic / condition, and / or may start the HARQ RTT timer at another time point under a second characteristic / condition, where the time points may be any of those listed above. The conditions may relate to any of the following: - whether SL HARQ feedback is enabled / disabled for a particular transmission / retransmission of a HARQ process; -Cast type associated with the transmission: For example, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first time if (e.g., when) a transmission is associated with unicast, and / or may start a HARQ RTT timer at a second time if (e.g., when) a transmission is associated with groupcast. QoS related parameters associated with the transmission (e.g. priority, MCR): For example, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first time if the priority associated with the transmission is above a threshold, and / or at a second time if not. -CBR value: For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer at a first time if the measured CBR is above a threshold, and / or at a second time if not; and / or Instructions / information by peer WTRU as described herein: For example, the (e.g., RX) WTRU (e.g., WTRU 102) may receive a DRX mode indication or other information related to DRX in PC5-RRC (e.g., semi-statically) or in SCI / MAC CE (dynamically), and / or may change the start time of the HARQ RTT timer based on this information; For example, a (e.g., RX) WTRU (e.g., WTRU 102) may receive DRX modes for different transmission types (e.g., the SL characteristics described above) and / or may apply HARQ RTT start times for each transmission type indicated by a peer WTRU.

[0096] Without loss of generality, the above conditions may also be applicable in determining when to start the HARQ RTT timer as well as whether to start the HARQ RTT timer.

[0097] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether HARQ is enabled / disabled for a received PDU. The (e.g., RX) WTRU (e.g., WTRU 102) may determine the HARQ RTT starting point according to the HARQ enabled / disabled property of the received PDU. If HARQ is enabled, the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer at the first symbol / slot following the transmission of a PSFCH that includes HARQ feedback for the transmission. If HARQ is disabled, the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer at the first symbol / slot following the reception of an SCI or the first symbol / slot following the reception of a PSSCH corresponding to the received PDU for that HARQ process. According to an embodiment, the (e.g., RX) WTRU (e.g., WTRU 102) may then start a HARQ RTT timer at a predefined time following receipt of the SCI, where such predefined time corresponds to a minimum requirement defined for the (e.g., RX) WTRU (e.g., WTRU 102). The (e.g., RX) WTRU (e.g., WTRU 102) may also use different values for the HARQ RTT timer in each of the two scenarios. The start time of the HARQ RTT may correspond to any of the times mentioned above.

[0098] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT at a time point associated with a retransmission resource under certain conditions. Under other conditions, the (e.g., RX) WTRU (e.g., WTRU 102) may not start the HARQ RTT and / or may instead start a retransmission timer at such a time point. For example, the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer in the slot following the retransmission resource indicated by a previous SCI if any or a combination of the conditions in this section and / or other sections is met. For example, the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer in the slot following the scheduled retransmission resource indicated in the SCI if it receives an instruction to start the HARQ RTT timer by the TX WTRU (e.g., WTRU 102) (e.g., Mode 1 transmission) or if preemption / reevaluation is disabled.

[0099] b) The (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ-RTT timer (or the like) when (e.g., when) it performs an UL / SL transmission on a PSFCH slot. According to an embodiment, for example, if the (e.g., TX) WTRU (e.g., WTRU 102) performs a transmission (UL transmission or SL transmission) at a time when the (e.g., TX) WTRU (e.g., WTRU 102) can (e.g., is expected to) transmit on the PSFCH, the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ-RTT associated with the HARQ process for reception. For example, if the (e.g., TX) WTRU (e.g., WTRU 102) prioritizes an UL transmission over an SL transmission of HARQ feedback on the PSFCH (e.g., skips a PSFCH transmission), the (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer for the HARQ process for which HARQ feedback was to be transmitted on the skipped PSFCH. The (e.g., RX) WTRU (e.g., WTRU 102) may start the HARQ RTT timer in either: - the symbol / slot following the (last) symbol / slot of the PSFCH, - the symbol / slot following the last symbol / slot of a UL / SL transmission that has priority over a PSFCH transmission, and / or The symbol / slot following the symbol / slot in which the (eg, TX) WTRU (eg, WTRU 102) received an UL grant for UL transmission.

[0100] 1.2 Determining when to start the retransmission timer a) The RX WTRU (e.g., WTRU 102) may be configured with different points in time for starting the retransmission timer for the SL HARQ process. The (e.g., RX) WTRU (e.g., WTRU 102) may start the retransmission timer for an SL HARQ process at different times depending on the SL characteristics. The (e.g., RX) WTRU (e.g., WTRU 102) may select one of the following times to start the retransmission timer following (unsuccessful) reception of an HARQ process: After the HARQ RTT time (timer) expires (e.g., when it expires), - at the time resource indicated in the SCI sent with the (unsuccessful) reception or at some time before that, - the slot (or some following slots) following the slot indicated in the SCI sent with (failed) reception, on the last retransmission resource received in the SCI of a particular HARQ process, at a time before or after that, and / or - Do not start the retransmission timer at all.

[0101] b) The RX WTRU (eg, WTRU 102) decides based on the SCI whether / when to start the HARQ process retransmission timer. The RX WTRU (e.g., WTRU 102) may set a retransmission timer for a particular first transmission / retransmission of an HARQ process. According to an embodiment, the RX WTRU (e.g., WTRU 102) may determine whether and / or when to start a retransmission timer for an HARQ process based on any of the following (among those listed above): - Whether the received SCI of the HARQ process indicates a retransmission resource. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., following some HARQ RTT time) if the SCI does not (e.g., does not) reserve resources for a subsequent retransmission. If the SCI reserves resources for a subsequent retransmission, the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer following reception of the current SCI (it may start the retransmission timer after (e.g., only after) reception of a subsequent SCI of the same HARQ process). (eg, RX) Whether the WTRU (eg, WTRU 102) expects additional retransmission resources (following the currently received transmission / retransmission resources) for a particular HARQ process. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., following some HARQ RTT time) if the current SCI / data reception for a particular HARQ process corresponds to the last (e.g., expected) retransmission of the HARQ process (e.g., reserved using the retransmission resource indicated in the SCI). If the SCI does not correspond to the last retransmission resource, the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer following reception of the SCI. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may decide whether to start a HARQ RTT timer depending on whether the SCI indicates additional retransmission resources. Specifically, if the SCI indicates additional retransmission resources, the UE may start the HARQ RTT timer at the time described herein. Alternatively, if the SCI does not indicate additional retransmission resources, the UE may not start the HARQ RTT timer for the HARQ process. (eg, RX) Whether the WTRU (eg, WTRU 102) successfully received an SCI at the reserved time indicated by a previous SCI of the same HARQ process. For example, if the (e.g., RX) WTRU (e.g., WTRU 102) does not decode an SCI in a slot in which it expects a retransmission, then it may start a retransmission timer (e.g., in the slot following the point indicated by the previous SCI for the HARQ process). Alternatively, if the (e.g., RX) WTRU (e.g., WTRU 102) receives an SCI for a HARQ process in a slot in which it expects a retransmission (based on the previous SCI), then it may not start a retransmission timer. Alternatively, the (e.g., RX) WTRU (e.g., WTRU102) may always start a retransmission timer in a slot in which the (e.g., RX) WTRU (e.g., WTRU102) is expecting a retransmission, and / or may stop the retransmission timer (e.g., immediately) if an SCI is received, or may continue to run the retransmission timer as long as no SCI is received. Whether the PDU of the HARQ process is successfully decoded. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer (in any of the other cases associated with this section) unless the (e.g., RX) WTRU (e.g., WTRU 102) successfully decoded a PDU associated with the HARQ process (e.g., in a previously received transmission / SCI). ■Specifically, successful decoding involves that an SCI has been received and / or the HARQ process ID and / or NDI indicates that the received transmission is a retransmission associated with a HARQ process currently assigned in the (e.g., RX) WTRU (e.g., WTRU 102). Whether the HARQ RTT timer expires (or stops) before or after the next scheduled retransmission. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may start the retransmission timer at the earliest expiration of the HARQ RTT timer and / or the retransmission timer. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start the retransmission timer if (e.g., upon) the HARQ RTT timer expires, or if the HARQ RTT timer expires before the next scheduled retransmission. Otherwise, the (e.g., RX) WTRU (e.g., WTRU 102) starts the retransmission timer at (or shortly after) the next scheduled retransmission indicated in the SCI. - Whether preemption is configured / enabled by the TX WTRU (e.g., WTRU 102). For example, if the TX WTRU (e.g., WTRU 102) is allowed to reselect a retransmission resource due to preemption, the TX WTRU (e.g., WTRU 102) may start the retransmission timer following expiration of the HARQ RTT timer. On the other hand, if the TX WTRU (e.g., WTRU 102) is not allowed to perform preemption, the TX WTRU (e.g., WTRU 102) may start the retransmission timer at or on the slot following the next scheduled retransmission indicated in the SCI. Whether the TX WTRU (eg, WTRU 102) is configured in Mode 1 or Mode 2. For example, the TX WTRU (e.g., WTRU 102) may always start a retransmission timer at the next scheduled retransmission (or at the next slot) indicated in the SCI if the SCI is provided, if the TX WTRU (e.g., WTRU 102) is configured (e.g., when) in Mode 1. Otherwise (e.g., in the case of Mode 2, or in the case of Mode 1 where no subsequent retransmission resource was provided in the SCI), the TX WTRU (e.g., WTRU 102) may start a retransmission timer following expiration of the HARQ RTT timer. - Whether the HARQ RTT timer for the HARQ process has started / run. For example, the TX WTRU (e.g., WTRU 102) may start a retransmission timer following expiration of the HARQ RTT timer for the corresponding HARQ process if the HARQ RTT timer for the corresponding HARQ process is running. Otherwise, the TX WTRU (e.g., WTRU 102) may start the retransmission timer at the next scheduled retransmission indicated in the SCI, or may not start the retransmission timer at all for that particular HARQ process. For example, the TX WTRU (e.g., WTRU 102) may start the retransmission timer upon expiration of the HARQ RTT timer if the HARQ RTT timer is started. Otherwise, if the HARQ RTT timer is not started (e.g., based on the rules for whether to start the HARQ RTT timer described herein), the TX WTRU (e.g., WTRU 102) may start the retransmission timer at another point in time as indicated herein (e.g., upon receipt of an SCI, transmission of a PSFCH, expected time of SCI reception based on a previous SCI retransmission resource indication, etc.). An indication from the TX WTRU (eg, WTRU 102) whether additional retransmission resources can be expected or whether the PDB will not be exceeded. o Specifically, the TX WTRU (e.g., the WTRU 102) may provide an indication (e.g., within a particular retransmission resource, such as via an indication in the SCI, MAC CE, or MAC PDU header) of whether additional retransmission resources are expected. Specifically, the TX WTRU (e.g., the WTRU 102) may indicate to the RX WTRU (e.g., the WTRU 102) that no additional retransmission resources are expected if (e.g., when) the TX WTRU (e.g., the WTRU 102) has reached a maximum number of retransmission resources. Such an indication may be provided in the SCI associated with the last retransmission resource or in a previous SCI indicating the retransmission resource. Specifically, if (e.g., when) the TX WTRU (e.g., the WTRU 102) cannot find (e.g., cannot find) additional resources following the last retransmission resource that fit within the PDB of the packet, the TX WTRU (e.g., the WTRU 102) may indicate to the RX WTRU (e.g., the WTRU 102) that no additional retransmission resources are expected. The RX WTRU (e.g., the WTRU 102) may start the HARQ RTT timer and / or the retransmission timer if the indication from the TX WTRU (e.g., the WTRU 102) indicates that additional retransmission resources are expected. Alternatively, the RX WTRU (e.g., the WTRU 102) may not start the HARQ RTT timer and / or the retransmission timer in a HARQ process if the indication from the TX WTRU (e.g., the WTRU 102) indicates that no retransmissions are sent in the HARQ process. o Specifically, such an indication may either be an indication that further retransmissions are expected, or an indication that further retransmissions are not expected. For example, if the TX WTRU (e.g., WTRU 102) indicates that the RX WTRU (e.g., WTRU 102) can expect additional retransmission resources, the RX WTRU (e.g., WTRU 102) may start a retransmission timer following a failure to decode an HARQ process; otherwise, the RX WTRU (e.g., WTRU 102) may not start a retransmission timer. - An indication from the TX WTRU (e.g., WTRU102) as to whether the TX WTRU (e.g., WTRU102) expects to perform reselection (e.g., following UL prioritization by the TX WTRU (e.g., WTRU102) in the event of a failed TX transmission by the TX WTRU (e.g., WTRU102)) (as further described herein). o Specifically, a TX WTRU (e.g., WTRU 102) may inform an RX WTRU (e.g., WTRU 102) whether the TX WTRU (e.g., WTRU 102) intends to perform reselection as a result of a failed transmission on a reserved retransmission resource. The RX WTRU (e.g., WTRU 102) may start a retransmission timer if such a reselection is expected or if the failed transmission was the last reserved retransmission (in any previous SCI). Otherwise, the RX WTRU (e.g., WTRU 102) may not start the retransmission timer and / or may restart the HARQ RTT timer. - Whether the expected PDB of a PDU has been exceeded at a given time. For example, a TX WTRU (e.g., WTRU 102) may provide the expected PDB of a PDU (e.g., at initial transmission / retransmission). For example, a RX WTRU (e.g., WTRU 102) may be configured with a priority and / or maximum PDB mapping (e.g., with respect to the first SCI reception time of the first transmission of the SCI). The (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer as long as the maximum PDB associated with the PDU is not exceeded. Whether the retransmission resource associated with the SCI transmission was the last known retransmission resource reserved in a previous SCI by a TX WTRU (eg, WTRU 102) for a HARQ process. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may use a first (pre-)configured value of the retransmission timer if there are additional reserved retransmission resources, and / or may use a second value of the retransmission timer if there are no reserved retransmission resources for the HARQ process from the previous SCI transmission. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer if the SCI was not decoded in the retransmission resource and / or if the retransmission resource was the last indicated / known retransmission resource reserved by a previous SCI. Otherwise, the (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer instead (e.g., the RX WTRU (e.g., WTRU 102) expects an additional retransmission at (e.g., only at) the next indicated position of the SCI). Based on the number of retransmissions performed by the TX WTRU (eg, WTRU 102) so far in a particular HARQ process, compared to a maximum number that may depend on, for example, CBR / priority. For example, if the number of retransmissions performed for a PDU is below a configured maximum, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer and / or a HARQ RTT timer, otherwise the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer and / or a HARQ RTT timer for that HARQ process. Based on the scheduled reception time of the SCI / data that is not received by the RX WTRU (eg, WTRU 102). For example, the RX WTRU (e.g., WTRU 102) may perform / prioritize UL transmission or reception at a time corresponding to a scheduled retransmission by the peer (e.g., TX) WTRU (e.g., WTRU 102) indicated by the previous SCI, and / or may not be able to receive the retransmission. For example, the RX WTRU (e.g., WTRU 102) may perform a sidelink transmission at a time corresponding to a scheduled retransmission by the peer (e.g., TX) WTRU (e.g., WTRU 102) indicated by the previous SCI, and / or may not be able to receive the retransmission due to half-duplex. In either case, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer at the time of the scheduled retransmission or at some time thereafter. -Based on PDU QoS. -Based on the cast type of the transmission (e.g. in combination with the instruction). For example, in the case of a unicast HARQ process, the WTRU may decide based on an indication (e.g., from the TX WTRU (e.g., WTRU 102)) whether to start a HARQ RTT timer following an SCI transmission (e.g., if such SCI transmission does not indicate a retransmission resource). The TX WTRU (e.g., WTRU 102) may set such an indication based on whether a PUCCH is configured in the TX WTRU (e.g., WTRU 102). Specifically, if a PUCCH is configured, the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer, and / or if a PUCCH is not configured, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer. On the other hand, in the case of groupcast and / or broadcast, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer (also, e.g., for an SCI transmission where such SCI does not indicate a retransmission resource).

[0102] The above conditions are also applicable when determining when and / or whether to start a retransmission timer. Without loss of generality, the above conditions are also applicable when and / or whether to start a HARQ RTT timer.

[0103] In an example embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to initiate a retransmission based on successful reception of an SCI for the retransmission, e.g., at the scheduled / expected reception time indicated by the previous SCI. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may receive a first SCI (e.g., at time T1) indicating a retransmission resource at time T2. The (e.g., RX) WTRU (e.g., WTRU 102) may further perform microsleep / DRX for the SL HARQ process until the time indicated by the first SCI (e.g., T2). The (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to start a retransmission timer for the HARQ process based on whether the (e.g., RX) WTRU (e.g., WTRU 102) successfully receives an SCI at time T2, e.g., indicating the same HARQ process ID. For example, if the (e.g., RX) WTRU (e.g., WTRU 102) monitors and / or does not receive an SCI at T2, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer for that HARQ process. On the other hand, if the (e.g., RX) WTRU (e.g., WTRU 102) monitors and / or receives an SCI associated with the HARQ process at T2, the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer for that HARQ process.

[0104] c) The RX WTRU (e.g., WTRU 102) decides if / when to start the retransmission timer for the HARQ process if it does not decode the SCI. In the above embodiments, whether the (e.g., RX) WTRU (e.g., WTRU 102) starts the retransmission timer may further depend on whether the (e.g., RX) WTRU (e.g., WTRU 102) was monitoring the SCI at time T2. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may skip monitoring the SCI due to half-duplex issues (e.g., performing transmissions at the same time) or UL / SL prioritization (e.g., performing UL transmissions instead of monitoring the SCI). In such cases, the (e.g., RX) WTRU (e.g., WTRU 102) may always start the retransmission timer at T2 if it did not decode the SCI. Alternatively, the (e.g., RX) WTRU (e.g., WTRU 102) may not start the retransmission timer and / or may restart the HARQ RTT timer for that HARQ process. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may perform microsleep / DRX until the next scheduled retransmission or based on the setting of the HARQ RTT timer, depending on the conditions described herein, for example: Under a first condition, the (eg, RX) WTRU (eg, WTRU 102) may start a HARQ RTT timer. Under a second condition, the (eg, RX) WTRU (eg, WTRU 102) may start a retransmission timer.

[0105] The first condition and the second condition can be any combination (and / or) of the following conditions: The TX WTRU (eg, WTRU 102) is operating in Mode 1. The TX WTRU (eg, WTRU 102) is operating in Mode 2. -Preemption is disabled. The failed SCI corresponds to the last retransmission resource indicated by the previous SCI. - The failed SCI does not correspond to the last retransmission resource indicated by the previous SCI. -CBR is above / below threshold. -Transmission priority is above / below threshold. - Behavior indicated by the TX WTRU (e.g., WTRU102) (e.g., the TX WTRU (e.g., WTRU102) can indicate whether the RX WTRU (e.g., WTRU102) should start the HARQ RTT timer or the retransmission timer). For example, the TX WTRU (eg, WTRU 102) may determine whether preemption is disabled based on the operating mode and / or provide this information to the RX WTRU (eg, WTRU 102).

[0106] For example, if a (e.g., RX) WTRU (e.g., WTRU 102) fails to retransmit a scheduled SCI (e.g., following expiration of a HARQ RTT timer), the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer if the TX WTRU (e.g., WTRU 102) is using Mode 2 and / or preemption is enabled, or if the failed SCI / retransmission is the last retransmission indicated by a previous SCI. Otherwise (e.g., if the TX WTRU (e.g., WTRU 102) is using Mode 1, or if the TX WTRU (e.g., WTRU 102) is using Mode 2 and preemption is disabled, and / or in either case, the failed SCI is not the last retransmission), the (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer.

[0107] 1.3 Determining the Value / Duration of the HARQ RTT Time / Timer or Retransmission Time / Timer in the RX WTRU (e.g., WTRU 102) a) The active time can be a combination of the scheduled receiving resource (indicated by the SCI) for retransmission and / or the time during which a timer (e.g., a retransmission timer) is running. According to an embodiment, the value of the HARQ RTT timer or retransmission timer may be determined by the TX WTRU (e.g., WTRU 102), the RX WTRU (e.g., WTRU 102), or a combination of the TX WTRU (e.g., WTRU 102) and / or the RX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) may determine the value of the timer using known conditions in the TX WTRU (e.g., WTRU 102) and / or send the value to the RX WTRU (e.g., WTRU 102). Alternatively, the RX WTRU (e.g., WTRU 102) may determine the value of the timer using known conditions in the RX WTRU (e.g., WTRU 102) and / or conditions signaled to the RX WTRU (e.g., WTRU 102) by the TX WTRU (e.g., WTRU 102). Finally, a portion of the timer may be determined by the TX WTRU (e.g., WTRU102) and / or transmitted to the RX WTRU (e.g., WTRU102), and / or another portion of the timer may be determined by the RX WTRU (e.g., WTRU102).

[0108] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may define its active time (e.g., the time during which the (e.g., RX) WTRU (e.g., WTRU 102) may (e.g., is required to) monitor the PSCCH) based on a combination of any scheduled reception resources for retransmission indicated by the SCI where the HARQ process associated with that SCI has not been successfully decoded, and / or the status of any of a number of timers. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may be active if any of the SL inactivity timer, SL on duration timer, or SL retransmission timer associated with any SL HARQ process is running, or on any particular resource where the (e.g., RX) WTRU (e.g., WTRU 102) is expecting a retransmission of a particular HARQ process according to a previous SCI and / or on any particular resource where the HARQ process has not been successfully decoded. Specifically, if the SCI indicates a next retransmission resource and / or if the (e.g., RX) WTRU (e.g., WTRU 102) decodes and determines a NACK for the current data received in the current transmission / retransmission associated with the same SCI / HARQ process, the (e.g., RX) WTRU (e.g., WTRU 102) may be expecting a retransmission according to a previous SCI (e.g., in a particular SL HARQ process). In this case, the (e.g., RX) WTRU (e.g., WTRU 102) may determine to be active on that retransmission resource indicated by the SCI, in addition to any additional timer-based activity. If the (e.g., RX) WTRU (e.g., WTRU 102) determines an ACK from the transmission, the (e.g., RX) WTRU (e.g., WTRU 102) may wake up according to timer-based activity (e.g., activity only).

[0109] b) The active time associated with the retransmission indicated by the SCI may be taken into account by starting and / or stopping the retransmission timer. According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may define its active time based on whether (e.g., only whether) a timer associated with DRX (such as Uu) is present. In such a case, monitoring for retransmission resources indicated by the SCI may be performed via the retransmission resources. Specifically, if the (e.g., RX) WTRU (e.g., WTRU 102) monitors resources (e.g., only resources) associated with the time instant indicated / reserved in the SCI for a particular HARQ process, the RX WTRU (e.g., WTRU 102) may: - setting the HARQ RTT timer to the amount of time until the next reserved retransmission resource, not including that resource; If (e.g., upon) expiration of the HARQ RTT timer and / or if (e.g., not when) the PDU of the HARQ process is not successfully decoded, the RX WTRU (e.g., WTRU 102) starts a retransmission timer for the HARQ process; Unless an SCI for the HARQ process is received, the (e.g., RX) WTRU (e.g., WTRU 102) continues to run the retransmission timer until the retransmission timer expires; and / or (eg, RX) The WTRU (eg, WTRU 102) stops the retransmission timer as soon as it decodes the SCI for the HARQ process.

[0110] c) The RX WTRU (e.g., WTRU 102) may set the retransmission value to a different value. According to an embodiment, the RX WTRU (e.g., WTRU 102) may set the retransmission timer to different values. Specifically, the RX WTRU (e.g., WTRU 102) may set the retransmission timer of the HARQ process to one of the following: (Pre-)configured value or value indicated by the TX WTRU (e.g., WTRU 102) (e.g., in RRC signaling, SCI, or MAC layer): ○ A (eg, RX) WTRU (eg, WTRU 102) may also be configured (pre-emptively) with a different retransmission timer value. A value of 0 (eg, the (eg, RX) WTRU (eg, WTRU 102) does not use a retransmission timer). -Single slot equivalent values: For example, under certain conditions described herein (e.g., the TX WTRU (e.g., WTRU 102) is using Mode 1 and / or the SCI does not include retransmission resources), the RX WTRU (e.g., WTRU 102) may set the retransmission timer to a value equivalent to a single slot. Specifically, the RX WTRU (e.g., WTRU 102) may run the retransmission timer for the slot associated with the retransmission resource in the SCI. -Value derived from the timing of the retransmission resource indicated in the SCI: For example, a TX WTRU (eg, WTRU 102) may set the value of the retransmission timer to the amount of time remaining (from the start of the retransmission timer) until the time position of the next retransmission resource indicated in the previous SCI. For example, a TX WTRU (eg, WTRU 102) may set the value of the retransmission timer to the amount of time remaining (from the start of the retransmission timer) until the time position of the retransmission resource after the next retransmission resource. -Value derived from the PDB or remaining PDB of the PDU and / or value derived from the priority of the PDU: For example, the RX WTRU (e.g., WTRU 102) may be provided with the PDB of PDUs or the remaining PDB by the TX WTRU (e.g., WTRU 102) (e.g., in the SCI or MAC Control Element (CE)). Alternatively, the RX WTRU (e.g., WTRU 102) may be configured with a mapping between the priority of the PDUs and / or the expected maximum PDB (e.g., measured from the receipt of the first transmission). ■ The RX WTRU (e.g., WTRU 102) may set a retransmission timer any time following receipt of such a PDB. The RX WTRU (e.g., WTRU 102) may set the retransmission timer to the time remaining (from the start of the retransmission timer) until the PDB expires. For example, the RX WTRU (eg, WTRU 102) may set the retransmission timer to another value (eg, a (pre)configured value) and / or to the minimum time remaining until the expiration of the PDB. A value dependent on the measured or indicated CBR (from the TX WTRU (e.g., WTRU 102)): For example, the RX WTRU (eg, WTRU 102) may be (pre-)configured with different values for the retransmission timer depending on the CBR / channel occupancy ratio (CR). -Value depending on the retransmission number (since the first transmission of the HARQ process): For example, the RX WTRU (e.g., WTRU 102) may be (pre-) configured with different retransmission timer values for each retransmission number, or with an offset / change in the retransmission timer value that applies for each retransmission (e.g., following the initial transmission).

[0111] d) The RX WTRU (e.g., WTRU 102) may determine / decide between either the first HARQ RTT / retransmission timer and / or the second HARQ RTT / retransmission timer based on the characteristics of the control / data transmission (e.g., SCI transmission). According to an embodiment, a (e.g., RX) WTRU (e.g., the WTRU 102) may determine the microsleep / DRX time for a HARQ process or the values of the HARQ RTT timer and / or retransmission timer based on information in a transmission by the TX WTRU (e.g., the WTRU 102), which may include information in the SCI, information in the physical sidelink shared channel (PSSCH) (e.g., MAC CE), information in PC5-RRC, etc. For example, the (e.g., RX) WTRU (e.g., the WTRU 102) may determine the HARQ RTT timer and / or retransmission timer based on whether there are retransmission resources in the SCI and / or the timing of such retransmission resources. Such a determination may include the (e.g., RX) WTRU (e.g., the WTRU 102) selecting between a first timer and a second timer. Such a decision may include the (e.g., RX) WTRU (e.g., WTRU 102) selecting between a time derived from the SCI and / or another time provided in another message (e.g., RRC configuration or pre-configuration). Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) may decide whether to use the first or second microsleep / DRX time and / or the first or second retransmission timer based on any or a combination (and / or) of the following: - Whether the SCI indicates one or more retransmission resources. - Whether preemption is enabled / disabled for transmissions within the pool. Specifically, the RX WTRU (e.g., WTRU 102) can determine whether preemption by the TX WTRU (e.g., WTRU 102) is disabled based on the pool configuration or based on an explicit indication from the TX WTRU (e.g., WTRU 102) (e.g., in the PC5-RRC, MAC CE, sidelink radio bearers (SLRB) configuration, or in the SCI transmission itself). -QoS (e.g. priority) within the SCI. The coverage (in-coverage or out-of-coverage) of the RX WTRU (eg, WTRU 102) or its peer (TX WTRU (eg, WTRU 102)). The RRC state of the RX WTRU (eg, the WTRU 102) or its peer (eg, the TX WTRU (eg, the WTRU 102)). - Whether the RX WTRU (e.g., WTRU102) is receiving data from a WTRU (e.g., TX) that is transmitting in Mode 1 or Mode 2 (such information may be further provided to the RX WTRU (e.g., WTRU102) by the TX WTRU (e.g., WTRU102)). Whether the RX WTRU (e.g., WTRU 102) is receiving data from a (e.g., TX) WTRU (e.g., WTRU 102) that is reporting an SL ACK / NACK to the network (e.g., transmitting information indicating the SL ACK / NACK) (e.g., if such TX WTRU (e.g., WTRU 102) is using (e.g., when) Mode 1 transmission) (such information may be further provided to the RX WTRU (e.g., WTRU 102) by the TX WTRU (e.g., WTRU 102)). -Whether the transmission is associated with blind or HARQ-based retransmission (e.g., HARQ enabled / disabled). Whether the HARQ RTT timer expires (or stops) before or after the next scheduled transmission. Whether the HARQ RTT timer / retransmission timer is started after the last transmission / retransmission resource indicated in the previous SCI. Whether the RX WTRU (eg, WTRU 102) successfully received an SCI at the reserved time indicated by a previous SCI of the same HARQ process. Timing of resources (e.g. for retransmission) indicated in the SCI of the HARQ process: For example, a (eg, RX) WTRU (eg, WTRU 102) may perform microsleep / DRX until the retransmission resource indicated in the SCI. For example, a (eg, RX) WTRU (eg, WTRU 102) may perform DRX up to several or more slots before / after the retransmission resource indicated in the SCI, where the number of slots may be: ■ Configured (in advance) by the network. ■ Provided by the WTRU (eg, WTRU 102) of the peer (eg, TX). ■ Depends on one or more other factors (eg, QoS, CBR, other instructions by the TX WTRU (eg, WTRU 102)) associated with the decision between the first HARQ RTT behavior and the second HARQ RTT behavior. For example, a (eg, RX) WTRU (eg, WTRU 102) may be (pre-) configured with the number of slots corresponding to each priority of data associated with a HARQ process. For example, the (e.g., RX) WTRU (e.g., WTRU102) may be (pre) configured with the number of slots corresponding to each indication of CBR / congestion measured by the RX WTRU (e.g., WTRU102) itself or indicated by the TX WTRU (e.g., WTRU102). An indication from the TX WTRU (eg, WTRU 102) as to whether additional retransmission resources can be expected (using new resource reservations) or whether the PDB has been exceeded. Any other implicit or explicit indication information provided by the TX WTRU (eg, WTRU 102) (eg, in the transmission itself or in a PC5-RRC before the transmission) as described herein. -As further described herein, an indication from the TX WTRU (e.g., WTRU102) as to whether the TX WTRU (e.g., WTRU102) expects to perform reselection (e.g., following UL prioritization by the TX WTRU (e.g., WTRU102) in the event of a failed TX transmission by the TX WTRU (e.g., WTRU102).

[0112] e) The (e.g., RX) WTRU (e.g., WTRU 102) decides whether to use the value provided (e.g., in the SCI) by the TX WTRU (e.g., WTRU 102) or to use a pre-configured value for the HARQ RTT. According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can determine whether to define the HARQ RTT based on a (pre-)configured timer or based on an explicit time indication (e.g., retransmission resource) in the SCI based on the above-mentioned information in the SCI. In one example, the (e.g., RX) WTRU (e.g., WTRU 102) can set the HARQ RTT timer (or microsleep / DRX time) to the time until the next retransmission resource indicated in the SCI. Specifically, the (e.g., RX) WTRU (e.g., WTRU 102) can allow a specific SL HARQ process to perform microsleep starting at a certain time as described herein with respect to starting the HARQ RTT timer, and / or can continue performing DRX until the timing of the next expected retransmission resource indicated in the SCI. Thereafter, the (e.g., RX) WTRU (e.g., WTRU 102) can start the retransmission timer or perform explicit monitoring of the resource associated with this next retransmission resource.

[0113] The (eg, RX) WTRU (eg, WTRU 102) may set the HARQ RTT to the timing of the next expected retransmission resource indicated in the SCI if either: - the SCI indicates at least one retransmission resource. The next retransmission resource (eg, following the transmission / retransmission resource for which the (eg, RX) WTRU (eg, WTRU 102) determines the HARQ RTT) has been provided to the SCI. - The transmission is mode 1 transmission. - The transmission is a mode 2 transmission with preemption disabled.

[0114] On the other hand, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to 0, or to some pre-configured value, or not use the HARQ RTT timer (e.g., start the retransmission timer immediately or do not perform microsleep / DRX) if: - the transmission / retransmission is associated with the last / only resource indicated in the SCI (e.g. no further retransmission resources following this resource are indicated in the SCI), and / or - the transmission is a Mode 2 transmission with preemption enabled.

[0115] For example, a (eg, RX) WTRU (eg, WTRU 102) may set the HARQ RTT timer to the timing of the expected retransmission resource indicated in the SCI retransmission resource if: The next retransmission resource is indicated in the SCI, and / or the TX WTRU (e.g., WTRU 102) is using Mode 1, and / or The next retransmission resource is indicated in the SCI and / or the TX WTRU (eg, WTRU 102) is using Mode 2 with preemption disabled.

[0116] Meanwhile, the (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a pre-configured value in the following cases (such pre-configured value may further depend on which of the following cases is considered): - the next retransmission resource is not indicated in the SCI, and / or The next retransmission resource is indicated in the SCI and / or the TX WTRU (eg, WTRU 102) is using Mode 2 with preemption enabled.

[0117] f) (e.g., RX) The WTRU (e.g., WTRU 102) determines the number of resources before the scheduled retransmission time to wake up. According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine the HARQ RTT as the time from the start of the HARQ RTT time or HARQ RTT timer to a particular point in time before the scheduled retransmission resource indicated in the SCI. The number of resources before the indicated retransmission or explicit point in time may be determined by the RX WTRU (e.g., WTRU 102) using any of the following: -Indicated by a TX WTRU (e.g., WTRU102): For example, a TX WTRU (e.g., WTRU 102) may provide the RX WTRU (e.g., WTRU 102) with the time or number of slots before the scheduled retransmission resource. This may be provided in the PC5-RRC message (e.g., as a configuration parameter) and / or may be semi-statically applied to all transmissions by the TX WTRU (e.g., WTRU 102). Alternatively, the RX WTRU (e.g., WTRU 102) may provide an indication of this number of slots in the SCI or MAC CE, or MAC header (e.g., as an index into a table or an explicit value). -Based on transmission priority: For example, the RX WTRU (e.g., WTRU 102) may determine the number of slots before a scheduled retransmission based on the priority indicated in the SCI. For example, the RX WTRU (e.g., WTRU 102) may set the number of slots for a given priority and / or may determine the HARQ RTT timer by subtracting the number of slots associated with that priority from the scheduled retransmission to determine the length of the HARQ RTT time. -Based on recall number: For example, the RX WTRU (e.g., WTRU 102) may determine the number of slots before the scheduled retransmission time or the HARQ RTT time value based on the retransmission number associated with the HARQ process. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may be (pre-)configured with a first number of slots for the first (initial) transmission, a second number of slots for the first retransmission, a third number of slots for the second retransmission, and / or so on. -Based on CBR: For example, the RX WTRU (e.g., WTRU 102) may determine a first number of slots for a first range of CBRs, and / or a second number of slots for a second (e.g., lower) range of CBRs, and / or so on. The RX WTRU (e.g., WTRU 102) may use its own measured CBR. Alternatively, the RX WTRU (e.g., WTRU 102) may use a CBR value provided by the TX WTRU (e.g., WTRU 102). Preferences (e.g., power-related) at the RX WTRU (e.g., WTRU 102): For example, the RX WTRU (e.g., WTRU 102) may determine the number of slots based on the current power saving status or preference of the RX WTRU (e.g., WTRU 102) as indicated by higher layers. Such number of slots may be set as a combination of the capabilities of the (e.g., RX) WTRU (e.g., WTRU 102) and / or the current power saving preference of the RX WTRU (e.g., WTRU 102).

[0118] g) The TX WTRU (e.g., WTRU 102) may define restrictions on reselection following preemption using the same / similar conditions. According to an embodiment, a TX WTRU (e.g., the WTRU 102) may limit the allowed reselection resources, e.g., for retransmission resources (e.g., following preemption, skipped transmission, etc.), to an active time associated with the RX WTRU (e.g., the WTRU 102), which may be defined by maintaining a set of timers and / or fixed / (pre-)configured resources at the TX WTRU (e.g., the WTRU 102). The TX WTRU (e.g., the WTRU 102) may limit the allowed reselection resources for retransmissions based on criteria similar to the above embodiments. The TX WTRU (e.g., the WTRU 102) may further impose such restrictions if the RX WTRU (e.g., the WTRU 102) is expected to be in DRX. The TX WTRU (e.g., the WTRU 102) may restrict the resources selected for retransmission after (e.g., at) preemption associated with the resources based on priority, CBR, retransmission number, preference from the RX WTRU (e.g., the WTRU 102), etc. For example, for a first value / range of transmission priority, the TX WTRU (e.g., the WTRU 102) may select resources that are limited to a first window of resources before and / or after the retransmission resource first indicated in the SCI. For a second priority or priority range, the TX WTRU (e.g., the WTRU 102) may select resources that are limited to a second window or resources before and / or after the retransmission resource first indicated in the SCI. Without loss of generality, such a window may be further restricted to a (pre-)configured pattern of resources. In such a case, the RX WTRU (e.g., the WTRU 102) monitors the pre-configured pattern of resources (e.g., only the pattern of resources) for the HARQ process when in DRX. For example, a WTRU may apply such restrictions in the case of preemption (e.g., only in the case of preemption) when communicating (e.g., when communicating) with an RX WTRU (e.g., WTRU 102) that has DRX configured.Specifically, the TX WTRU (e.g., WTRU 102) may restrict retransmission resource reselection such that a new retransmission resource may (e.g., always) occur after the timing of the scheduled retransmission resource (indicated by the previous SCI). As described herein with respect to conditions, this may be so that the RX WTRU (e.g., WTRU 102) (which may operate such that a resource before the next scheduled retransmission resource cannot be selected due to preemption) can use the timing of the next scheduled SCI as the HARQ RTT timer.

[0119] h) The (e.g., RX) WTRU (e.g., WTRU 102) Decides Whether to Set the HARQ RTT Time Based on Priority and / or CBR-Based SCI Retransmissions According to an embodiment, the (e.g., RX) WTRU (e.g., WTRU 102) may decide whether to use the timing of the SCI retransmission resources or a (pre-)configured value (e.g., expiring before such retransmission resources) based on the priority and / or measured / indicated CBR of the PDU. For example, whether the TX WTRU (e.g., WTRU 102) can select resources that occur before the scheduled retransmission resources in the SCI (as a result of preemption) or whether it can select resources (e.g., only resources) that occur after the retransmission resources may depend on the priority and / or CBR of the PDU. For example, if the priority of the PDU is above a threshold (higher than the priority indicated by the threshold) and / or for a particular range of CBR, the (e.g., RX) WTRU (e.g., WTRU 102) may use a first (shorter) HARQ RTT timer selected from a (pre-)configuration. In such a case, the TX WTRU (e.g., WTRU 102) may perform reselection as a result of preemption from a set of resources, some of which may occur before the scheduled retransmission in the SCI. On the other hand, if the priority of the PDU is below a threshold (lower than the priority indicated by the threshold) and / or for a second (e.g., lower) range of CBR, the RX WTRU (e.g., WTRU 102) may determine the value of the HARQ RTT to be the time until the next scheduled retransmission resource indicated in the SCI (either the retransmission resource or the following slot). In this case, with respect to a TX WTRU (e.g., WTRU102), when the TX WTRU (e.g., WTRU102) performs resource reselection following preemption (e.g., when running), the TX WTRU (e.g., WTRU102) may select resources (e.g., only resources) that occur after the first retransmission resource.

[0120] Such a selection may further use (e.g., depend on) the retransmission number. In particular, the priority threshold may use (e.g., depend on) the retransmission resource. Whether such a selection is possible may depend on which retransmission resource is considered.

[0121] i) The (e.g., RX) WTRU (e.g., WTRU 102) determines whether to use a first or second (pre-)configured value for the HARQ RTT. According to an embodiment, the (e.g., RX) WTRU (e.g., WTRU 102) may decide whether to select between a first (pre-)configured value or a second (pre-)configured value based on one of the conditions defined above for selecting between two different timer values. Such a decision may be further combined with the solution of deciding whether to use the value in the SCI or to use the pre-configured value, and the (e.g., RX) WTRU (e.g., WTRU 102) may decide to use the (pre-)configured value (rather than the value in the SCI) based on a first set of conditions, and / or may decide which (pre-)configured value to use based on a second set of conditions.

[0122] Without loss of generality, selecting a first / second (pre-)configuration value may mean combining (e.g., via addition) two (pre-)configuration values to determine the overall HARQ RTT. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a value of X+Y under a first condition and / or set the HARQ RTT timer to a value of X+Z under a second condition, where X, Y, and / or Z are all (pre-)configuration values. The (e.g., RX) WTRU (e.g., WTRU 102) may obtain such (pre-)configuration from a peer (e.g., TX) WTRU (e.g., WTRU 102) and / or from the network. The (e.g., RX) WTRU (e.g., WTRU 102) may further implicitly determine such values of X / Y / Z based on a configuration of a sidelink signal / channel (e.g., PSFCH). For example, the (e.g., RX) WTRU (e.g., WTRU 102) may determine a value of any component of the HARQ RTT associated with the time between SCI reception and / or the PSFCH. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may determine a value of any component of the HARQ RTT associated with the time between the PSFCH and / or any explicit resource indicated by the TX WTRU (e.g., WTRU 102). For example, the (e.g., RX) WTRU (e.g., WTRU 102) may determine a value of any component of the HARQ RTT as a specified value (e.g., in a specification).

[0123] For example: The (e.g., RX) WTRU (e.g., WTRU 102) may select a first (pre-)configured timer for HARQ-enabled transmissions during which the TX WTRU (e.g., WTRU 102) reports SL HARQ feedback to the network (e.g., transmits information indicating SL HARQ feedback). Such first timer may be determined by combining two values provided by the TX WTRU (e.g., WTRU 102) in PC5-RRC signaling, where the first value corresponds to the delay from PSFCH to PUCCH at the TX WTRU (e.g., WTRU 102) and / or the second value corresponds to the delay from PUCCH to DCI / SCI scheduling configured by the network (and sent by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102) in PC5-RRC signaling). The (e.g., RX) WTRU (e.g., WTRU 102) may select a second (pre-)configured timer for HARQ disabled transmissions during which the TX WTRU (e.g., WTRU 102) reports SL HARQ feedback to the network (e.g., transmits information indicating SL HARQ feedback). Such second timer may be determined by combining the minimum SCI to PUCCH latency provided by the TX WTRU (e.g., WTRU 102) and / or PUCCH to SCI / SCO scheduling configured by the network. The (e.g., RX) WTRU (e.g., WTRU 102) may select a third (pre-)configured timer for HARQ-enabled transmissions during which the TX WTRU (e.g., WTRU 102) does not report SL HARQ feedback to the network (e.g., does not transmit information indicating SL HARQ feedback). Such a third timer may be determined as a value of the PSFCH to PSSCH latency at the TX WTRU (e.g., WTRU 102), which may be provided by the TX WTRU (e.g., WTRU 102); and / or The (e.g., RX) WTRU (e.g., WTRU 102) may select a third (pre-)configured timer for HARQ disable transmission during which the (e.g., RX) WTRU (e.g., WTRU 102) does not report SL HARQ feedback to the network (e.g., does not transmit information indicating SL HARQ feedback). Such timer may be determined as the value of the minimum latency between the SCI associated with the last retransmission resource and / or a new SL resource scheduled by the network for the same HARQ process (configured by the network and / or transmitted by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102)).

[0124] Without loss of generality, the above embodiments also apply to the TX WTRU (e.g., WTRU102) and / or when the TX WTRU (e.g., WTRU102) calculates the HARQ RTT and / or sends it to the RX WTRU (e.g., WTRU102).

[0125] Without loss of generality, the above embodiments may be used in combination; specifically, a TX WTRU (e.g., WTRU 102) may calculate and / or send a first portion of the HARQ RTT to an RX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) may calculate a final value for the HARQ RTT by adding the received portion with its own determined portion. Both portions may be determined based on criteria described in the embodiments herein.

[0126] j) DRX timers can be a function of the configured resource pool A resource pool in V2X may have a different number of UL resources configured for sidelink transmission, which may affect the responsiveness of a WTRU (e.g., WTRU 102) in DRX (e.g., RX).

[0127] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may be configured with one or more timer values related to SL DRX operation (e.g., any of an inactivity timer, a HARQ RTT timer, a retransmission timer, an on-duration timer, etc.) for each resource pool. Specifically, the timers for SL DRX may be configured along with the RX resource pool for the (e.g., RX) WTRU (e.g., WTRU 102).

[0128] According to an embodiment, a (e.g., RX) WTRU (e.g., the WTRU 102) may apply a correction factor to a configured DRX timer (e.g., any of the inactivity timer, HARQ RTT timer, retransmission timer, on-duration timer, etc.), and such correction factor may be specific to the RX resource pool of the (e.g., RX) WTRU (e.g., the WTRU 102). For example, the (e.g., RX) WTRU (e.g., the WTRU 102) may be provided with the correction factor in the RX resource pool configuration. For example, the (e.g., RX) WTRU (e.g., the WTRU 102) may determine the correction factor using the amount / ratio of UL resources allowed for sidelink transmissions on the SL resource pool. The (e.g., RX) WTRU (e.g., the WTRU 102) may apply such correction factor to the configured timer (e.g., multiply by the factor) to obtain the actual timer value used in DRX operation.

[0129] k) The TX WTRU (e.g., the WTRU 102) provides information to the RX WTRU (e.g., the WTRU 102) for the RX WTRU (e.g., the WTRU 102) to calculate the HARQ RTT / retransmission timers. As described above, the RX WTRU (e.g., the WTRU 102) can determine the HARQ RTT time / timer and / or retransmission time / timer from an explicit determination by the TX WTRU (e.g., the WTRU 102). The TX WTRU (e.g., the WTRU 102) can signal such time / timer to the RX WTRU (e.g., the WTRU 102). Such determination and / or indication can be made for each HARQ process, for each SCI transmission, for each configured grant that is set / reconfigured / activated, statically (e.g., upon setting up a unicast link) or dynamically upon the occurrence of some event (e.g., a change in CBR).

[0130] According to an embodiment, a TX WTRU (e.g., WTRU 102) may provide information to an RX WTRU (e.g., WTRU 102) for the RX WTRU (e.g., WTRU 102) to calculate associated HARQ RTT and / or retransmission timers. This may include any of the following: Whether the TX WTRU (eg, WTRU 102) is configured for Mode 1 or Mode 2. Whether the TX WTRU (eg, WTRU 102) is configured to report HARQ ACK / NACK to the network in Mode 1 (eg, send information indicating the HARQ ACK / NACK). -Measured CBR / CR. - one or more network settings of a timer or components of such a timer. - One or more WTRU-determined values (eg, based on capabilities) of a timer or components of such a timer. An indication of whether the TX WTRU (eg, WTRU 102) will adopt one or another specific behavior with regard to preemption and / or UL / SL prioritization occurring in retransmission resources.

[0131] The TX WTRU (e.g., WTRU 102) may use any or a combination of fields in the PC5-RRC, MAC CE, MAC header, or SCI to convey any of the above information. For example, the TX WTRU (e.g., WTRU 102) may use fields in the SCI, with each codepoint in the field representing a combination of Mode 1 / Mode 2, HARQ ACK / NACK reporting (e.g., sending information indicating HARQ ACK / NACK), measured CBR range, etc.

[0132] l) [TX WTRU (e.g., WTRU 102) calculates and / or sends HARQ RTT to RX WTRU (e.g., WTRU 102)] According to an embodiment, the TX WTRU (e.g., the WTRU 102) may calculate the HARQ RTT, or a portion of the HARQ RTT, and / or send it to the RX WTRU (e.g., the WTRU 102) to use semi-statically and / or for a particular HARQ process, configured grant, or SCI transmission. The TX WTRU (e.g., the WTRU 102) may send the HARQ RTT in the MAC CE or in the SCI transmission.

[0133] m) [TX WTRU (e.g., WTRU 102) indicates whether / how to perform reselection following preemption, UL / SL prioritization, etc.] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may indicate to an RX WTRU (e.g., the WTRU 102) whether / how to perform resource reselection following an event that may change the timing of a scheduled transmission to the RX WTRU (e.g., the WTRU 102). Specifically, the TX WTRU (e.g., the WTRU 102) may inform the RX WTRU (e.g., the WTRU 102) of any of the following: -Whether the TX WTRU (e.g., WTRU102) always performs reselection whenever it prioritizes UL over SL during a scheduled retransmission, or whether it does not perform a retransmission (e.g., wait for a retransmission on the next retransmission resource whenever one is indicated, or drop the retransmission). A condition under which a TX WTRU (e.g., WTRU 102) performs reselection whenever the TX WTRU (e.g., WTRU 102) prioritizes UL over SL during a scheduled retransmission. Such a condition may be based on a certain parameter being above / below a certain threshold, and such a parameter may be any of the following: Priority ○CBR ○Resend number ○ Remaining retransmission count ○The remaining PDB ○ Time elapsed since the first transmission Whether the TX WTRU (eg, WTRU 102) performs reselection whenever the TX WTRU (eg, WTRU 102) performs preemption on a retransmission resource, or whether the TX WTRU (eg, WTRU 102) simply drops the transmission on the retransmission resource. Whenever a TX WTRU (e.g., WTRU 102) performs preemption on a retransmission resource, what are the conditions for the TX WTRU (e.g., WTRU 102) to perform reselection on the retransmission resource. Such conditions may be based on a certain parameter being above / below a certain threshold, and such a parameter may be any of the following: Priority ○CBR ○Resend number ○ Remaining retransmission count ○The remaining PDB ○ Time elapsed since the first transmission Whenever a TX WTRU (e.g., WTRU 102) performs preemption on a retransmission resource, which subset of resources (or window) the TX WTRU (e.g., WTRU 102) considers for reselection of retransmission resources (e.g., such resources are defined relative to the timing of the retransmission resources), or conditions for determining such resources, such as based on any of the following: Priority ○CBR ○Resend number ○ Remaining retransmission count ○The remaining PDB ○ Time elapsed since the first transmission Whenever a TX WTRU (e.g., WTRU 102) performs preemption on a retransmission resource, whether the TX WTRU (e.g., WTRU 102) can select from resources occurring before the retransmission resource previously indicated by the SCI, and / or if based on conditions, what conditions, such as based on any of the following: Priority ○CBR ○Resend number ○ Remaining retransmission count ○The remaining PDB ○ Time elapsed since the first transmission

[0134] The RX WTRU (eg, the WTRU 102) may determine the HARQ RTT timer value based on such information provided by the TX WTRU (eg, the WTRU 102), as described further herein.

[0135] (Mode 1) A WTRU (eg, WTRU 102) configured to transmit (eg, TX) using Mode 1 may calculate the HARQ RTT timer based on one of the mechanisms described below.

[0136] n) [The TX WTRU (e.g., WTRU 102) calculates the HARQ RTT sent to the RX WTRU (e.g., WTRU 102) based on the timing of the SL HARQ feedback to the gNB] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may determine the HARQ RTT to be transmitted to the RX WTRU (e.g., the WTRU 102) based on the timing of the PUCCH resources configured by the network. For example, the TX WTRU (e.g., the WTRU 102) may calculate the HARQ RTT, or a component of the HARQ RTT, based on any of the following: -Time difference between PSFCH resources carrying HARQ feedback for HARQ processes and / or PUCCH resources configured (e.g., in RRC for a cell group (CG) or DCI for a dynamic grant) to provide SL HARQ feedback. This may correspond to or be derived from the maximum value between PSFCH and PUCCH provided to the WTRU in DCI or RRC (eg, for CG type 1). This may correspond to the earliest PUCCH transmission opportunity calculated from the PUCCH resource indicator field in the DCI. -Time difference between SCI transmission / retransmission of HARQ process and / or PUCCH resources configured to provide SL HARQ feedback. The time difference between the PSFCH resources carrying HARQ feedback for the HARQ process and / or the physical uplink shared channel (PUSCH) resources on which the TX WTRU (e.g., WTRU 102) determines whether it can / will send SL HARQ feedback. -Time difference between SCI transmission / retransmission of HARQ process and / or PUCCH resources configured to provide SL HARQ feedback.

[0137] For example, a TX WTRU (eg, WTRU 102) may combine such values with network (NW) configured values (eg, by adding the values).

[0138] For example, the TX WTRU (e.g., WTRU 102) may calculate the components of the HARQ RTT based on a value for the delay between the PSFCH and the PUCCH provided by the network, if such value is configured (e.g., in DCI or RRC). Otherwise, the TX WTRU (e.g., WTRU 102) may calculate the HARQ RTT to be either: A specified minimum time value between PSFCH and / or PUSCH / PUCCH resources for reporting a HARQ ACK (e.g., transmitting information indicating a HARQ ACK). - Default value (e.g., 0). - The earliest PUSCH resource configured for transmitting HARQ feedback for the corresponding PSFCH.

[0139] o) The TX WTRU (e.g., WTRU 102) calculates the HARQ RTT by selecting / combining values. According to an embodiment, a TX WTRU (eg, WTRU 102) may select / combine a HARQ RTT or components of a HARQ RTT based on any of the following: -mode (mode 1 or mode 2), -Whether configured to report PUCCH / PUSCH (e.g., transmit information indicating PUCCH / PUSCH), and / or - Whether HARQ is enabled / disabled.

[0140] The behavior in such an embodiment is similar to that of an RX WTRU (eg, WTRU 102) that combines such timers upon receiving information of these factors from a TX WTRU (eg, WTRU 102).

[0141] (Mode 2) A WTRU (eg, WTRU 102) configured to transmit (eg, TX) using mode 2 may calculate the HARQ RTT timer based on one of the mechanisms described below.

[0142] p) The TX WTRU (e.g., WTRU 102) calculates the HARQ RTT based on the expected preemption check time. According to an embodiment, the TX WTRU (e.g., the WTRU 102) may calculate the HARQ RTT based on an expected preemption check time (e.g., as defined in the ETSI standard). For example, the TX WTRU (e.g., the WTRU 102) may determine the earliest / latest / expected time at which the TX WTRU (e.g., the WTRU 102) will perform a preemption check on the resources reserved for retransmission. The TX WTRU (e.g., the WTRU 102) may provide this time to the RX WTRU (e.g., the WTRU 102).

[0143] The (eg, TX) WTRU (eg, WTRU 102) may further determine such time based on any of the following: - The priority of the PDU sent in the first transmission. For example, a TX WTRU (eg, WTRU 102) may determine a first preemption check time for a first priority of packets, a second preemption check time for a second priority of packets, and so on. A preference indication (eg, based on power saving status) from the RX WTRU (eg, WTRU 102). For example, a TX WTRU (e.g., WTRU 102) may obtain power saving assistance information from a RX WTRU (e.g., WTRU 102). For example, such information may be in the form of a power saving level (low power mode, medium power mode, high power mode). For example, the TX WTRU (e.g., WTRU 102) may select a first preemption time for the low power mode, a second preemption time for the medium power mode, etc. -Measured CBR. - Configured (e.g., TX or RX) WTRU capabilities.

[0144] According to an embodiment, a TX WTRU (e.g., WTRU 102) may be configured to select a preemption check time from the above combinations (e.g., a first preemption check time for a particular combination of power preference indication, and / or CBR, and / or priority).

[0145] According to an embodiment, a (e.g., TX) WTRU (e.g., WTRU 102) may determine the HARQ RTT as the time (starting from the first transmission / retransmission) until the expected preemption check. The (e.g., TX) WTRU (e.g., WTRU 102) may determine the HARQ RTT by adding some (pre-)configured / specified time value to the expected preemption check time. The TX WTRU (e.g., WTRU 102) may send the calculated HARQ RTT to the RX WTRU (e.g., WTRU 102).

[0146] 1.4 Behavior of a TX WTRU (e.g., WTRU 102) Supporting HARQ RTT Timer and / or Retransmission Timer a) The TX WTRU (e.g., WTRU 102) decides whether to perform reselection following preemption / prioritization. According to an embodiment, a TX WTRU (e.g., the WTRU 102) may be configured with conditions regarding whether (re)selection can be triggered by preemption and / or prioritization (e.g., prioritizing UL over SL transmission). Specifically, a TX WTRU (e.g., the WTRU 102) may not perform resource reselection following preemption if the RX WTRU (e.g., the WTRU 102) is configured with SL DRX. Specifically, if the TX WTRU (e.g., the WTRU 102) performs (e.g., when performing) an UL transmission instead of an SL transmission when the RX WTRU (e.g., the WTRU 102) is configured with DRX, the TX WTRU (e.g., the WTRU 102) may not perform resource reselection following an unsuccessful transmission of SCI / data (e.g., on a scheduled or announced resource). Such behavior may be performed to avoid transmissions by a TX WTRU (e.g., WTRU 102) on resources where the RX WTRU (e.g., WTRU 102) is known to be in DRX (not monitoring SLs). According to an embodiment, for example, when the RX WTRU (e.g., WTRU 102) is in DRX (e.g., when in DRX), the TX WTRU (e.g., WTRU 102) may be configured with a particular condition or combination of conditions (and / or) regarding when such reselection should be performed, related to any of the following: -Priority / QoS: For example, a TX WTRU (eg, WTRU 102) may perform retransmission resource reselection if the priority of a transmission / PDU exceeds a threshold (where such threshold may further depend on the CBR). -Remaining retransmission resources: For example, the TX WTRU (e.g., WTRU 102) may perform retransmission resource reselection depending on the existence / number of remaining retransmission resources for the same HARQ process that are already reserved (e.g., not affected by preemption). For example, the TX WTRU (e.g., WTRU 102) may perform retransmission resource reselection if at least x additional retransmission resources remain after a failed / preempted retransmission (where x may further depend on any other conditions such as priority, CBR, etc.). -CBR: For example, a TX WTRU (eg, WTRU 102) may perform retransmission resource reselection if the CBR falls below a threshold.

[0147] According to an embodiment, a TX WTRU (e.g., WTRU 102) that may determine / decide not to perform reselection following a skipped retransmission may use the remaining resources indicated in the SCI if such resources were not preempted (e.g., assume that they were not preempted). Alternatively, the TX WTRU (e.g., WTRU 102) may choose to remove resources. Whether the TX WTRU (e.g., WTRU 102) decides to use or remove resources may further depend on any of the following: - The number of retransmissions already performed for the PDU. - The QoS associated with the PDU. The remaining number of retransmissions of the HARQ process that were previously announced and / or that can still be performed by the TX WTRU (eg, WTRU 102). - RX WTRU (eg, WTRU 102) power level / preference. -A combination of these.

[0148] For example, a TX WTRU (e.g., the WTRU 102) may be configured with a minimum number of retransmissions to be performed in an HARQ process for a particular priority and / or power preference level of the RX WTRU (e.g., the WTRU 102). If the (e.g., the TX) WTRU (e.g., the WTRU 102) is unable to perform a transmission associated with a particular scheduled retransmission resource, the TX WTRU (e.g., the WTRU 102) may delete all subsequent reserved retransmission resources in that HARQ process if the minimum number of retransmissions has been performed. Otherwise, if the minimum number of retransmissions has not been reached, the TX WTRU (e.g., the WTRU 102) may perform retransmissions on the remaining reserved retransmission resources and / or perform resource selection for a new set of resources associated with the same HARQ process.

[0149] A similar behavior can be expected for the RX WTRU (e.g., WTRU 102) to set the retransmission timers of HARQ processes. Specifically, the RX WTRU (e.g., WTRU 102) can be configured with the same minimum number of retransmissions for HARQ processes of a particular priority and / or power preference level. If the RX WTRU (e.g., WTRU 102) is unable to decode the SCI on the scheduled / reserved resources and / or is configured for DRX, the RX WTRU (e.g., WTRU 102) can do the following: If the minimum number of retransmissions for the HARQ process has not been reached, start the retransmission timer. If the minimum number of retransmissions for a HARQ process is reached, do not start the retransmission timer (e.g., go to sleep for that HARQ process).

[0150] b) The TX WTRU (e.g., WTRU 102) may indicate the last retransmission of the HARQ process. There may be ambiguity in the RX WTRU (e.g., WTRU102) as to whether the TX WTRU (e.g., WTRU102) does not indicate additional reserved retransmission resources in the SCI due to exceeding the number of retransmissions (for a particular priority / CBR) or exceeding the PDB, compared to when the TX WTRU (e.g., WTRU102) is unable to find sufficient retransmission resources during resource selection (and can perform separate resource selection for additional transmission resources later).

[0151] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may include an indication to a RX WTRU (e.g., the WTRU 102) as to whether additional retransmissions are expected in a particular HARQ process. The TX WTRU (e.g., the WTRU 102) may provide such an indication in the last reserved resource associated with a set of reserved resources in an SCI. The TX WTRU (e.g., the WTRU 102) may provide such an indication using a field in the SCI itself or using information at the MAC layer (e.g., the MAC header or a special MAC CE included with the transmission).

[0152] For example, a TX WTRU (e.g., WTRU 102) may indicate that additional retransmission resources are not expected if (e.g., when) the PDB is exceeded. For example, a TX WTRU (e.g., WTRU 102) may indicate that additional retransmission resources are not expected if (e.g., when) the maximum number of retransmissions of a PDU based on priority / CBR is exceeded. For example, a TX WTRU (e.g., WTRU 102) may indicate that additional retransmission resources are expected if (e.g., when) the WTRU is unable to select a retransmission resource during resource selection, but there is at least x ms between the last reserved (re)transmission of the PDU and / or the expiration of the PDB of the PDU. For example, a TX WTRU (e.g., WTRU 102) may indicate that additional retransmission resources are expected if (e.g., when) the maximum number of retransmission resources is not exceeded, if the WTRU is unable to select a retransmission resource for retransmission, and / or if the WTRU determines / expects / decides to include a retransmission of the PDU in a newly selected resource / grant.

[0153] c) Resource (re)selection in the TX WTRU (e.g., WTRU 102) may depend on an activity timer maintained by the TX WTRU (e.g., WTRU 102). A TX WTRU (e.g., the WTRU 102) may maintain a set of similar timers (HARQ RTT timers, retransmission timers, etc.) for each HARQ process associated with a given RX WTRU (e.g., the WTRU 102). The TX WTRU (e.g., the WTRU 102) may start / stop / reset such timers and / or set the values of such timers using the same rules as defined herein for the RX WTRU (e.g., the WTRU 102).

[0154] According to an embodiment, a TX WTRU (eg, WTRU 102) performing resource (re)selection to obtain resources for PDU retransmission may select resources from any of the following periods: - The HARQ RTT timer for a particular HARQ process is not running. - The retransmission timer for a particular HARQ process is running. At least one of the retransmission timers for the HARQ process associated with that RX WTRU (eg, WTRU 102) is expected to be running. An inactivity timer associated with the RX WTRU (e.g., WTRU 102) is expected to be running; and / or An on duration timer associated with the RX WTRU (eg, WTRU 102) is expected to be running.

[0155] For example, the TX WTRU (e.g., the WTRU 102) may perform resource reselection for the (re)transmission resources associated with a particular HARQ process. The TX WTRU (e.g., the WTRU 102) may select resources for the (re)transmission resources to be time-bounded if (e.g., when) any of the above timers associated with the RX WTRU (e.g., the WTRU 102) are running.

[0156] For example, the TX WTRU (e.g., WTRU 102) may perform resource reselection of (re)transmission resources associated with a particular HARQ process, taking into account the possibility of preemption. The TX WTRU (e.g., WTRU 102) may perform reselection within the set of resources associated with a retransmission timer running at the RX WTRU (e.g., WTRU 102), taking into account preemption.

[0157] d) Handling HARQ-based SL RLF in the presence of DRX An error in determining an ACK as a NACK may result in the TX WTRU (e.g., the WTRU 102) falsely triggering a Side Link-Radio Link Failure (SL-RLF). Specifically, if the RX WTRU (e.g., the WTRU 102) sends an ACK and / or is interpreted as a NACK by the TX WTRU (e.g., the WTRU 102), the TX WTRU (e.g., the WTRU 102) may perform a retransmission during the time when a retransmission timer may be running (e.g., assumed to be running) due to execution in the RX WTRU (e.g., the WTRU 102). However, because the RX WTRU (e.g., the WTRU 102) correctly decoded (sent an ACK), the retransmission timer may not have been started in this case. As a result, the DTX counter for triggering an RLF may be falsely incremented.

[0158] According to an embodiment, DTX may mean that a TX WTRU (e.g., WTRU 102) may not receive SL HARQ feedback from a RX WTRU (e.g., WTRU 102) at the expected time (e.g., PSFCH timing) following a HARQ-enabled transmission.

[0159] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may disable DTX counting if (e.g., when) the RX WTRU (e.g., the WTRU 102) is configured with DRX. Specifically, the TX WTRU (e.g., the WTRU 102) may not count some or all HARQ DTX occurrences when (e.g., when) transmitting to one or more RX WTRUs (e.g., the WTRU 102) that have SL DRX configured. The TX WTRU (e.g., the WTRU 102) may disable counting, e.g., always, e.g., at certain times (e.g., only when a certain timer is not running), for example: A TX WTRU (e.g., WTRU102) may not count HARQ DTX for all HARQ-based transmissions if SL DRX is configured (e.g., when configured) for at least one RX WTRU (e.g., WTRU102). A TX WTRU (eg, WTRU 102) may not count HARQ DTX for HARQ-based transmissions intended for an RX WTRU (eg, WTRU 102) that has SL DRX configured. A TX WTRU (e.g., WTRU102) may not count HARQ DTX for a HARQ-based transmission intended for one or more RX WTRUs (e.g., WTRU102) that have SL DRX configured if the corresponding transmission (for which DTX was observed) was performed in any of the following cases (e.g., at any of the following times): The On Duration timer associated with the RX WTRU (eg, WTRU 102) was not running. The inactivity timer associated with the RX WTRU (eg, WTRU 102) was not running. The HARQ RTT associated with the RX WTRU (eg, WTRU 102) has / has not been started. The TX WTRU (e.g., WTRU102) may not count HARQ DTXs subsequent to the first HARQ DTX received by the TX WTRU (e.g., WTRU102) that are associated with, for example, one or more of the other conditions in the previous example.

[0160] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may perform a limited number of retransmissions (e.g., associated with the same transport block (TB)), and such a maximum number of retransmissions is (pre-)configured for the WTRU by the NW to be used specifically for transmissions to the RX WTRU (e.g., the WTRU 102) in DRX. Specifically, such a maximum number of retransmissions may be configured to be different from a maximum number of retransmissions configured for other purposes. The TX WTRU (e.g., the WTRU 102) may also derive the maximum number of retransmissions from the maximum number of HARQ DTXs to trigger an SL RLF. For example, the TX WTRU (e.g., the WTRU 102) may use a (e.g., configured) percentage of the configured maximum HARQ DRX to derive the maximum number of retransmissions. The maximum number of retransmissions performed by a TX WTRU (e.g., WTRU102) for a TB (to avoid possible false SL RLFs) may be further limited to retransmissions that occur when (e.g., only when) the on-duration timer and / or inactivity timer for the RX WTRU (e.g., WTRU102) are not running (e.g., are not running).

[0161] According to embodiments that can be combined with the previous solution(s), a TX WTRU (e.g., WTRU 102) can adapt the transmission time of a TB following one or more HARQ-based transmissions that result in DTX. Specifically, the TX WTRU (e.g., WTRU 102) can stop retransmissions, e.g., associated with a particular TB, after one or more (or a (pre-)configured number) unsuccessful (re)transmissions that generate HARQ DTX and / or HARQ NACKs. The TX WTRU (e.g., WTRU 102) can resume such retransmissions at any one or more of the following times: The on duration timer of the RX WTRU (eg, WTRU 102) is running. The inactivity timer of the RX WTRU (eg, WTRU 102) is running. The retransmission timer of the RX WTRU (e.g., WTRU 102) is running (e.g., associated with another HARQ process), and / or, for example, the RX WTRU (e.g., WTRU 102) has successfully transmitted HARQ feedback (ACK or NACK).

[0162] According to an embodiment, different thresholds / conditions for triggering an SL RLF (e.g., a maximum number of consecutive HARQ DTXs) to be used for transmissions with one or more RX WTRUs (e.g., WTRU 102) configured for SL DRX may be configured in the TX WTRU (e.g., WTRU 102) by the NW. Specifically, the TX WTRU (e.g., WTRU 102) may receive two settings for the maximum number of consecutive HARQ RTXs for triggering an SL RLF. The TX WTRU (e.g., WTRU 102) may use a first setting when performing (e.g., when performing) transmissions to one or more RX WTRUs (e.g., WTRU 102) that do not have SL DRX configured, and / or may use a second setting when performing (e.g., when performing) transmissions to at least one or more RX WTRUs (e.g., WTRU 102) that have SL DRX configured.

[0163] 1.5 Exemplary Embodiments in a RX WTRU (e.g., WTRU 102) 4A-4C show timing diagrams of HARQ RTT timers and / or retransmission timers (e.g., ReTx timers) in a scenario for a TX WTRU (e.g., WTRU 102) in Mode 2 (e.g., resource allocation). Referring to FIGS. 4A-4C, a first transmission TR0 (e.g., associated with an SCI) is performed with indications of two SCI retransmissions (e.g., associated with an SCI) (a first retransmission TR1 and / or a second retransmission TR2). Specifically, as follows:

[0164] 4A, in Case 1, preemption is disabled and / or the TX WTRU (e.g., WTRU 102) may not skip the SCI associated with the first retransmission TR1. The HARQ RTT timer may be set to the time until the next retransmission resource TR2. A retransmission timer (e.g., ReTx timer) may start following (e.g., only following) the last scheduled retransmission. The TX WTRU (e.g., WTRU 102) may perform resource selection for a new SCI transmission associated with the same HARQ process within this retransmission timer.

[0165] 4B , in Case 2, preemption is disabled, and / or the TX WTRU (e.g., WTRU 102) may skip the SCI associated with the first retransmission TR1 due to UL / SL prioritization. Alternatively, the TX WTRU (e.g., WTRU 102) may enable preemption but may cause retransmission resource reselection for preemption to occur after the scheduled retransmission resource (as described herein for limiting retransmission resources for preemption). The RX WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., ReTx timer) following the location of this scheduled (and unreceived) retransmission TR1 (or following expiration of a HARQ RTT timer set based on the timing of the retransmission resource in the SCI). The TX WTRU (e.g., WTRU 102) may perform resource reselection for transmission of the first retransmission TR1 resource within the time associated with the retransmission timer (e.g., ReTx timer). A retransmission timer (e.g., ReTx timer) may start following the last scheduled retransmission TR2. The TX WTRU (e.g., WTRU 102) may perform resource selection for a new SCI transmission associated with the same HARQ process within this retransmission timer (e.g., ReTx timer).

[0166] 4C , in Case 3, preemption is enabled and / or the TX WTRU (e.g., WTRU 102) may skip the SCI associated with the first retransmission TR1 due to preemption (without any restriction, this may mean that the reselected retransmission resource may occur before the scheduled timing of the retransmission based on the information in the SCI). The TX WTRU (e.g., WTRU 102) may set a HARQ RTT timer to a value smaller than the next scheduled retransmission TR2 resource and / or may subsequently (e.g., immediately) start a retransmission timer (e.g., ReTx timer). The reselection window of the TX WTRU (e.g., WTRU 102) associated with preemption is determined based on the retransmission timer (e.g., ReTx timer).

[0167] a) Handling of HARQ RTT timer and / or retransmission timer when HARQ feedback is enabled In a first exemplary embodiment for handling HARQ RTT and / or retransmission timers, the RX WTRU (e.g., the WTRU 102) may first be notified in PC5-RRC signaling of the resource allocation mode (Mode 1 or Mode 2) or similar indication from the TX WTRU (e.g., the WTRU 102), which may determine the timer handling behavior in the RX WTRU (e.g., the WTRU 102). The RX WTRU (e.g., the WTRU 102) may allocate a received HARQ process to a new transmission / PDU after (e.g., upon) receiving a first SCI with an unoccupied HARQ process number or indicating that the first SCI represents a first transmission. The RX WTRU (e.g., the WTRU 102) may determine that the HARQ feedback is valid and, as a result, use the behavior associated with this embodiment. The RX WTRU (eg, WTRU 102) may store the location / timing of the initial transmission and / or possible retransmissions indicated in the first SCI representing the initial transmission.

[0168] The RX WTRU (e.g., WTRU 102) may transmit a PSFCH with HARQ feedback following decoding (successful or unsuccessful) of the first transmission. The RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer at the first symbol / slot following the transmission of the PSFCH. If the RX WTRU (e.g., WTRU 102) prioritizes UL transmission over SL transmission and / or skips the PSFCH as a result, the RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer at the first symbol / slot following the PSFCH that is skipped and / or intended for transmission of HARQ feedback.

[0169] 5 shows an overall method 500 for processing / setting HARQ RTT and / or retransmission timers. In step 501, the RX WTRU (e.g., WTRU 102) may determine the resource allocation mode of the peer (e.g., TX) WTRU (e.g., WTRU 102) from PC5-RRC. In step 502, after receiving (e.g., upon receiving) the first SCI, the RX WTRU (e.g., WTRU 102) may decode the first SCI and / or determine whether the first SCI represents an initial transmission or a retransmission. In step 510 and / or step 520, the RX WTRU (e.g., WTRU 102) may determine from the SCI whether there are additional retransmission resources reserved for the HARQ process.

[0170] The RX WTRU (eg, WTRU 102) may set the HARQ RTT timer as follows: If the resource allocation mode is Mode 1 (or if an indication from the TX WTRU (e.g., WTRU 102) indicates to use such HARQ behavior): o In step 512, if there are additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT to the time until the next retransmission resource for the HARQ process indicated in the SCI. ■ In a variation of this embodiment, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer. Instead, the RX WTRU (e.g., WTRU 102) may rely on the timing of the next retransmission resource to determine whether to start the retransmission timer. In such a variation, the active time may be (e.g., may be assumed to be) related to the timing of the retransmission resource and / or the running retransmission timer. o In step 511, if there are no additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT to a (pre-)configured value (from the NW or another WTRU) or a pre-defined value (also referred to as "ConfigValH1"), such value being associated with Mode 1. ■In addition, the RX WTRU (e.g., WTRU102) may further select a specific HARQ RTT timer for Mode 1 associated with the particular Mode 1 case being considered, for example from a list of (pre-)configured values provided by the TX WTRU (e.g., WTRU102), based on additional information provided by the TX WTRU (e.g., WTRU102) for the Mode 1 case being considered, such as: Whether the TX WTRU (eg, WTRU 102) has PUCCH resources configured. Whether the TX WTRU (eg, WTRU 102) reports HARQ feedback to the network (eg, transmits information indicating HARQ feedback). ■In a variation of this embodiment, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer at all and / or may start the retransmission timer immediately at this time or at some (pre)set or predefined time after this time. -If the resource allocation mode is mode 2: If there are additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT timer in step 521 to a (pre-)configured or pre-defined value (also referred to as "ConfigValH2") associated with preemption-based Mode 2 resource reselection (from the NW or another (e.g., RX) WTRU (e.g., WTRU 102). Such a timer may further depend on the priority / CBR. The (e.g., RX) WTRU (e.g., WTRU 102) may do this in step 522 if preemption is enabled. Alternatively, if preemption is disabled, the (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to the time until the next scheduled retransmission (step 512). If there are no additional retransmissions expected for the HARQ process, the (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer in step 523 to a (pre-)configured or pre-defined value (also referred to as "ConfigValH3") associated with the Mode 2 resource selection (from the NW or another WTRU) based on the new resource selection.

[0171] At step 530, the RX WTRU (eg, the WTRU 102) may start / run a HARQ RTT timer.

[0172] Following expiration of the HARQ RTT timer, the RX WTRU (e.g., WTRU 102) may determine whether the PDU for the HARQ process was successfully decoded in step 535. In step 540, the RX WTRU (e.g., WTRU 102) may determine whether the last received transmission for the HARQ process was not associated with the last retransmission resource in the indicated SCI for the HARQ process.

[0173] According to an embodiment, the RX WTRU (eg, WTRU 102) may perform the following related to the retransmission timer. -If the resource allocation mode is mode 1: If the last received transmission of an HARQ process was associated with the last retransmission resource in the indicated SCI for that HARQ process and / or if the PDU of the HARQ process was not successfully decoded, the RX WTRU (e.g., WTRU 102) may start a retransmission timer in step 542 and / or set the retransmission timer to a (pre-)configured value (also referred to as "ConfigValR1") associated with Mode 1 retransmissions in a new SCI (step 541). If the last received transmission for the HARQ process was not associated with the last retransmission resource in the indicated SCI for the HARQ process (e.g., a future mode retransmission), the (e.g., RX) WTRU (e.g., WTRU 102) may not start the retransmission timer in step 560. In step 561, the (e.g., RX) WTRU (e.g., WTRU 102) may further set the HARQ RTT time and / or start the HARQ RTT timer, e.g., as of the next retransmission resource (step 562). -If the resource allocation mode is mode 2: o In step 550, the (eg, RX) WTRU (eg, WTRU 102) may first determine whether the slot in which the HARQ RTT timer expires is associated with a reserved resource. ■ If associated and / or if the SCI is not successfully decoded within the slot, the RX WTRU (e.g., WTRU 102) may start a retransmission timer if a PDU associated with the HARQ process is not successfully decoded. If associated and / or if the SCI is successfully decoded, in step 560, the RX WTRU (e.g., WTRU 102) may not start a retransmission timer in this case and / or may continue with normal decoding of the (re)transmission associated with the HARQ process. In step 561, the (e.g., RX) WTRU (e.g., WTRU 102) may further set the HARQ RTT time, e.g., at the time of the next retransmission resource, and / or start the HARQ RTT timer (step 562). ■ In step 550, if the slot is not associated with a reserved resource in the SCI and / or if the (e.g., RX) WTRU (e.g., WTRU102) has not successfully decoded a PDU associated with the HARQ process, the RX WTRU (e.g., WTRU102) may start the HARQ retransmission timer in step 552 and / or may set the HARQ retransmission timer to a (pre)configured value or a specified value (also referred to as "ConfigValR2") in step 551. ■ Different values of the retransmission timer may be used by a WTRU (eg, WTRU 102) for different cases (eg, RX). Alternatively / alternatively, if the HARQ RTT timer is not started above (e.g., Mode 1 and / or additional retransmissions, or Mode 2 and / or preemption are disabled), the RX WTRU (e.g., WTRU 102) may consider the expiration of the HARQ RTT timer (step 565) and / or the slots associated with decoding the retransmission resource for which the previous SCI was indicated separately. Specifically, as follows: If a PDU associated with a HARQ process is not successfully decoded, the RX WTRU (e.g., WTRU 102) monitors the SCI on all resources associated with retransmissions indicated in the previous SCI for that HARQ process. At the time associated with the retransmission resource of the undecoded PDU, the RX WTRU (e.g., WTRU 102) starts a retransmission timer if the SCI is not decoded (e.g., even if the TX WTRU (e.g., WTRU 102) is in Mode 2). Otherwise, the RX WTRU (e.g., WTRU 102) does not start a retransmission timer. If the HARQ RTT timer expires and / or the PDU of the HARQ process is not successfully decoded, start the retransmission timer for the HARQ process.

[0174] An RX WTRU (eg, WTRU 102) may monitor the SL as long as either: one or more on-duration timers, inactivity timers, or retransmission timers are running in the RX WTRU (e.g., WTRU 102); and / or The timeslot is associated with a reserved retransmission resource associated with an HARQ process for which no PDUs associated with that HARQ process have been decoded.

[0175] b) Handling of HARQ RTT timer and / or retransmission timer when HARQ feedback is disabled In a second exemplary embodiment for handling HARQ RTT and / or retransmission timers, the RX WTRU (e.g., the WTRU 102) may first be informed of the resource allocation mode (Mode 1 or Mode 2) by the TX WTRU (e.g., the WTRU 102) in PC5-RRC signaling. The RX WTRU (e.g., the WTRU 102) may allocate a received HARQ process to a new transmission / PDU after (e.g., upon) receiving a first SCI with an unoccupied HARQ process number or indicating that the first SCI represents an initial transmission. The RX WTRU (e.g., the WTRU 102) may determine from the SCI that HARQ feedback is disabled and, as a result, use the behavior associated with this embodiment. Specifically, if (e.g., when) HARQ feedback is disabled (compared to the previous embodiment in which HARQ feedback is enabled), the RX WTRU (e.g., the WTRU 102) may configure a different set of (pre-)configured or specified timers for the HARQ processes. The RX WTRU (eg, WTRU 102) may store the location / timing of the initial transmission and / or possible retransmissions indicated in the first SCI representing the initial transmission.

[0176] After receiving (eg, upon receiving) an SCI with HARQ feedback disabled, the RX WTRU (eg, WTRU 102) may start the HARQ RTT timer immediately upon receiving the SCI.

[0177] The RX WTRU (eg, WTRU 102) may set the HARQ RTT timers similar to the previous embodiment, except that a different set of (pre-)configured timers may be used.

[0178] An RX WTRU (eg, WTRU 102) may, for example, set the retransmission timer in a similar manner to the previous embodiment, except that a different (pre-)configured timer value may be used.

[0179] An RX WTRU (eg, WTRU 102) may monitor the SL as long as either: one or more on-duration timers, inactivity timers, or retransmission timers are running in the RX WTRU (e.g., WTRU 102); and / or The timeslot is associated with a reserved retransmission resource associated with an HARQ process for which no PDUs associated with that HARQ process have been decoded.

[0180] 2. How to define the active time (inactivity timer) for the first transmission 2.1 Modeling the inactivity timer in the unicast case The described embodiments are defined for example for the unicast case, but may also be applicable to groupcast and / or broadcast.

[0181] a) Conditions for starting / using the inactivity timer According to an embodiment, a WTRU (a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may be configured to start / use an inactivity timer based on certain conditions. Such conditions may relate to any or a combination (and / or) of the following: -HARQ feedback enabled For example, the RX WTRU (e.g., WTRU 102) may start an inactivity timer if the received transmission / retransmission is associated with a transmission for which HARQ is enabled. Otherwise, if a transmission / retransmission for which HARQ is disabled is received, the RX WTRU (e.g., WTRU 102) may not start the inactivity timer. For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer if a transmission performed by the (e.g., RX) WTRU (e.g., WTRU 102) indicates HARQ enabled. Otherwise, if the transmission indicates HARQ disabled, the TX WTRU (e.g., WTRU 102) may not start an inactivity timer. CR / CBR in the RX WTRU (e.g., WTRU 102) For example, the RX WTRU (e.g., WTRU 102) may send a measurement of the CR / CBR at the RX WTRU (e.g., WTRU 102) to the TX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) may send such a measurement when the measurement changes from one range to another (e.g., when changing), or when the measurement changes by a specific amount (e.g., when changing). For example, if the CR / CBR is below a threshold, the RX WTRU (e.g., WTRU 102) may start the inactivity timer after (e.g., upon) receiving a new transmission or a retransmission. Otherwise, the RX WTRU (e.g., WTRU 102) may not start / restart the inactivity timer. For example, if the CR / CBR indicated by the RX WTRU (e.g., WTRU 102) is below a threshold, the TX WTRU (e.g., WTRU 102) may start the inactivity timer for transmission. Otherwise, the TX WTRU (e.g., WTRU 102) may not start / restart the inactivity timer.

[0182] b) Use of an inactivity timer in a TX WTRU (e.g., WTRU 102) According to an embodiment, a TX WTRU (e.g., the WTRU 102) may maintain an inactivity timer associated with an RX WTRU (e.g., the WTRU 102) to which it transmits if such RX WTRU (e.g., the WTRU 102) is configured for DRX. The TX WTRU (e.g., the WTRU 102) may use the inactivity timer (in addition to other timers such as the on-duration timer and the retransmission timer) to determine whether it can perform new transmissions and / or retransmissions to that particular(s) RX WTRU (e.g., the WTRU 102). For example, the TX WTRU (e.g., the WTRU 102) may perform (e.g., only perform) new transmissions and / or retransmissions to the RX WTRU (e.g., the WTRU 102) if any of the inactivity timer, on-duration timer, or retransmission timer is running (e.g., running).

[0183] c) The inactivity timers by the TX WTRUs (e.g., WTRU 102) can be started at different times. According to an embodiment, a TX WTRU (eg, WTRU 102) may start an inactivity timer at any of the following times: -After the first transmission of a new TB (e.g. resource) (e.g. when sending): For example, the TX WTRU (eg, WTRU 102) may start an inactivity timer in the first slot after transmission of the SCI associated with the new transmission. For example, a TX WTRU (eg, WTRU 102) may start an inactivity timer in the first slot following a (pre-)configured number of slots after transmitting the SCI associated with the new transmission. After (eg upon) reception of HARQ feedback, in which case this reception may further depend on the type of HARQ feedback. For example, if the TX WTRU (e.g., WTRU 102) receives a HARQ ACK or HARQ NACK, the TX WTRU (e.g., WTRU 102) may start an inactivity timer. However, if the TX WTRU (e.g., WTRU 102) decodes DTX on a PSFCH resource, the TX WTRU (e.g., WTRU 102) may not start the inactivity timer. For example, if a TX WTRU (e.g., WTRU 102) receives a HARQ ACK, the TX WTRU (e.g., WTRU 102) may start an inactivity timer. However, if the TX WTRU (e.g., WTRU 102) decodes a DTX or NACK on a PSFCH resource, the TX WTRU (e.g., WTRU 102) may not start the inactivity timer. -After the last retransmission of a new TB, indicated in the SCI: For example, a TX WTRU (eg, WTRU 102) may start an inactivity timer in the first slot after transmission of the SCI associated with the last retransmission indicated in the previous SCI. For example, the TX WTRU (e.g., WTRU 102) may start an inactivity timer a (pre-)configured number of slots after the transmission of the SCI associated with the last retransmission indicated in the previous SCI. After the Nth retransmission of a new TB indicated in the SCI (N can be configured or predefined): ○N may further depend on, for example, QoS (eg, priority).

[0184] According to an embodiment, a TX WTRU (eg, WTRU 102) may start the inactivity timer at different times (any of those indicated above) depending on any of the following specific factors: - Whether HARQ feedback is enabled / disabled for new transmissions for which an inactivity timer should be started. Depends on the CBR / CR measured and / or reported by the RX WTRU (e.g., WTRU 102). - QoS of transmission (e.g. priority).

[0185] For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer if (e.g., when) it receives a HARQ ACK or HARQ NACK if (e.g., when) HARQ feedback is enabled for the transmission, but may start the inactivity timer following the first transmission of a TB if HARQ feedback is not enabled.

[0186] d) The TX WTRU (e.g., WTRU 102) determines the duration of the inactivity timer to be used. According to an embodiment, the inactivity timer started by the TX WTRU (e.g., the WTRU 102) may have the same value as the value configured in the RX WTRU (e.g., the WTRU 102). According to an embodiment, the inactivity timer started by the TX WTRU (e.g., the WTRU 102) may have a shorter value than the value configured in the RX WTRU (e.g., the WTRU 102). For example, the TX WTRU (e.g., the WTRU 102) may be (pre-)configured with a different inactivity timer to use. According to an embodiment, the TX WTRU (e.g., the WTRU 102) may shorten the configured inactivity timer used in the RX WTRU (e.g., the WTRU 102) to account for the different start time of the inactivity timer. Specifically, if the TX WTRU (e.g., the WTRU 102) starts the inactivity timer after (e.g., upon) receiving HARQ feedback, it may do the following: -The TX WTRU (e.g., WTRU102) may shorten the inactivity timer (compared to the value used in the RX WTRU (e.g., WTRU102)) by the (or, for example, expected) start time of the first transmission for the first transmission received at the RX WTRU (e.g., WTRU102) and / or the time between the first ACK or NACK received by the TX WTRU (e.g., WTRU102) for the transmission / retransmission of that TB (or any other TB).

[0187] e) A single inactivity timer or multiple inactivity timers configured for each peer (e.g., TX) WTRU (e.g., WTRU 102) / L2 ID for the RX WTRU (e.g., WTRU 102). In the presence of multiple unicast links corresponding to unicast / groupcast and / or multiple involved L2 destination IDs, different embodiments are possible for maintaining the inactivity timer in the RX WTRU (eg, WTRU 102).

[0188] According to an embodiment, a WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may maintain an inactivity timer for each ID or set of IDs, such as a WTRU ID, a logical channel (LCH) ID, an L2 ID, etc. For example, the WTRU may maintain an inactivity timer for each unicast link (source / destination L2 ID pair) and / or participating L2 ID for groupcast / broadcast. The WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may set / reset an inactivity timer associated with a source / destination L2 ID each time the WTRU receives a transmission associated with the source / destination L2 ID.

[0189] According to an embodiment, a WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may maintain a single inactivity timer for all unicast links (source / destination ID pairs) and / or for all L2 IDs, e.g., associated with groupcast / broadcast communications. Specifically, the WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may set / reset the inactivity timer after (e.g., upon) reception of any sidelink transmission. For example, to account for different DRX configurations associated with different unicast links and / or groupcast L2 source / destination IDs, the WTRU may: - (When the inactivity timer is set / reset (e.g., when it is set / reset)) Set the inactivity timer value to different values depending on the L2 source / destination ID from which the transmission (that caused the timer to be reset) was received. Specifically, a WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) may be (pre-)configured (e.g., via PC5-RRC, Uu RRC, pre-configuration, SIB, etc.) with a different inactivity timer value for each source / destination L2 ID. After (e.g., upon) receiving a transmission associated with a particular source / destination L2, the RX WTRU (e.g., WTRU 102) may set the inactivity timer value to the configured value for that source / destination L2 ID, and / or - Determine the inactivity timer decode behavior differently based on the source / destination L2 ID whose transmission started the inactivity timer, which may include any of the following: Monitor different sets of SL resources, ○ Use different rules / priorities to determine whether to monitor SL or UL, and / or o Determine whether transmission can occur while the timer is running.

[0190] The embodiments described herein relating to an inactivity timer are applicable to any of the above embodiments.

[0191] f) The RX / TX WTRU (e.g., WTRU 102) handles the uncertainty of the MAC PDU decoding to start the inactivity timer. The inactivity timer is typically restarted for (e.g., only for) new transmissions, while retransmissions are handled by the HARQ RTT / retransmission timer (as in the Uu case). However, determining whether a transmission is associated with a new transmission may require / use decoding of the MAC PDU (with some variable latency associated with this decoding).

[0192] A DRX-related timer (e.g., an inactivity timer, a HARQ RTT timer, or a retransmission timer) may start after (e.g., upon) reception of the SCI, and / or whether such a timer is started may be conditioned based on information (e.g., HARQ process ID, new data indicator (NDI), L1 ID) conveyed in (e.g., only in) the SCI. Alternatively, such a timer may start after (e.g., upon) decoding of a MAC PDU and / or may be conditioned on information in the MAC PDU (e.g., L2 ID, LCH ID). Alternatively, the start of such a timer may be conditioned on information in both the MAC PDU and / or the SCI, but the timer may represent the time elapsed after reception of the SCI. A WTRU (e.g., a TX WTRU (e.g., WTRU 102) or a RX WTRU (e.g., WTRU 102)) may further have different behaviors for different timers.

[0193] g) The RX WTRU (e.g., WTRU 102) may start an inactivity timer at the PHY layer and / or stop the inactivity timer after decoding the PDU. According to an embodiment, an RX WTRU (e.g., WTRU 102) may start an inactivity timer based on a condition related to decoding of the SCI at the PHY layer. Following starting the inactivity timer by the PHY layer, the MAC layer may perform decoding of the MAC PDU and / or may stop the inactivity timer or continue running the inactivity timer depending on the decoding result, for example: The (eg, RX) WTRU (eg, WTRU 102) (PHY layer) may start an inactivity timer if (eg, upon reception) it receives an SCI that satisfies any of the following: The received transmission corresponds to a unicast transmission and / or the source and / or destination L1 ID matches the source / destination L1 ID of a unicast link currently configured in the WTRU. The received transmission corresponds to a groupcast transmission and / or the L1 destination ID in the SCI matches the L1 destination ID of the involved groupcast / broadcast service. ○ The NDI (within the SCI) is toggled and / or the HARQ process (within the SCI) is associated with a currently allocated HARQ process (e.g., a new transmission is indicated for that HARQ process). o HARQ in SCI is currently unallocated at the WTRU (indicating a new transmission for a new HARQ process). The received transmission corresponds to a new transmission (e.g. NDI is toggled). The received transmission corresponds to a retransmission (eg, NDI is not toggled), but the RX WTRU (eg, WTRU 102) did not receive / decode the original transmission associated with this retransmission. The (eg, RX) WTRU (eg, WTRU 102) (MAC layer) may stop the inactivity timer if any of the following occurs: The PDU is associated with a unicast and / or the L2 source / destination ID obtained by decoding the MAC PDU does not match the L2 source / destination ID of the established unicast link at the WTRU. The PDU is associated with a broadcast / groupcast and / or the L2 destination ID obtained by decoding the MAC PDU does not match the L2 destination ID of the unicast link established at the WTRU. The MAC layer is unable to decode the MAC PDU. The MAC layer decodes the MAC PDU, which includes the CSI report MAC CE (e.g., only the CSI report MAC CE). The PDU corresponds to the SCI that first started the inactivity timer (e.g., if the PHY layer started the inactivity timer (e.g., at start), the inactivity timer was not running at the time). The inactivity timer was not (re)started by another PDU while the decoding of the current PDU was in progress.

[0194] For example, the RX WTRU (e.g., WTRU 102) may stop the inactivity timer upon decoding a PDU if (e.g., when) the L2 source / destination IDs in the MAC header do not match any of the involved source / destination IDs in the WTRU and / or if the inactivity timer is running because it was started (and not restarted) by receipt of an SCI corresponding to the PDU. Specifically, the RX WTRU (e.g., WTRU 102) may stop the inactivity timer if (e.g., when) the L2 source / destination IDs in the MAC header do not match any of the involved source / destination IDs in the WTRU and / or if the inactivity timer was started (e.g., at the start) by receipt of a PDU and the inactivity timer was not previously running. For example, the RX WTRU (e.g., WTRU 102) may stop the inactivity timer upon decoding a PDU if (e.g., when) the L2 source / destination ID in the MAC header does not match any of the involved source / destination IDs in the WTRU, and / or if the inactivity timer has not been (re)started between the time the inactivity timer was started by the currently decoded PDU and / or the time the WTRU determines that the L2 source / destination ID in the MAC header does not match any of the involved source / destination IDs in the WTRU.

[0195] According to an embodiment, the TX WTRU (e.g., WTRU 102) may start its own inactivity timer (associated with the RX WTRU (e.g., WTRU 102)) in the first slot following the transmission of the SCI. In particular, the TX WTRU (e.g., WTRU 102) may transmit a first new TB to the (e.g., RX) WTRU in timeslot N and / or may be allowed to transmit a second new TB to the same (e.g., RX) WTRU already in timeslot N+1. Specifically, the TX WTRU (e.g., WTRU 102) may not place any restrictions on the inter-transmission time between two new transmissions, especially if the first transmission occurs at the end of the on duration or the end of the duration associated with the previous inactivity timer.

[0196] h) Multiple simultaneous inactivity timers can be run / stopped for each new transmission while determining whether decoding is successful. According to an embodiment that may be used in addition to other embodiments, the (e.g., RX) WTRU (e.g., WTRU 102) (PHY layer) may start multiple simultaneous inactivity timers, one for each new transmission identified by the WTRU based on decoding (e.g., decoding only) of the SCI (e.g., HARQ process, L1 ID, NDI). Following the start of each such timer, the MAC layer may stop the corresponding timer if (e.g., when) any of the conditions associated with stopping the timer in the previous solution are met. For example, the (e.g., RX) WTRU (e.g., WTRU 102) may operate according to any or combination (and / or) of the following examples: - Start a first inactivity timer if (e.g., upon receipt) an SCI associated with a new transmission is received. Such new transmission may not be successfully decoded by the MAC layer. The first inactivity timer may continue to run following a failed MAC decode. - Start a second inactivity timer if (e.g., upon receipt) an SCI associated with another new transmission is received. Such new transmission may not be successfully decoded by the MAC layer. The first inactivity timer may continue to run following a failed MAC decode. Following reception of an SCI in the same HARQ process as the first new transmission, the MAC PDU may be decoded successfully, but the L2 ID may not match the L2 ID expected at the WTRU (e.g., RX). The WTRU (e.g., WTRU 102) (MAC) may stop the inactivity timer associated with the first new transmission and maintain the inactivity timer associated with the second retransmission. Following reception of the SCI in the same HARQ process as the second new transmission, the MAC PDU may be successfully decoded, and / or the (e.g., RX) WTRU (e.g., WTRU 102) may repeat the same procedure to determine whether to stop or continue the inactivity timer associated with the second new transmission.

[0197] An RX WTRU (eg, WTRU 102) may be active for sidelink monitoring as long as at least one of the inactivity timers (the first inactivity timer or the second inactivity timer) is running.

[0198] i) The RX WTRU (e.g., WTRU 102) starts an inactivity timer at the MAC layer, but can compensate for the decoding delay. According to an embodiment, an RX WTRU (eg, WTRU 102) may start an inactivity timer based on a condition related to decoding of an SCI and / or a condition related to decoding of a MAC PDU.

[0199] For example, the RX WTRU (e.g., WTRU 102) may start the inactivity timer if any of the conditions associated with the SCI (described in another embodiment) are met and the PDU is successfully decoded and / or the conditions associated with the decoded MAC PDU are also met. The conditions associated with the decoded MAC PDU may include any or a combination (and / or) of the following: The PDU is associated with a unicast and / or the L2 source / destination ID obtained by decoding the MAC PDU matches the L2 source / destination ID of the unicast link established at the WTRU. The PDU is associated with a broadcast / groupcast and / or the L2 destination ID obtained by decoding the MAC PDU matches the L2 destination ID of the unicast link established in the WTRU. The MAC layer decodes the MAC PDU, and / or the MAC PDU does not include a CSI reporting MAC CE (e.g., only a CSI reporting MAC CE) (e.g., there is at least one LCH in the MAC PDU associated with the data).

[0200] For example, the RX WTRU (e.g., WTRU 102) may start the inactivity timer following (e.g., only after) successful decoding of a MAC PDU, which may occur after multiple retransmissions associated with that MAC PDU. The RX WTRU (e.g., WTRU 102) may start the inactivity timer at any of the following times: -Transmission of a HARQ ACK on the PSFCH if (e.g. when) the conditions defined above indicate a successfully decoded new transmission. - The (e.g. (pre)configured or predefined) number of symbols / slots following the reception of the SCI associated with the transmission / retransmission in which the new transmission was successfully decoded by the MAC layer. The number of symbols / slots may be zero. In such a case, the MAC layer may start a timer and / or compensate (e.g., add an elapsed time value) for the time between SCI reception and / or decoding of a MAC PDU. The time of SCI reception can be indicated to the MAC layer by the PHY layer. The number of symbols / slots reserved (e.g., (pre)configured or pre-defined) as retransmission resources following the last retransmission resource used by the TX WTRU (e.g., WTRU 102) to transmit a PDU or within the SCI used to transmit the first transmission.

[0201] According to an embodiment, a TX WTRU (eg, the WTRU 102) may start its own inactivity timer (associated with the RX WTRU (eg, the WTRU 102)) at any of the following times: - Upon reception of a HARQ ACK following a new transmission if HARQ feedback is enabled. The (e.g., (pre)configured or pre-defined) number of slots following the first transmission of a PDU by a TX WTRU (e.g., WTRU 102); and / or The number of slots reserved (e.g., (pre)configured or pre-defined) as retransmission resources within the SCI that follows the last retransmission resource used by the TX WTRU (e.g., WTRU 102) to transmit a PDU or that is used to transmit the first transmission.

[0202] Specifically, if the on duration timer is no longer running following the first transmission of a PDU by a TX WTRU (e.g., WTRU 102), the TX WTRU (e.g., WTRU 102) may delay transmission of other PDUs until a time associated with a retransmission resource for the PDU or until an indication of a HARQ ACK associated with the new transmission.

[0203] 2.2 Maintaining an Inactivity Timer in an RX WTRU and / or a TX WTRU (e.g., WTRU 102) Applicable to Groupcast The described embodiments are defined for example for groupcast, but may also be applied to unicast and / or broadcast.

[0204] a) The RX / TX WTRU (e.g., WTRU 102) starts / uses an inactivity timer based on certain conditions (e.g., only certain conditions) related to the groupcast. According to an embodiment, an RX and / or TX WTRU (e.g., WTRU 102) in a groupcast may start / assume / use an inactivity timer associated with DRX under certain conditions (e.g., only under certain conditions). Specifically, a TX WTRU (e.g., WTRU 102) may maintain an inactivity timer associated with a transmission for which any of the following conditions are met: -Conditions based on the type of cast: For example, a TX / RX WTRU (e.g., WTRU 102) may start / use an inactivity timer (e.g., inactivity timer only) for transmissions associated with a particular case (e.g., unicast (e.g., unicast only), or unicast and / or groupcast). For example, a TX / RX WTRU (eg, WTRU 102) may combine other conditions with a particular cast type (eg, only a particular cast type). ■For example, the TX / RX WTRU (e.g., WTRU 102) may start / use an inactivity timer for unicast or for groupcast as long as the groupcast transmission is associated with the type of HARQ feedback for groupcast as follows: -QoS-based conditions: For example, a TX / RX WTRU (eg, WTRU 102) may start / use an inactivity timer (eg, only an inactivity timer) for transmissions whose transmission priority is below a threshold. Conditions based on whether HARQ is enabled / disabled and / or which type of groupcast HARQ feedback reporting (ACK / NACK reporting or NACK (e.g., NACK only)) is enabled / disabled: For example, the TX WTRU (e.g., WTRU 102) may start / use an inactivity timer if (e.g., only if) a transmission by the TX WTRU (e.g., WTRU 102) is HARQ enabled (e.g., when HARQ is enabled). For example, the TX WTRU (e.g., WTRU 102) may start / use an inactivity timer if (e.g., only if) the transmission is associated with HARQ enabled and / or a positive acknowledgment-negative acknowledgment groupcast HARQ type is used. For example, the RX WTRU (e.g., WTRU 102) may start an inactivity timer, e.g., associated with an L2 ID, if (e.g., only if) the received transmission is HARQ-enabled (e.g., when HARQ is enabled). For example, the RX WTRU (e.g., WTRU 102) may start an inactivity timer associated with, for example, an L2 ID if (e.g., only if) the received transmission is HARQ-enabled using a groupcast positive acknowledgment-negative acknowledgment type (e.g., when HARQ is enabled). -Conditions based on member ID set by higher tier: For example, if a TX WTRU (e.g., WTRU102) and / or an RX WTRU (e.g., WTRU102) is configured with a member ID associated with a particular groupcast transmission (e.g., associated with a groupcast L2 ID), the TX WTRU (e.g., WTRU102) and / or the RX WTRU (e.g., WTRU102) may use an inactivity timer for such groupcast transmission. -Conditions based on group size: For example, a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102) may use an inactivity timer for a particular groupcast transmission (e.g., associated with a groupcast L2 ID) if the group number is not greater than the configured number of PSFCH resources. -Conditions based on MCR (Minimum Communication Range): For example, a TX WTRU (eg, WTRU 102) and / or an RX WTRU (eg, WTRU 102) may use an inactivity timer for a particular groupcast transmission if an MCR is configured for the transmission. ■ Specifically, if an MCR is configured for at least one of the SLRBs for transmission, the TX WTRU (e.g., WTRU 102) may operate using (e.g., assuming) an inactivity timer associated with transmissions to the L2 ID. Specifically, following a transmission while any of the timers associated with the active time of the L2 ID are running, the TX WTRU (e.g., WTRU 102) may start an inactivity timer each time the TX WTRU (e.g., WTRU 102) performs a transmission to the L2 ID (or receives an acknowledgment for a transmission). Otherwise, if an MCR is not configured, the TX WTRU (e.g., WTRU 102) may not start an inactivity timer under such conditions and / or may not maintain an activity condition based on the inactivity timer (e.g., may allow transmission only if (e.g., when) the on-duration timer is running or the retransmission timer is running). ■Similarly, an RX WTRU (e.g., WTRU102) can define its own active time for an L2 ID if it receives at least one packet associated with the MCR of that L2 ID or if an SLRB for transmission to an L2 ID for which an MCR is set is configured in the RX WTRU (e.g., WTRU102). For example, a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102) may use an inactivity timer for a particular groupcast if the MCR configured for any SLRB falls below a threshold. In this case, similar behavior to the example above is expected. Conditions based on MCR and / or HARQ feedback enablement: For example, the RX and / or RX WTRU (eg, WTRU 102) may use an inactivity timer for a particular groupcast transmission for which the MCR is set as long as HARQ feedback is valid. For example, if MCR is configured and / or HARQ is enabled for at least one SLRB for transmission to an L2 ID, the TX WTRU (eg, WTRU 102) may use an inactivity timer. ■For example, if MCR is set and / or HARQ is enabled for all SLRBs for transmission to a groupcast L2 ID, the TX WTRU (e.g., WTRU 102) may use an inactivity timer for that L2 ID, otherwise it does not.

[0205] According to an embodiment, a TX / RX WTRU (e.g., WTRU 102) may stop a currently running inactivity timer if one of the conditions or parameters for supporting the inactivity timer changes. For example, a TX / RX WTRU (e.g., WTRU 102) may stop an already running inactivity timer if the group size and / or member ID indicated by higher layers changes at the WTRU.

[0206] b) The RX WTRU (e.g., WTRU 102) resets the inactivity timer according to the MCR of the received transmission. According to an embodiment, an RX WTRU (e.g., WTRU 102) may determine whether to reset an inactivity timer associated with, for example, a groupcast transmission based on the location of the RX WTRU (e.g., WTRU 102) and / or the MCR associated with the transmission. Specifically, the RX WTRU (e.g., WTRU 102) may reset the inactivity timer after (e.g., upon) (e.g., only after) receipt of a new transmission if (e.g., when) such a new transmission has an MCR that satisfies any of the following conditions: -MCR does not exist. -MCR is present. The determined distance between the transmitter and / or receiver is less than (less than or equal to) the MCR. The determined distance between the transmitter and / or receiver is less than (or equal to or less than) the (pre-set) delta added to or subtracted from the MCR. Such deltas may further depend on any of the following: ■ For example, priority, WTRU speed, CBR, number of WTRUs in the group, power saving preferences in the RX WTRU (eg, WTRU 102), WTRU capabilities associated with the RX WTRU (eg, WTRU 102).

[0207] The consideration of distance relative to the MCR may further be based on the change in distance relative to the MCR from a previous transmission observed by the RX WTRU (e.g., WTRU 102). Specifically, if the distance between the two WTRUs, or the difference in such distance compared to the MCR, is decreasing with each subsequent transmission targeted to the L2 ID, the RX WTRU (e.g., WTRU 102) may restart the inactivity timer.

[0208] c) The TX WTRU (eg, the WTRU 102) maintains a timer set for each RX WTRU (eg, the WTRU 102) associated with it as the TX WTRU (eg, the WTRU 102). According to an embodiment, a TX WTRU (e.g., WTRU 102) may determine whether to transmit to a particular WTRU (unicast) or group of WTRUs (e.g., groupcast L2 ID) based on maintaining a similar timer as the RX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) may transmit to a particular group of WTRUs if at least one of the inactivity timers associated with that group is running.

[0209] According to an embodiment, a TX WTRU (eg, the WTRU 102) may maintain a set of timers that correspond to the timers of the RX WTRU (eg, the WTRU 102). Specifically, the TX WTRU (e.g., the WTRU 102) may maintain an inactivity timer per L2 source / destination ID (for unicast), per L2 destination ID (for groupcast), and / or per priority / QoS level of each address, for example. The TX WTRU (e.g., the WTRU 102) may use related (but different) values of such timers to compensate for delays in performing transmissions and / or performing reliable transmissions. The TX WTRU (e.g., the WTRU 102) may start / stop such timers earlier / later than the TX WTRU (e.g., the WTRU 102). For example: The TX WTRU (e.g., the WTRU 102) may be configured with a shorter on-duration timer, HARQ RTT timer, or retransmission timer than the RX WTRU (e.g., the WTRU 102); and / or A TX WTRU (eg, WTRU 102) may be configured to start its on duration timer earlier in the DRX cycle compared to a RX WTRU (eg, WTRU 102).

[0210] d) The TX WTRU (e.g., WTRU 102) (re)starts the inactivity timer upon receipt of HARQ feedback from one or more WTRUs in the group. According to an embodiment, a TX WTRU (eg, WTRU 102) may (re)start the inactivity timer based on receiving HARQ feedback from one or more WTRUs.

[0211] According to an embodiment, a TX WTRU (e.g., WTRU 102) may maintain a single inactivity timer for all RX WTRUs (e.g., WTRU 102) in a group (with respect to its transmissions to that group). The TX WTRU (e.g., WTRU 102) may start the inactivity timer under any of the following conditions: - Upon receiving (eg, upon reception) HARQ feedback (eg, ACK or NACK) from the first (eg, RX) WTRU. - If (eg, upon reception) HARQ feedback (eg, ACK or NACK) is received from a majority of WTRUs in the group (eg, a number or percentage of WTRUs above a threshold). - If HARQ feedback is received from all WTRUs in the group (eg, upon reception). - For example, upon receiving HARQ feedback from a specific subset of WTRUs in the group associated with a pre-configured pattern or set of member IDs (e.g., IDs closest to its own ID, or IDs 1-x). - if HARQ feedback is received within a certain time period from the first transmission; and / or - if HARQ feedback is received at the latest following x (re)transmissions of the PDU (e.g., upon reception).

[0212] For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer if (e.g., upon) receiving HARQ feedback (either ACK or NACK) from all RX WTRUs (e.g., WTRU 102) in the group.

[0213] For example, if a TX WTRU (e.g., WTRU 102) receives HARQ feedback from all RX WTRUs (e.g., WTRU 102) in the group (e.g., upon reception), it may start an inactivity timer as long as the HARQ feedback is received within the first x ms following the initial transmission or within the first y retransmissions of the PDU by the TX WTRU (e.g., WTRU 102).

[0214] According to an embodiment, a TX WTRU (e.g., the WTRU 102) may maintain an inactivity timer associated with each of the RX WTRUs (e.g., the WTRU 102) in the group. If (e.g., upon) the TX WTRU (e.g., the WTRU 102) receives HARQ feedback from a particular (e.g., RX) WTRU (e.g., the WTRU 102), it may start an RX WTRU (e.g., the WTRU 102)-specific inactivity timer for that (e.g., RX) WTRU (e.g., the WTRU 102). In this solution, the TX WTRU (e.g., the WTRU 102) may send a subsequent new transmission for its L2 ID (or for its group) as long as any of the following conditions are true: An inactivity timer associated with each RX WTRU (eg, WTRU 102) is running. The inactivity timers associated with the majority of the WTRUs in the group (eg, a number or percentage of WTRUs exceeding a threshold) are running. An inactivity timer associated with at least one WTRU in the group is running; and / or An inactivity timer associated with a particular subset of WTRUs in the group is running (such a subset may correspond to a pre-configured pattern or set of member IDs).

[0215] e) The TX WTRU (e.g., WTRU 102) starts the inactivity timer at different times for groups / transmissions for which feedback is enabled and disabled. According to an embodiment, a TX WTRU (e.g., WTRU 102) may have different criteria for starting the inactivity timer based on transmissions to a group. Such criteria may depend on any of the following: -HARQ feedback enable / disable. -Cast type. -HARQ feedback type (positive-negative feedback and negative (e.g., negative only) feedback). - Presence and / or value of MCR. -Whether or not a PSFCH resource is configured in the resource pool.

[0216] For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer after (e.g., upon) receiving HARQ feedback (according to the previous embodiment) if (e.g., when) the transmission is associated with a groupcast using positive acknowledgment-negative acknowledgment, and / or may start an inactivity timer after (e.g., upon) the first transmission (e.g., to a WTRU or group) otherwise.

[0217] f) The TX WTRU (e.g., WTRU 102) uses mechanisms to improve transmission reliability when (e.g., only when) feedback is not possible. According to an embodiment, a TX WTRU (e.g., WTRU 102) may use different values of the inactivity timer for different inactivity timer start criteria. Additionally, the TX WTRU (e.g., WTRU 102) may employ mechanisms to improve the reliability of transmissions during the inactivity time or towards the end of the on duration, such as any of the following: -Increase the transmission power. For example, a (eg, TX) WTRU (eg, WTRU 102) may increase transmit power for transmissions that occur outside the on duration or for transmissions where some of the retransmissions fall outside the on duration. -Increase the number of retransmissions. For example, a (eg, TX) WTRU (eg, WTRU 102) may increase the number of retransmissions of a transmission where the transmission occurs outside the on duration or where some of the retransmissions may be outside the on duration. - Ensures that retransmissions fall within the on-duration or within a subset of resources within the on-duration. For example, the (e.g., TX) WTRU (e.g., WTRU 102) may perform resource selection such that the number of retransmission resources fits within the ON duration, where for example, this number of resources may further depend on the QoS and / or CBR. For example, the (e.g., TX) WTRU (e.g., WTRU 102) may be configured with the number of (e.g., required) retransmission resources to be performed within the ON duration based on priority and / or CBR. For example, the (e.g., TX) WTRU (e.g., WTRU 102) may be configured with the number of retransmission resources to be performed when the TX WTRU's (e.g., WTRU 102's) inactivity timer is running (e.g., running) based on the QoS and / or CBR, where the number of such retransmissions may vary depending on: o In a general example, a (e.g., TX) WTRU (e.g., WTRU 102) may be configured with different numbers of allowed / minimum / required retransmissions to be performed depending on which timer is running. ■ For example, when the on duration timer is running (e.g., running) in a TX WTRU (e.g., WTRU 102) compared to when the on duration timer is not running (e.g., not running). ■ For example, when an inactivity timer is running (e.g., running) at a TX WTRU (e.g., WTRU 102) compared to when the inactivity timer is not running (e.g., not running). -Increase the modulation and / or coding scheme (MCS) of transmission.

[0218] A (e.g., TX) WTRU (e.g., WTRU 102) may use such a mechanism for (e.g., only for) transmissions that have specific criteria for starting the inactivity timer. Specifically, a TX WTRU (e.g., WTRU 102) may not use a reliability mechanism for groupcast transmissions that use positive acknowledgment-negative acknowledgment, but may use it for other groupcast transmissions.

[0219] A TX WTRU (e.g., WTRU 102) may use such a mechanism, for example, when the PSFCH is not configured. When the PSFCH is configured, the TX WTRU (e.g., WTRU 102) may always enable HARQ feedback or set the HARQ feedback mode to positive / negative acknowledgment to ensure reliability.

[0220] Furthermore, whether to apply the mechanism and / or the parameters / thresholds / increases / etc. (e.g., number of retransmissions, increase in number of retransmissions, increase in transmit power, MCS, etc.) can further depend on the congestion of the link. For example, this can be higher or lower for higher CBR.

[0221] In the unicast case, the (e.g., TX) WTRU (e.g., WTRU 102) may use such a mechanism for transmissions where HARQ is disabled (e.g., for transmissions only) and / or may use other mechanisms herein for transmissions where HARQ is enabled.

[0222] g) The TX WTRU (e.g., WTRU 102) transmits during the active time. According to an embodiment, for example, for a transmission associated with HARQ feedback (e.g., a unicast transmission with HARQ enabled), the TX WTRU (e.g., the WTRU 102) may perform the transmission at least K slots before the expiration of the inactivity timer, on duration timer, retransmission timer (or any timer in the RX WTRU (e.g., the WTRU 102) associated with the active transmission). K may be related to the latency associated with the HARQ feedback. Specifically, K may be any of the following: - The time difference between one (or more or all in case of groupcast) PSFCH resources for a transmission and / or HARQ feedback associated with that transmission. (eg, TX) A (pre)configured value that allows a WTRU (eg, WTRU 102) to schedule a retransmission (in case of DTX) before the expiration of such timer. - The time between the first transmission and / or the first retransmission. - Time between the first transmission and / or the Nth retransmission (N can depend on CBR, QoS, etc.). - the time between the initial transmission and / or the last retransmission indicated in the SCI of the initial transmission; and / or The time between the PSFCH resource associated with the first transmission in the SCI and / or the last retransmission indicated in the SCI.

[0223] h) The TX WTRU (e.g., WTRU 102) forces / enables HARQ feedback for a particular transmission to the RX WTRU (e.g., WTRU 102) in DRX. According to an embodiment, a TX WTRU (e.g., WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., WTRU 102) that is in DRX regardless of the LCH HARQ feedback enable setting, which allows the TX WTRU (e.g., WTRU 102) to accurately start its inactivity timer based on receiving HARQ feedback from the TX WTRU (e.g., WTRU 102).

[0224] A TX WTRU (e.g., the WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., the WTRU 102) for all transmissions to that RX WTRU. Alternatively, a TX WTRU (e.g., the WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., the WTRU 102) under any of the following conditions: - On duration timer is not running send. - Transmission with inactivity timer running. A transmission in which the (eg, TX) WTRU (eg, WTRU 102) still has data in its buffer that it plans / configures to transmit before the next on duration of the RX WTRU (eg, WTRU 102). - The transmission associated with the last grant during the on duration associated with the RX WTRU (eg, WTRU 102). The transmission associated with the last grant in the inactivity timer associated with the RX WTRU (eg, WTRU 102). (eg, TX) A transmission in which the WTRU still has data in its buffer (the data may have high priority (eg, priority above a threshold)). (eg, TX) Transmits where the WTRU still has data in its buffer and the PDB is less than the time until the next On Duration. - (e.g., TX) Transmissions where the WTRU still has data in its buffer and the LCHs with available data are configured to have HARQ feedback enabled transmissions before transmitting these LCHs.

[0225] 2.3 Inactivity Timer Handling in the Case of UL Prioritization or Half Duplex a) The RX WTRU (e.g., WTRU 102) may start an inactivity timer under conditions unrelated to data reception. According to an embodiment, an RX WTRU (e.g., the WTRU 102) may start / restart the inactivity timer without receiving a transmission. Specifically, the RX WTRU (e.g., the WTRU 102) may start / restart the inactivity timer after (e.g., when) performing one or more transmissions (either UL or SL transmissions) or after (e.g., when decoding) another interface (Uu or SL on a different carrier) that prevents such (e.g., RX) WTRU (e.g., the WTRU 102) from decoding on the sidelink at the time of the transmission.

[0226] According to an embodiment, an RX WTRU (e.g., the WTRU 102) may start / restart an inactivity timer at a time when the (e.g., RX) WTRU (e.g., the WTRU 102) performs a transmission / reception that prevents the (e.g., RX) WTRU (e.g., the WTRU 102) from decoding on the sidelink. This may be during the (e.g., RX) WTRU's (e.g., the WTRU 102's) active monitoring time / period, and may be either while the on duration timer is running, while the inactivity timer is running, or while any other timer defining active sidelink monitoring is running. Alternatively, the (e.g., RX) WTRU (e.g., the WTRU 102) may start the inactivity timer at a (pre-)configured or pre-defined point within either the on duration (defined by the on duration timer), the inactivity timer duration, etc., based on one of the following conditions: For example, the RX WTRU (e.g., the WTRU 102) may start / restart the inactivity timer upon (e.g., when) meeting one of the following conditions: At a (pre)configured or predefined slot within the on duration or inactivity timer duration. - in the last slot associated with the on duration or inactivity timer duration; and / or - The number of slots (pre-set or defined) before the end of the last slot associated with the on-duration or inactivity timer duration.

[0227] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may start / restart the inactivity timer (to proactively extend the activity timer) without receiving a transmission associated with a sidelink-related condition. Such a condition may be related to any of the following: -CBR conditions: For example, a (eg, RX) WTRU (eg, WTRU 102) may start / restart an inactivity timer if the CBR is greater than a configured threshold. - Criteria for the number / volume / percentage of failed Sidelink decode opportunities during Active Hours: For example, the (e.g., RX) WTRU (e.g., WTRU 102) may start / restart the inactivity timer if it fails to decode the sidelink in at least N slots or at least X% of slots during the on duration or currently running inactivity timer, where N and / or X% may be (pre-) configured. Conditions related to the QoS of the expected data, which may be determined based on the PC5 QoS identifier (PQI) of one or more established QoS flows, the configuration of one or more SLRBs (e.g., for reception), the priority of one or more recent transmissions (e.g., the transmission that started the currently running inactivity timer), etc.: For example, the (e.g., RX) WTRU (e.g., WTRU 102) may decide whether to start / restart the inactivity timer based on the QoS of the expected data (e.g., if the QoS of the expected data is higher than a threshold QoS, start / restart the inactivity timer). For example, a (eg, RX) WTRU (eg, WTRU 102) may decide either N or X% in the above example based on the expected QoS of the data. Conditions regarding the type or power saving preferences of the (e.g., RX) WTRU (e.g., WTRU 102): For example, a (e.g., RX) WTRU (e.g., WTRU 102) may start / restart the inactivity timer if it is of a particular WTRU type or if a particular power saving preference is in effect at the time another of the above conditions is triggered.

[0228] FIG. 6 illustrates an example method 600 performed by a first WTRU (e.g., an RX WTRU) for sidelink communication between the first WTRU (e.g., an RX WTRU) and / or a second WTRU (e.g., a TX WTRU).

[0229] According to an embodiment, in step 610, a first WTRU (e.g., an RX WTRU) may be configured to receive an SCI from a second WTRU (e.g., a TX WTRU) indicating one or more transmission resources for sidelink communication.

[0230] According to an embodiment, in step 620, the first WTRU (eg, the RX WTRU) may be configured to allocate HARQ processes to one or more transmission resources by the first WTRU (eg, the RX WTRU).

[0231] According to an embodiment, in step 630, the first WTRU (e.g., the RX WTRU) may be configured to monitor one or more transmission resources of the sidelink communication for retransmissions from the second WTRU (e.g., the TX WTRU) by the first WTRU (e.g., the RX WTRU) during a hybrid automatic repeat request round-trip time (HARQ RTT) period associated with the HARQ process.

[0232] According to an embodiment, in step 640, the first WTRU (e.g., the RX WTRU) may be configured to start a DRX retransmission period associated with the HARQ process upon expiration of the HARQ RTT period and / or on condition that the HARQ process is not decoded by the first WTRU (e.g., the RX WTRU).

[0233] For example, a first WTRU (e.g., an RX WTRU) may be configured to monitor one or more transmission resources of a sidelink communication for retransmission from a second WTRU (e.g., a TX WTRU) based on the DRX retransmission period.

[0234] For example, the HARQ RTT timer is started in a timeslot following the transmission of sidelink feedback channel information associated with one or more transmission resources.

[0235] For example, a first WTRU (e.g., an RX WTRU) may be configured to receive a resource allocation mode for sidelink communication between the first WTRU (e.g., an RX WTRU) and / or a second WTRU (e.g., a TX WTRU).

[0236] For example, the first WTRU (e.g., the RX WTRU) may be configured to determine the value of the HARQ RTT timer based on either a resource allocation mode of sidelink communication between the first WTRU (e.g., the RX WTRU) and / or the second WTRU (e.g., the TX WTRU) and / or an indication of additional retransmission resources reserved for the HARQ process by the received SCI or another previously received SCI.

[0237] For example, the DRX retransmission timer may be started based on any of the following: a resource allocation mode for sidelink communication between the first WTRU (e.g., RX WTRU) and / or the second WTRU (e.g., TX WTRU); an indication of additional retransmission resources reserved for the HARQ process by the received SCI or another previously received SCI; expiration of the HARQ RTT period in a time slot associated with a reserved resource in another previously received SCI; and / or decoding of the received SCI in a time slot associated with a reserved resource in another previously received SCI.

[0238] For example, the first WTRU (e.g., the RX WTRU) may be configured to determine the value of the DRX retransmission timer based on either a resource allocation mode of sidelink communication between the first WTRU (e.g., the RX WTRU) and / or the second WTRU (e.g., the TX WTRU), an indication of additional retransmission resources reserved for the HARQ process by the received SCI or another previously received SCI, and / or decoding of the received SCI in a time slot associated with the reserved resources in another previously received SCI.

[0239] For example, sidelink communication is unicast communication.

[0240] FIG. 7 illustrates an example of a method 700 performed by a first WTRU (e.g., an RX WTRU) for sidelink communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

[0241] According to an embodiment, in step 710, a first WTRU (e.g., an RX WTRU) may be configured to receive D2D control information from a second WTRU (e.g., a TX WTRU) including: (1) first information indicating one or more first transmission resources reserved for transmission of D2D communication; and (2) second information indicating whether at least one second transmission resource is reserved for retransmission of D2D communication.

[0242] According to an embodiment, in step 720, the first WTRU (e.g., the RX WTRU) may be configured to determine a sleep period for the first WTRU (e.g., the RX WTRU) that ends before the reception time of the retransmission of the D2D communication, the sleep period being based on the second information.

[0243] According to an embodiment, in step 730, the first WTRU (eg, the RX WTRU) may be configured to receive retransmissions of the D2D communication after the determined sleep period expires.

[0244] For example, on condition that the second information indicates that at least one second transmission resource is reserved for retransmission of D2D communication, the determined sleep period is based on timing information associated with the reserved at least one second transmission resource.

[0245] For example, the first WTRU (e.g., the RX WTRU) may be further configured to obtain a sleep duration value, and the determined sleep duration is based on the obtained sleep duration value, provided that the second information does not indicate that at least one second transmission resource is reserved for retransmission of the D2D communication.

[0246] For example, the first WTRU (eg, the RX WTRU) may be further configured to obtain the value of the sleep duration by receiving network configuration information indicating the value of the sleep duration.

[0247] For example, the step of obtaining the value of the sleep period may be further configured to obtain the value of the sleep period by determining the value of the sleep period based on a preset value.

[0248] For example, the D2D control information further includes information indicating whether transmission of the D2D feedback information associated with the first transmission resource is valid.

[0249] For example, the determined sleep period begins in the time slot following the reception of the D2D control information.

[0250] For example, on the condition that the transmission of the D2D feedback information is valid, the determined sleep period starts in the time slot following the transmission of the D2D feedback information.

[0251] For example, the determined sleep period starts in the time slot following the reception of the D2D control information, provided that the transmission of D2D feedback information is disabled.

[0252] For example, the determined sleep period may start at a predetermined time point or at a time point indicated in the received D2D control information.

[0253] For example, the determined sleep period starts at a time point based on the cast type of the D2D communication.

[0254] For example, D2D communication is sidelink communication.

[0255] FIG. 8 illustrates an example of a method 800 performed by a first WTRU (e.g., an RX WTRU) for sidelink communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

[0256] According to an embodiment, in step 810, a first WTRU (e.g., an RX WTRU) may be configured to receive D2D control information from a second WTRU (e.g., a TX WTRU) including: (1) first information indicating one or more first transmission resources reserved for transmitting D2D communications; and (2) second information indicating whether transmission of D2D feedback information associated with the first transmission resources is enabled.

[0257] According to an embodiment, in step 820, the first WTRU (e.g., the RX WTRU) may be configured to determine a sleep period for the first WTRU (e.g., the RX WTRU) that ends before the reception time of the retransmission of the D2D communication, and the start time of the sleep period is based on the second information.

[0258] According to an embodiment, in step 830, the first WTRU (eg, the RX WTRU) may be configured to receive retransmissions of the D2D communication after the determined sleep period expires.

[0259] For example, on the condition that the transmission of the D2D feedback information is valid, the determined sleep period starts in the time slot following the transmission of the D2D feedback information.

[0260] For example, the determined sleep period starts in the time slot following the reception of the D2D control information, provided that the transmission of D2D feedback information is disabled.

[0261] FIG. 9 illustrates an example of a method 900 performed by a first WTRU (e.g., an RX WTRU) for sidelink communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

[0262] According to an embodiment, in step 910, a first WTRU (e.g., an RX WTRU) may be configured to receive D2D control information from a second WTRU (e.g., a TX WTRU) including information indicating one or more first transmission resources reserved for transmitting D2D communication.

[0263] According to an embodiment, in step 920, the first WTRU (e.g., the RX WTRU) may be configured to determine a sleep period that ends before the time of reception of the retransmission of the D2D communication, the determined sleep period starting in a timeslot following the reception of the D2D control information.

[0264] According to an embodiment, in step 930, the first WTRU (eg, the RX WTRU) may be configured to receive retransmissions of the D2D communication after the determined sleep period expires.

[0265] FIG. 10 illustrates an example of a method 1000 performed by a first WTRU (e.g., a TX WTRU) for sidelink communication between the first WTRU (e.g., a TX WTRU) and a second WTRU (e.g., an RX WTRU).

[0266] According to an embodiment, in step 1010, a first WTRU (e.g., a TX WTRU) may be configured to transmit D2D control information to a second WTRU (e.g., an RX WTRU), the D2D control information including: (1) first information indicating one or more first transmission resources reserved for transmission of D2D communication; and (2) second information indicating at least one second transmission resource reserved for retransmission of D2D communication.

[0267] According to an embodiment, in step 1010, the first WTRU (e.g., TX WTRU) may be configured to transmit, to the second WTRU (e.g., RX WTRU), further D2D control information including third information indicating at least one third transmission resource reserved for retransmission of the D2D communication, provided that the at least one second transmission resource reserved for retransmission of the D2D communication is associated with a preemption indication / information, wherein the at least one third transmission resource is reserved after the at least one second transmission resource indicated in the second information (e.g., in a first window of transmission resources after the second transmission resource).

[0268] For example, the first WTRU (eg, a TX WTRU) may be configured to (re)select at least one third transmission resource reserved for retransmission of the D2D communication.

[0269] Additionally, any features, variations, or embodiments described in the methods are compatible with an apparatus device including means for processing the disclosed methods, compatible with a device with a processor configured to process the disclosed methods, compatible with a computer program product including program code instructions, and compatible with a non-transitory computer-readable storage medium storing program instructions.

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

[0271] The above-described embodiments are described with reference to the terminology and structure of infrared-enabled devices (i.e., infrared emitters and receivers) for simplicity, however, the described embodiments are not limited to these systems and may also be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves such as acoustic waves.

[0272] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or “image” can mean either a snapshot, a single image, and / or multiple images displayed over time. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote” and / or the term “head-mounted display” and its abbreviation “HMD” can mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of multiple embodiments of a WTRU, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device specifically configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired-enabled device configured to have less than all of the structure and functionality of a WTRU, or (iv) other. Details of an exemplary WTRU, which can represent any of the WTRUs listed herein, are provided herein with respect to FIGS. 1A-1D. As another example, various embodiments disclosed herein above and below are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays can be utilized and that the present disclosure and the various disclosed embodiments can be modified, in part or in whole, accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adaptive reality experience.

[0273] Additionally, the methods provided herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0274] Modifications to the methods, devices, and systems provided above are possible without departing from the scope of the present invention. In view of the wide variety of possible embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the appended claims. For example, the embodiments provided herein include a handheld device, which may include or be utilized with any suitable voltage source, such as a battery providing any suitable voltage.

[0275] Additionally, in the above embodiments, it should be noted that processing platforms, computing systems, controllers, and other devices include processors. These devices may include at least one central processing unit ("CPU") and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0276] Those of ordinary skill in the art will understand that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that can cause a resulting transformation or reduction of the electrical signals, and the memory system maintains the data bits in memory locations, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs described above, and that other platforms and CPUs may support the provided methods.

[0277] The data bits may also be maintained on computer-readable media, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by a CPU. The computer-readable media may include cooperative or interconnected computer-readable media that reside exclusively on a processing system or that are distributed among multiple interconnected processing systems, which may be local or remote to the processing system. It should be understood that the embodiments are not limited to the memories described above, and that other platforms and memories may support the methods provided.

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

[0279] There is little distinction between hardware and software implementations of aspects of the system. Whether to use hardware or software is generally a design choice representing a cost vs. efficiency trade-off (although the choice between hardware and software can be important in certain situations). There may be a variety of vehicles (e.g., hardware, software, and / or firmware) in which the processes and / or systems and / or other techniques described herein may be effective, and the preferred vehicle may vary depending on the context in which the processes and / or systems and / or other techniques are deployed. For example, if an implementer determines that speed and accuracy are paramount, the implementer may select a primarily hardware and / or firmware vehicle. If flexibility is paramount, the implementer may select a primarily software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0280] The foregoing detailed description has illustrated various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. To the extent that such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, it will be understood by those skilled in the art that each function and / or operation within such block diagrams, flowcharts, or examples may be individually and / or collectively implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In one embodiment, some portions of the subject matter described herein may be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), and / or other integrated forms. However, those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may equivalently be implemented, in whole or in part, in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is within the skill of those skilled in the art in light of this disclosure. Furthermore, those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as program products in various forms, and that exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution.Examples of signal bearing media include, but are not limited to, recordable-type media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission-type media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0281] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering techniques to integrate such described devices and / or processes into a data processing system, i.e., at least a portion of the devices and / or processes described herein may be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing, a video display device, memory such as volatile and non-volatile memory, a processor such as a microprocessor and a digital signal processor, computational entities such as an operating system, drivers, a graphical user interface and application programs, one or more interaction devices such as a touchpad or screen, and / or a control system such as feedback loops and control motors (e.g., feedback that senses position and / or velocity, control motors that move and / or adjust components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components such as those typically found in data computing / communications systems and / or network computing / communications systems.

[0282] The subject matter described herein may depict different components contained within or connected to different other components. It should be understood that such illustrated architectures are merely examples, and that in fact many other architectures may be implemented that achieve the same functionality. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Thus, any two components herein that combine to achieve a particular function may be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated may also be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components so associated may also be considered to be “operably coupleable” to each other to achieve the desired functionality. Examples of operably coupleable include, but are not limited to, components that are physically matable and / or physically interacting, and / or components that are wirelessly interacting and / or wirelessly interacting, and / or components that logically interact and / or logically interacting.

[0283] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for purposes of clarity.

[0284] In general, those skilled in the art will understand that terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including, but not limited to," the term "having" should be interpreted as "having at least," and the term "comprises" should be interpreted as "including, but not limited to"). Furthermore, where a specific number of recitations of an introduced claim are intended, such intention will be explicitly set forth in the claim; in the absence of such recitation, those skilled in the art will understand that no such intention exists. For example, where only one item is intended, the term "single" or similar language may be used. To assist in understanding, the following appended claims and / or description of this specification may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as meaning that the introduction of a claim recitation by the indefinite article "a" or "an" limits any particular claim containing such an introduced claim recitation to embodiments containing only one such recitation, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Furthermore, those skilled in the art will recognize that even when a specific number of recitations of an introduced claim are explicitly recited, such recitation should be interpreted to mean at least the recited number (e.g., the simple recitation "two recitations" without other modifiers means at least two recitations, or more than two recitations).Furthermore, when notation similar to "at least one of A, B, and C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). When notation similar to "at least one of A, B, or C" is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). Those skilled in the art will further appreciate that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibilities of "A" or "B" or "A and B." Furthermore, as used herein, the term "any of," followed by a list of items and / or a list of categories of items, is intended to include "any of," "any combination of," "any plurality of," and / or "any combination of" of the items and / or categories of items, individually or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "plurality."

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

[0286] As will be understood by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein encompass any possible subranges and combinations of subranges. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range described herein can be easily broken down into a lower third, middle third, upper third, etc. Additionally, as will be understood by those skilled in the art, all terms such as "up to," "at least," "greater than," "less than," etc., refer to ranges that are inclusive of the recited number and that can be further broken down into subranges as described above. Finally, as will be understood by those skilled in the art, ranges include each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

[0287] Furthermore, the claims should not be read as limited to the provided order or to the provided elements unless specifically so stated. Furthermore, the use of the term "means for" in any claim is intended to invoke 35 U.S.C. 112, paragraph 6, or means-plus-function claim format, and any claim without the term "means for" is not so intended.

Claims

1. a first wireless transmit / receive unit (WTRU) for a sidelink with a second WTRU, the first WTRU comprising circuitry including a transmitter, a receiver, a processor, and a memory; receiving sidelink control information from the second WTRU, the sidelink control information including: (1) first information indicating at least first transmission resources reserved for an initial transmission; and (2) second information indicating whether at least one second transmission resource is reserved for a sidelink retransmission of the initial transmission; determining a timer value of a Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) timer associated with a sidelink process, the timer value is determined to be a first value on condition that HARQ feedback is enabled for the associated sidelink process; and determining the timer value to be a second value on condition that the HARQ feedback is disabled for the associated sidelink process; starting the HARQ RTT timer associated with the sidelink process, starting the HARQ RTT timer in a first timeslot on condition that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission; starting the HARQ RTT timer in a second timeslot, on condition that the second information indicates that a second transmission resource is not reserved for the sidelink retransmission; a first WTRU configured to:

2. The first WTRU of claim 1 , further configured to receive network configuration information indicating the first value and the second value.

3. The first WTRU of claim 1 , wherein the first time slot follows transmission of the HARQ feedback, provided that the HARQ feedback is valid for the associated sidelink process.

4. 2. The first WTRU of claim 1, wherein the second timeslot follows the at least one first transmission resource, provided that the HARQ feedback is disabled for the associated sidelink process and provided that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission.

5. 2. The first WTRU of claim 1, wherein the second timeslot follows resources reserved for transmission of the HARQ feedback, provided that the HARQ feedback is disabled for the associated sidelink process and provided that the second information indicates that second transmission resources are not reserved for the sidelink retransmission.

6. The first WTRU of claim 1 , wherein the HARQ RTT timer is started at a predetermined time point, a first time point indicated in the sidelink control information, or a second time point based on a sidelink cast type.

7. The first WTRU of claim 1 , configured to send the sidelink retransmission after expiration of the HARQ RTT timer.

8. The sidelink control information further indicates an expected packet delay budget (PDB), and the first information further indicates a priority associated with the first transmission resource, and the WTRU: determining a maximum PDB based on the priority associated with the first transmission resource; starting the HARQ RTT timer on the condition that the expected PDB is less than the determined maximum PDB; The first WTRU of claim 1 further configured to:

9. 1. A method implemented by a first wireless transmit / receive unit (WTRU) for a sidelink with a second WTRU, comprising: receiving sidelink control information from the second WTRU, the sidelink control information including: (1) first information indicating at least first transmission resources reserved for an initial transmission; and (2) second information indicating whether at least one second transmission resource is reserved for a sidelink retransmission of the initial transmission; determining a timer value of a Hybrid Automatic Repeat Request (HARQ) Round Trip Time (RTT) timer associated with a sidelink process, the timer value is determined to be a first value on condition that HARQ feedback is enabled for the associated sidelink process; and determining the timer value to be a second value on condition that the HARQ feedback is disabled for the associated sidelink process. starting the HARQ RTT timer associated with the sidelink process, starting the HARQ RTT timer in a first timeslot on condition that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission; starting the HARQ RTT timer in a second timeslot, on condition that the second information indicates that a second transmission resource is not reserved for the sidelink retransmission; A method comprising:

10. The method of claim 9 , further comprising receiving network configuration information indicative of the first value and the second value.

11. 10. The method of claim 9, wherein the first timeslot follows transmission of the HARQ feedback, provided that the HARQ feedback is valid for the associated sidelink process.

12. 10. The method of claim 9, wherein the second timeslot follows the at least first transmission resource, provided that the HARQ feedback is disabled for the associated sidelink process and provided that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission.

13. 10. The method of claim 9, wherein the second timeslot follows resources reserved for transmission of the HARQ feedback, provided that the HARQ feedback is disabled for the associated sidelink process and provided that the second information indicates that second transmission resources are not reserved for the sidelink retransmission.

14. 10. The method of claim 9, wherein the HARQ RTT timer is started at a predetermined time, a first time indicated in the sidelink control information, or a second time based on a sidelink cast type.

15. the sidelink control information further indicates an expected packet delay budget (PDB); and the first information further indicates a priority associated with the first transmission resource. determining a maximum PDB based on the priority associated with the first transmission resource; starting the HARQ RTT timer on the condition that the expected PDB is less than the determined maximum PDB; 10. The method of claim 9 further comprising:

Images