Method, architecture, apparatus, and system for performing discontinuous reception on a sidelink

Abstract

The present disclosure relates to a method and apparatus for performing discontinuous reception using V2X extensions. In one embodiment, a method implemented by a first WTRU for device-to-device (D2D) communication between a first WTRU and a second WTRU, the method may include any of: receiving D2D control information from the second WTRU, the D2D control information including: (1) first information indicating one or more first transmission resources reserved for transmission of the D2D communication; and (2) second information indicating whether at least one second transmission resource is reserved for retransmission of the D2D communication; determining a sleep period for the first WTRU that ends prior to a reception time of the retransmission of the D2D communication, the sleep period being based on the second information; and receiving the retransmission of the D2D communication after the expiration of the determined sleep period.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of (i) U.S. Provisional Patent Application No. 63 / 159,792, filed Mar. 11, 2021, and (ii) U.S. Provisional Patent Application No. 63 / 185,747, filed May 7, 2021, each of which is incorporated herein by reference.

[0002] Embodiments disclosed herein generally relate to wireless communications, for example, methods, apparatuses, and systems for performing discontinuous reception (DRX) using vehicle - to - everything (V2X) extensions.

Background Art

[0003] The 5G specifications include provisions for DRX to conserve energy in a WTRU. The main purpose of DRX is to reduce battery consumption when there is no uplink or downlink data to be processed by a wireless transmit / receive unit (WTRU), e.g., when there is none. Thus, 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 on to process messages.

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

[0005] V2X communication is supported in Release 14 LTE and is inspired by previous research on device-to-device (D2D) communication. V2X communication services can consist of the following four different types. (i) V2V (Vehicle to Vehicle): Vehicle WTRUs can communicate directly with each other. (ii) V2I (Vehicle to Infrastructure): Vehicle WTRUs can communicate with roadside units / eNode Bs (RSUs / eNBs). (iii) V2N (Vehicle to Network): Vehicle WTRUs can communicate with the core network. (iv) V2P (Vehicle to Pedestrian): Vehicle WTRUs can communicate with WTRUs having special conditions such as low battery capacity.

Brief Description of the Drawings

[0006] A more detailed understanding can be provided from the following detailed description in conjunction with the accompanying drawings by way of example. The diagrams of such drawings, like the detailed description, are examples. Therefore, the drawings and the detailed description should not be considered limiting, and other equally effective examples are possible and likely. Further, similar reference numerals (''references'') in the figures indicate similar elements.

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4A

Figure 4B

Figure 4C

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

[0007] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Further, embodiments and examples not specifically described herein may be practiced in lieu of, or in combination with, the embodiments and other examples explicitly, implicitly, and / or inherently (collectively "provided") described, disclosed, or otherwise provided herein. In this specification, various embodiments are described and / or claimed in which an apparatus, system, device, etc. and / or any element thereof performs various operations, processes, algorithms, functions, etc. and / or any part thereof, but it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, system, device, etc. and / or any element thereof is configured to perform any operation, process, algorithm, function, etc. and / or any part thereof.

[0008] Exemplary Communication System The methods, apparatuses, 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 FIGS. 1A-1D. In FIGS. 1A-1D, various elements of the network can utilize, execute, be arranged in accordance with, and / or be adapted and / or configured for the methods, apparatuses, and systems provided herein.

[0009] FIG. 1A is a system diagram showing an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 can be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to a plurality of wireless users. The communication system 100 can enable a plurality of wireless users to access the above-described content through sharing of system resources including wireless bandwidth. For example, the communication system 100 can 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 filter type OFDM, filter bank multicarrier (FBMC), etc.

[0010] As shown in Figure 1A, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106 / 115, a 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 the WTRUs 102a, 102b, 102c, 102d can 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, each of which can also be referred to as a "station" and / or "STA", can be configured to transmit and / or receive wireless signals and can be a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular 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., a robot and / or other wireless devices operating in an industrial and / or automated processing chain scenario), a home electronic device, a device operating in a commercial and / or industrial wireless network, etc. (or be any of these). Any of the WTRUs 102a, 102b, 102c, and 102d can also be referred to interchangeably as a UE.

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

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

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

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

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

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

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

[0018] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement wireless technologies 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), etc.

[0019] The base station 114b in Fig. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connection in a local area such as, for example, an office, a home, a vehicle, a campus, an industrial facility, an aerial corridor (for use by drones, for example), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a wireless 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 can implement a wireless 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 can utilize a cellular-based RAT (such as, for example, WCDMA, CDMA 2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of a small cell, a pico cell, or a femto cell. As shown in Fig. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0020] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data can have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that employ the same RAT or a different RAT as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize NR radio technology, 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 technology.

[0021] CN 106 / 115 can also function 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 that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include wired and / or wireless communication networks that are owned and / or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT or a different RAT as the RAN 104 / 114.

[0022] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multimode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via 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 cellular-based wireless technology and a base station 114b that may use IEEE 802 wireless technology.

[0023] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 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, a non-removable memory 130, a removable memory 132, a power supply 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 partial combination of the foregoing elements while remaining consistent with one embodiment.

[0024] The processor 118 can be a general-purpose processor, a dedicated 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 can 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 can be coupled to a transceiver 120 that can be coupled to a transmit / receive element 122. Although Figure 1B shows 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, for example, in an electronic package or a chip.

[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) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical 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] Although the transmit / receive element 122 is shown in FIG. 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 via 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 described 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, for example, NR and IEEE 802.11.

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

[0029] The processor 118 can receive power from the power supply 134, and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 can include one or more dry cells (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), a solar cell, a fuel cell, 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 a base station (e.g., base stations 114a, 114b) via the air interface 116 and / or may determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by any suitable positioning method while remaining consistent with one 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 connections. For example, the element / peripheral 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 element / peripheral 138 may include one or more sensors, and the sensors may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0032] The WTRU 102 may include a full-duplex radio in which transmission and reception of some or all of the signals (associated with a particular subframe for both, e.g., an uplink (e.g., for transmission) and a downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., via a separate processor (not shown) or the 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 (associated with a particular subframe for either, e.g., an uplink (e.g., for transmission) or a downlink (e.g., for reception)).

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

[0034] The RAN 104 may include eNodeBs 160a, 160b, 160c, although it will be understood that the RAN 104 may include any number of eNodeBs while remaining consistent with one embodiment. Each of the eNodeBs 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c via the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a may transmit a wireless signal to the WTRU 102a and receive a wireless signal from the WTRU 102a, for example, using a plurality of antennas.

[0035] Each of the eNodeBs 160a, 160b, and 160c is associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, the eNodeBs 160a, 160b, and 160c may communicate with each other via the X2 interface.

[0036] The CN 106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although 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 within the RAN 104 via the S1 interface and may function as a control node. For example, the MME 162 may authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for switching between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM and / or WCDMA.

[0038] The SGW 164 can be connected to each of the eNodeBs 160a, 160b, 160c within the RAN 104 via the S1 interface. The SGW 164 can generally route and transfer user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can perform other functions such as fixing the user plane during handover between eNodeBs, triggering paging when DL data is available to the WTRUs 102a, 102b, 102c, and managing and storing the contexts of the WTRUs 102a, 102b, 102c.

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

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

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

[0042] In an exemplary embodiment, the other network 112 can be a WLAN.

[0043] A WLAN in infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can have an access or interface to 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 an STA can reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS can be sent to the AP and then to their respective destinations. Traffic between STAs within the BSS can be sent, for example, through the AP, where the source STA can send the traffic to the AP and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent in a direct link setup (DLS) between the source STA and the destination STA (e.g., directly between them). In certain exemplary embodiments, the DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) can communicate directly with each other. The IBSS communication mode may also be referred to herein as the "ad hoc" communication mode.

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

[0045] A High Throughput (HT) STA can use a 40 MHz wide channel for communication, for example, via a combination of a primary 20 MHz channel and an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0046] A very high throughput (VHT) STA may support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. The above-mentioned 40 MHz and / or 80 MHz wide channels may be formed by combining adjacent 20 MHz channels. A 160 MHz channel may be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels, which may be referred to as an 80+80 configuration. In the case of the 80+80 configuration, after channel encoding, the data may pass through a segment parser that may split the data into two streams. The inverse fast Fourier transform (IFFT) process and time domain processing may be performed separately for 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 above-described operations for the 80+80 configuration are reversed, and the combined data may be transmitted to the media access control (MAC) layer, entity, etc.

[0047] The sub-1 GHz operation mode is supported by 802.11af and 802.11ah. The channel operating bandwidth 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, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication (MTC) such as MTC devices in a macro coverage area. The MTC device may have specific capabilities, including, for example, support for a specific and / or limited bandwidth (e.g., support only for that). The MTC device may include a battery having a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0048] A WLAN system that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operating mode. In the example of 802.11ah, the primary channel can be 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only that) even when 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) setting may depend on the state of the primary channel. For example, if the primary channel is busy due to an STA transmitting to the AP (supporting only the 1 MHz operating mode), the entire available frequency band may be considered busy even if most of the frequency band remains idle and available.

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

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

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

[0052] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with an extensible numerology. For example, the OFDM symbol interval and / or the OFDM subcarrier interval can be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or extensible lengths (e.g., including various numbers of OFDM symbols and / or continuously varying times of various lengths of absolute time).

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

[0054] Each of gNBs 180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, 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, gNBs 180a, 180b, and 180c may communicate with each other via the Xn interface.

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

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

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

[0058] UPF 184a and 184b can be connected to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface, which can provide access to a packet-switched network such as the Internet 110 for WTRU 102a, 102b, and 102c, for example, to facilitate communication between WTRU 102a, 102b, and 102c and IP-compatible devices. UPF184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0060] In view of FIGS. 1A-1D and the corresponding descriptions 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 can be performed by one or more emulation elements / devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functionality.

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

[0062] One or more emulation devices can perform one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by an emulation device 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 use the same or different principles, for example, that may be applicable.

[0064] As described herein, a WTRU can be taken as an example of a UE. Therefore, the terms UE and WTRU can be used interchangeably herein.

[0065] As used herein, the term WTRU is further used as a generic term to identify a device on which one or more V2X applications are being executed. A V2X application server (V2X AS) can be located within a network and can interface with the V2X applications installed on the WTRU. A V2X control function (CF) can handle the authentication and provisioning of V2X devices. This can include, for example, V2X policies and / or parameter settings for the WTRU. The V2X CF function can be processed in the PCF. V2X WTRU-to-WTRU communication can be based on two operating modes, namely, an operating mode via the Uu reference point and an operating mode via the PC5 reference point.

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

[0067] Figure 2 shows a non-roaming 5G system architecture for PC5 and Uu-based V2X communication. As can be seen in Figure 2, some examples of the V2X WTRU 102 can be vehicle WTRUs (WTRU 102b and WTRU 102c) or pedestrian WTRUs (WTRU 102a). V2X communication may occur between two pedestrian WTRUs. V2X communication 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). Communication between WTRU 102b or 102c (vehicle) and WTRU 102a (pedestrian) may be referred to as V2P communication, and communication between WTRU 102b (vehicle) and WTRU 102c (vehicle) may be referred to as V2V communication. As shown in Figure 2, both V2V communication and V2P communication can be performed via the PC5 interface, and characteristics such as the message frequency and power of V2V communication may be different from those of V2P type communication.

[0068] Referring to FIG. 2, the V2X communication network 200 can include a DN 185 that executes / runs one or more V2X applications, a first vehicle (e.g., vehicle WTRU 102b) that executes one or more V2X applications, a second vehicle (e.g., vehicle WTRU 102c) that executes one or more V2X applications, a pedestrian (e.g., pedestrian / V2P WTRU 102a) that executes one or more V2X applications, a stationary / fixed device (e.g., stationary WTRU 102d) that executes one or more V2X applications, an NG-RAN 104, and a CN 106. The CN 106 can include an AMF 182, an SMF 183, a UPF 184, a DN 185, a unified data management (UDM) 186 that 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 WTRU 102 (e.g., vehicle WTRU 102b, vehicle WTRU 102c, pedestrian WTRU 102a, and / or stationary WTRU 102d) can communicate using a PC5 interface (e.g., PC5 communication). The V2X applications executed on the WTRU 102 (e.g., vehicle WTRU 102b, vehicle WTRU 102c, pedestrian WTRU 102a, and / or stationary WTRU 102d) can communicate using a V5 interface. The vehicle WTRU 102b and the stationary WTRU 102d can communicate with the NG-RAN 104 using a Uu interface. The NG-RAN 104 can communicate with the AMF 182 of the CN 106 using an N2 interface and communicate with the UPF 184 of the CN 106 using an N3 interface. The DN 185 can be internal to the CN 106 or may interface with the NG-RAN 104 using an N6 interface.UPF184 and SMF can communicate using the N4 interface.

[0069] The V2P WTRU102a that supports the V2P application sends a message containing V2P application information. The V2P application information can be sent by a WTRU that supports the vehicle's V2X application, such as a warning to a pedestrian, or by a WTRU that supports a V2X application associated with a vulnerable road user, such as a warning to a vehicle. The 3GPP transport of the message containing V2P application information can include direct transport between WTRU102s and / or transport between WTRU102s via an infrastructure that supports V2X communication (e.g., RSU, application server, etc.) because the direct communication range is limited, for example. As described herein and based on the architecture of FIG. 2, the vehicle-type WTRU102b / 102c and the pedestrian-type WTRU102a can be supported by V2X. Other functions specific to the pedestrian-type WTRU102a carried by a pedestrian user, cyclist, etc. can also be supported by V2X. A special resource selection mechanism (e.g., partial sensing or random selection) for the pedestrian-type WTRU102a can be utilized in PC5 communication. Generally, there is no optimization for the pedestrian-type WTRU102a, which has limitations regarding power and computation compared to the vehicle WTRU102b / 102c. It is desirable to support V2X utilization by vulnerable road users (VRUs) and thus provide extensions regarding related aspects (e.g., power saving, etc.).

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

[0071] In LTE, the resource pools are semi-statically signaled to the WTRU via radio resource control (RRC) signaling. In Mode 4, the WTRU uses sensing before selecting resources from a transmission pool configured by the RRC. LTE V2X does not support dynamic reconfiguration of resource pools. The pool configuration can be communicated (e.g., only via) via system information block (SIB) and / or dedicated RRC signaling. As used herein with respect to NR V2X using DRX, a resource pool can include a set of resources used in V2X communication. A reception (RX) resource pool defines the resources that the WTRU should monitor. A transmission (TX) resource pool defines the resources that the WTRU can use for transmission. Not all sidelink resources are available 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 wireless system called NR. The NR system is expected to support many use cases, such as enhanced Mobile Broadband (eMBB) and / or ultra-high reliability and / or low latency communications (URLLC).

[0073] 3GPP can support extended V2X (eV2X) communication in the NR system. 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 require different performance requirements and / or a latency of 3 ms may be required for some scenarios.

[0074] NR V2X can support two operation modes, namely 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 the received resource reservation to SL transmission. Mode 2 can use LTE Mode 4 as the baseline for semi-persistent scheduling. In Mode 4, the WTRU can autonomously select and / or reserve resources from a set resource pool. In one example, the set resource pool can be a pre-configured resource pool. Autonomous resource reservation can be based on WTRU sensing to identify available candidate resources.

[0075] New Use Cases of NR V2X NR V2X is expected to support new use cases as defined in the 3GPP standard. In particular, the following use cases are planned to be supported.

[0076] Platoon driving. Platoon driving enables vehicles to dynamically form a group that travels together. All vehicles within the platoon receive periodic data from the leading vehicle in order to continue the platoon operation. With this information, the distance between vehicles can be made very small, for example, the gap distance in terms of time can be made very small (less than 1 second). In a platoon driving application, the following vehicles can be autonomously driven.

[0077] Advanced driving. Advanced driving enables semi-autonomous or fully autonomous driving. A longer inter-vehicle distance is assumed. Each vehicle and / or RSU shares the data obtained from its local sensors with nearby vehicles, so that the vehicle can adjust its trajectory or steering. Furthermore, each vehicle shares its driving intention with nearby vehicles. The advantages of this use case group are safer driving, collision avoidance, and / or improved 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 the surrounding environment beyond the range detectable by their own sensors and / or gain a more comprehensive understanding of the local situation.

[0079] Remote driving. Remote driving enables a remote driver or a V2X application to operate a remote vehicle for passengers who are unable to drive themselves or for vehicles in a dangerous environment. In cases where there are limited variations and / or predictable routes, such as in public transportation, cloud computing-based driving can be used. Additionally, access to a cloud-based backend service platform can also be considered in this use case group.

[0080] QoS in NR V2X In 3GPP, a QoS model for NR V2X is used. In Release 14 V2X documented in TS 23.285, QoS on PC5 is supported using ProSe per-packet priority (PPPP). The application layer can mark packets with a PPP indicating the required QoS level. For example, specific extensions were added to enable derivation of the packet delay budget (PDB) from the PPP.

[0081] The new QoS requirements in NR V2X are described, for example, in TS 22.186. The new key performance indicators (KPIs) are specified using the following parameters. - Payload (bytes), - Transmission speed (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. These QoS characteristics can be well represented 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. For example, by also using 5QI for V2X communication via PC5, the application layer can indicate QoS requirements in a consistent manner regardless of the link used.

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

[0085] In the case of broadcast traffic, there is no bearer concept. Therefore, each message may have different characteristics according to the requirements of the application. In that case, 5QI needs to be used in a similar way to PPP / ProSe packet unit reliability (PPPR), for example, tagging each of the packets. 5QI can represent all the characteristics (such as latency, priority, reliability, etc.) required for PC5 broadcast operation. A group of 5QI specific to V2X broadcast (for example, VQI) can be defined for the use of PC5.

[0086] PC5 QoS parameters are negotiated during the establishment of the one-to-one communication procedure. Therefore, for example, the one-to-one communication establishment procedure defined in TS 23.303 is extended to support the 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 (such as 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 (for example, WTRU-1) sends a direct communication request message to UE-2 (for example, WTRU-2) to trigger mutual authentication. This message includes the required PC5 QoS parameters. In Message 2, UE-2 (for example, WTRU-2) starts the mutual authentication procedure. UE-2 (for example, WTRU-2) includes the received PC5 QoS parameters in the response message.

[0088] DRX in NR Uu Connected mode DRX is specified for power saving in NR Uu for WTRUs in the RRC_CONNECTED state. DRX is based on a configured schedule of wake-up times in the WTRU. When the WTRU receives physical downlink control channel (PDCCH) scheduling during a wake-up time, it remains in an awake state for a certain period until no further scheduling is received. The WTRU can be configured with any of the following exemplary parameters. -drx-onDurationTimer: The duration at the start of a DRX cycle, -drx-SlotOffset: The delay before starting drx-onDurationTimer, -drx-InactivityTimer: The duration after a PDCCH indicating a new UL or DL transmission for the MAC entity until a PDCCH opportunity, -drx-RetransmissionTimerDL (per DL hybrid automatic repeat request (HARQ) process except for broadcast processes): The maximum duration until receiving a DL retransmission, -drx-RetransmissionTimerUL (per UL HARQ process): The maximum duration until receiving a grant for UL retransmission, -drx-LongCycleStartOffset: Defines the subframe in which the long DRX cycle and / or drx-StartOffset start the long DRX cycle and short DRX cycle, -drx-ShortCycle (optional): The short DRX cycle, -drx-ShortCycleTimer (optional): The duration for which the WTRU follows the short DRX cycle, -drx-HARQ-RTT-TimerDL (per DL HARQ process except for broadcast processes): The minimum duration before 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 WTRU with DRX configured determines its active time (the time during which the WTRU actively monitors the PDCCH) based on either of the following. When a DRX cycle is configured (e.g., at configuration time), the active time includes the following times. - The drx-onDurationTimer or drx-InactivityTimer or drx-RetransmissionTimerDL or drx-RetransmissionTimerUL or ra-ContentionResolutionTimer (as described in Section 5.1.5 of Release 14) is running. Or - A scheduling request is transmitted and pending on the physical uplink control channel (PUCCH) (as described in Section 5.4.4 of Release 14). And / or - After successfully receiving a random access response for a preamble not selected by the MAC entity (as described in Section 5.1.4 of Release 14), no PDCCH indicating a new transmission addressed to the cell radio network temporary identifier (C-RNTI) of the MAC entity has been received.

[0090] Partial sensing and / or random selection in LTE V2X Another power saving mechanism introduced in LTE V2X (used in pedestrian WTRUs) was the partial sensing mode. When using partial sensing, the upper layer can configure the WTRU to set the minimum number of candidate subframes within the resource selection window [T1, T2], and a specific subframe is selected by the WTRU implementation. The WTRU can perform sensing on the subframes within the sensing window, which is an integral number of reservation periods from the candidate subframes (e.g., only for the subframes), thus reducing the amount of resources that the WTRU needs to sense within the sensing window.

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

[0092] In SL communication, there are several differences from Uu scheduling, which can cause problems in the approach of the DRX concept implemented by Uu. - For retransmissions, an indication based on signaling control information (SCI) is used. Specifically, in SL, one SCI can indicate the resources for additional transmissions and / or further retransmissions in the HARQ process, and the transmissions and / or retransmissions may not be temporally continuous. When executing the HARQ RTT timer and / or the retransmission timer, such an indication from the SCI can be taken into account (e.g., needs to be taken into account). - HARQ can be either active or inactive in transmission, in which case the timeline of HARQ feedback is different. In the case of a transmission where HARQ is active, the RX WTRU (e.g., WTRU 102) can transmit a physical sidelink feedback channel (PSFCH) (similar to Uu). In the case of a transmission where HARQ is inactive, the RX WTRU (e.g., WTRU 102) cannot transmit HARQ feedback on the PSFCH. This can affect the definition of the timer for the HARQ process. - Specifically, in Uu, the HARQ RTT can start at the last symbol / slot of the transmission that conveys the DL HARQ feedback. However, in the sidelink, the WTRU may not be able to transmit the PSFCH (e.g., always) for various reasons (such as HARQ inactivity, UL / SL prioritization). - The minimum micro-sleep / DRX time can be different depending on whether Mode 1 or Mode 2 is used. - The SCI can indicate the scheduled retransmission time in the HARQ process, but events in the TX WTRU (e.g., WTRU 102) can cause changes to these times. Specifically, the TX WTRU (e.g., WTRU 102) can perform preemption of the retransmission resources, for example, due to transmission by a higher-priority WTRU. Specifically, the TX WTRU (e.g., WTRU 102) can perform reselection, for example, due to UL being prioritized higher than SL. Specifically, the TX WTRU (e.g., WTRU 102) may not be able to immediately indicate (e.g., transmit a signal indicating) all retransmission resources in the SCI (due to, for example, the channel busy ratio (CBR)).

[0093] Method for the sidelink DRX timer 1. Method for defining the active time for SL retransmission (For example, a TX or RX) WTRU can have a mechanism for determining the period of micro-sleep / DRX following a transmission or retransmission, for example, with respect to a HARQ process, which depends on the SL characteristics. This can be modeled to use a HARQ RTT timer (similar to Uu), whereby the start of such a timer represents the start of a potential micro-sleep / DRX opportunity (whereby the WTRU does not monitor the PSCCH in operation (assuming, for example, not being executed) when other timers defining activity (such as an inactivity timer, retransmission timer, etc.) are not being executed). The HARQ RTT timer can be set for each SL HARQ process. The micro-sleep / DRX opportunity can end when the HARQ RTT timer expires and / or when a retransmission timer (or a similar timer representing activity) is started (for example, at such a time). Alternatively, the WTRU can be set with an explicit period or set of resources for micro-sleep / DRX (such as a set of slots for an SL event), and / or an explicit period or set of resources that should be active for each SL HARQ process (such as a set of slots for an SL event). Each of the following embodiments can be applicable to any of the options. Further, "HARQ RTT timer" and / or "HARQ RTT time" are used interchangeably to represent the micro-sleep / DRX time of the HARQ process, regardless of whether this time is explicitly implemented using a timer (as in Uu). Further, the HARQ RTT time / timer refers to the SL HARQ RTT timer in the present disclosure.

[0094] 1.1 Determination of the start time of the HARQ RTT timer The RX WTRU (for example, WTRU 102) can start the HARQ RTT timer at a certain point in time (for example, a subsequent slot, or a number of subsequent specified slots) based on any of the following. - Receiving the SCI and / or data of that HARQ process, - When decoding the MAC PDU associated with the HARQ process, - For example, at the time of the scheduled retransmission by the TX WTRU (e.g., WTRU102) as indicated in the previous SCI, or after the retransmission, - Determining the decoding result (ACK or NACK) associated with the reception, - Transmitting the HARQ feedback associated with the received data, - The time set (in advance) or the time defined in advance following the reception of the SCI and / or data of that HARQ process, ○ Such a time set (in advance) or the time defined in advance can be defined, for example, based on the minimum WTRU capabilities, and / or - Do not start the HARQ RTT timer at all, and / or, for example, directly start the retransmission timer of the HARQ process.

[0095] a) The RX WTRU (e.g., WTRU102) can determine to start the HARQ-RTT at different times according to the characteristics of the SL (For example, the (RX) WTRU (e.g., WTRU102)) can determine the timing to start the HARQ RTT (timer) to be different according to the characteristics or conditions of the SL. Specifically, (for example, the (RX) WTRU (e.g., WTRU102)) can start the HARQ RTT timer at a certain point in time under the first characteristic / condition, and / or can start the HARQ RTT timer at another point in time under the second characteristic / condition, and the point in time can be any of those shown above. The conditions can be related to any of the following. - Whether the SL HARQ feedback is valid / invalid for a specific transmission / retransmission of the HARQ process, - The cast type associated with the transmission: ○ For example, (e.g., RX) WTRU (e.g., WTRU102) can start the HARQ RTT timer at a first time point when the transmission is associated with unicast (e.g., when associated), and / or can start the HARQ RTT timer at a second time point when the transmission is associated with multicast (e.g., when associated). - QoS related parameters associated with the transmission (e.g., priority, MCR): ○ For example, (e.g., RX) WTRU (e.g., WTRU102) can start the HARQ RTT timer at a first time point when the priority associated with the transmission exceeds a threshold, and / or can start it at a second time point if not. - Value of CBR: ○ For example, (e.g., RX) WTRU (e.g., WTRU102) can start the HARQ RTT timer at a first time point when the measured CBR exceeds a threshold, and / or can start it at a second time point if not, and / or - Instructions / information by the peer WTRU as described herein: ○ For example, (e.g., RX) WTRU (e.g., WTRU102) can receive a DRX mode instruction or other information related to DRX in PC5 - RRC (e.g., semi - statically) or in SCI / MAC CE (dynamically), and / or can change the start time of the HARQ RTT timer based on this information. ○ For example, (e.g., RX) WTRU (e.g., WTRU102) can receive DRX modes for different transmission types (e.g., the SL characteristics described above), and / or can apply the HARQ RTT start times for each transmission type indicated by the peer WTRU.

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

[0097] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can determine whether hybrid automatic repeat request (HARQ) is effective or ineffective for a received protocol data unit (PDU). The (e.g., RX) WTRU (e.g., WTRU 102) can determine a HARQ round-trip time (RTT) start point according to the HARQ effective / ineffective property of the received PDU. When HARQ is effective, the (e.g., RX) WTRU (e.g., WTRU 102) can start a HARQ RTT timer in the first symbol / slot following the transmission of a physical shared feedback channel (PSFCH) including HARQ feedback for the transmission. When HARQ is ineffective, the (e.g., RX) WTRU (e.g., WTRU 102) can start the HARQ RTT timer in the first symbol / slot following the reception of a scheduling control information (SCI), or in the first symbol / slot following the reception of a physical shared data channel (PSSCH) corresponding to the received PDU of the HARQ process. According to an embodiment, the (e.g., RX) WTRU (e.g., WTRU 102) can, in this case, start the HARQ RTT timer at a predefined time following the reception of the SCI, such a predefined time corresponding to the minimum requirements defined for the (e.g., RX) WTRU (e.g., WTRU 102). The (e.g., RX) WTRU (e.g., WTRU 102) can further use different values of the HARQ RTT timer in each of the two scenarios. The start time of the HARQ RTT can correspond to any of the times described above.

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

[0099] b) A (e.g., RX) WTRU (e.g., WTRU 102) can start a HARQ-RTT timer (or similar) when performing UL / SL transmission on a PSFCH slot (e.g., at the time of execution). According to an embodiment, for example, when a (e.g., TX) WTRU (e.g., WTRU 102) can transmit (e.g., is expected to transmit) on a PSFCH, if the (e.g., TX) WTRU (e.g., WTRU 102) performs a transmission (UL transmission or SL transmission), the (e.g., RX) WTRU (e.g., WTRU 102) can start a HARQ - RTT associated with a HARQ process for reception. For example, if the (e.g., TX) WTRU (e.g., WTRU 102) gives priority to UL transmission over SL transmission of HARQ feedback on the PSFCH (e.g., skips PSFCH transmission), the (e.g., RX) WTRU (e.g., WTRU 102) can start a HARQ RTT timer of a HARQ process for which HARQ feedback was to be transmitted on the skipped PSFCH. The (e.g., RX) WTRU (e.g., WTRU 102) can start a HARQ RTT timer in any of the following cases. - The symbol / slot following the (last) symbol / slot of the PSFCH, - The symbol / slot following the last symbol / slot of a UL / SL transmission prioritized over PSFCH transmission, and / or - The symbol / slot following the symbol / slot in which the (e.g., TX) WTRU (e.g., WTRU 102) received a UL grant for UL transmission.

[0100] 1.2 Determination of the start time of the retransmission timer a) Different times for starting a retransmission timer of an SL HARQ process can be set for the RX WTRU (e.g., WTRU 102) (For example, the RX) WTRU (e.g., WTRU 102) can start a retransmission timer of an SL HARQ process at different times according to the characteristics of the SL. (For example, the RX) WTRU (e.g., WTRU 102) can select any of the following times to start a retransmission timer following a (failed) reception of a HARQ process. - After the HARQ RTT time (timer) expires (e.g., at expiration), - At the time resources indicated in the SCI transmitted with the (failed) reception, or at some time before that, - The slot (or some subsequent slots) following the slot indicated in the SCI transmitted with the (failed) reception, - At the last retransmission resource received in the SCI of a specific HARQ process, at some time before that, or at some time after that, and / or - Do not start the retransmission timer at all.

[0101] b) [The RX WTRU (e.g., WTRU 102) determines whether and / or when to start the HARQ process retransmission timer based on the SCI.] The RX WTRU (e.g., WTRU 102) can set the retransmission timer for a specific first transmission / retransmission of a HARQ process. According to an embodiment, the RX WTRU (e.g., WTRU 102) can determine whether and / or the start time of the retransmission timer based on any of the following (from among those shown above). - Whether the received SCI of the HARQ process indicates a retransmission resource. ○ For example, (e.g., RX) WTRU (e.g., WTRU 102) can start the retransmission timer (e.g., after some HARQ RTT time) when the SCI does not reserve resources for subsequent retransmissions (e.g., when it does not reserve). When the SCI reserves resources for subsequent retransmissions, (e.g., RX) WTRU (e.g., WTRU 102) may not start the retransmission timer following the reception of the current SCI (it can start the retransmission timer after the reception of subsequent SCI of the same HARQ process (e.g., only after reception)). - Whether the (e.g., RX) WTRU (e.g., WTRU 102) expects additional retransmission resources (following the currently received transmission / retransmission resources) of a specific HARQ process. ○ For example, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., after some HARQ RTT time) if the current SCI / data reception of a particular HARQ process corresponds to the last (e.g., expected) retransmission of the HARQ process reserved using the retransmission resources indicated in the SCI (e.g.). 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) can determine 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 can start a HARQ RTT timer at the time described herein. Alternatively, if the SCI does not indicate additional retransmission resources, the UE may not start a HARQ RTT timer for the HARQ process. - Whether the (e.g., RX) WTRU (e.g., WTRU 102) has successfully received the SCI at the reserved time indicated by a previous SCI of the same HARQ process. ○ For example, if a (e.g., RX) WTRU (e.g., WTRU102) does not decode an SCI in a slot where retransmission is expected (e.g., RX) WTRU (e.g., WTRU102) can start a retransmission timer in a slot following the point in time indicated by a previous SCI of (e.g., a HARQ process). Otherwise, if a (e.g., RX) WTRU (e.g., WTRU102) receives an SCI of a HARQ process in a slot where (e.g., RX) WTRU (e.g., WTRU102) expects retransmission (based on a previous SCI), (e.g., RX) WTRU (e.g., WTRU102) may not need to start a retransmission timer. Alternatively, a (e.g., RX) WTRU (e.g., WTRU102) can always start a retransmission timer in a slot where (e.g., RX) WTRU (e.g., WTRU102) expects retransmission, and / or can stop the retransmission timer (e.g., immediately) when an SCI is received, or can continue to run the retransmission timer unless an SCI is received. - Whether the PDU of the HARQ process was successfully decoded. ○ For example, as long as a (e.g., RX) WTRU (e.g., WTRU102) does not successfully decode a PDU associated with a HARQ process in (e.g., a previously received transmission / SCI), (e.g., RX) WTRU (e.g., WTRU102) can start a retransmission timer (in any of the other cases associated with this section). ■ Specifically, successful decoding involves the receipt of an SCI and / or the HARQ process ID and / or NDI indicating that the received transmission is a retransmission associated with the HARQ process currently assigned in a (e.g., RX) WTRU (e.g., WTRU102). - Whether the HARQ RTT timer expires (or stops) before or after the next scheduled retransmission. Specifically, for example, an (e.g., RX) WTRU (e.g., WTRU 102) can start a retransmission timer at the earliest of the expiration of a HARQ RTT timer and / or a retransmission timer. For example, an (e.g., RX) WTRU (e.g., WTRU 102) can start a retransmission timer when the HARQ RTT timer expires (e.g., at expiration), or when 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 immediately after) the next scheduled retransmission indicated by the SCI. - Whether preemption is set / granted by the TX WTRU (e.g., WTRU 102). For example, if a TX WTRU (e.g., WTRU 102) is permitted to reselect retransmission resources due to preemption, the TX WTRU (e.g., WTRU 102) can start a retransmission timer following the expiration of the HARQ RTT timer. On the other hand, if the TX WTRU (e.g., WTRU 102) is not permitted to perform preemption, the TX WTRU (e.g., WTRU 102) can start the retransmission timer in the slot following the next scheduled retransmission indicated by the SCI, or on that slot. - Whether the TX WTRU (e.g., WTRU 102) is set to mode 1 or mode 2. For example, for a TX WTRU (e.g., WTRU 102), when the TX WTRU (e.g., WTRU 102) is set to mode 1 (e.g., when set), if an SCI is provided, the retransmission timer can always be started in the next scheduled retransmission indicated by the SCI (or in the next slot). Otherwise (e.g., in the case of mode 2, or in the case of mode 1 where no subsequent retransmission resources are provided in the SCI), the TX WTRU (e.g., WTRU 102) can start the retransmission timer following the expiration of the HARQ RTT timer. - Whether the HARQ RTT timer of the HARQ process has been started / executed. ○ For example, when the HARQ RTT timer of the corresponding HARQ process is running, the TX WTRU (e.g., WTRU 102) can start the retransmission timer following the expiration of the corresponding HARQ RTT timer. Otherwise, the TX WTRU (e.g., WTRU 102) can start the retransmission timer in the next scheduled retransmission indicated by the SCI, or may not start the retransmission timer at all in that particular HARQ process. ○ For example, when the HARQ RTT timer is started, the TX WTRU (e.g., WTRU 102) can start the retransmission timer at the expiration of the HARQ RTT timer. Otherwise, when 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) can start the retransmission timer at another point in time indicated herein (e.g., reception of the SCI, transmission of the PSFCH, expected time of reception of the SCI based on the previous SCI retransmission resource indication, etc.). - An indication from the TX WTRU (e.g., WTRU 102) as to whether additional retransmission resources can be expected or whether the PDB will not be exceeded. Specifically, the TX WTRU (e.g., WTRU 102) can provide an indication as to whether additional retransmission resources are expected, within a specific retransmission resource (e.g., via an indication in the SCI, MAC CE, or MAC PDU header). Specifically, the TX WTRU (e.g., WTRU 102) can indicate to the RX WTRU (e.g., WTRU 102) that no additional retransmission resources are expected when the TX WTRU (e.g., WTRU 102) reaches the maximum number of retransmission resources (e.g., when it reaches). Such an indication can be provided in the SCI associated with the last retransmission resource or in a previous SCI indicating the retransmission resource. Specifically, when the TX WTRU (e.g., WTRU 102) cannot find (via resource selection) additional resources following the last retransmission resource that fit within the PDB of the packet (e.g., when it cannot find), the TX WTRU (e.g., WTRU 102) can indicate to the RX WTRU (e.g., WTRU 102) that no additional retransmission resources are expected. The RX WTRU (e.g., WTRU 102) can start the HARQ RTT timer and / or the retransmission timer when the indication from the TX WTRU (e.g., WTRU 102) indicates that additional retransmission resources are expected. Alternatively, the RX WTRU (e.g., WTRU 102) cannot start the HARQ RTT timer and / or the retransmission timer in the HARQ process when the indication from the TX WTRU (e.g., WTRU 102) indicates that no retransmission will be sent in the HARQ process. Specifically, such an indication can be either an indication that additional retransmissions are expected or an indication that no additional retransmissions are expected. For example, when 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) can start the retransmission timer following a decoding failure in the HARQ process. Otherwise, the RX WTRU (e.g., WTRU 102) cannot start the retransmission timer. An indication from the TX WTRU (e.g., WTRU 102) (further described herein) as to whether the TX WTRU (e.g., WTRU 102) expects to perform reselection following UL prioritization by the TX WTRU (e.g., WTRU 102) in the case of a failed TX transmission by the TX WTRU (e.g., WTRU 102). ○Specifically, the TX WTRU (e.g., WTRU 102) can notify the RX WTRU (e.g., WTRU 102) as to 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) can start a retransmission timer if such reselection is scheduled or if the failed transmission was the last reserved retransmission at any previous SCI. Otherwise, the RX WTRU (e.g., WTRU 102) cannot start the retransmission timer and / or can restart the HARQ RTT timer. -Whether the expected PDB of the PDU has been exceeded at a given time. ○For example, the TX WTRU (e.g., WTRU 102) can provide the expected PDB of the PDU (e.g., in the first transmission / retransmission). For example, the RX WTRU (e.g., WTRU 102) can be configured with a mapping of priorities and / or maximum PDBs (e.g., related to the first SCI reception time of the first transmission of the SCI). The (e.g., RX) WTRU (e.g., WTRU 102) can start the 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 by the TX WTRU (e.g., WTRU 102) for the HARQ process with a previous SCI. ○ For example, a (e.g., RX) WTRU (e.g., WTRU102) can use a first (pre) - set value of the re - transmission timer if there are additional reserved re - transmission resources, and / or can use a second value of the re - transmission timer if there are no reserved re - transmission resources for the HARQ process from a previous SCI transmission. ○ For example, a (e.g., RX) WTRU (e.g., WTRU102) can start the re - transmission timer if the SCI is not decoded in the re - transmission resource and / or if the re - transmission resource is the last indicated / known re - transmission resource reserved by a previous SCI. Otherwise, the (e.g., RX) WTRU (e.g., WTRU102) can instead start the HARQ RTT timer (e.g., the RX WTRU (e.g., WTRU102) expects additional re - transmissions at the next indicated position of the SCI (e.g., only at the position)). - Based on, for example, the number of re - transmissions performed by the TX WTRU (e.g., WTRU102) up to that point in a particular HARQ process compared to the maximum number that may depend on CBR / priority. ○ For example, if the number of re - transmissions performed for a PDU is below the set maximum value, the (e.g., RX) WTRU (e.g., WTRU102) can start the re - transmission timer and / or the HARQ RTT timer. Otherwise, the (e.g., RX) WTRU (e.g., WTRU102) cannot start the re - transmission timer and / or the HARQ RTT timer in that HARQ process. - Based on the scheduled reception time of the SCI / data that the RX WTRU (e.g., WTRU102) does not receive. ○ For example, an RX WTRU (e.g., WTRU 102) can perform / prioritize UL transmission or reception at a time corresponding to a scheduled retransmission by a peer (e.g., TX) WTRU (e.g., WTRU 102) indicated by a previous SCI, and / or may not be able to receive the retransmission. For example, an RX WTRU (e.g., WTRU 102) can perform sidelink transmission at a time corresponding to a scheduled retransmission by a peer (e.g., TX) WTRU (e.g., WTRU 102) indicated by a 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) can start a retransmission timer at the time of the scheduled retransmission or at some time thereafter. - Based on the QoS of the PDU. - Based on the cast type of the transmission (e.g., in combination with an indication). ○ For example, in the case of a unicast HARQ process, the WTRU can determine whether to start a HARQ RTT timer following an SCI transmission (e.g., if such an SCI transmission does not indicate a retransmission resource) based on an indication (e.g., from a TX WTRU (e.g., WTRU 102)). The TX WTRU (e.g., WTRU 102) can set such an indication based on whether PUCCH is configured in the TX WTRU (e.g., WTRU 102). Specifically, if PUCCH is configured, the RX WTRU (e.g., WTRU 102) can start the HARQ RTT timer, and / or if PUCCH is not configured, the RX WTRU (e.g., WTRU 102) may not need to 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 need to start the HARQ RTT timer (similarly, e.g., in the case of an SCI transmission where such an SCI does not indicate a retransmission resource).

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

[0103] In an exemplary embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can determine whether to start a retransmission based on, for example, the normal reception of an SCI for retransmission at a scheduled / expected reception time indicated by a previous SCI. Specifically, a (e.g., RX) WTRU (e.g., WTRU 102) can receive a first SCI indicating retransmission resources at time T2 (e.g., at time T1). The (e.g., RX) WTRU (e.g., WTRU 102) can further perform a microsleep / DRX of the SL HARQ process until the time point (e.g., T2) indicated by the first SCI. The (e.g., RX) WTRU (e.g., WTRU 102) can determine whether to start the retransmission timer of the HARQ process based on whether the (e.g., RX) WTRU (e.g., WTRU 102) normally receives an SCI indicating, for example, the same HARQ process ID at time T2. 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) can start the retransmission timer of 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 need to start the retransmission timer of that HARQ process.

[0104] c) If the RX WTRU (e.g., WTRU 102) does not decode the SCI, determine whether and / or when to start the retransmission timer of the HARQ process In the above embodiments, whether a (e.g., RX) WTRU (e.g., WTRU 102) starts a 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 a half-duplex problem (e.g., performing transmission at the same time) or UL / SL prioritization (e.g., performing a UL transmission instead of monitoring the SCI). In such a case, if the (e.g., RX) WTRU (e.g., WTRU 102) did not decode the SCI, it can always start the retransmission timer at T2. 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) can perform micro-sleep / DRX until the next scheduled retransmission or based on the setting of the HARQ RTT timer, according to the conditions described herein. For example, as follows. - Under the first condition, the (e.g., RX) WTRU (e.g., WTRU 102) can start the HARQ RTT timer. - Under the second condition, the (e.g., RX) WTRU (e.g., WTRU 102) can start the retransmission timer.

[0105] The first condition and the second condition can be any combination (and / or) of the following conditions. - The TX WTRU (e.g., WTRU 102) is operating in mode 1. - The TX WTRU (e.g., 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. - The CBR exceeds / falls below the threshold. - The transmission priority exceeds / falls below the threshold. - The behavior indicated by the TX WTRU (e.g., WTRU 102) (e.g., the TX WTRU (e.g., WTRU 102) can indicate whether the RX WTRU (e.g., WTRU 102) should start the HARQ RTT timer or the retransmission timer). ○ For example, the TX WTRU (e.g., WTRU 102) can determine whether preemption is disabled based on the operating mode and / or provide this information to the RX WTRU (e.g., WTRU 102).

[0106] For example, if the (e.g., RX) WTRU (e.g., WTRU 102) fails to retransmit a scheduled SCI (e.g., following the expiration of the HARQ RTT timer), the (e.g., RX) WTRU (e.g., WTRU 102) can start the 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 the TX WTRU (e.g., WTRU 102) is using mode 2 and preemption is disabled, and / or in any case where the failed SCI is not the last retransmission), the (e.g., RX) WTRU (e.g., WTRU 102) can start the HARQ RTT timer.

[0107] 1.3 Determination of 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 reception resources (indicated by the SCI) for retransmission and / or the time during which a timer (e.g., retransmission timer) is operating. According to an embodiment, the value of the HARQ RTT timer or the retransmission timer can be determined by a TX WTRU (e.g., WTRU 102), an RX WTRU (e.g., WTRU 102), or a combination of a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) can 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) can determine the value of the timer using known conditions in the RX WTRU (e.g., WTRU 102) and / or conditions notified to the RX WTRU (e.g., WTRU 102) by the TX WTRU (e.g., WTRU 102). Finally, a part of the timer can be determined by the TX WTRU (e.g., WTRU 102) and / or sent to the RX WTRU (e.g., WTRU 102), and / or another part of the timer can be determined by the RX WTRU (e.g., WTRU 102).

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

[0109] b) The active time associated with retransmission indicated by the SCI can be considered by starting and / or stopping a retransmission timer According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can define its active time based on whether (e.g., only on whether) there is a timer associated with DRX (such as Uu). In such a case, monitoring regarding the retransmission resource indicated by the SCI can be performed via the retransmission resource. Specifically, when a (e.g., RX) WTRU (e.g., WTRU 102) monitors the resource associated with the time point indicated / reserved in the SCI in a specific HARQ process (e.g., only the resource), the RX WTRU (e.g., WTRU 102) can do the following. - Set the HARQ RTT timer to the amount of time until the next reserved retransmission resource that does not include that resource. - When the HARQ RTT timer expires (e.g., at expiration), and / or when the PDU of the HARQ process is not successfully decoded (e.g., when not decoded), the RX WTRU (e.g., WTRU 102) starts the retransmission timer of the HARQ process. - Unless the SCI of the HARQ process is received, the (e.g., RX) WTRU (e.g., WTRU 102) continues to execute the retransmission timer until the expiration of the retransmission timer, and / or - The (e.g., RX) WTRU (e.g., WTRU 102) stops the retransmission timer immediately when it decodes the SCI of the HARQ process.

[0110] c) The RX WTRU (e.g., WTRU 102) can set the retransmission value to a different value. According to an embodiment, the RX WTRU (e.g., WTRU 102) can set the retransmission timer to a different value. Specifically, the RX WTRU (e.g., WTRU 102) can set the retransmission timer of the HARQ process to any of the following. - A (pre-)set value, or a value indicated by the TX WTRU (e.g., WTRU 102) (e.g., in RRC signaling, SCI, or the MAC layer). ○A different retransmission timer value can be further set (in advance) for a (e.g., RX) WTRU (e.g., WTRU102). - Value 0 (e.g., the (e.g., RX) WTRU (e.g., WTRU102) does not use a retransmission timer). - Value corresponding to a single slot: ○For example, under certain conditions described herein (e.g., the TX WTRU (e.g., WTRU102) is using mode 1 and / or the SCI does not include retransmission resources), the RX WTRU (e.g., WTRU102) can set the retransmission timer to a value corresponding to a single slot. Specifically, the RX WTRU (e.g., WTRU102) can run the retransmission timer between the slots associated with the retransmission resources in the SCI. - Value derived from the timing of the retransmission resources indicated in the SCI: ○For example, the TX WTRU (e.g., WTRU102) can 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, the TX WTRU (e.g., WTRU102) can 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 TX WTRU (e.g., WTRU102) can provide the PDB or remaining PDB of the PDU to the RX WTRU (e.g., WTRU102) (e.g., in the SCI or MAC control element (CE)). Alternatively, a mapping can be set for the RX WTRU (e.g., WTRU102) between the priority of the PDU and / or the expected maximum PDB (measured, e.g., from the reception of the first transmission). ■The RX WTRU (e.g., WTRU 102) can set a retransmission timer at any time following the reception of such a PDB. The RX WTRU (e.g., WTRU 102) can set the retransmission timer to the remaining time until the PDB expires (from the start of the retransmission timer). ■For example, the RX WTRU (e.g., WTRU 102) can set the retransmission timer to another value (e.g., a (pre-) set value) and / or the minimum value of the remaining time until the PDB expires. -A value that depends on measurement or the CBR indicated (from the TX WTRU (e.g., WTRU 102)) ○For example, different values of the retransmission timer can be (pre-) set for the RX WTRU (e.g., WTRU 102) according to the CBR / channel occupancy ratio (CR). -A value that depends on the retransmission number (after the first transmission of the HARQ process) ○For example, different values of the retransmission timer for each retransmission number, or an offset / change of the value of the retransmission timer applied for each retransmission (e.g., following the first transmission), can be (pre-) set for the RX WTRU (e.g., WTRU 102).

[0111] d) The RX WTRU (e.g., WTRU 102) can 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 (for example, RX) WTRU (for example, WTRU 102) can determine the micro-sleep / DRX time in a HARQ process, or the value of a HARQ RTT timer and / or a retransmission timer, based on information within a transmission by a TX WTRU (for example, WTRU 102) (which may include information within an SCI, information within a physical sidelink shared channel (PSSCH) (for example, MAC CE), information within PC5-RRC, etc.). For example, a (for example, RX) WTRU (for example, WTRU 102) can determine a HARQ RTT timer and / or a retransmission timer based on whether there are retransmission resources within an SCI and / or the timing of such retransmission resources. Such determination can include a (for example, RX) WTRU (for example, WTRU 102) selecting between a first timer and a second timer. Such determination can include a (for example, RX) WTRU (for example, WTRU 102) selecting between a time derived from an SCI and / or another time provided in another message (for example, an RRC configuration or a preset). Specifically, a (for example, RX) WTRU (for example, WTRU 102) can determine whether to use a first micro-sleep / DRX time or a second micro-sleep / DRX time, and / or whether to use a first retransmission timer or a second retransmission timer, based on any one 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 a pool. ○ Specifically, an RX WTRU (for example, WTRU 102) can determine whether preemption by a TX WTRU (for example, WTRU 102) is disabled based on a pool setting or based on an explicit indication from the TX WTRU (for example, within PC5-RRC, MAC CE, sidelink radio bearers (SLRB) settings, or within the SCI transmission itself). - QoS (e.g., priority) within the SCI. - Coverage (inside or outside coverage) of the RX WTRU (e.g., WTRU 102) or its peer (TX WTRU (e.g., WTRU 102)). - RRC state of the RX WTRU (e.g., WTRU 102) or its peer (e.g., TX WTRU (e.g., WTRU 102)). - Whether the RX WTRU (e.g., WTRU 102) is receiving data from the (e.g., TX) WTRU (e.g., WTRU 102) transmitting in mode 1 or mode 2 (such information can be further provided to the RX WTRU (e.g., WTRU 102) by the TX WTRU (e.g., WTRU 102)). - Whether the RX WTRU (e.g., WTRU 102) is receiving data from the (e.g., TX) WTRU (e.g., WTRU 102) reporting SL ACK / NACK to the network (e.g., transmitting information indicating SL ACK / NACK) (e.g., when such TX WTRU (e.g., WTRU 102) is using mode 1 transmission) (such information can 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 retransmission or HARQ-based retransmission (e.g., HARQ is 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 (e.g., WTRU 102) has received the SCI normally at the reserved time indicated by the previous SCI of the same HARQ process. - Timing of the resources indicated in the SCI of the HARQ process (e.g., for retransmission): ○ For example, a (e.g., RX) WTRU (e.g., WTRU102) can perform micro-sleep / DRX up to the retransmission resource indicated in the SCI. ○ For example, a (e.g., RX) WTRU (e.g., WTRU102) can perform DRX several slots before / after the retransmission resource indicated in the SCI, and the number of slots can be as follows. ■ Set (in advance) by the network. ■ Provided by a peer (e.g., TX) WTRU (e.g., WTRU102). ■ Dependent on one or more other factors (e.g., QoS, CBR, other indications by the TX WTRU (e.g., WTRU102)) associated with the determination between the first HARQ RTT behavior and the second HARQ RTT behavior. ● For example, a (e.g., RX) WTRU (e.g., WTRU102) can be set (in advance) with the number of slots corresponding to each priority of data associated with the HARQ process. ● For example, a (e.g., RX) WTRU (e.g., WTRU102) can be set (in advance) 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 (e.g., WTRU102) as to whether an additional retransmission resource (using a new resource reservation) can be expected or whether it exceeds the PDB. - Any other implicit or explicit indication information provided by the TX WTRU (e.g., WTRU102) as described herein (e.g., in the transmission itself or in the PC5-RRC before transmission). -As further described herein, an indication from a TX WTRU (e.g., WTRU102) as to whether the TX WTRU (e.g., WTRU102) anticipates performing reselection following UL prioritization by the TX WTRU (e.g., WTRU102) (e.g., in the case of a failed TX transmission by the TX WTRU (e.g., WTRU102)).

[0112] e) An (e.g., RX) WTRU (e.g., WTRU102) determines whether to use a value provided by the TX WTRU (e.g., WTRU102) (e.g., in the SCI) or a pre - set value of the HARQ RTT According to an embodiment, an (e.g., RX) WTRU (e.g., WTRU102) can determine whether to define the HARQ RTT based on a (pre -) set timer or based on an explicit time indication (e.g., re - transmission resource) within the SCI based on the above - described information within the SCI. In one example, the (e.g., RX) WTRU (e.g., WTRU102) can set the HARQ RTT timer (or micro - sleep / DRX time) to the time until the next re - transmission resource indicated in the SCI. Specifically, the (e.g., RX) WTRU (e.g., WTRU102) can be permitted to execute a micro - sleep of a particular SL HARQ process that starts at a certain time described herein with respect to the start of the HARQ RTT timer, and / or can continue to execute DRX until the timing of the next expected re - transmission resource indicated in the SCI. Thereafter, the (e.g., RX) WTRU (e.g., WTRU102) can start a re - transmission timer or can perform an explicit monitoring of the resources associated with this next re - transmission resource.

[0113] An (e.g., RX) WTRU (e.g., WTRU102) can set the HARQ RTT to the timing of the next expected re - transmission resource indicated in the SCI in any of the following cases. -The SCI indicates at least one re - transmission resource. -The next retransmission resource (e.g., following the transmission / retransmission resource for which a (e.g., RX) WTRU (e.g., WTRU 102) determines the HARQ RTT) was provided in the SCI. -The transmission is a 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 preconfigured value, or not use the HARQ RTT timer (e.g., start the retransmission timer immediately, or not perform micro-sleep / DRX) in the following cases. -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 (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to the timing of the expected retransmission resource indicated in the SCI retransmission resource in the following cases. -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 (e.g., WTRU 102) is using mode 2 with preemption disabled.

[0116] On the other hand, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a preconfigured value in the following cases (such preconfigured value may further depend on which of the following cases are 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 (e.g., WTRU 102) is using Mode 2 where preemption is enabled.

[0117] f) The (e.g., RX) WTRU (e.g., WTRU 102) determines the number of resources before the scheduled retransmission time to wake up According to an embodiment, the (e.g., RX) WTRU (e.g., WTRU 102) can determine the HARQ RTT as the time from the start of the HARQ RTT time or HARQ RTT timer to a specific 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 can be determined by the RX WTRU (e.g., WTRU 102) using any of the following. - Indicated by the TX WTRU (e.g., WTRU 102): ○ For example, the TX WTRU (e.g., WTRU 102) can provide the RX WTRU (e.g., WTRU 102) with the number of points in time or slots before the scheduled retransmission resource. This can be provided in the PC5 - RRC message (e.g., as a configuration parameter) and / or applied semi - statically to all transmissions by the TX WTRU (e.g., WTRU 102). Alternatively, the RX WTRU (e.g., WTRU 102) can provide an indication representing this number of slots in the SCI or MAC CE, or MAC header (e.g., as an index to a table or an explicit value). - Based on the transmission priority: ○ For example, the RX WTRU (e.g., WTRU 102) can determine the number of slots before the scheduled retransmission based on the priority indicated in the SCI. For example, the RX WTRU (e.g., WTRU 102) can be configured with the number of slots for a given priority and / or the HARQ RTT timer can be determined 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 the retransmission number: ○ For example, an RX WTRU (e.g., WTRU102) can determine the number of slots before the scheduled retransmission time or the value of the HARQ RTT time based on the retransmission number associated with the HARQ process. For example, the (e.g., RX) WTRU (e.g., WTRU102) can be (pre-)configured with the number of slots for the first (initial) transmission, the number of slots for the first retransmission, the number of slots for the second retransmission, and / or similar numbers of slots as follows. -Based on CBR: ○ For example, an RX WTRU (e.g., WTRU102) can determine the number of slots for the first range of CBR and / or the number of slots for the second range (e.g., lower) of CBR and / or similar numbers of slots as follows. The RX WTRU (e.g., WTRU102) can use its measured CBR. Alternatively, the RX WTRU (e.g., WTRU102) can use the value of CBR provided by the TX WTRU (e.g., WTRU102). -Preference in the RX WTRU (e.g., WTRU102) (e.g., power related): ○ For example, an RX WTRU (e.g., WTRU102) can determine the number of slots based on the current power saving status or preference in the RX WTRU (e.g., WTRU102) indicated by the upper layer. Such a number of slots can be set as a combination of the capabilities of the (e.g., RX) WTRU (e.g., WTRU102) and / or the current power saving preference in the RX WTRU (e.g., WTRU102).

[0118] g) The TX WTRU (e.g., WTRU102) can define the restrictions on reselection following preemption using the same / similar conditions. According to an embodiment, a TX WTRU (e.g., WTRU 102) can limit a permitted reselection resource (e.g., for retransmission resources, such as following preemption, skipped transmission, etc.) to an active time associated with an RX WTRU (e.g., WTRU 102), and such active time can be defined by a series of timers and / or maintenance of fixed / (pre)-set resources in the TX WTRU (e.g., WTRU 102). The TX WTRU (e.g., WTRU 102) can limit the permitted reselection resources for retransmission based on criteria similar to those of the above embodiments. The TX WTRU (e.g., WTRU 102) can further impose such a limitation when the RX WTRU (e.g., WTRU 102) is expected to be in DRX. The TX WTRU (e.g., WTRU 102) can limit the selected resources for retransmission based on priority, CBR, retransmission number, preference from the RX WTRU (e.g., WTRU 102), etc. after (e.g., at the time of) preemption associated with the resource. For example, for a first value / range of transmission priority, the TX WTRU (e.g., WTRU 102) can select resources 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., WTRU 102) can select resources 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 can be further limited to a (pre)-set pattern of resources. In such a case, the RX WTRU (e.g., WTRU 102) monitors a (pre)-set pattern of resources (e.g., only the pattern of resources) for the HARQ process when in DRX. For example, the WTRU can apply such a limitation when communicating with an RX WTRU (e.g., WTRU 102) in which DRX is set (e.g., during communication), and in the case of preemption (e.g., only in the case of preemption).Specifically, the TX WTRU (e.g., WTRU 102) can limit the reselection of retransmission resources such that a new retransmission resource can occur (e.g., always) after the timing of the scheduled retransmission resource (indicated by the previous SCI). As described herein with respect to the conditions, this can be for the purpose of enabling the RX WTRU (e.g., WTRU 102) to operate (assuming so) such that a resource prior to the next scheduled retransmission resource cannot be selected by preemption, and to enable the timing of the next scheduled SCI to be used as the HARQ RTT timer.

[0119] h) The (e.g., RX) WTRU (e.g., WTRU 102) determines whether to set the HARQ RTT time based on priority and / or SCI retransmission based on CBR According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can determine whether to use the timing of the SCI retransmission resource or use a (pre-) set value (e.g., expiring before such a retransmission resource) based on the priority of the PDU and / or the measured / indicated CBR. For example, whether a TX WTRU (e.g., WTRU 102) can select a resource that occurs before the scheduled retransmission resource in the SCI (as a result of preemption), or whether it can select a resource that occurs after the retransmission resource (e.g., only the resource) may depend on the priority of the PDU and / or the CBR. For example, if the priority of the PDU exceeds a threshold (a priority higher than the priority indicated by the threshold), and / or in the case of a specific range of CBR, a (e.g., RX) WTRU (e.g., WTRU 102) can use a first (shorter) HARQ RTT timer selected from the (pre-) set. In such a case, the TX WTRU (e.g., WTRU 102) can 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 the threshold (lower than the priority indicated by the threshold), and / or in the case of a second (e.g., lower) range of CBR, the RX WTRU (e.g., WTRU 102) can determine that the value of the HARQ RTT is the time until the next scheduled retransmission resource indicated in the SCI (either the retransmission resource or the slot following it). In this case, with respect to the TX WTRU (e.g., WTRU 102), if the TX WTRU (e.g., WTRU 102) performs resource reselection following preemption (e.g., at the time of execution), the TX WTRU (e.g., WTRU 102) can select a resource that occurs after the first retransmission resource (e.g., only the resource).

[0120] With such a selection, a retransmission number can be further used (e.g., be dependent on the retransmission number). Specifically, the priority threshold can be used (e.g., be dependent on the retransmission resource). Whether such a selection is possible or not may depend on which retransmission resources are considered.

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

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

[0123] For example, as follows. -(For example, RX) WTRU (e.g., WTRU 102) can select a first (pre-)configured timer for HARQ active transmission in which the TX WTRU (e.g., WTRU 102) reports SL HARQ feedback to the network (e.g., transmits information indicating SL HARQ feedback). Such a first timer can 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 in the TX WTRU (e.g., WTRU 102), and / or the second value corresponds to the delay from PUCCH to DCI / SCI scheduling set by the network (and transmitted by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102) in PC5-RRC signaling). -(For example, RX) WTRU (e.g., WTRU 102) can select a second (pre-)configured timer for HARQ inactive transmission in 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 second timer can be determined by combining the minimum latency from SCI to PUCCH provided by the TX WTRU (e.g., WTRU 102), and / or the delay from PUCCH to SCI / SCO scheduling set by the network. -(For example, RX) WTRU (e.g., WTRU 102) can select a third (pre-)configured timer for HARQ active transmission in 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 can be determined as the value of the latency from PSFCH to PSSCH in the TX WTRU (e.g., WTRU 102) that can be provided by the TX WTRU (e.g., WTRU 102), and / or -(For example, RX)WTRU (e.g., WTRU 102) can select a third (pre-)configured timer for HARQ invalid transmission where 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 a timer can be determined as the minimum latency value between the SCI associated with the last retransmission resource and / or a new SL resource scheduled by the network for the same HARQ process (set 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 when the TX WTRU (e.g., WTRU 102) and / or the TX WTRU (e.g., WTRU 102) calculates the HARQ RTT and / or sends it to the RX WTRU (e.g., WTRU 102).

[0125] Without loss of generality, the above embodiments can be used in combination. Specifically, the TX WTRU (e.g., WTRU 102) can calculate and / or send the first part of the HARQ RTT to the RX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) can calculate the final value of the HARQ RTT by adding the received part to its own determined part. Either part can be determined based on the criteria described in the embodiments herein.

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

[0127] According to an embodiment, 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.) can be set for a (e.g., RX) WTRU (e.g., WTRU 102) for each resource pool. Specifically, the timer for SL DRX can be set together 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., WTRU 102) can apply a correction factor to a set DRX timer (e.g., any of an inactivity timer, a HARQ RTT timer, a retransmission timer, an on-duration timer, etc.), and such a correction factor can be specific to the RX resource pool of the (e.g., RX) WTRU (e.g., WTRU 102). For example, a correction factor in the RX resource pool setting can be provided to the (e.g., RX) WTRU (e.g., WTRU 102). For example, the (e.g., RX) WTRU (e.g., WTRU 102) can determine the correction factor using the amount / ratio of UL resources allowed for sidelink transmission on the SL resource pool. The (e.g., RX) WTRU (e.g., WTRU 102) can apply such a correction factor to the set timer (e.g., multiply by the factor) to obtain the actual timer value used in the DRX operation.

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

[0130] According to an embodiment, the TX WTRU (e.g., WTRU 102) can provide the RX WTRU (e.g., WTRU 102) with information for the RX WTRU (e.g., WTRU 102) to calculate the associated HARQ RTT timer and / or retransmission timer. This can include any of the following. - Whether mode 1 or mode 2 is set in the TX WTRU (e.g., WTRU 102). - Whether the TX WTRU (e.g., WTRU 102) is set to report HARQ ACK / NACK to the network in mode 1 (e.g., transmit information indicating HARQ ACK / NACK). - Measured CBR / CR. - One or more network set values of a timer or components of such timer. - One or more WTRU determined values (e.g., based on capabilities) of a timer or components of such timer. - An indication of whether the TX WTRU (e.g., WTRU 102) takes one or another specific behavior regarding preemption occurring in the retransmission resource and / or UL / SL prioritization.

[0131] The TX WTRU (e.g., WTRU 102) can use any one or combination of fields within PC5 - RRC, MAC CE, MAC header, or SCI to convey any of the above information. For example, the TX WTRU (e.g., WTRU 102) can use a field within the SCI, and each code point of that field represents a combination such as mode 1 / mode 2, HARQ ACK / NACK reporting (e.g., transmission of information indicating HARQ ACK / NACK), measured CBR range, etc.

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

[0133] m) [The TX WTRU (e.g., WTRU 102) indicates whether / how to perform reselection following pre - emption, UL / SL prioritization, etc.] According to an embodiment, the TX WTRU (e.g., WTRU 102) can indicate to the RX WTRU (e.g., WTRU 102) whether / how to perform resource reselection following an event that can change the timing of a scheduled transmission to the RX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) can notify the RX WTRU (e.g., WTRU 102) of any of the following. - Whenever the TX WTRU (e.g., WTRU 102) prioritizes the UL over the SL at a scheduled retransmission, whether the TX WTRU (e.g., WTRU 102) always performs reselection or does not perform the retransmission (e.g., always waits for retransmission at that resource when the next retransmission resource is indicated, or cancels the retransmission). - Whenever the TX WTRU (e.g., WTRU 102) prioritizes the UL over the SL at a scheduled retransmission, the conditions under which the TX WTRU (e.g., WTRU 102) performs reselection. Such conditions can be based on a specific parameter exceeding / falling below a specific threshold, and such a parameter can be any of the following. ○ Priority ○ CBR ○ Retransmission number ○ Remaining number of retransmissions ○ Remaining PDB ○ Time elapsed after the first transmission - Whenever the TX WTRU (e.g., WTRU 102) performs preemption on a retransmission resource, whether the TX WTRU (e.g., WTRU 102) performs reselection or simply cancels the transmission on the retransmission resource. - Whenever the 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 can be based on a specific parameter exceeding / falling below a specific threshold, and such a parameter can be any of the following. ○ Priority ○ CBR ○ Retransmission number ○ Remaining number of retransmissions ○ Remaining PDB ○ Time elapsed after the first transmission Whenever a TX WTRU (e.g., WTRU 102) performs preemption on a retransmission resource, the TX WTRU (e.g., WTRU 102) determines which subset (or window) of resources to consider for reselection of the retransmission resource (e.g., such resources are defined relative to the timing of the retransmission resource), or conditions for determining such resources, such as based on any of the following: ○ Priority ○ CBR ○ Retransmission number ○ Remaining number of retransmissions ○ 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 that occur 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 ○ Retransmission number ○ Remaining number of retransmissions ○ Remaining PDB ○ Time elapsed since the first transmission

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

[0135] (In the case of Mode 1) A (e.g., TX) WTRU (e.g., WTRU 102) configured to transmit using Mode 1 can 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 transmitted to the RX WTRU (e.g., WTRU 102) based on the timing of the SL HARQ feedback to the gNB.] According to an embodiment, the TX WTRU (e.g., WTRU 102) can determine the HARQ RTT transmitted to the RX WTRU (e.g., WTRU 102) based on the timing of the PUCCH resource set by the network. For example, the TX WTRU (e.g., WTRU 102) can calculate the HARQ RTT, or a component of the HARQ RTT, based on any of the following. - The time difference between the PSFCH resource that conveys the HARQ feedback of the HARQ process and / or the PUCCH resource set to provide the SL HARQ feedback (e.g., in RRC for a cell group (CG) or DCI for a dynamic grant). - This can correspond to, or be derived from, the maximum value between the PSFCH and the PUCCH provided to the WTRU in DCI or RRC (e.g., in the case of CG type 1). - This can correspond to the earliest PUCCH transmission opportunity calculated from the PUCCH resource indicator field in DCI. - The time difference between the SCI transmission / resending of the HARQ process and / or the PUCCH resource set to provide the SL HARQ feedback. - The time difference between the PSFCH resource that conveys the HARQ feedback of the HARQ process and / or the physical uplink shared channel (PUSCH) resource through which the TX WTRU (e.g., WTRU 102) can send / is determined to be able to send the SL HARQ feedback. - The time difference between the SCI transmission / resending of the HARQ process and / or the PUCCH resource set to provide the SL HARQ feedback.

[0137] For example, a TX WTRU (e.g., WTRU102) can combine such a value with a network (NW) set value (e.g., by adding the values).

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

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

[0140] The behavior in such an embodiment is similar to the behavior of an RX WTRU (e.g., WTRU102) that combines such timers when receiving information on these factors from the TX WTRU (e.g., WTRU102).

[0141] (In the case of Mode 2) A (e.g., TX) WTRU (e.g., WTRU102) configured to transmit using Mode 2 can calculate a HARQ RTT timer based on one of the mechanisms described below.

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

[0143] The (e.g., TX) WTRU (e.g., WTRU102) can further determine such a time based on any of the following. - The priority of the PDU transmitted in the first transmission. - For example, the TX WTRU (e.g., WTRU102) can determine a first preemption check time for the first priority of the packet, a second preemption check time for the second priority of the packet, etc. - A preference indication from the RX WTRU (e.g., WTRU102) (e.g., based on a power saving status). - For example, a TX WTRU (e.g., WTRU 102) can obtain power saving assistance information from an RX WTRU (e.g., WTRU 102). For example, such information can be in the form of power saving levels (low power mode, medium power mode, high power mode). For example, a TX WTRU (e.g., WTRU 102) can 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) can be configured to select a preemption check time from the above combinations (e.g., a first preemption check time for a specific 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) can determine the HARQ RTT as the time from the first transmission / resending until the expected preemption check. A (e.g., TX) WTRU (e.g., WTRU 102) can determine the HARQ RTT by adding some (pre - set) time value to the expected preemption check time. The TX WTRU (e.g., WTRU 102) can 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) determines whether to perform reselection following preemption / prioritization. According to an embodiment, conditions regarding whether (re)selection can be triggered for a TX WTRU (e.g., WTRU 102) by means of preemption and / or prioritization (e.g., giving priority to UL over SL transmission) can be set. Specifically, the TX WTRU (e.g., WTRU 102) may not need to perform resource reselection following preemption when SL DRX is set for the RX WTRU (e.g., WTRU 102). Specifically, when DRX is set for the RX WTRU (e.g., WTRU 102) and the TX WTRU (e.g., WTRU 102) performs UL transmission instead of SL transmission (e.g., at the time of execution), the TX WTRU (e.g., WTRU 102) may not need to perform resource reselection following a failed transmission of SCI / data (e.g., in a scheduled or announced resource). Such behavior can be performed to avoid transmission by the TX WTRU (e.g., WTRU 102) in resources where it is known that the RX WTRU (e.g., WTRU 102) is in DRX (not monitoring SL). According to an embodiment, for example, when the RX WTRU (e.g., WTRU 102) is in DRX (e.g., when in DRX), specific conditions or combinations of conditions (and / or) regarding when such reselection should be performed can be set for the TX WTRU (e.g., WTRU 102) in relation to any of the following. - Priority / QoS: ○ For example, the TX WTRU (e.g., WTRU 102) can perform reselection of retransmission resources when the priority of the transmission / PDU exceeds a threshold (where such a threshold can further depend on the CBR). - Remaining retransmission resources: ○ For example, the TX WTRU (e.g., WTRU 102) can perform reselection of retransmission resources according to the presence / number of remaining retransmission resources of the same HARQ process that have already been reserved (e.g., not affected by preemption). ○ For example, if at least x additional retransmission resources remain after a failed / preempted retransmission, the TX WTRU (e.g., WTRU 102) can perform reselection of the retransmission resources (where x can further depend on any other conditions such as priority, CBR, etc.). - CBR: ○ For example, the TX WTRU (e.g., WTRU 102) can perform reselection of the retransmission resources if the CBR is 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 can use such resources if the remaining resources indicated in the SCI were not preempted (e.g., assumed not to be preempted). Alternatively, the TX WTRU (e.g., WTRU 102) can choose to delete the resources. Whether the TX WTRU (e.g., WTRU 102) determines to use the resources or determines to delete the resources can further depend on any of the following. - The number of retransmissions already performed on the PDU. - The QoS associated with the PDU. - The remaining number of retransmissions of the HARQ process that was previously announced and / or can still be performed by the TX WTRU (e.g., WTRU 102). - The power level / preference of the RX WTRU (e.g., WTRU 102). - Combinations thereof.

[0148] For example, a TX WTRU (e.g., WTRU 102) can set the minimum number of retransmissions to be performed in a HARQ process for a specific priority and / or power preference level of an RX WTRU (e.g., WTRU 102). If the (e.g., TX) WTRU (e.g., WTRU 102) is unable to perform a transmission associated with a specific scheduled retransmission resource, the TX WTRU (e.g., WTRU 102) can 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., WTRU 102) can perform retransmissions in the remaining reserved retransmission resources and / or can perform resource selection for a new set of resources associated with the same HARQ process.

[0149] An RX WTRU (e.g., WTRU 102) can also expect similar behavior to set a retransmission timer for a HARQ process. Specifically, the same minimum number of retransmissions can be set for the HARQ process of a specific priority and / or power preference level for the RX WTRU (e.g., WTRU 102). If the RX WTRU (e.g., WTRU 102) is unable to decode an SCI in a scheduled / reserved resource and / or if DRX is set for the RX WTRU (e.g., WTRU 102), the RX WTRU (e.g., WTRU 102) can do the following. - Start the retransmission timer if the minimum number of retransmissions for the HARQ process has not been reached. - Do not start the retransmission timer (e.g., transition to sleep in that HARQ process) if the minimum number of retransmissions for the HARQ process has been reached.

[0150] b) The TX WTRU (e.g., WTRU 102) can indicate the last retransmission of a HARQ process There may be ambiguity at the RX WTRU (e.g., WTRU 102) as to whether the TX WTRU (e.g., WTRU 102) indicates 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., WTRU 102) cannot find sufficient retransmission resources during resource selection (and when a separate resource selection can be performed later for additional transmission resources).

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

[0152] For example, the TX WTRU (e.g., WTRU 102) can indicate that no additional retransmission resources are expected when exceeding the PDB (e.g., when exceeded). For example, the TX WTRU (e.g., WTRU 102) can indicate that no additional retransmission resources are expected when exceeding the maximum number of retransmissions of a PDU based on priority / CBR (e.g., when exceeded). For example, the TX WTRU (e.g., WTRU 102) can indicate that additional retransmission resources are expected when the WTRU cannot select retransmission resources 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 (e.g., when there is). For example, the TX WTRU (e.g., WTRU 102) can indicate that additional retransmission resources are expected when not exceeding the maximum number of retransmission resources (e.g., when not exceeding), the WTRU cannot select retransmission resources for retransmission, and / or the WTRU determines / expects / decides to include the retransmission of the PDU in the newly selected resources / grants.

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

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

[0155] For example, the TX WTRU (e.g., WTRU102) can perform resource reselection for the (re)transmission resources associated with a specific HARQ process. The TX WTRU (e.g., WTRU102) can select the resources of the (re)transmission resources in a time-limited manner when any of the above timers associated with the RX WTRU (e.g., WTRU102) is running (e.g., when it is running).

[0156] For example, the TX WTRU (e.g., WTRU102) can perform resource reselection for the (re)transmission resources associated with a specific HARQ process considering that preemption is possible. The TX WTRU (e.g., WTRU102) can perform reselection within the set of resources associated with the retransmission timer running at the RX WTRU (e.g., WTRU102) considering preemption.

[0157] d) Handling of HARQ-based SL RLF when DRX exists Errors that determine ACK as NACK may lead to the result that the TX WTRU (e.g., WTRU 102) wrongly triggers SL-RLF (Side Link - Radio Link Failure). Specifically, when the RX WTRU (e.g., WTRU 102) sends an ACK and / or is interpreted as a NACK by the TX WTRU (e.g., WTRU 102), the TX WTRU (e.g., WTRU 102) can perform a retransmission during the time when the retransmission timer may be operating (e.g., assumed to be operating) by the execution in the RX WTRU (e.g., WTRU 102). However, since the RX WTRU (e.g., WTRU 102) has decoded correctly (sent an ACK), in this case, the retransmission timer may not have been started. As a result, the DTX counter for triggering RLF may be wrongly incremented.

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

[0159] According to an embodiment, the TX WTRU (e.g., WTRU 102) can invalidate the count of DTX when DRX is set in the RX WTRU (e.g., WTRU 102) (e.g., when it is set). Specifically, when the TX WTRU (e.g., WTRU 102) sends to one or more RX WTRUs (e.g., WTRU 102) where SL DRX is set (e.g., when sending), it may not count some or all HARQ DTX occurrences. The TX WTRU (e.g., WTRU 102) can invalidate the count, for example, always, for example, at a specific time (e.g., only when a specific timer is not running). For example, it is as follows. - The -TX WTRU (e.g., WTRU 102) may not count HARQ DTX for all HARQ-based transmissions when SL DRX is set for at least one RX WTRU (e.g., WTRU 102) (e.g., when it is set). - The -TX WTRU (e.g., WTRU 102) may not count HARQ DTX for HARQ-based transmissions targeted at an RX WTRU (e.g., WTRU 102) for which SL DRX is set. - The -TX WTRU (e.g., WTRU 102) may not count HARQ DTX for HARQ-based transmissions targeted at one or more RX WTRUs (e.g., WTRU 102) for which SL DRX is set if the corresponding transmission (where DTX was observed) was executed when any of the following occurred (e.g., when any of the following is true). ○ The on-duration timer associated with the RX WTRU (e.g., WTRU 102) was not running. ○ The inactivity timer associated with the RX WTRU (e.g., WTRU 102) was not running. ○ The HARQ RTT associated with the RX WTRU (e.g., WTRU 102) was started / not started. - The -TX WTRU (e.g., WTRU 102) may not count HARQ DTX following the first HARQ DTX received by the -TX WTRU (e.g., WTRU 102) that was associated with one or more of the other conditions in the previous example.

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

[0161] According to an embodiment that can be combined with the previous (one or more) solutions, the 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 the retransmissions associated with a particular TB, for example, after one or more (or a (pre)set number of) failed (re)transmissions that generate HARQ DTX and / or HARQ NACK. 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 (e.g., WTRU 102) is running. - The inactivity timer of the RX WTRU (e.g., 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 a HARQ feedback (ACK or NACK).

[0162] According to an embodiment, different thresholds / conditions (e.g., the maximum number of consecutive HARQ DTX) for triggering SL RLF for transmissions to one or more RX WTRUs (e.g., WTRU 102) with SL DRX configured can be set by the NW for the TX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) can receive two settings of the maximum number of consecutive HARQ RTX for triggering SL RLF. The TX WTRU (e.g., WTRU 102) can use the first setting when performing transmissions to one or more RX WTRUs (e.g., WTRU 102) without SL DRX configured (e.g., when performing), and / or can use the second setting when performing transmissions to at least one or more RX WTRUs (e.g., WTRU 102) with SL DRX configured (e.g., at the time of execution).

[0163] 1.5 Exemplary embodiments in the RX WTRU (e.g., WTRU 102) Figures 4A - 4C show the timing diagrams of the HARQ RTT timer and / or the retransmission timer (e.g., ReTx timer) in the scenario of the TX WTRU (e.g., WTRU 102) in mode 2 (e.g., resource allocation). Referring to Figures 4A - 4C, the first transmission TR0 (e.g., associated with the SCI) is performed along with the indication of two SCI retransmissions (the first retransmission TR1 and / or the second retransmission TR2) (e.g., associated with the SCI). Specifically, it is as follows.

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

[0165] Referring to FIG. 4B, in Case 2, preemption is disabled and / or the TX WTRU (e.g., WTRU 102) can skip the SCI associated with the first retransmission TR1 by UL / SL prioritization. Alternatively, the TX WTRU (e.g., WTRU 102) may enable preemption, but (as described herein with respect to restricting the retransmission resources for preemption) the reselection of the retransmission resources for preemption can be made after the scheduled retransmission resources. The RX WTRU (e.g., WTRU 102) can start a retransmission timer (e.g., ReTx timer) following the position of this scheduled (and not yet received) retransmission TR1 (or following the expiration of the HARQ RTT timer set based on the timing of the retransmission resources within the SCI). The TX WTRU (e.g., WTRU 102) can perform resource reselection for the transmission of the first retransmission TR1 resources within the time associated with the retransmission timer (e.g., ReTx timer). The retransmission timer (e.g., ReTx timer) can start following the last scheduled retransmission TR2. The TX WTRU (e.g., WTRU 102) can perform resource selection for the transmission of a new SCI associated with the same HARQ process within the time of this retransmission timer (e.g., ReTx timer).

[0166] Referring to FIG. 4C, in case 3, the preemption is effective and / or the TX WTRU (e.g., WTRU 102) can skip the SCI associated with the first retransmission TR1 due to preemption (without any limitation, this may mean that the reselected retransmission resource can occur before the scheduled timing of the retransmission based on the information in the SCI). The TX WTRU (e.g., WTRU 102) can set the HARQ RTT timer to a value smaller than the next scheduled retransmission TR2 resource and / or can subsequently (e.g., immediately) start the 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) Processing of HARQ RTT timer and / or retransmission timer when HARQ feedback is effective In a first exemplary embodiment of processing the HARQ RTT timer and / or the retransmission timer, first, the RX WTRU (e.g., WTRU 102) can be notified in PC5-RRC signaling from the TX WTRU (e.g., WTRU 102) of the resource allocation mode (mode 1 or mode 2) or a similar indication from the TX WTRU (e.g., WTRU 102) that can determine the timer processing behavior in the RX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) can allocate a received HARQ process to a new transmission / PDU after receiving a HARQ process number that is not occupied or a first SCI indicating that the first SCI represents the first transmission (e.g., upon reception). The RX WTRU (e.g., WTRU 102) can determine that the HARQ feedback is effective and, as a result, use the behavior associated with this embodiment. The RX WTRU (e.g., WTRU 102) can store the position / timing of the first transmission and / or possible retransmissions indicated by the first SCI representing the first transmission.

[0168] The RX WTRU (e.g., WTRU 102) can transmit a PSFCH with HARQ feedback following the decoding (successful or unsuccessful) of the first transmission. The RX WTRU (e.g., WTRU 102) can start the HARQ RTT timer in 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 as a result skips the PSFCH, the RX WTRU (e.g., WTRU 102) can start the HARQ RTT timer in the first symbol / slot that is skipped and / or that follows the PSFCH that is intended for the transmission of HARQ feedback.

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

[0170] The RX WTRU (e.g., WTRU 102) can set the HARQ RTT timer as follows. - If the resource allocation mode is mode 1 (or the indication of the TX WTRU (e.g., WTRU 102) indicates the use of such HARQ behavior): ○ In step 512, if there is additional retransmission resource reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) can set the HARQ RTT to the time until the next retransmission resource of the HARQ process indicated in the SCI. ■ As a variant 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) can depend on determining whether to start the retransmission timer at the time of the next retransmission resource. In such a variant, the active time can be associated with (e.g., assumed to be) the timing of the retransmission resource and / or the ongoing retransmission timer. ○ In step 511, if there is no additional retransmission resource reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) can set the HARQ RTT to a (pre-)set value or a pre-defined value (also referred to as "ConfigValH1") from (the NW or another WTRU), and such a value is associated with mode 1. ■ In addition to this, the RX WTRU (e.g., WTRU 102) can further select a specific HARQ RTT timer of mode 1 associated with the specific case of mode 1 under consideration, for example, from a list of (pre-)set values provided by the TX WTRU (e.g., WTRU 102) based on the following additional information provided by the TX WTRU (e.g., WTRU 102) for the case of mode 1 under consideration. ● Whether the TX WTRU (e.g., WTRU 102) has a set PUCCH resource. ● Whether the TX WTRU (e.g., WTRU 102) reports HARQ feedback to the network (e.g., transmits information indicating HARQ feedback). ■In a variant 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 pre-defined time after this time. -When 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, in step 521, set the HARQ RTT timer to a (pre-)set value or pre-defined value (also referred to as "ConfigValH2") associated with mode 2 resource reselection based on preemption from the NW or another (e.g., RX) WTRU (e.g., WTRU 102). Such a timer may further depend on priority / CBR. Such a timer may further depend on priority / CBR. The (e.g., RX) WTRU (e.g., WTRU 102) may do so 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, in step 523, set the HARQ RTT timer to a (pre-)set value or pre-defined value (also referred to as "ConfigValH3") associated with mode 2 resource selection based on the selection of new resources from the NW or another WTRU.

[0171] In step 530, the RX WTRU (e.g., WTRU 102) may start / run the HARQ RTT timer.

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

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

[0174] The RX WTRU (e.g., WTRU 102) can monitor for SL as long as any of the following are true. - One or more on-duration timers, inactivity timers, or retransmission timers are running in the RX WTRU (e.g., WTRU 102), and / or - The time slot is associated with reserved retransmission resources associated with a HARQ process for which the PDU associated with the HARQ process has not been decoded.

[0175] b) Handling of the HARQ RTT timer and / or retransmission timer when HARQ feedback is disabled In a second exemplary embodiment for processing the HARQ RTT timer and / or the retransmission timer, first, the RX WTRU (e.g., WTRU 102) can be notified of the resource allocation mode (mode 1 or mode 2) from the TX WTRU (e.g., WTRU 102) in PC5-RRC signaling. The RX WTRU (e.g., WTRU 102) can allocate a received HARQ process to a new transmission / PDU after having an unoccupied HARQ process number or after receiving a first SCI indicating that the first SCI represents the first transmission (e.g., at reception). The RX WTRU (e.g., WTRU 102) can determine that the HARQ feedback is invalid from the SCI, and as a result, use the behavior associated with this embodiment. Specifically, when the HARQ feedback is invalid (e.g., when it is invalid, as compared to the previous embodiment before the HARQ feedback was valid), different sets of (pre-)configured or specified timers for the HARQ process can be set for the RX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) can store the position / timing of the first transmission and / or possible retransmissions indicated by the first SCI representing the first transmission.

[0176] After receiving the SCI in a state where the HARQ feedback is invalid (e.g., at reception), the RX WTRU (e.g., WTRU 102) can immediately start the HARQ RTT timer at the time of receiving the SCI.

[0177] The RX WTRU (e.g., WTRU 102) can set the HARQ RTT timer in the same manner as in the previous embodiment, except that different sets of (pre-)configured timers can be used.

[0178] The RX WTRU (e.g., WTRU 102) can set the retransmission timer in the same manner as in the previous embodiment, except that different (pre-)configured timer values can be used.

[0179] The RX WTRU (e.g., WTRU 102) can monitor SL as long as it is any of the following. - One or more on-duration timers, inactivity timers, or retransmission timers are running in the RX WTRU (e.g., WTRU 102), and / or - The time slot is associated with reserved retransmission resources associated with a HARQ process for which the PDU associated with the HARQ process has not been decoded.

[0180] 2. Method for Defining the Active Time (Inactivity Timer) for the First Transmission 2.1 Modeling of the Inactivity Timer in the Case of Unicast The described embodiments are defined, for example, for the case of unicast, but may also be applicable to groupcast and / or broadcast.

[0181] a) Conditions for Starting / Using the Inactivity Timer According to an embodiment, the WTRU (TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) can be configured to start / use the inactivity timer based on specific conditions. Such conditions may be related to any one or combination (and / or) of the following. - HARQ feedback is enabled ○ For example, the RX WTRU (e.g., WTRU 102) can start the inactivity timer if the received transmission / retransmission is associated with a transmission for which HARQ is enabled. Otherwise, if the RX WTRU (e.g., WTRU 102) receives a transmission / retransmission for which HARQ is disabled, it may not start the inactivity timer. ○ For example, if the transmission performed by the TX WTRU (e.g., WTRU 102) indicates that HARQ is enabled, the TX WTRU can start an inactivity timer. Otherwise, if the transmission indicates that HARQ is disabled, the TX WTRU (e.g., WTRU 102) may not need to start an inactivity timer. - CR / CBR in the RX WTRU (e.g., WTRU 102) ○ For example, the RX WTRU (e.g., WTRU 102) can send the measured value of CR / CBR in the RX WTRU (e.g., WTRU 102) to the TX WTRU (e.g., WTRU 102). The RX WTRU (e.g., WTRU 102) can send such a measured value when the measured value changes from one range to another (e.g., at the time of change), or when the measured value changes by a specific amount (e.g., at the time of change). ■ For example, if the CR / CBR is below a threshold, the RX WTRU (e.g., WTRU 102) can start an inactivity timer after receiving a new transmission or retransmission (e.g., at the time of reception). Otherwise, the RX WTRU (e.g., WTRU 102) may not need to 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) can start an inactivity timer for transmission. Otherwise, the TX WTRU (e.g., WTRU 102) may not need to start / restart the inactivity timer.

[0182] b) Use of the inactivity timer in the TX WTRU (e.g., WTRU 102) According to an embodiment, when the RX WTRU (e.g., WTRU 102) to which the TX WTRU (e.g., WTRU 102) is to send is set to DRX, the TX WTRU (e.g., WTRU 102) can maintain an inactivity timer associated with such RX WTRU (e.g., WTRU 102). The TX WTRU (e.g., WTRU 102) can use the inactivity timer (in addition to other timers such as an on-duration timer and a retransmission timer) to determine whether to perform a new transmission and / or retransmission to that specific (one or more) RX WTRU (e.g., WTRU 102). For example, the TX WTRU (e.g., WTRU 102) can perform (e.g., only perform) a new transmission and / or retransmission to the RX WTRU (e.g., WTRU 102) when any of the inactivity timer, the on-duration timer, or the retransmission timer is running (e.g., at the time of execution).

[0183] c) The inactivity timer can be started by the TX WTRU (e.g., WTRU 102) at different times According to an embodiment, the TX WTRU (e.g., WTRU 102) can start the inactivity timer at any of the following times. - After the first transmission of a new TB (e.g., resource) (e.g., at the time of transmission): ○ For example, the TX WTRU (e.g., WTRU 102) can start the inactivity timer in the first slot after the transmission of the SCI associated with the new transmission. ○ For example, the TX WTRU (e.g., WTRU 102) can start the inactivity timer in the first slot following a (pre-set) number of slots after the transmission of the SCI associated with the new transmission. - After receiving the HARQ feedback (e.g., at the time of reception), in which case this reception can 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) can start an inactivity timer. However, if the TX WTRU (e.g., WTRU 102) decodes DTX on the PSFCH resource, the TX WTRU (e.g., WTRU 102) may not need to start an inactivity timer. ○ For example, if the TX WTRU (e.g., WTRU 102) receives a HARQ ACK, the TX WTRU (e.g., WTRU 102) can start an inactivity timer. However, if the TX WTRU (e.g., WTRU 102) decodes DTX or NACK on the PSFCH resource, the TX WTRU (e.g., WTRU 102) may not need to start an inactivity timer. - After the last retransmission of the new TB indicated in the SCI: ○ For example, the TX WTRU (e.g., WTRU 102) can start an inactivity timer in the first slot after the transmission of the SCI associated with the last retransmission indicated in the previous SCI. ○ For example, the TX WTRU (e.g., WTRU 102) can start an inactivity timer after a (pre-)configured number of slots from the transmission of the SCI associated with the last retransmission indicated in the previous SCI. - After the Nth retransmission of the new TB indicated in the SCI (N can be (pre-)configured or pre-defined): ○ N can further depend on, for example, QoS (e.g., priority).

[0184] According to an embodiment, the TX WTRU (e.g., WTRU 102) can start an inactivity timer at different times (any of the times shown above) according to any of the following specific factors. - Whether HARQ feedback is valid / invalid in a new transmission for which the inactivity timer should be started. - Depends on the CBR / CR measured and / or reported by the RX WTRU (e.g., WTRU 102). - The QoS of the transmission (e.g., priority).

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

[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., WTRU 102) can have the same value as the value set in the RX WTRU (e.g., WTRU 102). According to an embodiment, the inactivity timer started by the TX WTRU (e.g., WTRU 102) can have a value shorter than the value set in the RX WTRU (e.g., WTRU 102). For example, different inactivity timers for use can be (pre-)set in the TX WTRU (e.g., WTRU 102). According to an embodiment, the TX WTRU (e.g., WTRU 102) can shorten the set inactivity timer used in the RX WTRU (e.g., WTRU 102) to account for different start times of the inactivity timer. Specifically, when the TX WTRU (e.g., WTRU 102) starts an inactivity timer after (e.g., upon) reception of HARQ feedback, it can be as follows. - The TX WTRU (e.g., WTRU 102) can shorten the inactivity timer (compared to the value used in the RX WTRU (e.g., WTRU 102)) by the time between the start time of the first transmission (or the assumed start time, e.g.) of the first transmission received at the RX WTRU (e.g., WTRU 102), and / or the first ACK or NACK received by the TX WTRU (e.g., WTRU 102) for the transmission / resending of that TB (or any other TB).

[0187] e) A single inactivity timer for each peer (e.g., TX) WTRU (e.g., WTRU 102) / L2 ID, or multiple inactivity timers are set 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 (e.g., WTRU 102).

[0188] According to an embodiment, the WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) can maintain an inactivity timer for each ID or set of IDs such as the WTRU ID, logical channel (LCH) ID, L2 ID, etc. For example, the WTRU can maintain an inactivity timer for each unicast link (pair of source / destination L2 IDs), and / or each involved L2 ID for groupcast / broadcast. The WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) can set / reset the inactivity timer associated with the 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)) can maintain a single inactivity timer for all unicast links (pairs of source / destination IDs) and / or for all L2 IDs associated with, for example, groupcast / broadcast communications. Specifically, a WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) can set / reset the inactivity timer after (e.g., upon) receiving any sidelink transmission. For example, to account for different DRX settings associated with different unicast links and / or groupcast L2 source / destination IDs, the WTRU can do the following. - When the inactivity timer is set / reset (e.g., at the time of setting / resetting), set the value of the inactivity timer to a different value according to the L2 source / destination ID from which the transmission (which caused the timer to be reset) was received. ○ Specifically, different values of the inactivity timer can be (pre-)set for each source / destination L2 ID in the WTRU (e.g., a TX WTRU (e.g., WTRU 102) or an RX WTRU (e.g., WTRU 102)) via, for example, any of PC5-RRC, Uu RRC, pre-configuration, SIB, etc. After receiving a transmission associated with a particular source / destination L2 (e.g., upon receiving), the RX WTRU (e.g., WTRU 102) can set the value of the inactivity timer to the value set for that source / destination L2 ID, and / or - Determine that the behavior during decoding of the inactivity timer is different based on the L2 source / destination ID from which the inactivity timer was started by the transmission, which can 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 ○ Determine whether a transmission can be performed during the execution of the timer.

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

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

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

[0193] g) The RX WTRU (e.g., WTRU 102) can start an inactivity timer at the PHY layer and / or stop the inactivity timer after decrypting a PDU. According to an embodiment, the RX WTRU (e.g., WTRU 102) can start an inactivity timer based on conditions related to the decryption of an SCI in the PHY layer. Following the start of the inactivity timer by the PHY layer, the MAC layer can perform the decryption of the MAC PDU and / or, depending on the decryption result, can stop the inactivity timer or continue the execution of the inactivity timer. For example, it is as follows. -(e.g., RX) The WTRU (e.g., WTRU 102) (PHY layer) can start an inactivity timer when it receives an SCI that meets any of the following (e.g., upon reception). ○ The received transmission corresponds to a unicast transmission and / or the source and / or destination L1 ID matches the source / destination L1 ID of the unicast link currently set 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 groupcast / broadcast service involved. ○ The NDI (in the SCI) is toggled and / or the HARQ process (in the SCI) is associated with the currently assigned HARQ process (e.g., a new transmission is indicated for that HARQ process). ○ The HARQ in the SCI is not currently assigned in the WTRU (indicating a new transmission for a new HARQ process). ○ The received transmission corresponds to a new transmission (e.g., the NDI is toggled). ○ The received transmission corresponds to a retransmission (e.g., the NDI is not toggled), but the RX WTRU (e.g., WTRU 102) did not receive / decrypt the first transmission associated with this retransmission. -(For example, RX) A WTRU (e.g., WTRU 102) (MAC layer) can stop the inactivity timer when any of the following occurs. ○ The PDU is associated with unicast and / or the L2 source / destination ID obtained by decrypting the MAC PDU does not match the L2 source / destination ID of the unicast link established in the WTRU. ○ The PDU is associated with broadcast / groupcast and / or the L2 destination ID obtained by decrypting the MAC PDU does not match the L2 destination ID of the unicast link established in the WTRU. ○ The MAC layer cannot decrypt the MAC PDU. ○ The MAC layer decrypts the MAC PDU, but the MAC PDU contains a 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., when the PHY layer starts the inactivity timer (e.g., at the start), the inactivity timer was not running at that time). ○ The inactivity timer was not (re)started by another PDU while the current PDU was being decrypted.

[0194] For example, when the L2 source / destination ID in the MAC header does not match any of the source / destination IDs involved in the WTRU (e.g., when they do not match), and / or when the inactivity timer is running because the reception of the SCI corresponding to the PDU has been started (and not restarted), the RX WTRU (e.g., WTRU 102) can stop the inactivity timer when decrypting the PDU. Specifically, when the L2 source / destination ID in the MAC header does not match any of the source / destination IDs involved in the WTRU (e.g., when they do not match), and / or when the inactivity timer has not been previously run when the inactivity timer is started by the reception of the PDU (e.g., at the start), the RX WTRU (e.g., WTRU 102) can stop the inactivity timer. For example, when the L2 source / destination ID in the MAC header does not match any of the source / destination IDs involved in the WTRU (e.g., when they do not match), and / or when the inactivity timer has not been (re)started during the time when the inactivity timer was started by the currently decrypted PDU, and / or during the time when the WTRU determines that the L2 source / destination ID in the MAC header does not match any of the source / destination IDs involved in the WTRU, the RX WTRU can stop the inactivity timer when decrypting the PDU.

[0195] According to an embodiment, the TX WTRU (e.g., WTRU 102) can start its 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) can transmit a first new TB to the (e.g., RX) WTRU in time slot N and / or can also permit the transmission of a second new TB to the same (e.g., RX) WTRU in time slot N + 1. Specifically, the TX WTRU (e.g., WTRU 102) can impose no restrictions on the time between the transmissions of two new transmissions, especially when the first transmission occurs at the end of the on-duration or at the end of the duration associated with the previous inactivity timer.

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

[0197] The RX WTRU (e.g., WTRU102) can be active with respect to 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., WTRU102) starts an inactivity timer in the MAC layer but can correct for decoding delays According to an embodiment, the RX WTRU (e.g., WTRU102) can start an inactivity timer based on conditions related to the decoding of the SCI and / or conditions related to the decoding of the MAC PDU.

[0199] For example, an RX WTRU (e.g., WTRU 102) can start an inactivity timer if any of the conditions associated with the SCI (described in another embodiment) are met, the PDU is successfully decoded, and / or conditions associated with the decoded MAC PDU are also met. The conditions associated with the decoded MAC PDU can include any one or combination (and / or) of the following. - The PDU is associated with 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 in the WTRU. - The PDU is associated with 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 contain a CSI report MAC CE (e.g., only CSI report MAC CE) (e.g., there is at least one LCH in the MAC PDU associated with data).

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

[0201] According to an embodiment, the TX WTRU (e.g., WTRU102) can start its inactivity timer at any of the following times, related to the RX WTRU (e.g., WTRU102). - When HARQ feedback is enabled, upon receiving a HARQ ACK following a new transmission. - The number of slots (e.g., (pre-)set or pre-defined) following the first transmission of a PDU by the TX WTRU (e.g., WTRU102). And / or - The number of slots reserved (e.g., (pre-)set or pre-defined) as the retransmission resource in the SCI following the last retransmission resource used by the TX WTRU (e.g., WTRU102) to transmit a PDU or for transmitting the first transmission.

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

[0203] 2.2 Maintenance of Inactivity Timer in RX WTRU and / or TX WTRU (e.g., WTRU102) Applied to Group Cast The described embodiments are defined, for example, for group cast, but can also be applied to unicast and / or broadcast.

[0204] a) The RX / TX WTRU (e.g., WTRU102) starts / uses an inactivity timer based on specific conditions related to group cast (e.g., based on only specific conditions). According to an embodiment, the RX and / or TX WTRU (e.g., WTRU102) in group cast can start / assume / use an inactivity timer associated with DRX under specific conditions (e.g., only at specific times). Specifically, the TX WTRU (e.g., WTRU102) can maintain an inactivity timer associated with a transmission that meets any of the following conditions. - Conditions based on cast type: ○ For example, the TX / RX WTRU (e.g., WTRU102) can start / use an inactivity timer (e.g., only the inactivity timer) for transmissions associated with a specific case (e.g., unicast (e.g., only unicast), or unicast and / or group cast). ○ For example, the TX / RX WTRU (e.g., WTRU102) can combine other conditions with a specific cast type (e.g., only a specific cast type). ■ For example, the TX / RX WTRU (e.g., WTRU102) can start / use an inactivity timer for unicast or for group cast as long as the group cast transmission is associated with a type of HARQ feedback for group cast as follows. - Conditions based on QoS: For example, a TX / RX WTRU (e.g., WTRU 102) can start / use an inactivity timer (e.g., only the 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 report (ACK / NACK report or NACK (e.g., only NACK)) is enabled / disabled: For example, a TX WTRU (e.g., WTRU 102) can start / use an inactivity timer when the transmission by the TX WTRU (e.g., WTRU 102) is HARQ-enabled (e.g., when HARQ is enabled) (e.g., only in the case). For example, a TX WTRU (e.g., WTRU 102) can start / use an inactivity timer when the transmission is associated with HARQ being enabled and / or when a groupcast HARQ type of acknowledgement - negative acknowledgement is used (e.g., when used) (e.g., only in the case). For example, an RX WTRU (e.g., WTRU 102) can start an inactivity timer associated with, for example, an L2 ID when the received transmission is HARQ-enabled (e.g., when HARQ is enabled) (e.g., only in the case). For example, an RX WTRU (e.g., WTRU 102) can start an inactivity timer associated with, for example, an L2 ID when the received transmission is HARQ-enabled using a groupcast acknowledgement - negative acknowledgement type (e.g., when HARQ is enabled) (e.g., only in the case). - Conditions based on a member ID set by a higher layer: ○ For example, if a member ID associated with a specific groupcast transmission (e.g., associated with a groupcast L2 ID) is set in a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102), the TX WTRU (e.g., WTRU 102) and / or the RX WTRU (e.g., WTRU 102) can use an inactivity timer for such groupcast transmission. - Conditions based on group size: ○ For example, if the group number of a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102) is not greater than the set number of PSFCH resources, the TX WTRU (e.g., WTRU 102) and / or the RX WTRU (e.g., WTRU 102) can use an inactivity timer for a specific groupcast transmission (e.g., associated with a groupcast L2 ID). - Conditions based on MCR (Minimum Communication Range): ○ For example, if an MCR is set for transmission, a TX WTRU (e.g., WTRU 102) and / or an RX WTRU (e.g., WTRU 102) can use an inactivity timer for a specific groupcast transmission. Specifically, when MCR is set for at least one of the SLRBs for transmission, the TX WTRU (e.g., WTRU 102) can operate (e.g., assume) using the inactivity timer associated with transmission to the L2 ID. Specifically, following a transmission while any of the timers associated with the active time of the L2 ID is running, the TX WTRU (e.g., WTRU 102) can start the inactivity timer each time the TX WTRU (e.g., WTRU 102) executes a transmission to the L2 ID (or receives an acknowledgement response for the transmission). Otherwise, when MCR is not set, the TX WTRU (e.g., WTRU 102) may not need to start the inactivity timer under such conditions and / or may not need to maintain the activity conditions based on the inactivity timer (e.g., when the on-duration timer is running or the retransmission timer is running (e.g., at the time of execution) (e.g., only in the case), transmission can be permitted). Similarly, the RX WTRU (e.g., WTRU 102) can define its own active time for that L2 ID when it receives at least one packet associated with the MCR of the L2 ID or when the SLRB for transmission to the L2 ID with MCR set is set for the RX WTRU (e.g., WTRU 102). - For example, the TX WTRU (e.g., WTRU 102) and / or the RX WTRU (e.g., WTRU 102) can use the inactivity timer for a specific groupcast when the MCR set for any SLRB is below a threshold. ○ In this case, behavior similar to the above example is expected. - Conditions based on MCR and / or HARQ feedback enabled: ○ For example, the RX and / or the RX WTRU (e.g., WTRU 102) can use the inactivity timer for a specific groupcast transmission with MCR set as long as the HARQ feedback is enabled. ■For example, if an MCR is set for at least one SLRB for transmission to an L2 ID and / or HARQ is enabled, the TX WTRU (e.g., WTRU 102) can use an inactivity timer. ■For example, if an MCR is set for all SLRBs for transmission to a groupcast L2 ID and / or HARQ is enabled, the TX WTRU (e.g., WTRU 102) can use an inactivity timer for that L2 ID, and otherwise, not use it.

[0205] According to an embodiment, the TX / RX WTRU (e.g., WTRU 102) can stop the currently running inactivity timer if one of the conditions or parameters for supporting the inactivity timer changes. For example, the TX / RX WTRU (e.g., WTRU 102) can stop the inactivity timer that is already running if the group size and / or member ID indicated by the upper layer is changed in 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, the RX WTRU (e.g., WTRU 102) can determine whether to reset an inactivity timer associated with, for example, a groupcast transmission, based on the position of the RX WTRU (e.g., WTRU 102) and / or the MCR associated with the transmission. Specifically, the RX WTRU (e.g., WTRU 102) can reset the inactivity timer after (e.g., only after) receiving such a new transmission if the new transmission has an MCR that meets any of the following conditions (e.g., when it has). - The MCR does not exist. - The MCR exists. - The required distance between the transmitter and / or receiver is less than (less than or equal to) the MCR. - The required distance between the transmitter and / or receiver is less than (or equal to) the value obtained by adding (or subtracting) a (pre-set) delta to the MCR. ○ Such a delta can further depend on any of the following. ■ For example, priority, WTRU speed, CBR, number of WTRUs in a group, power saving preference in the RX WTRU (e.g., WTRU102), WTRU capabilities associated with the RX WTRU (e.g., WTRU102).

[0207] The consideration of the distance with respect to the MCR can further be based on the change in the distance with respect to the MCR from a previous transmission, observed by the RX WTRU (e.g., WTRU102). Specifically, if the distance between two WTRUs, or the difference of such a distance compared to the MCR, decreases for each subsequent transmission targeting the L2 ID, the RX WTRU (e.g., WTRU102) can restart the inactivity timer.

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

[0209] According to an embodiment, a TX WTRU (e.g., WTRU 102) can maintain a set of timers corresponding to the timers of an RX WTRU (e.g., WTRU 102). Specifically, the TX WTRU (e.g., WTRU 102) can maintain an inactivity timer for each L2 source / destination ID (for unicast), for each L2 destination ID (for groupcast), and / or for example for each priority / QoS level of each address. The TX WTRU (e.g., WTRU 102) can use the relevant (but different) values of such timers to correct the delay when performing transmissions and / or when performing reliable transmissions. The TX WTRU (e.g., WTRU 102) can start / stop such timers earlier / later than the TX WTRU (e.g., WTRU 102). For example, it is as follows. - A shorter on-duration timer, HARQ RTT timer, or retransmission timer than that of the RX WTRU (e.g., WTRU 102) can be set for the TX WTRU (e.g., WTRU 102). And / or - The TX WTRU (e.g., WTRU 102) can be set to start the on-duration timer earlier in the DRX cycle compared to the RX WTRU (e.g., WTRU 102).

[0210] d) The TX WTRU (e.g., WTRU 102) restarts (or starts) the inactivity timer upon receiving HARQ feedback from one or more WTRUs within the group According to an embodiment, the TX WTRU (e.g., WTRU 102) can restart (or start) the inactivity timer based on the reception of HARQ feedback from one or more WTRUs.

[0211] According to an embodiment, a TX WTRU (e.g., WTRU 102) can maintain a single inactivity timer for all RX WTRUs (e.g., WTRU 102) within a group (with respect to its own transmissions to the group). The TX WTRU (e.g., WTRU 102) can start the inactivity timer in any of the following conditions. - When receiving a HARQ feedback (e.g., ACK or NACK) from a first (e.g., RX) WTRU (e.g., at the time of reception). - When receiving HARQ feedback (e.g., ACK or NACK) from a majority of WTRUs within the group (e.g., a number or percentage of WTRUs exceeding a threshold) (e.g., at the time of reception). - When receiving HARQ feedback from all WTRUs within the group (e.g., at the time of reception). - When receiving HARQ feedback from a specific subset of WTRUs within the group (e.g., at the time of reception) associated with, for example, a pre - set pattern or a set of member IDs (e.g., the ID closest to its own ID, or ID1~x). - When receiving HARQ feedback within a certain time from the first transmission. And / or - When receiving HARQ feedback (e.g., at the time of reception) following at least x (re)transmissions of the PDU.

[0212] For example, the TX WTRU (e.g., WTRU 102) can start the inactivity timer when receiving HARQ feedback (either ACK or NACK) from all RX WTRUs (e.g., WTRU 102) within the group (e.g., at the time of reception).

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

[0214] According to an embodiment, the TX WTRU (e.g., WTRU 102) can maintain an inactivity timer associated with each of the RX WTRUs (e.g., WTRU 102) in the group. When the TX WTRU (e.g., WTRU 102) receives HARQ feedback from a particular (e.g., RX) WTRU (e.g., WTRU 102) (e.g., at the time of reception), it can start an inactivity timer specific to that (e.g., RX) WTRU (e.g., WTRU 102). In this solution, the TX WTRU (e.g., WTRU 102) can transmit a subsequent new transmission of its L2 ID (or to its group) as long as any of the following conditions are met. - The inactivity timer associated with each RX WTRU (e.g., WTRU 102) is running. - The inactivity timers associated with a majority of the WTRUs in the group (e.g., a number or percentage of WTRUs exceeding a threshold) are running. - The inactivity timer associated with at least one WTRU in the group is running. And / or - The inactivity timers associated with a particular subset of the WTRUs in the group are running (such a subset may correspond to a pre-set 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 with feedback possible and groups / transmissions with feedback not possible According to an embodiment, a TX WTRU (e.g., WTRU 102) can have different criteria for starting an inactivity timer based on transmissions to a group. Such criteria can depend on any of the following. - Whether HARQ feedback is enabled or disabled. - Cast type. - HARQ feedback type (acknowledgment - negative acknowledgment feedback and negative (e.g., negative only) feedback). - The presence and / or value of MCR. - Whether PSFCH resources are configured in a resource pool.

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

[0217] f) A TX WTRU (e.g., WTRU 102) uses a mechanism to improve the reliability of transmissions when feedback is not possible (e.g., only when not possible) According to an embodiment, a TX WTRU (e.g., WTRU 102) can use different values of the inactivity timer for different start criteria of the inactivity timer. Additionally, a TX WTRU (e.g., WTRU 102) can employ a mechanism to improve the reliability of transmissions such as any of the following during the inactivity time or towards the end of the on - duration. - Increase transmission power. ○For example, a (e.g., TX) WTRU (e.g., WTRU 102) can increase its transmission power for transmissions that occur outside the on-duration, or for transmissions where a portion of the retransmission occurs outside the on-duration. - Increase the number of retransmissions. ○For example, a (e.g., TX) WTRU (e.g., WTRU 102) can increase the number of retransmissions for transmissions that occur outside the on-duration, or for transmissions where a portion of the retransmission can occur outside the on-duration. - Guarantee that the retransmission fits within the on-duration or within a subset of the resources within the on-duration. ○For example, a (e.g., TX) WTRU (e.g., WTRU 102) can perform resource selection such that the number of retransmission resources fits within the on-duration, where, for example, this number of resources can further depend on QoS and / or CBR. For example, a (e.g., TX) WTRU (e.g., WTRU 102) can be configured to set the number of (e.g., required) retransmission resources to be performed within the on-duration based on priority and / or CBR. For example, a (e.g., TX) WTRU (e.g., WTRU 102) can be configured to set the number of retransmission resources to be performed when the inactivity timer of the TX WTRU (e.g., WTRU 102) is running (e.g., at runtime) based on QoS and / or CBR, and the number of such retransmissions can vary depending on the following. ○In a general example, a (e.g., TX) WTRU (e.g., WTRU 102) can be configured to set 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., at runtime) 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 the inactivity timer is running (e.g., at runtime) in a TX WTRU (e.g., WTRU 102) compared to when the inactivity timer is not running (e.g., not running). - Improve the modulation and / or coding scheme (MCS) of the transmission.

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

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

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

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

[0222] g) The TX WTRU (e.g., WTRU 102) performs a transmission within the active time According to an embodiment, for example, in the case of a transmission associated with HARQ feedback (e.g., a unicast transmission in which HARQ is enabled), the TX WTRU (e.g., WTRU 102) can perform the transmission at least K slots before the expiration of an inactivity timer, an on-duration timer, a retransmission timer (or any timer in the RX WTRU (e.g., WTRU 102) associated with an active transmission). K can be associated with the latency associated with the HARQ feedback. Specifically, K can be any of the following. - The time difference between the transmission and / or one (or multiple or all in the case of multicast) PSFCH resources for the HARQ feedback associated with that transmission. - A (pre) set value that enables the (e.g., TX) WTRU (e.g., WTRU 102) to schedule a retransmission before the expiration of such a timer (in the case of DTX). - The time between the first transmission and / or the first retransmission. - The time between the first transmission and / or the Nth retransmission (N can depend on CBR, QoS, etc.). - The time between the first transmission and / or the last retransmission indicated in the SCI of the first transmission. And / or - The time between the first transmission in the SCI and / or the PSFCH resources associated with the last retransmission indicated in the SCI.

[0223] h) The TX WTRU (e.g., WTRU 102) forces / enables HARQ feedback for a specific transmission to an RX WTRU (e.g., WTRU 102) in DRX According to an embodiment, the TX WTRU (e.g., WTRU 102) can enable HARQ feedback to an RX WTRU (e.g., WTRU 102) in DRX regardless of the LCH HARQ feedback enable setting. Thereby, the TX WTRU (e.g., WTRU 102) can accurately start an inactivity timer based on the reception of HARQ feedback from the TX WTRU (e.g., WTRU 102).

[0224] The TX WTRU (e.g., WTRU 102) can enable HARQ feedback to the RX WTRU (e.g., WTRU 102) for all transmissions to that RX WTRU (e.g., WTRU 102). Alternatively, the TX WTRU (e.g., WTRU 102) can enable HARQ feedback to the RX WTRU (e.g., WTRU 102) under any of the following conditions. - Transmissions for which the on-duration timer is not running. - Transmissions for which the inactivity timer is running. - Transmissions in which the (e.g., TX) WTRU (e.g., WTRU 102) still has in its buffer data that is scheduled / configured to be transmitted before the next on-duration of the RX WTRU (e.g., WTRU 102). - Transmissions associated with the last grant during the on-duration associated with the RX WTRU (e.g., WTRU 102). - Transmissions associated with the last grant in the inactivity timer associated with the RX WTRU (e.g., WTRU 102). - Transmissions in which the (e.g., TX) WTRU still has data in its buffer (the data can have a high priority (e.g., the priority is above a threshold)). - Transmissions in which the (e.g., TX) WTRU still has data in its buffer and the PDB is less than the time until the next on-duration. - Transmissions in which the (e.g., TX) WTRU still has data in its buffer and the LCHs with available data are configured such that HARQ feedback enabled transmissions are enabled before transmission of these LCHs.

[0225] 2.3 UL prioritization or inactivity timer handling in the case of half-duplex a) The RX WTRU (e.g., WTRU 102) can start the inactivity timer under conditions not related to data reception According to an embodiment, the RX WTRU (e.g., WTRU 102) can start / restart an inactivity timer without receiving a transmission. Specifically, the RX WTRU (e.g., WTRU 102) can start / restart the inactivity timer after executing one or more transmissions (either UL transmission or SL transmission) (e.g., during execution), or after decoding another interface (Uu or SL on a different carrier) that prevents such (e.g., RX) WTRU (e.g., WTRU 102) from decoding on the sidelink at the time of transmission (e.g., at the time of decoding).

[0226] According to an embodiment, the RX WTRU (e.g., WTRU 102) can start / restart an inactivity timer at the time when the (e.g., RX) WTRU (e.g., WTRU 102) executes a transmission / reception that prevents it from decoding on the sidelink. This can be during the active monitoring time / period of the (e.g., RX) WTRU (e.g., WTRU 102), and can be during the execution of the on-duration timer, during the execution of the inactivity timer, or during the execution of any other timer that defines active sidelink monitoring. Alternatively, the (e.g., RX) WTRU (e.g., WTRU 102) can start the inactivity timer at a (pre-)set or pre-defined point in time within any time, such as the on-duration (defined by the on-duration timer) or the inactivity timer duration, based on one of the following conditions. For example, the RX WTRU (e.g., WTRU 102) can start / restart the inactivity timer in any of the following conditions after satisfying one of the following conditions (e.g., when satisfied). - In a (pre-)set or pre-defined 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 (pre-set or defined) slots before the last slot associated with the on-duration or inactivity timer duration ends.

[0227] According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) can start / restart an inactivity timer without receiving a transmission associated with a sidelink-related condition (in order to actively extend the activity timer). Such conditions can be related to any of the following. - Conditions related to CBR: ○ For example, a (e.g., RX) WTRU (e.g., WTRU 102) can start / restart an inactivity timer if the CBR is greater than a set threshold. - Conditions related to the number / amount / percentage of sidelink decoding opportunities that failed during the active time: ○ For example, a (e.g., RX) WTRU (e.g., WTRU 102) can start / restart an inactivity timer if it fails to decode the sidelink in at least N slots or at least X% of the slots during the on-duration or during the currently running inactivity timer, where N and / or X% can be (pre-)set. - Conditions related to the QoS of the expected data that can be determined based on the PC5 QoS identifier (PQI) of one or more established QoS flows, the settings 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, a (e.g., RX) WTRU (e.g., WTRU 102) can determine whether to start / restart an inactivity timer based on the QoS of the expected data (e.g., start / restart the inactivity timer if the QoS of the expected data is higher than a threshold QoS). For example, a (e.g., RX) WTRU (e.g., WTRU 102) can determine either N or X% in the above example based on the expected QoS of the data. - Conditions related to the type of (e.g., RX) WTRU (e.g., WTRU 102) or power saving preference: For example, a (e.g., RX) WTRU (e.g., WTRU 102) can start / restart an inactivity timer when it is a specific WTRU type or when a specific power saving preference is effective when another of the above conditions is triggered.

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

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

[0230] According to an embodiment, in step 620, a first WTRU (e.g., RX WTRU) can be configured to allocate a HARQ process to one or more transmission resources by the first WTRU (e.g., RX WTRU).

[0231] According to an embodiment, in step 630, a first WTRU (e.g., RX WTRU) can be configured to monitor, by the first WTRU (e.g., RX WTRU), one or more transmission resources for sidelink communication for retransmission from the second WTRU (e.g., TX 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., RX WTRU) may be configured to start a DRX retransmission period associated with a HARQ process when the HARQ RTT period expires and / or on the condition that the HARQ process is not decoded by the first WTRU (e.g., RX WTRU).

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

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

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

[0236] For example, the first WTRU (e.g., RX WTRU) may be configured to determine the value of the HARQ RTT timer based on either the resource allocation mode for sidelink communication between the first WTRU (e.g., RX WTRU) and / or the second WTRU (e.g., 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 is started based on any one of: the resource allocation mode of sidelink communication between a first WTRU (e.g., RX WTRU) and / or a second WTRU (e.g., TX WTRU); an indication of additional retransmission resources reserved for a HARQ process by a received SCI or another previously received SCI; expiration of a HARQ RTT period in a time slot associated with resources reserved in another previously received SCI; and / or decoding of a received SCI in a time slot associated with resources reserved in another previously received SCI.

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

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

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

[0241] According to an embodiment, in step 710, a first WTRU (e.g., RX WTRU) can be configured to receive, from a second WTRU (e.g., TX WTRU), 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 whether at least one second transmission resource is reserved for retransmission of D2D communication.

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

[0243] According to an embodiment, in step 730, the first WTRU (e.g., RX WTRU) can be configured to receive a retransmission of D2D communication after the end of the determined sleep period.

[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 at least one reserved second transmission resource.

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

[0246] For example, the first WTRU (e.g., RX WTRU) can be further configured to obtain the value of the sleep period by receiving network configuration information indicating the value of the sleep period.

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

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

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

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

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

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

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

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

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

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

[0257] According to an embodiment, at step 820, the first WTRU (e.g., RX WTRU) can be configured to determine a sleep period of the first WTRU (e.g., 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, at step 830, the first WTRU (e.g., RX WTRU) can be configured to receive the retransmission of the D2D communication after the end of the determined sleep period.

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

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

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

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

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

[0264] According to an embodiment, in step 930, a first WTRU (e.g., RX WTRU) can be configured to receive a retransmission of D2D communication after the end of a determined sleep period.

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

[0266] According to an embodiment, in step 1010, a first WTRU (e.g., TX WTRU) can be configured to transmit D2D control information to a second WTRU (e.g., 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, a first WTRU (e.g., TX WTRU) can be configured to transmit additional D2D control information to a second WTRU (e.g., RX WTRU), the additional D2D control information including third information indicating at least one third transmission resource reserved for retransmission of D2D communication, on the condition that at least one second transmission resource reserved for retransmission of D2D communication is associated with a preemption indication / information, where at least one third transmission resource is reserved after (e.g., in a first window of transmission resources after the second transmission resource) at least one second transmission resource indicated by the second information.

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

[0269] In addition, any feature, variation, or embodiment described with respect to the method is compatible with an apparatus device including means for processing the disclosed method, is compatible with a device comprising a processor configured to process the disclosed method, is compatible with a computer program product including program code instructions, and is compatible with a non-transitory computer-readable storage medium storing the program instructions.

[0270] Conclusion Although the features and elements have been provided in specific combinations above, those of ordinary skill in the art will understand that each feature or each 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 in this application, and these embodiments are intended as examples of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the present invention. Any element, operation, or instruction used in the description of this application should not be construed as important or essential to the present invention unless explicitly presented as such. In addition to those listed herein, functionally equivalent methods and apparatuses within the scope of the present disclosure 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, and is limited together with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

[0271] The foregoing embodiments have been described in relation to the terminology and structure of infrared-compatible devices (i.e., infrared emitting devices and receivers) for the sake of brevity. However, the described embodiments are not limited to these systems and can 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 terms used in this specification are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the term "video" or the term "image" can mean any of a snapshot, a single image, and / or a plurality of 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" or its abbreviation "HMD" can (i) mean or include a wireless transmit and / or receive unit (WTRU). (ii) any of a plurality of embodiments of a WTRU, (iii) a wireless and / or wired compatible (e.g., tetherable) device configured to have some or all of the structure and functionality of a WTRU, (iii) a wireless and / or wired compatible device configured to have less structure and functionality than all of the structure and functionality of a WTRU, or (iv) otherwise. Details of exemplary WTRUs that can represent any WTRU listed herein are provided herein with respect to FIGS. 1A - 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. One of ordinary skill in the art will recognize that devices other than a head-mounted display can be utilized and that some or all of the present disclosure and the various disclosed embodiments can be modified accordingly without undue experimentation. Examples of such other devices can include drones or other devices configured to stream information for providing an augmented reality experience.

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

[0274] Without departing from the scope of the present invention, variations of the methods, apparatuses, and systems provided above are possible. Considering the various embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the appended claims. For example, the embodiments provided herein include a handheld device that may include or be utilized with any suitable voltage source, such as a battery that provides any suitable voltage.

[0275] Furthermore, note the other devices including a processing platform, computing system, controller, and processor in the above embodiments. These devices may include at least one central processing unit ("CPU") and memory. According to the convention of those skilled in the art of computer programming, references to operations, and symbolic representations of operations or instructions may be implemented by various CPUs and memories. Such operations and operations or instructions may be referred to as "executed," "executed by a computer," or "executed by a CPU."

[0276] Those of ordinary skill in the art will appreciate that operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. An electrical system represents data bits that can cause a resulting transformation or reduction of electrical signals, maintains the data bits at memory locations in a memory system, thereby restructuring or otherwise changing the operation of the CPU and the processing of other signals. The memory location where the data bits are maintained is a physical location having specific electrical, magnetic, optical, or organic characteristics corresponding to or representing 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] Data bits may also be maintained on a computer-readable medium including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage systems readable by a CPU. The computer-readable medium may include cooperative or interconnected computer-readable media that exist exclusively on a processing system or are distributed among multiple interconnected processing systems that may be local or remote to the processing system. It should be understood that embodiments are not limited to the memories described above, and that other platforms and memories may support the provided methods.

[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. The computer-readable instructions may be executed by a processor of a mobile body, network element, and / or any other computing device.

[0279] There is little difference between the hardware implementation and the software implementation of the system aspects. Whether to use hardware or software is generally (although in certain situations the choice between hardware and software may be crucial) a design choice representing a cost - effectiveness trade - off. There can be various vehicles (e.g., hardware, software, and / or firmware) through which the processes and / or systems and / or other technologies described herein can be effective, and the preferred vehicle can vary depending on the situation in which the process and / or system and / or other technology is deployed. For example, if the implementer determines that speed and accuracy are of utmost importance, the implementer can primarily select a hardware and / or firmware vehicle. If flexibility is of utmost importance, the implementer can primarily select a software implementation. Alternatively, the implementer may select some combination of hardware, software, and / or firmware.

[0280] In the foregoing detailed description, various embodiments of devices and / or processes have been shown through the use of block diagrams, flowcharts, and / or examples. As long as 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 can be implemented individually and / or collectively 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 formats. However, some aspects of the embodiments disclosed herein may be equivalently implemented in an integrated circuit as one or more computer programs operating on one or more computers (e.g., as one or more programs operating on one or more computer systems), as one or more programs operating on one or more processors (e.g., as one or more programs operating on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing the circuitry and / or writing the code for the software and / or firmware is within the scope of the skill of those in the art in light of this disclosure. Further, it will be understood by those skilled in the art that the mechanisms of the subject matter described herein can be distributed as various forms of program products, and that the exemplary embodiments of the subject matter described herein apply regardless of the particular type of signal carrying medium used to actually carry out the distribution.Examples of signal-carrying media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memories, and transmission media such as digital and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication links, etc.).

[0281] It will be recognized by those skilled in the art that it is common in the art to describe devices and / or processes in the manner described herein and then, using engineering techniques, to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. A typical data processing system generally includes one or more of a system unit housing, a video display device, memories such as volatile and non-volatile memories, processors such as microprocessors and digital signal processors, computing entities such as operating systems, drivers, graphical user interfaces, and application programs, one or more interactive devices such as touch pads or screens, and / or control systems such as feedback loops and control motors (e.g., feedback that senses position and / or speed, control motors that move and / or adjust components and / or quantities). It will be recognized by those skilled in the art that a typical data processing system can be implemented using any suitable commercially available components as typically found in a data computing / communication system and / or a network computing / communication system.

[0282] The subject matter described in this specification may refer to different components that are included within or connected to different other components. It should be understood that such illustrated architectures are merely examples, and in practice, many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components for achieving the same functionality is effectively "associated" so that the desired functionality can be achieved. Thus, any two components in this specification that are combined to achieve a particular functionality can 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 can also be considered to be "operably connected" or "operably coupled" to each other for achieving the desired functionality, and any two components that can be so associated can also be considered to be "operably couplable" to each other for achieving the desired functionality. Specific examples of operably couplable include, but are not limited to, components that are physically mating and / or physically interacting, and / or components that are wirelessly interacting and / or wirelessly interacting, and / or components that are logically interacting and / or logically interactable.

[0283] Regarding the use of substantially any plural and / or singular terms in this specification, one of ordinary skill in the art can convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. In this specification, various singular / plural permutations may be explicitly described for clarity purposes.

[0284] Generally, it will be understood by those skilled in the art that the terms used in this specification, particularly in the appended claims (e.g., the body of the appended claims), are generally intended to be "non-limiting" terms (e.g., the term "comprising" should be interpreted as "comprising but not limited to", the term "having" should be interpreted as "having at least", and the term "including" should be interpreted as "including but not limited to"). Further, if a specific number of recitations of a claim is intended, such intention will be expressly recited in the claim, and it will be understood by those skilled in the art that if there is no such recitation, such intention does not exist. For example, if only one item is intended, the term "single" or similar words may be used. To assist understanding, the following appended claims and / or the description in this specification may include the use of introductory phrases such as "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to limit any particular claim that introduces a claim recitation by the indefinite article "a" or "an" to an embodiment that includes only one such recitation, even if the same claim includes both an introductory phrase such as "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 as meaning "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim recitations. Further, even if a specific number of recitations of a claim is expressly recited, it will be recognized by those skilled in the art that such recitation should be interpreted as meaning at least the recited number (e.g., a simple recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations).Furthermore, when notations similar to "at least one of A, B, and C" are used, generally, such a structure is intended in the sense that those skilled in the art will understand the notation (e.g., "a system having at least one of A, B, and C" includes a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, but is not limited thereto). When notations similar to "at least one of A, B, or C" are used, generally, such a structure is intended in the sense that those skilled in the art will understand the notation (e.g., "a system having at least one of A, B, or C" includes a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, but is not limited thereto). It will be further understood by those skilled in the art that substantially any disjunctive word and / or phrase presenting two or more alternative terms in any of the description, claims, or drawings is to be understood as contemplating the possibility of including either one of the terms, any of the terms, or both terms. For example, the phrase "A or B" is to be understood as including the possibilities of "A" or "B" or "A and B". Further, as used herein, the term "any of" following a list of multiple items and / or a list of multiple categories of items is intended to include "any of", "any combination of", "any plurality of", and / or "any combination of a plurality of" of the items and / or categories of items, individually or in combination with other items and / or other categories of items. Further, as used herein, the term "set" is intended to include any number of items including zero. Further, 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 "plural".

[0285] Furthermore, when a feature or aspect of the present disclosure is described from the perspective of a Markush group, those skilled in the art will recognize that the present disclosure is thereby also described from the perspective of any individual member of the Markush group or a subgroup of members.

[0286] As will be understood by those skilled in the art, for all purposes, such as for the purpose of providing a written description, all ranges disclosed herein include any possible sub-ranges and combinations of sub-ranges thereof. Any recited range can be readily recognized as enabling, by way of sufficient explanation, that the same range can be decomposed into at least equal halves, thirds, fourths, fifths, tenths, and the like. As a non-limiting example, each range described herein can be readily decomposed into lower thirds, middle thirds, and upper thirds, and the like. Also, as will be understood by those skilled in the art, all words such as "up to", "at least", "greater than", "less than", and the like, include the recited number and mean a range that can be further decomposed into sub-ranges as described above. Finally, as will be understood by those skilled in the art, a range includes 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 being limited to the order provided or the elements provided, unless specifically so recited. Additionally, in any claim, the use of the term "means for" is intended to invoke 35 U.S.C. § 112, paragraph 6, or the means-plus-function claim format, and no claim that does not have the term "means for" is 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, (1) first information indicating at least a first transmission resource reserved for transmission, the first information having a priority associated with the transmission; (2) second information indicating whether at least one second transmission resource is reserved for sidelink retransmission of the transmission; and (3) receiving sidelink control information including an expected packet delay budget (PDB) from the second WTRU, determining a maximum PDB based on the priority associated with the transmission, determining a timer value of a hybrid automatic repeat request (HARQ) round trip time (RTT) timer associated with a sidelink process, wherein the timer value is determined to be a first value on condition that HARQ feedback is valid for an associated sidelink process, wherein the timer value is determined to be a second value on condition that the HARQ feedback is invalid for the associated sidelink process, starting the HARQ RTT timer associated with the sidelink process on condition that the expected PDB is less than the determined maximum PDB, wherein the HARQ RTT timer is started in a first time slot on condition that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission, wherein the HARQ RTT timer is started in a second time slot on condition that the second information indicates that no second transmission resource is reserved for the sidelink retransmission, A first WTRU configured to perform the above.

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

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

4. The first WTRU according to claim 1, wherein the second time slot follows the at least first transmission resource, on the condition that the HARQ feedback is invalid for the associated sidelink process and on the condition that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission.

5. The first WTRU according to claim 1, wherein the second time slot follows a resource reserved for the transmission of the HARQ feedback, on the condition that the HARQ feedback is invalid for the associated sidelink process and on the condition that the second information indicates that a second transmission resource is not reserved for the sidelink retransmission.

6. The first WTRU according to claim 1, 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 the sidelink cast type.

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

8. A method implemented by a first wireless transmit / receive unit (WTRU) for a sidelink with a second WTRU, the method comprising: receiving from the second WTRU (1) first information indicating at least a first transmission resource reserved for transmission, the first information having a priority associated with the transmission; (2) second information indicating whether at least one second transmission resource is reserved for a sidelink retransmission of the transmission; and (3) sidelink control information including an expected packet delay budget (PDB); determining a maximum PDB based on the priority associated with the transmission; determining a timer value of a hybrid automatic repeat request (HARQ) round trip time (RTT) timer associated with a sidelink process, wherein, on the condition that the HARQ feedback is valid for the associated sidelink process, the timer value is determined as a first value; and on the condition that the HARQ feedback is invalid for the associated sidelink process, the timer value is determined as a second value. Starting the HARQ RTT timer associated with the sidelink process, on condition that the expected PDB is smaller than the determined maximum PDB, wherein the HARQ RTT timer is started in a first time slot, on condition that the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission, and the HARQ RTT timer is started in a second time slot, on condition that the second information indicates that no second transmission resource is reserved for the sidelink retransmission, comprising a method. **Claim 9** The method according to claim 8, further comprising receiving network configuration information indicating the first value and the second value. **Claim 10** The method according to claim 8, wherein the first time slot follows the transmission of the HARQ feedback, on condition that the HARQ feedback is valid for the associated sidelink process. **Claim 11** The method according to claim 8, wherein the second time slot follows at least the first transmission resource, on condition that the HARQ feedback is invalid for the associated sidelink process and the second information indicates that at least one second transmission resource is reserved for the sidelink retransmission. **Claim 12** The method according to claim 8, wherein the second time slot follows the resource reserved for the transmission of the HARQ feedback, on condition that the HARQ feedback is invalid for the associated sidelink process and the second information indicates that no second transmission resource is reserved for the sidelink retransmission. **Claim 13** The method according to claim 8, 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 the sidelink cast type. **Claim 14** The method according to claim 8, further comprising sending the sidelink retransmission after the expiration of the HARQ RTT timer.

Images