CN117296437A

CN117296437A - Method, architecture, apparatus and system for performing discontinuous reception on side chains

Info

Publication number: CN117296437A
Application number: CN202280028960.1A
Authority: CN
Inventors: 马蒂诺·弗雷达; 黄祥; 邓涛; 李文一; 保罗·马里内尔
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2021-03-11
Filing date: 2022-03-09
Publication date: 2023-12-26
Also published as: CN118200874A

Abstract

The present disclosure relates to methods and apparatus for performing discontinuous reception using V2X enhancement. In an embodiment, a method implemented by a first WTRU for device-to-device (D2D) communication between the first WTRU and a second WTRU is disclosed, the method may include any one of: receiving D2D control information from a second WTRU, the D2D control information comprising: (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; determining a sleep period of the first WTRU ending before a receive time of a retransmission of the D2D communication, wherein the sleep period is based on the second information; and receiving a retransmission of the D2D communication after the determined sleep period ends.

Description

Method, architecture, apparatus and system for performing discontinuous reception on side chains

Cross Reference to Related Applications

The present application claims the benefit of (i) U.S. provisional patent application No. 63/159,792 filed on day 3, month 11 of 2021 and (ii) U.S. provisional patent application No. 63/185,747 filed on day 5, month 7 of 2021, each of which are incorporated herein by reference.

Technical Field

Embodiments disclosed herein relate generally to wireless communications and, for example, relate to methods, apparatuses, and systems for performing Discontinuous Reception (DRX) using V2X enhancements.

Background

The 5G specification includes providing DRX to save energy in the WTRU. The main purpose of DRX is to reduce battery consumption in situations where a wireless transmit/receive unit (WTRU) does not have uplink or downlink data to process, e.g., in this case. Thus, the WTRU may enter a sleep mode in which the RF interface is in a low power or off mode. The mobile unit may initiate to process information when traffic associated with the WTRU is desired.

Vehicular communication is a communication mode whereby WTRUs may communicate directly with each other. There are two scenarios for vehicle-to-everything (V2X) operation:

(a) An in-coverage scenario in which the WTRU receives assistance from the network to begin transmitting and receiving V2X messages, and (b) an out-of-coverage scenario in which the WTRU begins transmitting and receiving V2X messages using some pre-configured parameters.

V2X communications are supported in release 14LTE and inspired by previous work on device-to-device (D2D) communications. V2X communication services may consist of four different types:

(i) V2V (vehicle-to-vehicle): the vehicle WTRUs may communicate directly with each other.

(ii) V2I (vehicle to infrastructure): the vehicle WTRU may communicate with a roadside unit/evolved node B (RSU/eNB).

(iii) V2N (vehicle to network): the vehicle WTRU may communicate with a core network.

(iv) V2P (vehicle to pedestrian): the vehicle WTRU may communicate with a WTRU having special conditions (e.g., low battery capacity).

Drawings

A more detailed understanding can be obtained from the following detailed description, which is given by way of example in connection with the accompanying drawings. As with the detailed description, the drawings in such figures are examples. Accordingly, the drawings and detailed description are not to be regarded as limiting, and other equally effective examples are possible and contemplated. Additionally, like reference numerals ("ref") in the drawings denote like elements, and wherein:

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

fig. 1B is a system diagram illustrating an example WTRU that may be used within the communication system shown in fig. 1A, in accordance with an embodiment;

fig. 1C is a system diagram illustrating an example Radio Access Network (RAN) and an example Core Network (CN) that may be used within the communication system shown in fig. 1A, according to an embodiment;

Fig. 1D is a system diagram illustrating another example RAN and another example CN that may be used in the communication system shown in fig. 1A according to an embodiment;

FIG. 2 illustrates a non-roaming 5G system architecture for PC5 and Uu based V2X communications;

FIG. 3 depicts an exemplary establishment of a secure layer 2 link on PC 5;

fig. 4A, 4B, 4C show examples of timing diagrams of a hybrid automatic repeat request (HARQ) Round Trip Time (RTT) timer and a retransmission timer;

fig. 5 is a flow chart of a process involving determining a sidelink monitoring time for a WTRU;

figure 6 is a diagram illustrating an example of a method implemented by a first WTRU for side link (e.g., D2D) communication between the first WTRU and a second WTRU;

fig. 7 is a diagram illustrating another example of a method implemented by a first WTRU for D2D communication between the first WTRU and a second WTRU;

fig. 8 is a diagram illustrating another example of a method implemented by a first WTRU for D2D communication between the first WTRU and a second WTRU;

fig. 9 is a diagram illustrating another example of a method implemented by a first WTRU for D2D communication between the first WTRU and a second WTRU; and is also provided with

Figure 10 is a diagram illustrating another example of a method implemented by a first WTRU for D2D communication between the first WTRU and a second WTRU.

Detailed Description

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 should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the description below. Furthermore, embodiments and examples not specifically described herein may be practiced in place of or in combination with embodiments and other examples that are explicitly, implicitly, and/or inherently described, disclosed, or otherwise provided (collectively, "provided"). Although various embodiments are described and/or claimed herein, wherein an apparatus, system, device, etc., and/or any element thereof, performs an operation, procedure, algorithm, function, etc., and/or any portion thereof, it is to 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, procedure, algorithm, function, etc., and/or any portion thereof.

Example communication System

The methods, apparatus and systems provided herein are well suited for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to fig. 1A-1D, wherein various elements of a network may utilize, perform, adapt and/or configure the methods, apparatuses and systems provided herein, according to and/or with respect to the methods, apparatuses and systems provided herein.

Fig. 1A is a system diagram illustrating an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messages, broadcasts, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), frequency Division Multiple Access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero Tail (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter Bank Multicarrier (FBMC), and the like.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, radio Access Networks (RANs) 104/113, CNs 106/115, public Switched Telephone Networks (PSTN) 108, the internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. As an example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include (or may be) User Equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal Digital Assistants (PDAs), smartphones, laptop computers, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, internet of things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in an industrial and/or automated processing chain environment), consumer electronics devices, devices operating on a commercial and/or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d, for example, to facilitate access to one or more communication networks, such as the CN 106/115, the internet 110, and/or the network 112. As an example, the base stations 114a, 114B may be any of a Base Transceiver Station (BTS), a Node B (NB), an evolved node B (eNB), a Home Node B (HNB), a home evolved node B (HeNB), a g node B (gNB), an NR node B (NR NB), a site controller, an Access Point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

Base station 114a may be part of RAN 104/113 that may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), radio Network Controllers (RNCs), relay nodes, and the like. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of wireless services to a particular geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, i.e., one for each sector of a cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each or any sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

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

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

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may use Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro) to establish the air interface 116.

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a new air interface (NR) to establish the air interface 116.

In embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, e.g., using a Dual Connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., enbs and gnbs).

In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., wireless fidelity (Wi-Fi)), IEEE 802.16 (i.e., worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000 1X, CDMA EV-DO, tentative standard 2000 (IS-2000), tentative standard 95 (IS-95), tentative standard 856 (IS-856), global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, home node B, home evolved node B, or access point, and may utilize any suitable RAT to facilitate wireless connections in local areas such as businesses, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, and the like. In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-a Pro, NR, etc.) to establish any of a micro-cell, pico-cell, or femto-cell. As shown in fig. 1A, the base station 114b may be directly connected to the internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106/115.

The RANs 104/113 may communicate with the CNs 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location based services, prepaid calls, internet connections, video distribution, etc., and/or perform advanced security functions such as user authentication. Although not shown in fig. 1A, it should be appreciated that the RANs 104/113 and/or CNs 106/115 may communicate directly or indirectly with other RANs that employ the same RAT as the RANs 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113 that may utilize NR radio technologies, the CN 106/115 may also communicate with another RAN (not shown) employing any of GSM, UMTS, CDMA, wiMAX, E-UTRA, or Wi-Fi radio technologies.

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112.PSTN 108 may include circuit-switched telephone networks that provide Plain Old Telephone Services (POTS). The internet 110 may include a global system for interconnecting computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), user Datagram Protocol (UDP), and/or Internet Protocol (IP) in the TCP/IP internet protocol suite. Network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RANs 104/114 or a different RAT.

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

Fig. 1B is a system diagram illustrating an exemplary WTRU 102. As shown in fig. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, a non-removable memory 130, a removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and/or other elements/peripherals 138, etc. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together, for example, in an electronic package or chip.

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

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

The transceiver 120 may be configured to modulate signals to be transmitted by the transmit/receive element 122 and demodulate signals received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touchpad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), read Only Memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may never physically locate memory access information on the WTRU 102, such as on a server or home computer (not shown), and store the data in that memory.

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

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 in lieu of information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114 b) over the air interface 116 and/or determine its location based on the timing of signals received from two or more nearby base stations. It should be appreciated that the WTRU 102 may obtain location information by any suitable location determination method while remaining consistent with an embodiment.

The processor 118 may also be coupled to other elements/peripherals 138 that may include one or more software modules/units and/or hardware modules/units that provide additional features, functionality, and/or wired or wireless connections. For example, the elements/peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (e.g., for photos and/or videos), universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset,Modules, frequency Modulation (FM) radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and/or augmented reality (VR/AR) devices, activity trackers, and the like. The element/peripheral 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.

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

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

RAN 104 may include enode bs 160a, 160B, 160c, but it should be understood that RAN 104 may include any number of enode bs while remaining consistent with an embodiment. The enode bs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the evolved node bs 160a, 160B, 160c may implement MIMO technology. Thus, the enode B160a may use multiple antennas to transmit wireless signals to and receive wireless signals from the WTRU 102a, for example.

Each of the evolved node bs 160a, 160B, and 160c may be associated with a particular cell (not shown) and may be configured to process radio resource management decisions, handover decisions, user scheduling in the Uplink (UL) and/or Downlink (DL), and so on. As shown in fig. 1C, the enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

The CN 106 shown in fig. 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) gateway (PGW) 166. Although each of the foregoing elements are depicted as part of the CN 106, it should be understood that any of these elements may be owned and/or operated by an entity other than the CN operator.

MME 162 may be connected to each of evolved node bs 160a, 160B, and 160c in RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating the user of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide control plane functionality for switching between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and/or WCDMA.

SGW 164 may be connected to each of the evolved node bs 160a, 160B, 160c in RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102 c. The SGW 164 may perform other functions such as anchoring user planes during inter-enode B handover, triggering paging when DL data is available to the WTRUs 102a, 102B, 102c, managing and storing the contexts of the WTRUs 102a, 102B, 102c, etc.

The SGW 164 may be connected to a PGW 166 that may provide the WTRUs 102a, 102b, 102c with access to a packet switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

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

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

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

A WLAN in an infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STA and leading to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may pass the traffic to the destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Point-to-point traffic may be sent between (e.g., directly between) the source and destination STAs using Direct Link Setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

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

High Throughput (HT) STAs may communicate using 40MHz wide channels, for example, via a combination of a primary 20MHz channel with an adjacent or non-adjacent 20MHz channel to form a 40MHz wide channel.

Very High Throughput (VHT) STAs may support channels that are 20MHz, 40MHz, 80MHz, and/or 160MHz wide. 40MHz and/or 80MHz channels may be formed by combining consecutive 20MHz channels. The 160MHz channel may be formed by combining 8 consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this may be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data may pass through a segment parser that may split the data into two streams. An Inverse Fast Fourier Transform (IFFT) process and a time domain process may be performed on each stream separately. These streams may be mapped to two 80MHz channels and data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to a Medium Access Control (MAC) layer, entity, or the like.

The 802.11af and 802.11ah support modes of operation below 1 GHz. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. The 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and the 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/Machine Type Communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery lives above a threshold (e.g., to maintain very long battery lives).

WLAN systems that can support multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. The 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 may be set and/or limited by STAs from all STAs operating in the BSS (which support a minimum bandwidth mode of operation). In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only) 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth modes of operation. The carrier sense and/or Network Allocation Vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because the STA (supporting only 1MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though most of the frequency band remains idle and possibly available.

The available frequency band for 802.11ah in the united states is 902MHz to 928MHz. In korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Fig. 1D is a system diagram illustrating a RAN 113 and a CN 115 according to an embodiment. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, 102c over an air interface 116. RAN 113 may also communicate with CN 115.

RAN 113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN 113 may include any number of gnbs while remaining consistent with an embodiment. Each of the gnbs 180a, 180b, 180c may include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the gnbs 180a, 180b, 180c may implement MIMO technology. For example, the gnbs 180a, 180b may utilize beamforming to transmit signals to and/or receive signals from the WTRUs 102a, 102b, 102 c. Thus, the gNB 180a may use multiple antennas to transmit wireless signals to the WTRU 102a and/or receive wireless signals from the WTRU 102a, for example. In an embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on the unlicensed spectrum while the remaining component carriers may be on the licensed spectrum. In embodiments, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180 c).

The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using transmissions associated with the scalable parameter sets. For example, the OFDM symbol interval and/or OFDM subcarrier interval may vary from transmission to transmission, from cell to cell, and/or from part of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using various or scalable length subframes or Transmission Time Intervals (TTIs) (e.g., including different numbers of OFDM symbols and/or continuously varying absolute time lengths).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not accessing other RANs (e.g., such as the enode bs 160a, 160B, 160 c). In an independent configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In an independent configuration, the WTRUs 102a, 102b, 102c may use signals in unlicensed frequency bands to communicate with the gnbs 180a, 180b, 180 c. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs (such as the enode bs 160a, 160B, 160 c). For example, the WTRUs 102a, 102B, 102c may implement DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enode bs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for serving the WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slices, 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, and so on. As shown in fig. 1D, gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

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

AMFs 182a, 182b may be connected to one or more of gNB 180a, 180b, 180c in RAN 113 via an N2 interface and may function as a control node. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slices (e.g., handling of different Protocol Data Unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, and so on. The AMFs 182a, 182b may use network slices to customize CN support for the WTRUs 102a, 102b, 102c, e.g., based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra high reliability low latency (URLLC) access, services relying on enhanced large-scale mobile broadband (eMBB) access, services for MTC access, etc. AMF 182 may provide control plane functionality for switching between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as Wi-Fi.

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

UPFs 184a, 184b may be connected to one or more of the gnbs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, for example, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-host PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.

The CN 115 may facilitate communications with other networks. For example, the CN 115 may include or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and/or wireless networks owned and/or operated by other service providers. In embodiments, WTRUs 102a, 102b, 102c may connect to local Data Networks (DNs) 185a, 185b through UPFs 184a, 184b via an N3 interface to UPFs 184a, 184b and an N6 interface between UPFs 184a, 184b and DNs 185a, 185b.

In view of fig. 1A-1D and the corresponding descriptions of fig. 1A-1D, one or more or all of the functions described herein with reference to any one of the following may be performed by one or more emulation elements/devices (not shown): the WTRUs 102a-102d, base stations 114a-114B, eNodeBs 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMFs 182a-182B, UPFs 184a-184B, SMFs 183a-183B, DNs 185a-185B, and/or any other elements/devices described herein. The emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device may be used to test other devices and/or analog network and/or WTRU functions.

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

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

The examples provided herein do not limit the applicability of the subject matter to other wireless technologies, e.g., using the same or different principles as may be applicable.

As explained herein, a WTRU may be an example of a UE. Thus, the terms UE and WTRU are used interchangeably herein.

As used herein, the term WTRU is also used as a generic term to identify a device in which one or more V2X applications are running. A V2X application server (V2X AS) may be located in the network and may interface with V2X applications installed on the WTRU. The V2X Control Function (CF) may handle authorization and provisioning of V2X devices. This may include, for example, V2X policy and/or parameter configuration for the WTRU. V2XCF functions may be handled at the PCF. V2X WTRU-to-WTRU communication may be based on two modes of operation: through the Uu reference point and through the PC5 reference point.

V2X communication through the PC5 reference point may be one type of ProSe communication (e.g., D2D communication). One-to-one ProSe direct communication may be achieved by establishing a secure layer 2 link on the PC5 between two WTRUs, which is commonly referred to as unicast communication (e.g., the communication may involve 2 peers).

Fig. 2 shows a non-roaming 5G system architecture for PC5 and Uu based V2X communication. As shown in fig. 2, some examples of V2X WTRUs 102 may be vehicle WTRUs (WTRU 102b and WTRU 102 c) or pedestrian WTRUs (WTRU 102 a). V2X communication may also occur between two pedestrian WTRUs. V2X communication may also occur between the mobile WTRUs 102a, 102b, and/or 102c and the fixed/stationary WTRU 102c (e.g., a roadside unit (RSU) or other stationary device). The communication between the WTRU 102b or 102c (vehicle) and the WTRU 102a (pedestrian) may be referred to as V2P communication, while the communication between the WTRU 102b (vehicle) and the WTRU 102c (vehicle) may be referred to as V2V communication. As shown in fig. 2, both V2V and V2P communications may occur over the PC5 interface, and characteristics of V2V communications such as message frequency, power, etc. may be different than V2P type communications.

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

The V2P WTRU 102a supporting V2P applications sends a message that includes or contains V2P application information. The V2P application information may be sent by a WTRU supporting a V2X application in the vehicle, such as a warning for pedestrians, or by a WTRU supporting a V2X application associated with a vulnerable road user, such as a warning for the vehicle. The 3GPP transmissions of messages including/containing V2P application information may include direct transmissions between WTRUs 102 and/or transmissions between WTRUs via an infrastructure supporting V2X communications (e.g., RSUs, application servers, etc.), e.g., due to limited direct communication range. As described herein and based on the architecture in fig. 2, V2X may support both vehicle-type WTRUs 102b/102c and pedestrian-type WTRUs 102a. V2X may also support other specific functions of the pedestrian WTRU 102a carried by a pedestrian user, cyclist, etc. A special resource selection mechanism (e.g., partial interception or random selection) for the pedestrian WTRU 102a may be used in PC5 communications. Generally, the pedestrian-type WTRU 102a is not optimized, and has power and computational limitations compared to the vehicle WTRUs 102b/102 c. It is desirable to support V2X use by Vulnerable Road Users (VRUs) and thus provide enhancements in relevant aspects (e.g., energy savings, etc.).

V2X resource allocation in LTE

LTE defines two modes of operation in V2X communications. Mode 3, wherein the network provides scheduling assignments for V2X Side Link (SL) transmissions for WTRUs. Mode 4, wherein the WTRU autonomously selects resources from a configured/pre-configured resource pool. Furthermore, V2X LTE defines two types of resource pools: a receiving pool, which may be monitored for receiving V2X transmissions; and/or V2X transmission pools that may be used by the WTRU to select transmission resources in mode 4. A WTRU configured in mode 3 may not use the transmission pool. The resource pool defines a subset of available subframes and/or resource blocks for side link transmission or reception. The side link communication is a half duplex scheme and/or the WTRU may be configured with multiple transmit resource pools and/or multiple receive resource pools.

In LTE, these resource pools are signaled semi-statically to WTRUs via Radio Resource Control (RRC) signaling. In mode 4, the WTRU uses listening before selecting resources in the RRC configured transmission pool. LTE V2X does not support dynamic resource pool reconfiguration; the pool configuration may be carried (e.g., only) via System Information Blocks (SIBs) and/or dedicated RRC signaling. As used herein, for NR V2X using DRX, the resource pool may include a set of resources used in V2X communications. The Receive (RX) resource pool defines the resources that the WTRU should monitor. A Transmission (TX) resource pool defines the resources that a WTRU may use for transmission. Not all resources in the side link may be used for TX or RX. The RX resource pool may also be referred to herein as an RX pool and/or the TX resource pool may also be referred to as a TX pool.

NR V2X access technology

The third generation partnership project (3 GPP) includes next generation wireless systems, referred to as NR. NR systems are expected to support a variety of use cases, such as enhanced mobile broadband (emmbb), ultra-high reliability, and/or low latency communications (URLLC).

The 3GPP may support enhanced V2X (eV 2X) communications in NR systems. eV2X in NR is expected to support new services for both safe and/or unsafe scenarios, such as sensor sharing, autopilot, vehicle formation, remote driving. Different eV2X services require different performance requirements and/or for certain scenarios a delay of 3ms may be required.

NR V2X can support two modes of operation, mode 1 and/or mode 2. Mode 1 operates based on LTE V2X mode 3. For example, the network may schedule SL resources via Downlink (DL) Downlink Control Information (DCI) signaling and/or the WTRU may apply the received resource reservation for SL transmissions. Mode 2 may use LTE mode 4 as a baseline for semi-persistent scheduling. In mode 4, the WTRU may autonomously select and/or reserve resources from the configured resource pool. In one example, the configured resource pool may be a pre-configured resource pool. Autonomous resource reservation may be based on WTRU interception to identify available candidate resources.

New use case of NR V2X

It is desirable for NR V2X to support new use cases defined in the 3GPP standard. Specifically, the following use cases will be supported:

the vehicles are queued.Vehicle formation enables vehicles to dynamically form groups that travel together. All vehicles in the fleet receive periodic data from the lead vehicle for fleet operation. This information allows the distance between vehicles to become extremely small, e.g., the gap distance converted to time can be very low (sub-second). The queuing application may allow the following vehicle to drive autonomously.

Advanced driving.Advanced driving can achieve semi-automatic or fully automatic driving. Assume a longer inter-vehicle distance. Each vehicle and/or RSU shares data obtained from its local sensors with the approaching vehicle, allowing the vehicle to coordinate its trajectory or maneuver. This isIn addition, each vehicle shares its driving intent with the approaching vehicle. The benefits of such use case sets are safer travel, collision avoidance, and/or improved traffic efficiency.

The sensor is expanded.The expansion sensor is capable of exchanging raw or processed data or real-time video data collected by the local sensor between vehicles, RSUs, pedestrian devices and/or V2X application servers. The vehicle may enhance its perception of its environment beyond what can be detected by its own sensors and/or provide a more comprehensive understanding of the local situation.

And (5) remote driving.Remote driving enables a remote driver or V2X application to operate a remote vehicle for passengers that cannot drive themselves or for remote vehicles located in a dangerous environment. For situations where the change is limited and/or route is predictable (such as public transportation), cloud computing based driving may be used. In addition, the use case group may consider accessing a cloud-based backend service platform.

QoS for NR V2X

The QoS model is used for NR V2X in 3 GPP. In Rel-14 v2x recorded in TS23.285, qoS on PC5 is supported by ProSe Per Packet Priority (PPPP). The application layer is allowed to mark the packet with PPPP, which indicates the required QoS level. For example, some enhancement functions are added by allowing a Packet Delay Budget (PDB) to be derived from PPPP.

For example, new QoS requirements for NRV2X are recorded in TS 22.186. The new performance Key Performance Indicator (KPI) is specified by the following parameters:

-a payload (bytes);

transmission rate (messages/sec);

-maximum end-to-end delay (ms);

reliability (%);

-data rate (Mbps);

-a minimum required communication range (meter).

Note that the same set of service requirements may apply to both PC 5-based V2X communications and/or Uu-based V2X communications. These QoS characteristics may be well represented by the 5G QoS indicator (5 QI) defined in TS 23.501.

One possibility is to have a unified QoS model for PC5 and/or Uu, e.g. also using 5QI for V2X communication over PC5, so that the application layer can have a consistent way of indicating QoS requirements, regardless of the link used.

Considering a WTRU supporting 5gs v2x, there are three different traffic types: broadcast, multicast and/or unicast. For unicast type traffic, the same QoS model as Uu may be utilized, e.g., each of the unicast links may be considered a bearer and/or QoS flows may be associated therewith. Additional parameters of all QoS characteristics and/or data rates defined in 5QI may be applied. Furthermore, the minimum (e.g., required) communication range may be considered an additional parameter that is specifically used for the PC 5. Similar considerations apply to multicast traffic as it can be considered a special case of unicast, e.g. with multiple defined traffic receivers.

For broadcast services, there is no bearer concept. Thus, each of these messages may have different characteristics depending on the application requirements. Then, 5QI should be used in a similar way as PPPP/ProSe Per Packet Reliability (PPPR), e.g. to label each packet. The 5QI can represent all characteristics required for the PC5 broadcast operation, such as delay, priority, reliability, etc. A set of V2X broadcast specific 5QI (e.g., VQI) may be defined for PC5 use.

PC5 QoS parameters are negotiated when a one-to-one communication procedure is established, thus enhancing the one-to-one communication setup procedure defined in TS 23.303, for example, to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation procedure, the same QoS is used in both directions.

WTRUs participating in one-to-one communications (e.g., D2D communications) negotiate PC5 QoS parameters during a link setup procedure as depicted in fig. 3. Message 1 is a Direct Communication Request (DCR) message and message 2 is authentication and establishment of a security association message. At message 1, UE-1 (e.g., WTRU-1) sends a direct communication request message to UE-2 (e.g., WTRU-2) to trigger mutual authentication. The message includes the requested PC5 QoS parameters. At message 2, UE-2 (e.g., WTRU-2) initiates a procedure for mutual authentication. UE-2 (e.g., WTRU-2) includes the accepted PC5 QoS parameters in a response message.

DRX in NR Uu

The CONNECTED mode DRX is designated for power saving in NR uu of the WTRU in rrc_connected. DRX is based on a configured schedule of wake-up times at WTRUs. If the WTRU receives a Physical Downlink Control Channel (PDCCH) schedule during its wakeup time, it remains awake for a certain time until no further schedule is received. The WTRU may be configured with any of the following exemplary parameters:

-drx-onDurationTimer: duration at the beginning of DRX cycle;

-drx-SlotOffset: the delay before starting the drx-onduration timer;

-drx-inactivatytimer: a duration after a PDCCH occasion in which the PDCCH indicates a new UL or DL transmission of the MAC entity;

drx-retransmission timerdl (per DL hybrid ARQ, HARQ process other than broadcast process): up to the maximum duration of the DL retransmission received;

-drx-retransmission timerul (per UL HARQ process): until a maximum duration of grant for UL retransmission is received;

-drx-LongCycleStartOffset: a long DRX cycle and/or a DRX-StartOffset defining subframes for which the long DRX cycle and the short DRX cycle are started;

-drx-ShortCycle (optional): a short DRX cycle;

-drx-ShortCycleTimer (optional): the duration of the short DRX cycle should be followed by the UE;

drx-HARQ-RTT-TimerDL (per DL HARQ process other than broadcast process): a minimum duration before the MAC entity expects DL assignments for HARQ retransmissions;

-drx-HARQ-RTT-TimerUL (per UL HARQ process): the minimum duration before the MAC entity expects UL HARQ retransmission authorization.

The WTRU configured with DRX will then determine its active time (the time the WTRU actively monitors the PDCCH) based on any of the following:

In the case of configuring a DRX cycle (e.g., in this case), the active time includes the time when:

-drx-onduration timer or drx-incaactyitytimer or drx-retransmission timer dl or drx-retransmission timer ul or ra-contentioresolutotimer (e.g. as described in sub-clause 5.1.5 of release 14); or alternatively

The scheduling request is sent on a Physical Uplink Control Channel (PUCCH) and is in a pending state (e.g. as described in sub-clause 5.4.4 of release 14); and/or

After successful reception of the random access response of the preamble not selected by the MAC entity, a PDCCH indicating a new transmission of a cell radio network temporary identifier (C-RNTI) addressed to the MAC entity has not been received (as described in sub-clause 5.1.4 of release 14).

Partial interception and/or random selection in LTE V2X

Another power saving mechanism introduced in LTE V2X (for use by pedestrian WTRUs) is the partial interception aspect. In the case of partial interception, the WTRU may be configured by the upper layer with the smallest number of candidate subframes in the resource selection window T1, T2, where a particular subframe is selected by the WTRU implementation. The WTRU may perform listening in the listening window (e.g., only) for subframes that are an integer number of reservation periods from the candidate subframes, thereby reducing the amount of resources the WTRU needs to perform listening in the listening window.

Another possibility for a pedestrian WTRU is to perform a random selection of the resource pool. If the resource pool is configured for random selection, the WTRU is able to perform resource selection without regard to any listening results during the listening procedure.

In SL communication, uu scheduling has many differences, which may cause problems with the DRX concept approach implemented by Uu:

-using a retransmission indication based on Signaling Control Information (SCI). In particular, in SL, a single SCI may indicate resources for additional transmissions and/or further retransmissions of the HARQ process, where the transmissions and/or retransmissions may be discontinuous in time. The running of the HARQ RTT timer and/or retransmission timer may (e.g., need) take such SCI indications into account.

The transmission may enable or disable HARQ, in which case the timeline of HARQ feedback is different. For HARQ-enabled transmissions, an RX WTRU (e.g., WTRU 102) may transmit a physical side chain feedback channel (PSFCH) (as in Uu). For transmission with disabled HARQ, the RX WTRU (e.g., WTRU 102) may not transmit HARQ feedback on the PSFCH. This may affect the definition of the timer for the HARQ process.

In particular, in Uu, the HARQ RTT may start in the symbol/slot at the end of the transmission carrying DL HARQ feedback. However, in the side link, the WTRU may not (e.g., always) transmit the PSFCH for different reasons (e.g., HARQ disable, UL/SL prioritization).

The minimum microsleep/DRX time may be different depending on whether mode 1 or mode 2 is used.

While SCI may indicate scheduled retransmission times for HARQ processes, events at the TXWTRU (e.g., WTRU 102) may cause changes in these times. In particular, a TX WTRU (e.g., WTRU 102) may perform preemption of retransmission resources, e.g., due to transmissions by higher priority WTRUs. Specifically, a TX WTRU (e.g., WTRU 102) may perform reselection, for example, due to UL over SL. In particular, a TX WTRU (e.g., WTRU 102) may not indicate all retransmission resources (e.g., transmit a signal indicating all retransmission resources) immediately (in SCI), e.g., due to Channel Busy Rate (CBR).

Method for side link DRX timer

1.Method for defining active time of SL retransmission

A WTRU (e.g., TX or RX) may have a mechanism to determine the period of microsleep/DRX after transmission or retransmission, e.g., for a HARQ process, depending on SL characteristics. This may be modeled as using a HARQ RTT timer (similar to Uu), whereby the start of such a timer indicates the start of a potential microsleep/DRX opportunity (whereby the WTRU does not monitor PSCCH operation, where no other timers (e.g., inactivity timers, retransmission timers, etc.) defining activity are running, for example. The HARQ RTT timer may be configured for each SL HARQ process. In case the HARQ RTT timer expires and/or a retransmission timer (or similar timer representing activity) starts (e.g. in this case), the microsleep/DRX opportunity may end. Alternatively, the WTRU may be configured with an explicit period or set of resources (e.g., a set of slots relative to a SL event) for microsleep/DRX and/or in the case that the WTRU should be active, e.g., for each SL HARQ process (e.g., a set of slots relative to a SL event). Each of the following embodiments may be applicable to either alternative. Further, "HARQ RTT timer" and/or "HARQ RTT time" may be used interchangeably to refer to the microsleep/DRX time for a HARQ process, whether or not this time is explicitly achieved by using a timer (as in Uu). Further, the HARQ RTT time/timer refers to a SL HARQ RTT timer in the present disclosure.

1.1Determining a start time of a HARQ RTT timer

An RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer at some point in time (e.g., a subsequent slot or subsequent multiple specified slots) with respect to any of the following:

-reception of SCI and/or data for the HARQ process;

-decoding time of MAC PDU associated with HARQ process;

at or after the time of the scheduled retransmission by the TX WTRU (e.g., WTRU 102), e.g., indicated in the previous SCI;

-determining a decoding result (ACK or NACK) associated with the reception;

-transmission of HARQ feedback associated with the received data;

-a (pre) configuration or a predefined time after reception of SCI and/or data for the HARQ process;

such (pre) configuration or predefined time may be defined, for example, based on minimum WTRU capabilities; and/or

The HARQ RTT timer is not started at all and/or the retransmission timer for the HARQ process is started directly, for example.

a)RX WTRU (e.g., WTRU 102) may determine to start HARQ-RTT at different times based on SL characteristics

A WTRU (e.g., WTRU 102) may determine when to start a HARQ RTT (timer) differently depending on SL characteristics or conditions. In particular, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at one time under a first characteristic/condition and/or may start a HARQ RTT timer at another time under a second characteristic/condition, where the time instance may be any of those described above. These conditions may be related to any of the following:

-whether to enable/disable SL HARQ feedback for a specific transmission/retransmission of a HARQ process;

-a broadcast type associated with the transmission:

for example, a WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first time when transmitting (e.g., in this case) associated with unicast and/or may start a HARQ RTT timer at a second time when transmitting (e.g., in this case) associated with multicast;

QoS related parameters associated with the transmission (e.g. priority, MCR):

for example, if a priority associated with a transmission is above a threshold, a (e.g., RX) WTRU (e.g., WTRU 102) may start an HARQ RTT timer at a first time and/or otherwise may start an HARQ RTT timer at a second time;

value of CBR:

for example, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first time when the measured CBR is above a threshold and/or may start a HARQ RTT timer at a second time otherwise; and/or

-indication/information of a peer WTRU as described herein:

for example, a (e.g., RX) WTRU (e.g., WTRU 102) may receive a DRX mode indication or other information about DRX in a PC5-RRC (e.g., semi-statically) or in a SCI/MAC CE (dynamically), and/or may change the start time of the HARQ RTT timer based on the information;

For example, a (e.g., RX) WTRU (e.g., WTRU 102) may receive DRX patterns for different transmission types (e.g., SL characteristics described above) and/or may apply HARQ RTT start times to each transmission type indicated by a peer WTRU.

While not losing generality, the above conditions may also be applicable to determine when to start the HARQ RTT timer and whether to start the HARQ RTT timer.

According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to enable/disable HARQ for a received PDU. A WTRU (e.g., WTRU 102) may determine a HARQ RTT start point based on HARQ enable/disable attributes of the received PDU. If HARQ is enabled, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first symbol/slot after its transmission of a PSFCH containing HARQ feedback for the transmission. If HARQ is disabled, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first symbol/slot after receiving the SCI or after receiving a PSSCH corresponding to a received PDU for the HARQ process. According to embodiments, in such a case, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a predefined time after receiving the SCI, where such predefined time corresponds to a minimum requirement defined for the (e.g., RX) WTRU (e.g., WTRU 102). A WTRU (e.g., WTRU 102) may also use a different value of the HARQ RTT timer for each of the two scenarios. The start time of the HARQ RTT may correspond to any of the above-described times.

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may initiate a HARQ RTT at a time associated with a retransmission resource under certain conditions. Under other conditions, a (e.g., RX) WTRU (e.g., WTRU 102) may not start the HARQ RTT and/or may instead start a retransmission timer at such a time. For example, if any one or a combination of the conditions of the clause and/or other clauses are met, the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer in a time slot after the retransmission resource indicated by the previous SCI. For example, if an RX WTRU (e.g., WTRU 102) receives an indication (e.g., mode 1 transmission) to do so by a TX WTRU (e.g., WTRU 102), or if preemption/re-evaluation is disabled, the RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer in the time slot after the scheduled retransmission resource indicated in the SCI.

b)A (e.g., RX) WTRU (e.g., WTRU 102) may perform UL/SL transmission on a PSFCH slot at the WTRU In case (e.g. in this case) a HARQ-RTT timer (or the like) is started

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may initiate a HARQ-RTT associated with a HARQ process for reception in the event that the (e.g., TX) WTRU (e.g., WTRU 102) performs a transmission (UL transmission or SL transmission), for example, at a time instance when the (e.g., TX) WTRU (e.g., WTRU 102) may (e.g., expect) to transmit on a PSFCH. For example, if a (e.g., TX) WTRU (e.g., WTRU 102) prioritizes UL transmission of HARQ feedback over SL transmission over PSFCH (e.g., skip PSFCH transmission), a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer for the HARQ process in which HARQ feedback should be transmitted over skipped PSFCH. A (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer at any of the following:

-atPSFCHThe symbol/slot after the (last) symbol/slot of (a);

-in preference toThe symbol/slot following the last symbol/slot of transmission of UL/SL for PSFCH transmission; and/or

-Wherein the method comprises the steps ofA symbol/slot after a symbol/slot in which a WTRU (e.g., WTRU 102) receives a UL grant for a UL transmission (e.g., TX).

1.2Determining a start time of a retransmission timer

a)An RX WTRU (e.g., WTRU 102) may be configured with a retransmission timer for starting a SL HARQ process Is not a time instance of (b)

A (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer for a SL HARQ process at different times based on SL characteristics. A (e.g., RX) WTRU (e.g., WTRU 102) may select any of the following times for starting a retransmission timer after the (failed) reception of the HARQ process:

-after expiration of the HARQ RTT time (timer) (e.g. at time);

-at or some time before the time resource indicated in the SCI sent with the (failed) reception;

-a slot (or slots) following the slot indicated in the SCI transmitted with the (failed) reception;

-at, some time before or some time after the last retransmission resource received in SCI for a specific HARQ process; and/or

-not starting the retransmission timer at all.

b)[ RX WTRU (e.g., WTRU 102) determines whether/when to start HARQ process retransmission timer based on SCI]

An RX WTRU (e.g., WTRU 102) may set a retransmission timer for a particular initial transmission/retransmission of a HARQ process. According to embodiments, an RX WTRU (e.g., WTRU 102) may determine whether to start a retransmission timer and/or a start time of a retransmission timer for a HARQ process (from those given above) based on any of the following:

-for the purpose ofWhether the SCI received by the HARQ process indicates retransmission resources:

for example, a WTRU (e.g., WTRU 102) may start a retransmission timer if the SCI has not reserved resources for subsequent retransmissions (e.g., in this case) (e.g., after a certain HARQ RTT time). If the SCI reserves resources for subsequent retransmissions, a (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer after receiving the current SCI (and may start a retransmission timer (e.g., only) after receiving a subsequent SCI for the same HARQ process).

Whether an (e.g., RX) WTRU (e.g., WTRU 102) is expecting additional retransmission resources (after the currently received transmission/retransmission resources) for a particular HARQ process:

For example, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer in the case (e.g., in this case) (e.g., after a certain HARQ RTT time) where the current SCI/data reception for a particular HARQ process corresponds to the last (e.g., desired) retransmission for that HARQ process (as reserved for retransmission resources indicated using SCI). If the SCI does not correspond to the last retransmission resource, a (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer after receiving the SCI.

For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to start the HARQ RTT timer based on whether the SCI indicates additional retransmission resources. Specifically, if the SCI indicates additional retransmission resources, the UE may start the HARQ RTT timer at the time instance described herein. Alternatively, if the SCI does not indicate additional retransmission resources, the UE may not start the HARQ RTT timer for the HARQ process.

Whether a (e.g., RX) WTRU (e.g., WTRU 102) successfully receives an SCI at a reserved time indicated by a previous SCI for the same HARQ process:

for example, if a (e.g., RX) WTRU (e.g., WTRU 102) does not decode the SCI in a time slot in which the (e.g., RX) WTRU (e.g., WTRU 102) expects a retransmission, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., in a time slot after the time indicated by the previous SCI for the HARQ process). Otherwise, if the (e.g., RX) WTRU (e.g., WTRU 102) receives the SCI for the HARQ process in a time slot in which the (e.g., RX) WTRU (e.g., WTRU 102) is expecting to retransmit (based on the previous SCI), the (e.g., RX) WTRU (e.g., WTRU 102) may not start the retransmission timer. Alternatively, the (e.g., RX) WTRU (e.g., WTRU 102) may always start the retransmission timer in the time slot in which the (e.g., RX) WTRU (e.g., WTRU 102) is expected to retransmit and/or may stop the retransmission timer (e.g., immediately) if the SCI is received or continue to run as long as the SCI is not received.

-whether a PDU for a HARQ process was successfully decoded:

for example, as long as a (e.g., RX) WTRU (e.g., WTRU 102) does not successfully decode a PDU associated with a HARQ process (e.g., in a previously received transmission/SCI), a (e.g., RX) WTRU (e.g., WTRU 102) may (in any of the other cases associated with that clause) start a retransmission timer:

■ In particular, successful decoding means herein that the SCI is received and/or the HARQ process ID and/or NDI indicates that the received transmission is a retransmission associated with a currently allocated HARQ process at the (e.g., RX) WTRU (e.g., WTRU 102).

Whether the HARQ RTT timer expires (or is stopped) before or after the next scheduled retransmission:

specifically, (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer at the earliest instant that the HARQ RTT timer and/or retransmission timer expires. For example, if the HARQ RTT timer expires before the next scheduled retransmission, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer if the HARQ RTT timer expires (e.g., in this case). Otherwise, the (e.g., RX) WTRU (e.g., WTRU 102) starts a retransmission timer at (or immediately after) the next scheduled retransmission indicated in the SCI.

-whether a TX WTRU (e.g., WTRU 102) configures/allows preemption:

for example, if a TX WTRU (e.g., WTRU 102) is allowed to reselect retransmission resources due to preemption, the TX WTRU (e.g., WTRU 102) may start a retransmission timer after the HARQ RTT timer expires. On the other hand, if the TX WTRU (e.g., WTRU 102) is not allowed to perform preemption, the TXWTRU (e.g., WTRU 102) may start a retransmission timer at or on the time slot after the next scheduled retransmission indicated in the SCI.

-whether a TX WTRU (e.g., WTRU 102) is configured with mode 1 or mode 2:

for example, in the case where a TX WTRU (e.g., WTRU 102) is configured as mode 1 (e.g., in this case), if provided, the TX WTRU (e.g., WTRU 102) may always start a retransmission timer at the next scheduled retransmission (or at a time slot thereafter) indicated in the SCI. Otherwise (e.g., for mode 2, or for mode 1 where no subsequent retransmission resources are provided in the SCI), the TX WTRU (e.g., WTRU 102) may start a retransmission timer after the HARQ RTT timer expires.

-whether the HARQ RTT timer is started/run for a HARQ process:

for example, if the HARQ RTT timer is running for a corresponding HARQ process, the TX WTRU (e.g., WTRU 102) may start a retransmission timer after the corresponding HARQ RTT timer expires. Otherwise, the TX WTRU (e.g., WTRU 102) may start the retransmission timer at the SCI indicated by the next scheduled retransmission, or may not start the retransmission timer for that particular HARQ process at all.

For example, if the HARQ RTT timer is started, the TX WTRU (e.g., WTRU 102) may start a retransmission timer when the HARQ RTT timer expires. Otherwise, if the HARQ RTT timer is not started (e.g., based on the rules whether to start the HARQ RTT timer described herein), the TXWTRU (e.g., WTRU 102) may start a retransmission timer at another time instance indicated herein (e.g., receipt of SCI, transmission of PSFCH, expected time of SCI receipt based on previous SCI retransmission resource indication, etc.).

-an indication from the TX WTRU (e.g., WTRU 102) as to whether additional retransmission resources may be desired or whether PDB is not exceeded:

specifically, TX WTRU (e.g., WTRU 102) may provide an indication as to whether or not it should be desirable to attach retransmission resources (e.g., within a particular retransmission resource, such as via an indication in the SCI, MAC CE, or in the MAC PDU header). In particular, in the event that the TX WTRU (e.g., WTRU 102) reaches the maximum number of retransmission resources (e.g., in this case), the TX WTRU (e.g., WTRU 102) may indicate to the RX WTRU (e.g., WTRU 102) that additional retransmission resources are not desired. Such indication may be provided in the SCI associated with the last retransmission resource or in a previous SCI indicating the retransmission resource. In particular, in the event (e.g., in this case) that the TX WTRU (e.g., WTRU 102) cannot find additional resources after the last retransmission resources that fall in the packet's PDB (via resource selection), the TX WTRU (e.g., WTRU 102) may indicate to the RX WTRU (e.g., WTRU 102) that additional retransmission resources are not desired. An RX WTRU (e.g., WTRU 102) may start a HARQ RTT and/or a retransmission timer if an indication from the TX WTRU (e.g., WTRU 102) indicates that additional retransmission resources are desired. Alternatively, if the indication from the TX WTRU (e.g., WTRU 102) indicates that no retransmission is to be sent for the HARQ process, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT and/or retransmission timer for the HARQ process.

In particular, such an indication may be an indication that an additional retransmission is desired or an indication that an additional retransmission is not desired.

For example, if a TX WTRU (e.g., WTRU 102) indicates that an RX WTRU (e.g., WTRU 102) may desire to attach retransmission resources, the RX WTRU (e.g., WTRU 102) may start a retransmission timer after decoding failure for the HARQ process. Otherwise, the RX WTRU (e.g., WTRU 102) may not start the retransmission timer.

As further described herein, an indication from the TX WTRU (e.g., WTRU 102) as to whether the TX WTRU (e.g., WTRU 102) is expecting (e.g., after the TX WTRU (e.g., WTRU 102) prioritizes the UL, in which case the TX WTRU (e.g., WTRU 102) missed the TX transmission) to perform the reselection):

specifically, a TX WTRU (e.g., WTRU 102) may inform an RX WTRU (e.g., WTRU 102) whether the TX WTRU (e.g., WTRU 102) intends to perform reselection due to a missed transmission in reserved retransmission resources. An RX WTRU (e.g., WTRU 102) may start a retransmission timer if such a reselection is planned, or if the missed transmission is the last reserved retransmission (in any previous SCI). Otherwise, the RX WTRU (e.g., WTRU 102) may not start the retransmission timer and/or start the HARQ RTT timer again.

-whether the expected PDB of the PDU is exceeded at a given time:

for example, a TX WTRU (e.g., WTRU 102) may provide a desired PDB for a PDU (e.g., in an initial transmission/retransmission). For example, an RX WTRU (e.g., WTRU 102) may be configured with a priority and/or a mapping of maximum PDB (e.g., time of initial SCI reception relative to initial transmission of SCI). A WTRU (e.g., WTRU 102) may start a retransmission timer as long as the maximum PDB associated with the PDU is not exceeded.

Whether the retransmission resources associated with SCI transmission are the last known retransmission resources reserved by the TX WTRU (e.g., WTRU 102) for HARQ processes by previous SCIs:

for example, if there are additional reserved retransmission resources, a (e.g., RX) WTRU (e.g., WTRU 102) may use a first (pre) configuration value of the retransmission timer and/or may use a second value of the retransmission timer if there are no reserved retransmission resources for HARQ processes from previous SCI transmissions.

For example, if the SCI is not decoded at the retransmission resource and/or the retransmission resource is the last indicated/known retransmission resource reserved by the previous SCI, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer. Otherwise, the (e.g., RX) WTRU (e.g., WTRU 102) may in turn start a HARQ RTT timer (e.g., RX WTRU (e.g., WTRU 102) (e.g., only) expects additional retransmission at the next indicated location of the SCI).

Based on the number of retransmissions to that point performed by the TX WTRU (e.g., WTRU 102) for a particular HARQ process, e.g., compared to a maximum number that may depend on CBR/priority:

for example, if the number of retransmissions performed for the PDU is below a configured maximum value, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer and/or HARQ RTT timer. Otherwise, the (e.g., RX) WTRU (e.g., WTRU 102) may not start the retransmission timer and/or HARQ RTT timer for the HARQ process.

-scheduled receive time based on SCI/data not received by an RX WTRU (e.g., WTRU 102):

for example, an RX WTRU (e.g., WTRU 102) may perform/prioritize UL transmissions or receptions at a time corresponding to scheduled retransmissions 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 retransmissions. For example, an RX WTRU (e.g., WTRU 102) may perform a side link 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, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer at or some time after the time of the scheduled retransmission.

PDU-based QoS.

-based on the broadcast type of the transmission (e.g. combined with the indication):

for example, for a unicast HARQ process, the WTRU may determine whether to start a HARQ RTT timer after SCI transmission based on an indication (e.g., from a TX WTRU (e.g., WTRU 102)), e.g., in the case where such SCI transmission does not indicate retransmission resources. A TX WTRU (e.g., WTRU 102) may set such an indication based on whether the PUCCH is configured at the TX WTRU (e.g., WTRU 102). Specifically, the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer if PUCCH is configured and/or the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer if PUCCH is not configured. On the other hand, for multicast and/or broadcast, an RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer (e.g., again for SCI transmissions where such SCIs do not indicate retransmission resources).

The above conditions may also be applicable to determining when to start a retransmission timer and/or whether to start a retransmission timer. The above conditions may also apply when or if the HARQ RTT timer is started, without loss of generality.

In an example embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to begin retransmission based on successful receipt of the SCI for retransmission, e.g., at the planned/expected receive time indicated by the previous SCI. Specifically, a (e.g., RX) WTRU (e.g., WTRU 102) may receive a first SCI indicating retransmission resources at time T2 (e.g., at time T1). The (e.g., RX) WTRU (e.g., WTRU 102) may also perform microsleep/DRX for SL HARQ processes up to the time instance indicated by the first SCI (e.g., T2). Based on whether a (e.g., RX) WTRU (e.g., WTRU 102) successfully receives, for example, a SCI indicating the same HARQ process ID at time instance T2, the (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to start a retransmission timer for the HARQ process. For example, if a (e.g., RX) WTRU (e.g., WTRU 102) monitors the SCI at T2 and/or does not receive the SCI, the (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer for the HARQ process. On the other hand, if the (e.g., RX) WTRU (e.g., WTRU 102) monitors the SCI at T2 and/or receives the SCI associated with the HARQ process, the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer for the HARQ process.

c)If the RX WTRU (e.g., WTRU 102) does not decode the SCI, it determines if/when to start HARQ process retransmission timer

Whether or not a (e.g., RX) WTRU (e.g., WTRU 102) starts a retransmission timer in the above embodiments may also depend on whether or not the (e.g., RX) WTRU (e.g., WTRU 102) monitors the SCI at time T2. In particular, a (e.g., RX) WTRU (e.g., WTRU 102) may skip monitoring SCI due to half-duplex issues (e.g., it performs transmission at the same time instance) or UL/SL prioritization (e.g., it performs UL transmission instead of SCI monitoring). In this case, if the (e.g., RX) WTRU (e.g., WTRU 102) does not decode the SCI, it may always start the retransmission timer at T2. Alternatively, a (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer and/or may start a HARQ RTT timer for the HARQ process again. In particular, a (e.g., RX) WTRU (e.g., WTRU 102) may perform microsleep/DRX until the next scheduled retransmission, or based on the configuration of the HARQ RTT timer, depending on the conditions described herein. For example:

-under a first condition, a (e.g., RX) WTRU (e.g., WTRU 102) may start a HARQ RTT timer;

In a second condition, a (e.g., RX) WTRU (e.g., WTRU 102) may start a retransmission timer.

The first condition and the second condition may be a combination (and/or) of any one of the following conditions:

a TX WTRU (e.g., WTRU 102) is operating in mode 1.

A TX WTRU (e.g., WTRU 102) is operating in mode 2.

Preemption is disabled.

The SCI that is missed corresponds to the last retransmission resource indicated by the previous SCI.

The missing SCI does not correspond to the last retransmission resource indicated by the previous SCI.

CBR above/below a threshold.

The priority of the transmission is above/below a threshold.

-an action indicated by the TX WTRU (e.g., WTRU 102) (e.g., TX WTRU (e.g., WTRU 102) may indicate whether the RX WTRU (e.g., WTRU 102) should start the HARQ RTT timer or the retransmission timer):

for example, a TX WTRU (e.g., WTRU 102) may determine whether preemption is disabled and/or whether to provide this information to an RX WTRU (e.g., WTRU 102) based on the mode of operation.

For example, if the (e.g., RX) WTRU (e.g., WTRU 102) misses the planned SCI retransmission (e.g., after expiration of the HARQ RTT timer), the (e.g., RX) WTRU (e.g., WTRU 102) may start the retransmission timer if the TX WTRU (e.g., WTRU 102) uses mode 2 and/or preemption is enabled, or if the missed SCI/retransmission is the last retransmission indicated by the previous SCI. Otherwise (e.g., if the TX WTRU (e.g., WTRU 102) uses mode 1, or the TX WTRU (e.g., WTRU 102) uses mode 2 where preemption is disabled, and/or in either case the missing SCI is not the last retransmission), (e.g., the RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer).

1.3Determining HARQ RTT time/timer or retransmission time/timer at an RXWTRU (e.g., WTRU 102) Value/duration of (2)

a)The active time may be a scheduled receive resource (indicated by the SCI) and/or a timer for retransmission (e.g., retransmission timer) is running

According to embodiments, the value of the HARQ RTT timer or retransmission timer may be determined by the TX WTRU (e.g., WTRU 102), the RX WTRU (e.g., WTRU 102), or a combination of the TX WTRU (e.g., WTRU 102) and/or the RX WTRU (e.g., WTRU 102). In particular, a TX WTRU (e.g., WTRU 102) may determine and/or transmit a value of a timer to an RX WTRU (e.g., WTRU 102) using conditions known at the TX WTRU (e.g., WTRU 102). Alternatively, the RX WTRU (e.g., WTRU 102) may determine the value of the timer using conditions known at the RX WTRU (e.g., WTRU 102) and/or conditions notified by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102). Finally, a portion of the timer may be determined by the TX WTRU (e.g., WTRU 102) and/or transmitted to the RX WTRU (e.g., WTRU 102), and/or another portion of the timer may be determined by the RX WTRU (e.g., WTRU 102).

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

b)The activity associated with the retransmission indicated by the SCI may be considered by starting and/or stopping a retransmission timer Time

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may define its active time (e.g., based only on whether there are any timers associated with DRX operation, as in Uu). In this case, the monitoring of the retransmission resources indicated by the SCI may be performed via the retransmission resources. Specifically, in the case where a (e.g., RX) WTRU (e.g., WTRU 102) monitors resources associated with the time instance indicated/reserved in the SCI for a particular HARQ process (e.g., only), the RX WTRU (e.g., WTRU 102) may:

-setting the HARQ RTT timer to an amount of time until the next reserved retransmission resource, excluding the resource;

-in case the HARQ RTT timer expires and/or the PDU for the HARQ process has not been successfully decoded (e.g., in this case), the RX WTRU (e.g., WTRU 102) starts a retransmission timer for the HARQ process;

-the (e.g., RX) WTRU (e.g., WTRU 102) continuing to run the retransmission timer until the retransmission timer expires as long as the SCI for the HARQ process is not received; and/or

Once the (e.g., RX) WTRU (e.g., WTRU 102) decodes the SCI for the HARQ process, the (e.g., RX) WTRU (e.g., WTRU 102) stops the retransmission timer.

c) An RX WTRU (e.g., WTRU 102) may set the retransmission value to a different value

According to an embodiment, an RX WTRU (e.g., WTRU 102) may set the retransmission timer to a different value. Specifically, an RX WTRU (e.g., WTRU 102) may set a retransmission timer for a HARQ process to any one of:

- (pre) configuration values, or values indicated by the TX WTRU (e.g., WTRU 102) (e.g., in RRC signaling, SCI, or in MAC layer):

a (e.g., RX) WTRU (e.g., WTRU 102) may be further (pre) configured with a different retransmission timer value.

A value of 0 (e.g., an (RX) WTRU (e.g., WTRU 102) does not use a retransmission timer).

-a value equivalent to a single time slot:

for example, under certain conditions described herein (e.g., TX WTRU (e.g., WTRU 102) uses mode 1 and/or SCI does not contain any retransmission resources), an RX WTRU (e.g., WTRU 102) may set the retransmission timer to be equivalent to a single slot. Specifically, an RX WTRU (e.g., WTRU 102) may run a retransmission timer during a time slot associated with a retransmission resource in the SCI.

-a value derived from the timing of the retransmission resource indicated in the SCI:

for example, a TX WTRU (e.g., WTRU 102) may set the value of the retransmission timer to the amount of time remaining (from the start of the retransmission timer) until the time position of the next retransmission resource indicated in the previous SCI.

For example, a TX WTRU (e.g., WTRU 102) may set the value of the retransmission timer to the amount of time remaining (from the start of the retransmission timer) until the time position of the retransmission resource after the next retransmission resource.

-a value derived from the PDB of the PDU or the remaining PDB and/or derived from the priority of the PDU:

for example, an RX WTRU (e.g., WTRU 102) may provide a PDB of a PDU or a remaining PDB by a TX WTRU (e.g., WTRU 102) (e.g., in a SCI or MAC Control Element (CE)). Alternatively, an RX WTRU (e.g., WTRU 102) may be configured with a priority of PDUs and/or a mapping between maximum expected PDBs (e.g., measured from receipt of an initial transmission).

■ An RX WTRU (e.g., WTRU 102) may set a retransmission timer at any time after receiving such a PDB. An RX WTRU (e.g., WTRU 102) may set the retransmission timer to the remaining time (from the start of the retransmission timer) until the PDB expires.

■ For example, an RX WTRU (e.g., WTRU 102) may set the retransmission timer to another value (e.g., a (pre) configuration value) and/or a minimum of the remaining time until the PDB expires.

-based on the measured or indicated CBR value (from TX WTRU (e.g., WTRU 102)):

For example, an RX WTRU (e.g., WTRU 102) may be (pre) configured with different values of the retransmission timer according to CBR/channel occupancy (CR).

-value according to number of retransmissions (since initial transmission for HARQ process)

For example, an RX WTRU (e.g., WTRU 102) may be (pre) configured with a different value of the retransmission timer for each number of retransmissions or (pre) configured with an offset/change of the value of the retransmission timer applied to each retransmission (e.g., after an initial transmission).

d)An RX WTRU (e.g., WTRU 102) may be on the first based on characteristics of the control/data transmission (e.g., SCI transmission) Determining/determining between a HARQ RTT/retransmission timer and/or a second HARQ RTT/retransmission timer

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may determine a microsleep/DRX time for a HARQ process or a value of a HARQ RTT timer and/or retransmission timer based on information in transmissions by the TX WTRU (e.g., WTRU 102), which may include information in SCI, information in a physical side link shared channel (PSSCH) (e.g., MAC CE), information in PC5-RRC, etc. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine a HARQ RTT timer and/or a retransmission timer based on whether retransmission resources and/or timing of such retransmission resources are present in the SCI. Such a determination may include (e.g., RX) a WTRU (e.g., WTRU 102) selecting between a first timer and a second timer. Such a determination may include (e.g., RX) the WTRU (e.g., WTRU 102) selecting between a time derived from the SCI and/or another time provided in another message (e.g., RRC configuration or pre-configuration). In particular, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to use the first microsleep/DRX time or the second microsleep/DRX time, and/or whether to use the first retransmission timer or the second retransmission timer based on any one of (and/or a combination of) the following:

Whether the SCI indicates one or more retransmission resources.

-whether preemption is enabled/disabled for transmissions in the pool:

specifically, the RX WTRU (e.g., WTRU 102) may determine whether to disable preemption by the TX WTRU (e.g., WTRU 102) based on a pool configuration or based on an explicit indication from the TX WTRU (e.g., WTRU 102) (e.g., in a PC5-RRC, MAC CE, side Link Radio Bearer (SLRB) configuration or in the SCI transmission itself).

QoS in SCI (e.g., priority).

Coverage (in-coverage or out-of-coverage) of an RX WTRU (e.g., WTRU 102) or its peer (TX WTRU (e.g., WTRU 102)).

An RRC state of an RX WTRU (e.g., WTRU 102) or its peer (e.g., TX WTRU (e.g., WTRU 102)).

Whether an RX WTRU (e.g., WTRU 102) is receiving data from a (e.g., TX) WTRU (e.g., WTRU 102) transmitting in either mode 1 or mode 2 (where such information may also be provided by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102)).

Whether an RX WTRU (e.g., WTRU 102) is receiving data from a (e.g., TX) WTRU (e.g., WTRU 102) that is reporting a SLACK/NACK (e.g., transmitting information indicating a SL ACK/NACK) to the network (where such information may also be provided by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102)) where such a TXWTRU (e.g., WTRU 102) is transmitting using mode 1 (e.g., in this case)).

Whether the transmission is associated with a blind retransmission or a HARQ-based retransmission (e.g. enabling/disabling HARQ).

Whether the HARQ RTT timer expires (or is stopped) before or after the next scheduled transmission.

Whether the HARQ RTT timer/retransmission timer starts after the last transmission/retransmission resource indicated in the previous SCI.

Whether an RX WTRU (e.g., WTRU 102) successfully receives a SCI at a reserved time indicated by a previous SCI for the same HARQ process.

-timing of resources indicated in SCI for HARQ process (e.g. for retransmission):

for example, a (e.g., RX) WTRU (e.g., WTRU 102) may perform microsleep/DRX up to the retransmission resources indicated in SCI.

For example, (e.g., RX) WTRU (e.g., WTRU 102) may perform DRX up to a number of slots before/after the retransmission resources indicated in SCI, where the number of slots may be:

■ Configured by the network (pre).

■ Provided by a peer-to-peer (e.g., TX) WTRU (e.g., WTRU 102).

■ Depending on one or more other factors associated with the decision between the first HARQ RTT behavior and the second HARQ RTT behavior (e.g., qoS, CBR, other indications by the TX WTRU (e.g., WTRU 102)):

● For example, a (e.g., RX) WTRU (e.g., WTRU 102) may be (pre) configured with a number of slots for each priority of data associated with a HARQ process.

● For example, a (e.g., RX) WTRU (e.g., WTRU 102) may be (pre) configured with a number of slots for each indication of CBR/congestion measured by the RX WTRU (e.g., WTRU 102) itself or indicated by the TX WTRU (e.g., WTRU 102).

An indication from the TX WTRU (e.g., WTRU 102) as to whether additional retransmission resources (using new resource reservations) may be expected or whether PDB is exceeded.

Some other implicit or explicit indication information provided by a TX WTRU (e.g., WTRU 102) as described herein (e.g., in the transmission itself, or in the PC5-RRC prior to transmission).

As further described herein, an indication from the TX WTRU (e.g., WTRU 102) as to whether the TX WTRU (e.g., WTRU 102) is expecting (e.g., after the TX WTRU (e.g., WTRU 102) prioritizes the UL, in which case the TX WTRU (e.g., WTRU 102) missed the TX transmission) to perform the reselection).

e)A WTRU (e.g., WTRU 102) determines whether to use a data packet that is transmitted by a TXWTRU (e.g., WTRU 102) (e.g., in SCI) or a preconfigured value for HARQ RTT

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to define the HARQ RTT based on a (pre) configured timer or whether to define the HARQ RTT based on an explicit time indication (e.g., retransmission resource) in the SCI based on the above information in the SCI. In one example, a (e.g., RX) WTRU (e.g., WTRU 102) may set a HARQ RTT timer (or micro sleep/DRX time) to the time until the next retransmission resource indicated in the SCI. In particular, a (e.g., RX) WTRU (e.g., WTRU 102) may be allowed to perform microsleep for a particular SL HARQ process that begins at some time as described herein for the start of the HARQ RTT timer and/or may continue to perform DRX until the timing of the next desired retransmission resource indicated in the SCI. A (e.g., RX) WTRU (e.g., WTRU 102) may then start a retransmission timer or perform explicit monitoring of the resources associated with the next retransmission resource.

The (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT to the timing of the next desired retransmission resource indicated in SCI if any of the following conditions exist:

-SCI indicates at least one retransmission resource.

Providing a next retransmission resource in the SCI (after a transmission/retransmission resource for which a (e.g., RX) WTRU (e.g., WTRU 102) is determining a HARQ RTT).

The transmission is a mode 1 transmission.

The transmission is a mode 2 transmission where preemption is disabled.

On the other hand, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to 0, to some pre-configured value, or not use the HARQ RTT timer (e.g., immediately start the retransmission timer, or not perform microsleep/DRX):

transmission/retransmission is associated with the last/only resource indicated in the SCI (e.g. after this resource no further retransmission resource is indicated in the SCI); and/or

The transmission is a mode 2 transmission with preemption enabled.

For example, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to the timing of the desired retransmission resource indicated in the SCI retransmission resource:

-indicating a next retransmission resource in SCI and/or TX WTRU (e.g., WTRU 102) using mode 1; and/or

-indicating the next retransmission resource in SCI and/or TX WTRU (e.g. WTRU 102) using mode 2 where preemption is disabled.

On the other hand, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a pre-configured value (where such pre-configured value may further depend on which of the following is considered):

-not indicating a next retransmission resource in SCI; and/or

-indicating the next retransmission resource in SCI and/or TX WTRU (e.g. WTRU 102) using mode 2 where preemption is enabled.

f)(e.g., RX) WTRU (e.g., WTRU 102) determines the number of resources prior to a scheduled retransmission time for waking up Measuring amount

According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine the HARQ RTT as the time from the HARQ RTT time or the start of a timer to a particular moment before the scheduled retransmission resource indicated in SCI. An RX WTRU (e.g., WTRU 102) may determine the number of resources prior to the indicated retransmission or explicit time instance using any of the following:

-indicated by a TX WTRU (e.g., WTRU 102):

for example, a TX WTRU (e.g., WTRU 102) may provide a time, number, or time slot to an RX WTRU (e.g., WTRU 102) before scheduling retransmission resources. This may be provided in a PC5-RRC message (e.g., as a configuration parameter) and/or semi-statically applied to all transmissions by a TX WTRU (e.g., WTRU 102). Alternatively, an RX WTRU (e.g., WTRU 102) may provide an indication of the number of slots in the SCI or MAC CE or in the MAC header (e.g., as an index to a table or an explicit value).

-based on priority of transmission:

for example, an RX WTRU (e.g., WTRU 102) may determine the number of slots before a scheduled retransmission based on the priority indicated in the SCI. For example, an RXWTRU (e.g., WTRU 102) may be configured with a number of slots for a given priority and/or may determine the HARQ RTT timer by subtracting the number of slots associated with that priority from the scheduled retransmission, thereby determining the length of the harqtt time.

-based on the number of retransmissions:

for example, an RX WTRU (e.g., WTRU 102) may determine a number of time slots before a value of a scheduled retransmission time or HARQ RTT time based on a number of retransmissions associated with the HARQ process. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may be (pre) configured with a first number of time slots for a first (initial) transmission, a second number of time slots for a first retransmission, a third number of time slots for a second retransmission, and so on.

-CBR based:

for example, an RX WTRU (e.g., WTRU 102) may determine a first number of time slots for a first range of CBRs, and/or a second number of time slots for a second range of CBRs (e.g., lower), and so on. An RX WTRU (e.g., WTRU 102) may use its own measured CBR. Alternatively, the RXWTRU (e.g., WTRU 102) may use the value of CBR provided by the TX WTRU (e.g., WTRU 102).

Preference (e.g., power-related) at an RX WTRU (e.g., WTRU 102):

for example, an RX WTRU (e.g., WTRU 102) may determine the number of slots based on a current power saving state or preference at the RX WTRU (e.g., WTRU 102) indicated from an upper layer. This may be configured as a combination of (e.g., RX) WTRU (e.g., WTRU 102) capabilities and/or current power saving preferences at the RX WTRU (e.g., WTRU 102).

g)A TX WTRU (e.g., WTRU 102) may use the same/similar conditions to define reselection after preemption Limitation of (2)

According to an embodiment, a TX WTRU (e.g., WTRU 102) may limit allowed reselection resources, e.g., for retransmission resources (e.g., after preempting, skipped transmissions, etc.), to an active time associated with an RX WTRU (e.g., WTRU 102), where such active time may be defined by maintaining a set of timers and/or fixed/(pre) configuration resources at the TX WTRU (e.g., WTRU 102). The TX WTRU (e.g., WTRU 102) may limit the allowed reselection resources for retransmissions based on similar criteria to the above-described embodiments. The TX WTRU (e.g., WTRU 102) may also impose such restrictions for cases where the RX WTRU (e.g., WTRU 102) is expected to be in DRX. After preemption associated with the resources (e.g., while), the TX WTRU (e.g., WTRU 102) may limit the selected resources for retransmission based on priority, CBR, number of retransmissions, preferences from the RX WTRU (e.g., WTRU 102), etc. For example, for a first value/range of priority of transmission, a TX WTRU (e.g., WTRU 102) may select resources limited to a first resource window before and/or after the retransmission resources initially indicated in the SCI. For a second priority or priority range, a TX WTRU (e.g., WTRU 102) may select resources limited to a second window or resource before and/or after the retransmission resources initially indicated in the SCI. Such windows may also be limited to (pre) configuration resource modes without loss of generality. In this case, an RX WTRU (e.g., WTRU 102) will monitor (e.g., only) the pre-configured resource pattern for the HARQ process while in DRX. For example, in the case of communicating with a DRX-configured RX WTRU (e.g., WTRU 102) (e.g., in this case), the WTRU may apply such restrictions (e.g., only) to the case of preemption. In particular, a TX WTRU (e.g., WTRU 102) may limit the reselection of retransmission resources to ensure that new retransmission resources (e.g., always) may occur after the scheduled retransmission resource timing (indicated by the previous SCI). As discussed with the conditions herein, this may be to ensure that an RX WTRU (e.g., WTRU 102), which may operate if (e.g., assuming) preemption may not select resources before the next scheduled retransmission resources, may use the timing of the next scheduled SCI as the HARQ RTT timer.

h)A (e.g., RX) WTRU (e.g., WTRU 102) determines whether it is based on priority and/or CBR based on SCI retransmissions Setting HARQ RTT time

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to use the timing or (pre) configuration value of SCI retransmission resources (which would expire before such retransmission resources, for example) based on the priority of PDUs and/or measured/indicated CBR. For example, whether a TX WTRU (e.g., WTRU 102) may select resources that occur before the scheduled retransmission resources in the SCI (due to preemption) or whether resources that occur after the scheduled retransmission resources in the SCI (e.g., only) may be selected, which may depend on the priority of the PDU and/or CBR. For example, if the priority of the PDU is above a threshold (higher priority than indicated by the threshold), and/or for a particular range of CBRs, a (e.g., RX) WTRU (e.g., WTRU 102) may use a first (shorter) HARQ RTT timer selected from the (pre) configuration. In this case, the TX WTRU (e.g., WTRU 102) may perform reselection due to preemption from a set of resources, some of which may occur prior to the scheduled retransmission in the SCI. On the other hand, if the priority of the PDU is below the threshold (below the priority indicated by the threshold), and/or for a second (e.g., lower) range of CBRs, the RX WTRU (e.g., WTRU 102) may determine the value of HARQ RTT as the time until the next desired retransmission resource (retransmission resource or time slot after) indicated in the SCI. In this case, for a TX WTRU (e.g., WTRU 102), where the TX WTRU (e.g., WTRU 102) performs a resource reselection after preemption (e.g., in this case), the TX WTRU (e.g., WTRU 102) may select resources that occur after the initial retransmission resources (e.g., only).

Such a selection may also use (e.g., depend on) the number of retransmissions. In particular, the priority threshold may use (e.g., depend on) retransmission resources. Whether such a selection might depend on which retransmission resource is considered.

i)A WTRU (e.g., WTRU 102) determines to use a first value for HARQ RTT (e.g., RX) provisioningSetting a value Whether or not to a second value

According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may determine whether to select between a first (pre) configuration value or a second (pre) configuration value based on one of the conditions defined above for selecting between two different timer values. Such determination may be further combined with a solution to determine whether to use a value in the SCI or a pre-configured value, such that a (e.g., RX) WTRU (e.g., WTRU 102) may determine to use the (pre) configured value based on a first set of conditions (instead of the value in the SCI) and/or may determine which (pre) configured value to use based on a second set of conditions.

While not losing generality, selecting the first (pre) configuration value/the second (pre) configuration value may mean combining (e.g., via addition) the two (pre) configuration values to determine the total HARQ RTT. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a value x+y in a first condition and/or may set the HARQ RTT timer to a value x+z in a second condition, where X, Y and/or Z are both (pre) configured values. A (e.g., RX) WTRU (e.g., WTRU 102) may obtain such (pre) configuration from a peer-to-peer (e.g., TX) WTRU (e.g., WTRU 102) and/or from a network. A (e.g., RX) WTRU (e.g., WTRU 102) may also implicitly determine such a value X/Y/Z based on the configuration of a side link signal/channel (e.g., PSFCH). For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine a value of any component of HARQ RTT associated with time between SCI reception and/or PSFCH. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine a value of any component of HARQ RTT associated with a PSFCH and/or a time between some explicit resources indicated by the TX WTRU (e.g., WTRU 102). For example, a WTRU (e.g., WTRU 102) may determine the value of any component of the HARQ RTT as the specified value (e.g., in the specification).

For example:

the- (e.g., RX) WTRU (e.g., WTRU 102) may select a first (pre) configured timer for HARQ-enabled transmissions for which the TX WTRU (e.g., WTRU 102) reports SL HARQ feedback (e.g., transmits information indicating SL HARQ feedback) to the network. Such a first timer may be determined by combining two values provided by a TX WTRU (e.g., WTRU 102) in PC5-RRC signaling, where the first value corresponds to a PSFCH-to-PUCCH delay at the TX WTRU (e.g., WTRU 102) and/or the second value corresponds to a PUCCH-to-DCI/SCI schedule configured by the network (and sent by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102) in PC5-RRC signaling);

the- (e.g., RX) WTRU (e.g., WTRU 102) may select a second (pre) configured timer for a disabled HARQ transmission for which the TX WTRU (e.g., WTRU 102) reports SL HARQ feedback (e.g., transmits information indicating SL HARQ feedback) to the network. Such a second timer may be determined by combining SCI-to-PUCCH minimum delay provided by the TX WTRU (e.g., WTRU 102) and/or PUCCH-to-SCI/SCO scheduling configured by the network;

the- (e.g., RX) WTRU (e.g., WTRU 102) may select a third (pre) configured timer for HARQ-enabled transmissions for which the TX WTRU (e.g., WTRU 102) does not report SL HARQ feedback (e.g., transmits information indicating SL HARQ feedback) to the network. Such a third timer may be determined as a value of PSFCH-to-PSSCH delay at the TX WTRU (e.g., WTRU 102), which may be provided by the TX WTRU (e.g., WTRU 102); and/or

The- (e.g., RX) WTRU (e.g., WTRU 102) may select a third (pre) configured timer for a disabled HARQ transmission for which the (e.g., RX) WTRU (e.g., WTRU 102) does not report SLHARQ feedback (e.g., transmit information indicating SL HARQ feedback) to the network. Such a timer may be determined as a value of minimum delay between SCI associated with the last retransmission resource and/or new SL resources scheduled by the network for the same HARQ process (e.g., as configured by the network and/or sent by the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102)).

While not losing generality, the above embodiments also apply to cases where the TX WTRU (e.g., WTRU 102) and/or TX WTRU (e.g., WTRU 102) calculates and/or transmits the HARQ RTT to the RX WTRU (e.g., WTRU 102).

While not losing generality, the above embodiments may be used in combination, in particular, a TX WTRU (e.g., WTRU 102) may calculate a first portion of the HARQ RTT and/or send it to an RX WTRU (e.g., WTRU 102). An RX WTRU (e.g., WTRU 102) may calculate a final value of the HARQ RTT by summing the received portion with its own determined portion. Any of these portions may be determined based on the criteria discussed in the implementations herein.

j)The DRX timer may be a function of a configured resource pool

The resource pool in V2X may have a different number of UL resources configured for side link transmission. This may affect (e.g., RX) the responsiveness of a WTRU (e.g., WTRU 102) in DRX.

According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may be configured to have one or more timer values (e.g., any of an inactivity timer, a HARQ RTT timer, a retransmission timer, an on duration timer, etc.) associated with SL DRX operation per resource pool. In particular, the timer for SL DRX may be configured with a RX resource pool of a (e.g., RX) WTRU (e.g., WTRU 102).

According to embodiments, a (e.g., RX) WTRU (e.g., WTRU 102) may apply a compensation factor to a configured DRX timer (e.g., any of an inactivity timer, a HARQ RTT timer, a retransmission timer, an on duration timer, etc.), where such compensation factor may be specific to an RX resource pool of the (e.g., RX) WTRU (e.g., WTRU 102). For example, a compensation factor may be provided to a (e.g., RX) WTRU (e.g., WTRU 102) in an RX resource pool configuration. For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine the backoff factor using the UL resource amount/ratio allowed for the side link transmission on the SL resource pool. A (e.g., RX) WTRU (e.g., WTRU 102) may apply (e.g., multiply) such a compensation factor to the configured timer to obtain an actual timer value to be used in DRX operation.

k)A TX WTRU (e.g., WTRU 102) to an RXWTRU (e.g., WTRU 102 Providing information forRX WTRU (example) For example, WTRU 102) calculates the HARQRTT/retransmission timer

As described above, an RX WTRU (e.g., WTRU 102) may determine the HARQ RTT time/timer and/or the retransmission time/timer based on explicit determinations made by the TX WTRU (e.g., WTRU 102). A TX WTRU (e.g., WTRU 102) may signal such a time/timer to an RX WTRU (e.g., WTRU 102). Such determination and/or indication may be done statically (e.g., during configuration of the unicast link) or dynamically upon occurrence of some event (e.g., change of CBR) for each HARQ process, for each SCI transmission, for each configured grant configuration/reconfiguration/activation, etc.

According to an embodiment, a TX WTRU (e.g., WTRU 102) may provide information to an RX WTRU (e.g., WTRU 102) for the RX WTRU (e.g., WTRU 102) to calculate an associated HARQ RTT and/or retransmission timer. This may include any of the following:

whether a TX WTRU (e.g., WTRU 102) is configured with mode 1 or mode 2.

Whether a TX WTRU (e.g., WTRU 102) is configured 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 configuration values of a timer, or a component of such a timer.

-a value determined by one or more WTRUs of the timer (e.g., based on capabilities), or a component of such a timer.

-an indication of whether a TX WTRU (e.g., WTRU 102) will take one or another specific action regarding preemption and/or UL/SL prioritization occurring at retransmission resources.

A TX WTRU (e.g., WTRU 102) may carry any of the above using any one or a combination of the fields in the PC5-RRC, MAC CE, MAC header, or SCI. For example, a TX WTRU (e.g., WTRU 102) may use a field in the SCI, where each code point of the field represents a combination of mode 1/mode 2, HARQ ACK/NACK reporting the measured CBR range (e.g., transmitting information indicating the measured CBR range), etc.

l)[ TX WTRU (e.g., WTRU 102) calculates HARQ RTT and/or sends it to RX WTRU (e.g., WTRU) 102)]

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

m)[ TX WTRU (e.g., WTRU 102) indicates whether/how it performs after preemption, UL/SL prioritization, etc.) Reselection]

According to an embodiment, a TX WTRU (e.g., WTRU 102) may indicate to an RX WTRU (e.g., WTRU 102) whether/how to perform a reselection of resources after an event that may change the timing of a scheduled transmission to the RX WTRU (e.g., WTRU 102). Specifically, a TX WTRU (e.g., WTRU 102) may notify an RX WTRU (e.g., WTRU 102) of any of the following:

whenever a TX WTRU (e.g., WTRU 102) prioritizes UL over SL during a scheduled retransmission, the TX WTRU (e.g., WTRU 102) will always perform a reselection or not perform a retransmission (e.g., always wait for a retransmission in the next retransmission resource if it is indicated, or discard a retransmission).

Whenever a TX WTRU (e.g., WTRU 102) prioritizes UL over SL during scheduled retransmission, the TX WTRU (e.g., WTRU 102) will perform a reselection condition, where such condition may be based on a particular parameter above/below a particular threshold, where such parameter may be any of the following:

priority level.

○CBR。

Number of retransmissions.

The number of retransmissions remaining.

The remaining PDB.

Time elapsed after initial transmission.

Whenever a TX WTRU (e.g., WTRU 102) performs preemption of the retransmission resources, the TX WTRU (e.g., WTRU 102) performs reselection or simply discards the transmission of the retransmission resources.

Whenever a TX WTRU (e.g., WTRU 102) performs preemption of a retransmission resource, what the condition the TX WTRU (e.g., WTRU 102) performs reselection of the retransmission resource, where such condition may be based on a particular parameter above/below a particular threshold, where such parameter may be any of the following:

priority level.

○CBR。

Number of retransmissions.

The number of retransmissions remaining.

The remaining PDB.

Time elapsed after initial transmission.

Whenever a TX WTRU (e.g., WTRU 102) performs preemption of retransmission resources, the TX WTRU (e.g., WTRU 102) considers which subset (or window) of resources is used for reselection of retransmission resources (e.g., such resources are defined relative to the timing of retransmission resources), or for determining the condition of such resources, such as based on any of the following:

priority level.

○CBR。

Number of retransmissions.

The number of retransmissions remaining.

The remaining PDB.

Time elapsed after initial transmission.

Whenever a TX WTRU (e.g., WTRU 102) performs preemption of retransmission resources, whether the TX WTRU (e.g., WTRU 102) may select from the resources that occur before the retransmission resources previously indicated by the SCI, and/or if based on this condition, such conditions are what, such as based on any of the following:

Priority level.

○CBR。

Number of retransmissions.

The number of retransmissions remaining.

The remaining PDB.

Time elapsed after initial transmission.

Based on such information provided by the TX WTRU (e.g., WTRU 102), the RX WTRU (e.g., WTRU 102) may determine the HARQ RTT timer value as further described herein.

(Pattern 1 case)

A (e.g., TX) WTRU (e.g., WTRU 102) configured to transmit using mode 1 may calculate a HARQ RTT timer based on one of the mechanisms described below.

n)[ TX WTRU (e.g., WTRU 102)]Calculating timing of SL HARQ feedback to gNB based on transmission to RX HARQ of WTRU (e.g., WTRU 102) RTT]

According to an embodiment, a TX WTRU (e.g., WTRU 102) may determine a HARQ RTT to send to an RX WTRU (e.g., WTRU 102) based on the timing of PUCCH resources configured by the network. For example, a TX WTRU (e.g., WTRU 102) may calculate a HARQ RTT or a component of a HARQ RTT based on any of the following:

the time difference between PSFCH resources carrying HARQ feedback for the HARQ process and/or PUCCH resources configured (e.g. in RRC for Cell Group (CG) or in DCI for dynamic grant) for providing SL HARQ feedback.

This may correspond to or be derived from the maximum value of PSFCH to PUCCH provided to the WTRU in DCI or RRC (e.g., for CG type 1).

This may correspond to the earliest PUCCH occasion for transmission calculated from the PUCCH resource indicator field in the DCI.

-time difference between SCI transmission/retransmission for HARQ processes and/or PUCCH resources configured for providing SL HARQ feedback.

The PSFCH resources and/or the TXWTRU (e.g., WTRU 102) carrying HARQ feedback for the HARQ process may transmit/decide the time difference between the Physical Uplink Shared Channel (PUSCH) resources transmitting SL HARQ feedback.

For example, a TX WTRU (e.g., WTRU 102) may combine such values with Network (NW) configuration values (e.g., by adding the values together).

For example, if such values are configured (e.g., in DCI or RRC), the TX WTRU (e.g., WTRU 102) may calculate a component of the HARQ RTT based on the value of the PSFCH-to-PUCCH delay provided by the network. Otherwise, the TX WTRU (e.g., WTRU 102) may calculate the HARQ RTT as any of the following:

-a value for reporting a specified minimum time between PSFCH resources and/or PUSCH/PUCCH resources of the HARQ ACK (e.g. transmitting information indicating the HARQ ACK).

-a default value (e.g. 0).

-earliest PUSCH resources configured for transmitting HARQ feedback for the corresponding PSFCH.

○)TX WTRU (e.g., WTRU 102) calculates HARQ by selecting/combining values RTT

According to an embodiment, a TX WTRU (e.g., WTRU 102) may select/combine HARQ RTTs or components of HARQ RTTs based on any of the following:

-mode (mode 1 or mode 2);

whether or not configured to report PUCCH/PUSCH (e.g., transmit information indicating PUCCH/PUSCH); and/or

Whether HARQ is enabled/disabled.

The behavior in such embodiments is similar to that of an RX WTRU (e.g., WTRU 102) combining such timers when information of these factors is received from the TX WTRU (e.g., WTRU 102).

(pattern 2 cases)

A (e.g., TX) WTRU (e.g., WTRU 102) configured to transmit using mode 2 may calculate a HARQ RTT timer based on one of the mechanisms described below.

p)A TX WTRU (e.g., WTRU 102) calculates HARQ RTT based on expected preemption check time

According to an embodiment, a TX WTRU (e.g., WTRU 102) may calculate a HARQ RTT based on an expected preemption check time (e.g., as defined in the ETSI standard). For example, a TX WTRU (e.g., WTRU 102) may determine an earliest/latest/expected time that the TX WTRU (e.g., WTRU 102) will perform a preemption check of reserved resources for retransmission. A TX WTRU (e.g., WTRU 102) may provide the time to an RX WTRU (e.g., WTRU 102).

A (e.g., TX) WTRU (e.g., WTRU 102) may also determine such time based on any of the following:

-priority of PDUs transmitted in the initial transmission.

For example, a TX WTRU (e.g., WTRU 102) may determine a first preemption check time for a first priority of a packet, a second preemption check time for a second priority of a packet, etc.

-a preference indication (e.g., based on power saving state) from an RX WTRU (e.g., WTRU 102).

For example, a TX WTRU (e.g., WTRU 102) may obtain power saving assistance information from an RX WTRU (e.g., WTRU 102). For example, such information may 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) may select a first preemption time for a low power mode, a second preemption time for a medium power mode, etc.

-measured CBR.

Configured (e.g., TX or RX) WTRU capabilities.

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

According to an embodiment, a (e.g., TX) WTRU (e.g., WTRU 102) may determine the HARQ RTT as the time until a desired preemption check (from initial transmission/retransmission). A (e.g., TX) WTRU (e.g., WTRU 102) may determine the HARQ RTT by adding a certain (pre) configured/specified time value to the desired preemption check time. A TX WTRU (e.g., WTRU 102) may send the calculated HARQ RTT to an RX WTRU (e.g., WTRU 102).

1.4TX WTRUs (e.g., WTRUs) supporting HARQ RTT and/or retransmission timers 102 Behavior of (1)

a)A TX WTRU (e.g., WTRU 102) determines whether to perform reselection after preemption/prioritization

According to an embodiment, a TX WTRU (e.g., WTRU 102) may be configured with a condition as to whether preemption and/or prioritization (e.g., UL transmission over SL transmission) may trigger a selection (reselection). In particular, if an RX WTRU (e.g., WTRU 102) is configured with SL DRX, the TX WTRU (e.g., WTRU 102) may not perform resource reselection after preemption. In particular, if an RX WTRU (e.g., WTRU 102) is configured in DRX, in the case where the TX WTRU (e.g., WTRU 102) performs UL transmissions instead of SL transmissions (e.g., in this case), the TX WTRU (e.g., WTRU 102) may not perform resource reselection after missing SCI/data transmissions (e.g., at scheduled or advertised resources). This may be done to avoid the TX WTRU (e.g., WTRU 102) transmitting on resources for which the RX WTRU (e.g., WTRU 102) is known to be in DRX (not monitoring SL). According to embodiments, a TX WTRU (e.g., WTRU 102) may be configured with specific conditions or combinations of conditions as to when such reselection should be performed (and/or), such as in the case where an RX WTRU (e.g., WTRU 102) is in DRX (e.g., in this case), in relation to any of the following:

priority/QoS:

for example, if the priority of the transmission/PDU is higher than a threshold (where such threshold may further depend on CBR), then the TX WTRU (e.g., WTRU 102) may perform reselection of the retransmission resources.

-remaining retransmission resources:

for example, a TX WTRU (e.g., WTRU 102) may perform reselection of retransmission resources based on the presence/amount of remaining retransmission resources for the same HARQ process that have been reserved (e.g., not affected by preemption).

For example, if at least x additional retransmission resources remain after the missed/preempted retransmission (where x may further depend on any other condition such as priority, CBR, etc.), a TX WTRU (e.g., WTRU 102) may perform a reselection of the retransmission resources.

-CBR：

For example, if CBR is below a threshold, a TX WTRU (e.g., WTRU 102) may perform reselection of retransmission resources.

According to an embodiment, a TX WTRU (e.g., WTRU 102) that may decide/determine not to perform reselection after a skipped retransmission may use the remaining resources indicated in the SCI, in case (e.g., assuming) such resources are not preempted. Alternatively, a TX WTRU (e.g., WTRU 102) may choose to discard resources. The TX WTRU (e.g., WTRU 102) decision whether to use or discard these resources may further depend on any of the following:

-the number of retransmissions that have been performed on the PDU.

QoS associated with the PDU.

The number of remaining retransmissions for the HARQ process that were previously advertised and/or that may still be performed by the TX WTRU (e.g., WTRU 102).

Power level/preference of an RX WTRU (e.g., WTRU 102).

-combinations thereof.

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

Similar behavior may be desired at an RX WTRU (e.g., WTRU 102) to set a retransmission timer for a HARQ process. In particular, an RX WTRU (e.g., WTRU 102) may be configured with the same minimum number of retransmissions of HARQ processes for a particular priority and/or power preference level. If the RX WTRU (e.g., WTRU 102) is unable to decode the SCI at the planned/reserved resources and/or the RX WTRU (e.g., WTRU 102) is configured with DRX, the RX WTRU (e.g., WTRU 102) may:

-if the minimum number of retransmissions for the HARQ process is not reached, starting a retransmission timer;

if the minimum number of retransmissions for the HARQ process is reached, then the retransmission timer is not started (e.g. moved to sleep for the HARQ process).

b)A TX WTRU (e.g., WTRU 102) may indicate the last retransmission for a HARQ process

In contrast to the case where the TX WTRU (e.g., WTRU 102) cannot find enough retransmission resources at the time of resource selection (and may later perform separate resource selection for additional transmission resources), ambiguity as to whether the TX WTRU (e.g., WTRU 102) did not indicate additional reserved retransmission resources in the SCI due to the fact that the number of retransmissions (for a particular priority/CBR) was exceeded or that the PDB was exceeded may exist at the RX WTRU (e.g., WTRU 102).

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

For example, a TX WTRU (e.g., WTRU 102) may indicate that in the event that PDB is exceeded (e.g., in this case), it is not desirable to attach retransmission resources. For example, a TX WTRU (e.g., WTRU 102) may indicate that in the event that the maximum number of retransmissions of priority/CBR based PDUs is exceeded (e.g., in this case), it is not desirable to attach retransmission resources. For example, a TX WTRU (e.g., WTRU 102) may indicate that retransmission resources are desired in the case where the WTRU cannot select retransmission resources during resource selection, but there are at least x milliseconds between the last reserved transmission (retransmission) for a PDU and/or the expiration of the PDB for the PDU (e.g., in this case). For example, a TX WTRU (e.g., WTRU 102) may indicate that additional retransmission resources are desired without exceeding a maximum number of retransmission resources, the WTRU failing to select retransmission resources for retransmission, and/or the WTRU may decide/expect/determine to include retransmissions of PDUs in the newly selected resources/grants.

c)The resource selection (reselection) at the TX WTRU (e.g., WTRU 102) may depend on the information received by the TX WTRU (e.g., WTRU 102) maintained activity timer

A TX WTRU (e.g., WTRU 102) may maintain a similar set of timers (HARQ RTT timers, retransmission timers, etc.) for each HARQ process associated with a given RX WTRU (e.g., WTRU 102). A TX WTRU (e.g., WTRU 102) may start/stop/reset such timers and/or set the values of such timers using the same rules defined herein for an RX WTRU (e.g., WTRU 102).

According to an embodiment, a TX WTRU (e.g., WTRU 102) performing resource selection (reselection) to obtain resources for retransmission of PDUs may select resources from a time period in which any of the following occurs:

-the HARQ RTT timer for a specific HARQ process is not running;

-a retransmission timer for a specific HARQ process is running;

-at least one of the retransmission timers for any HARQ process associated with the RX WTRU (e.g., WTRU 102) is expected to run;

an inactivity timer associated with an RX WTRU (e.g., WTRU 102) is expected to run; and/or

An on duration timer associated with an RX WTRU (e.g., WTRU 102) is expected to run.

For example, a TX WTRU (e.g., WTRU 102) may perform resource reselection on transmission (retransmission) resources associated with a particular HARQ process. In the case where any of the above timers are running in association with an RX WTRU (e.g., WTRU 102), the TX WTRU (e.g., WTRU 102) may select resources for time-limited transmission (retransmission) resources.

For example, a TX WTRU (e.g., WTRU 102) may perform a resource reselection for transmission (retransmission) resources associated with a particular HARQ process, given that preemption is possible. In view of preemption, a TX WTRU (e.g., WTRU 102) may perform reselection within a set of resources associated with a retransmission timer running at an RX WTRU (e.g., WTRU 102).

d)Handling HARQ based SL RLF in the presence of DRX

ACK-to-NACK errors may cause a TX WTRU (e.g., WTRU 102) to erroneously trigger a SL-RLF (side link-radio link failure). In particular, if an RX WTRU (e.g., WTRU 102) sends an ACK and/or is interpreted by a TX WTRU (e.g., WTRU 102) as a NACK, the TX WTRU (e.g., WTRU 102) may perform a retransmission during a time that the retransmission timer may operate by (e.g., is assumed to be) running at the RX WTRU (e.g., WTRU 102). However, since an RX WTRU (e.g., WTRU 102) may have decoded correctly (and transmitted an ACK), the retransmission timer may never start in this case. This may result in the DTX counter for triggering RLF being erroneously incremented.

According to an embodiment, DTX may refer to a situation where a TX WTRU (e.g., WTRU 102) may not receive SL HARQ feedback from an RX WTRU (e.g., WTRU 102) at a desired time (e.g., PSFCH timing) after a HARQ enabled transmission.

According to an embodiment, in the case where an RX WTRU (e.g., WTRU 102) is configured with DRX (e.g., in this case), the TX WTRU (e.g., WTRU 102) may disable the count of DTX. In particular, in the case of transmission to one or more RX WTRUs configured with SL DRX (e.g., WTRU 102) (e.g., in this case), the TX WTRU (e.g., WTRU 102) may not count some/all HARQ DTX occurrences. A TX WTRU (e.g., WTRU 102) may, for example, always disable the count, e.g., at certain times (e.g., only when a particular timer is not running). For example:

In the case where at least one RX WTRU (e.g., WTRU 102) is configured with SL DRX (e.g., in this case), the TX WTRU (e.g., WTRU 102) may not count HARQ DTX for all HARQ based transmissions.

A TX WTRU (e.g., WTRU 102) may not count HARQ DTX intended for HARQ based transmissions of an RX WTRU (e.g., WTRU 102) configured with SLDRX.

In the case (e.g., in this case) where the corresponding transmission (for which DTX is observed) is performed in any of the following cases (e.g., in this case), the TXWTRU (e.g., WTRU 102) may not count HARQ DTX intended for HARQ-based transmissions of one or more RX WTRUs (e.g., WTRU 102) configured with SL DRX:

the on duration timer associated with an RX WTRU (e.g., WTRU 102) is not running.

The inactivity timer associated with the RX WTRU (e.g., WTRU 102) is not running.

HARQ RTT associated with an RX WTRU (e.g., WTRU 102) is enabled/disabled.

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), e.g., associated with one or more of the other conditions in the previous examples.

According to an embodiment, a TX WTRU (e.g., WTRU 102) may perform a limited number of retransmissions (e.g., associated with the same Transport Block (TB)), where such maximum number of retransmissions is (pre) configured by the NW to the WTRU to be dedicated to transmissions to the RX WTRU (e.g., WTRU 102) in DRX. In particular, such a maximum number of retransmissions may be configured differently than a maximum number of retransmissions configured for other purposes. The TX WTRU (e.g., WTRU 102) may also derive a maximum number of retransmissions from the maximum number of HARQ DTX triggering SL RLF. For example, a TX WTRU (e.g., WTRU 102) may use a (e.g., configured) percentage of the configured maximum HARQ DRX to derive the maximum number of retransmissions. The maximum number of retransmissions performed by the TX WTRU (e.g., WTRU 102) for the TB (to avoid possible erroneous SL RLF) may be further limited to retransmissions that occur (e.g., only) if the on duration timer and/or the inactivity timer for the RX WTRU (e.g., WTRU 102) are not running (e.g., in this case).

According to embodiments that may be combined with previous solutions, a TX WTRU (e.g., WTRU 102) may adjust its transmission time for a TB after one or more HARQ based transmissions that result in DTX. In particular, a TX WTRU (e.g., WTRU 102) may stop, for example, retransmissions associated with a particular TB after one or more (or a (pre) configured number of) failed transmissions (retransmissions) that generated HARQ DTX and/or HARQ NACK. A TX WTRU (e.g., WTRU 102) may resume such retransmissions at one or any of the following times:

An on duration timer for an RX WTRU (e.g., WTRU 102) is running.

An inactivity timer for an RX WTRU (e.g., WTRU 102) is running.

A retransmission timer for an RX WTRU (e.g., WTRU 102) is running (e.g., associated with another HARQ process), and/or, for example, the RX WTRU (e.g., WTRU 102) has successfully transmitted HARQ feedback (ACK or NACK).

According to an embodiment, a TX WTRU (e.g., WTRU 102) may be configured by the NW with different thresholds/conditions (e.g., maximum number of continuous HARQ DTX) for triggering SL RLF for transmission with one or more RX WTRUs (e.g., WTRU 102) configured with SL DRX. In particular, a TX WTRU (e.g., WTRU 102) may receive two configurations for triggering the maximum number of consecutive HARQ RTXs for SL RLFs. The TX WTRU (e.g., WTRU 102) may use the first configuration if it performs a transmission to one or more RX WTRUs (e.g., WTRU 102) that are not configured with SL DRX (e.g., in this case), and/or may use the second configuration if it performs a transmission where at least one or more RX WTRUs (e.g., WTRU 102) are configured with SL DRX (e.g., in this case).

1.5Exemplary embodiments at an RX WTRU (e.g., WTRU 102)

Fig. 4A-4C illustrate timing diagrams of HARQ RTT timers and/or retransmission timers (e.g., reTx timers) for a scenario of a (e.g., resource allocation) mode 2TX WTRU (e.g., WTRU 102). Referring to fig. 4A-4C, an initial transmission TR0 (e.g., associated with an SCI) is performed along with an indication of two SCI retransmissions (first retransmission TR1 and/or second retransmission TR 2) (e.g., associated with an SCI). Specifically:

referring to fig. 4A, in case 1, preemption may be disabled and/or a TX WTRU (e.g., WTRU 102) may not skip the SCI associated with the first retransmission TR 1. The HARQ RTT timer may be set to a time until the next retransmission resource TR 2. A retransmission timer (e.g., a ReTx timer) may be started (e.g., only) after the last scheduled retransmission. The TX WTRU (e.g., WTRU 102) may perform resource selection for a new SCI transmission associated with the same HARQ process during the time of the retransmission timer.

Referring to fig. 4B, in case 2, preemption may be disabled and/or a TX WTRU (e.g., WTRU 102) may skip the SCI associated with the first retransmission TR1 due to UL/SL prioritization. Alternatively, a TX WTRU (e.g., WTRU 102) may enable preemption, but may ensure that the reselection of the retransmission resources for preemption occurs after planning the retransmission resources (as discussed herein with respect to limiting the retransmission resources for preemption). An RX WTRU (e.g., WTRU 102) may start a retransmission timer (e.g., reTx timer) after the location of the scheduled (and not received) retransmission TR1 (or after expiration of a HARQ RTT timer set based on the timing of the retransmission resources in the SCI). A TX WTRU (e.g., WTRU 102) may perform a resource reselection on the transmission of the first retransmission TR1 resource for a time associated with a retransmission timer (e.g., reTx timer). A retransmission timer (e.g., reTx timer) may be started after the last scheduled retransmission TR 2. A TX WTRU (e.g., WTRU 102) may perform resource selection for a new SCI transmission associated with the same HARQ process during the time of the retransmission timer (e.g., reTx timer).

Referring to fig. 4C, in case 3, preemption may be enabled and/or a TX WTRU (e.g., WTRU 102) may skip the SCI associated with the first retransmission TR1 due to preemption (without limitation, which may mean that the re-selected retransmission resources may occur prior to the scheduled timing of the retransmission based on information in the SCI). The TX WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a value less than the next scheduled retransmission TR2 resource and/or the retransmission timer (e.g., reTx timer) may start after (e.g., immediately after). A TX WTRU (e.g., WTRU 102) reselection window associated with the preemption is determined based on a retransmission timer (e.g., reTx timer).

a)Enabling HARQ RTT and/or retransmission timer handling for HARQ feedback

In a first exemplary embodiment of processing the HARQ RTT timer and/or the retransmission timer, the RX WTRU (e.g., WTRU 102) may be first informed of the resource allocation pattern (pattern 1 or pattern 2) or a similar indication from the TX WTRU (e.g., WTRU 102) in PC5-RRC signaling, which may determine the timer processing behavior at the RX WTRU (e.g., WTRU 102). After receiving the first SCI with the unoccupied HARQ process number or indicating that the first SCI represents an initial transmission (e.g., while), an RX WTRU (e.g., WTRU 102) may assign the receiving HARQ process to a new transmission/PDU. An RX WTRU (e.g., WTRU 102) may determine that HARQ feedback is enabled, which results in using the behavior associated with this embodiment. An RX WTRU (e.g., WTRU 102) may store the initial transmission and/or the location/timing of the possible retransmission indicated in the first SCI representing the initial transmission.

After (successful or unsuccessful) decoding of the initial transmission, an RX WTRU (e.g., WTRU 102) may transmit a PSFCH with HARQ feedback. An RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first symbol/slot after transmission of a PSFCH. If the RX WTRU (e.g., WTRU 102) prioritizes UL transmissions over SL transmissions and/or thus skips PSFCH, the RX WTRU (e.g., WTRU 102) may start a HARQ RTT timer at a first symbol/slot after PSFCH that skips and/or implies transmission of HARQ feedback.

Fig. 5 depicts an overall method 500 of processing/configuring HARQ RTT timers and/or retransmission timers. At step 501, an RX WTRU (e.g., WTRU 102) may determine a resource allocation pattern of a peer (e.g., TX) WTRU (e.g., WTRU 102) from PC 5-RRC. At step 502, an RX WTRU (e.g., WTRU 102) may decode a first SCI after (e.g., while) receiving the first SCI and/or determine that the first SCI represents an initial transmission or retransmission. At steps 510 and/or 520, the RX WTRU (e.g., WTRU 102) may determine whether there are additional retransmission resources from the SCI reserved for the HARQ process.

An RX WTRU (e.g., WTRU 102) may set a HARQ RTT timer as follows:

-if the resource allocation pattern is pattern 1 (or TX WTRU (e.g., WTRU 102) indication indicates use of such HARQ behavior):

at step 512, if there are additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT to the time until the next retransmission resource for the HARQ process indicated in the SCI.

■ As a variation of this embodiment, the RX WTRU (e.g., WTRU 102) may not start the HARQ RTT timer. Instead, an RX WTRU (e.g., WTRU 102) may rely on determining whether to start a retransmission timer at the time of the next retransmission resource. In such variations, the (e.g., may assume) active time may be associated with the timing of the retransmission resources and/or the retransmission timer running.

At step 511, if there are no additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT to a (pre) configured or predefined value (also referred to as "ConfigValH 1"), where the value is associated with mode 1 (from NW or other WTRUs).

■ Furthermore, the RX WTRU (e.g., WTRU 102) may also select a specific HARQ RTT timer for mode 1 associated with the specific mode 1 case under consideration, e.g., from a list of (pre) configuration values provided by the TX WTRU (e.g., WTRU 102), based on additional information provided by the TX WTRU (e.g., WTRU 102) of the mode 1 case under consideration, such as:

● Whether a TX WTRU (e.g., WTRU 102) has PUCCH resources configured.

● Whether the TX WTRU (e.g., WTRU 102) reports HARQ feedback (e.g., transmits information indicating HARQ feedback) to the network.

■ In variations 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 that time, or at some (pre) configured or predefined time after that time.

-if the resource allocation pattern is pattern 2:

at step 521, if there are additional retransmission resources reserved for the HARQ process from the SCI, the RX WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a (pre) configured or predefined value (also referred to as "configval 2") associated with the preemptive mode 2 resource reselection (from NW or other (e.g., RX) WTRUs (e.g., WTRU 102)). Such timers may further depend on priority/CBR. Such timers may further depend on priority/CBR. At step 522, if preemption is enabled, a (e.g., RX) WTRU (e.g., WTRU 102) may do so. Alternatively, if preemption is disabled, a (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to the time until the next scheduled retransmission (step 512).

At step 523, if there is no additional retransmission desired for the HARQ process, the (e.g., RX) WTRU (e.g., WTRU 102) may set the HARQ RTT timer to a (pre) configured or predefined value (also referred to as "ConfigValH 3") associated with the mode 2 resource selection based on the selection of new resources (from NW or other WTRUs).

At step 530, an RX WTRU (e.g., WTRU 102) may start/run a HARQ RTT timer.

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

According to an embodiment, an RX WTRU (e.g., WTRU 102) may perform the following operations in relation to a retransmission timer:

-if the resource allocation pattern is pattern 1:

at step 542, if the last received transmission of the HARQ process is associated with the last retransmission resource in the indicated SCI for the HARQ process and/or the PDU for the HARQ process was not successfully decoded, the RX WTRU (e.g., WTRU 102) may start a retransmission timer and/or set it to a (pre) configuration value (also referred to as "ConfigValR 1") associated with the mode 1 retransmission in the new SCI (step 541).

At step 560, the (e.g., RX) WTRU (e.g., WTRU 102) may not start a retransmission timer if the last received transmission of the HARQ process is not associated with the last retransmission resource in the indicated SCI for the HARQ process (e.g., an upcoming mode retransmission). At step 561, the (e.g., RX) WTRU (e.g., WTRU 102) may also set the HARQ RTT time, e.g., at the time of the next retransmission resource, and/or start the HARQ RTT timer (step 562).

-if the resource allocation pattern is pattern 2:

at step 550, a (e.g., RX) WTRU (e.g., WTRU 102) may first determine whether a slot for which the HARQ RTT timer expires is associated with reserved resources.

■ If so, and/or the SCI is not successfully decoded in the slot, the RX WTRU (e.g., WTRU 102) may start a retransmission timer if the PDU associated with the HARQ process is not successfully decoded. If so, and/or the SCI is successfully decoded, the RX WTRU (e.g., WTRU 102) may not start a retransmission timer in this case and/or continue to decode the transmission (retransmission) associated with the HARQ process normally at step 560. At step 561, the (e.g., RX) WTRU (e.g., WTRU 102) may also set the HARQ RTT time, e.g., at the time of the next retransmission resource, and/or start the HARQ RTT timer (step 562).

■ At step 550, if the time slot is not associated with reserved resources in the SCI and/or 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) may start the HARQ retransmission timer at step 552 and/or set it to a (pre) configured or specified value (also referred to as "ConfigValR 2") at step 551.

■ Different values of the retransmission timer may be used by (e.g., RX) the WTRU (e.g., WTRU 102) for different situations

■ Alternatively, for the case/alternative case where the HARQ RTT timer is not started above (e.g., mode 1 and/or additional retransmissions, or mode 2 and/or preemption is disabled), the RX WTRU (e.g., WTRU 102) may consider the expiration of the HARQ RTT timer alone (step 565) and/or the time slot associated with decoding of the retransmission resources indicated with the previous SCI. Specifically:

● If the PDU associated with the HARQ process is not successfully decoded, the RX WTRU (e.g., WTRU 102) monitors the SCI at all resources associated with the retransmission indicated in the previous SCI for the HARQ process. At a time instance associated with retransmission resources for an undecoded PDU, the RX WTRU (e.g., WTRU 102) starts a retransmission timer if the SCI is not decoded (e.g., additionally, if the TX WTRU (e.g., WTRU 102) is in mode 2). Otherwise, the RX WTRU (e.g., WTRU 102) does not start the retransmission timer.

● If the HARQ RTT timer expires and/or the PDU for the HARQ process is not successfully decoded, a retransmission timer for the HARQ process is started.

An RX WTRU (e.g., WTRU 102) may monitor the SL whenever any of the following conditions occur:

one or more on duration timers, inactivity timers, or retransmission timers at an RX WTRU (e.g., WTRU 102) are running; and/or

The time slot is associated with a reserved retransmission resource associated with a HARQ process for which the PDU associated with the HARQ process has not yet been decoded.

b)Disabling HARQ RTT and/or retransmission timer processing for HARQ feedback

In a second exemplary embodiment of processing the HARQ RTT timer and/or the retransmission timer, the resource allocation mode (mode 1 or mode 2) may be first notified from the TX WTRU (e.g., WTRU 102) to the RX WTRU (e.g., WTRU 102) in PC5-RRC signaling. After receiving the first SCI with the unoccupied HARQ process number or indicating that the first SCI represents an initial transmission (e.g., while), an RX WTRU (e.g., WTRU 102) may assign the receiving HARQ process to a new transmission/PDU. An RX WTRU (e.g., WTRU 102) may determine that HARQ feedback from the SCI is disabled, which results in using the behavior associated with this embodiment. In particular, an RX WTRU (e.g., WTRU 102) may be configured with a different set of (pre) configured or specified timers for HARQ processes in case HARQ feedback is disabled (e.g., as compared to previous embodiments in which HARQ feedback is enabled). An RX WTRU (e.g., WTRU 102) may store the initial transmission and/or the location/timing of the possible retransmission indicated in the first SCI representing the initial transmission.

After receiving the SCI with HARQ feedback disabled (e.g., while), an RX WTRU (e.g., WTRU 102) may start the HARQ RTT timer immediately upon receiving the SCI.

An RX WTRU (e.g., WTRU 102) may set the HARQ RTT timer similar to the previous embodiments, except that a different set of (pre) configuration timers may be used.

An RX WTRU (e.g., WTRU 102) may set the retransmission timer similarly to the previous embodiments, e.g., except that a different (pre) configured timer value may be used.

2.Method for defining an active time (inactivity timer) relative to an initial transmission

2.1Modeling inactivity timers for unicast

The described embodiments may be defined, for example, for unicast, but may also be applicable to multicast and/or broadcast.

a)Conditions for starting/using inactivity timers

According to embodiments, a WTRU (TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may be configured to start/use an inactivity timer based on certain conditions. These conditions may be related to any one of the following or a combination (and/or) thereof:

-enabling HARQ feedback

For example, if the received transmission/retransmission is associated with a HARQ enabled transmission, an RX WTRU (e.g., WTRU 102) may start an inactivity timer. Otherwise, if a transmission/retransmission disabling HARQ is received, the RX WTRU (e.g., WTRU 102) may not start the inactivity timer.

For example, if a transmission performed by a (e.g., RX) WTRU (e.g., WTRU 102) indicates HARQ enablement, then the TX WTRU (e.g., WTRU 102) may start an inactivity timer. Otherwise, if the transmission indicates HARQ disabling, the TX WTRU (e.g., WTRU 102) may not start the inactivity timer.

CR/CBR at RX WTRU (e.g., WTRU 102)

For example, an RX WTRU (e.g., WTRU 102) may send to a TX WTRU (e.g., WTRU 102) a measurement of CR/CBR at the RX WTRU (e.g., WTRU 102). An RX WTRU (e.g., WTRU 102) may send such a measurement if it changes from one range to another (e.g., in this case) or if it changes by some amount (e.g., in this case).

■ For example, if the CR/CBR is below a threshold, the RX WTRU (e.g., WTRU 102) may start an inactivity timer after receiving a new transmission or retransmission (e.g., while). Otherwise, the RX WTRU (e.g., WTRU 102) may not start/restart the inactivity timer.

■ For example, if the CR/CBR indicated by the RX WTRU (e.g., WTRU 102) is below a threshold, the TX WTRU (e.g., WTRU 102) may start an inactivity timer for transmission. Otherwise, the TX WTRU (e.g., WTRU 102) may not start/restart the inactivity timer.

b)Use of inactivity timers at a TX WTRU (e.g., WTRU 102)

According to an embodiment, if such an RX WTRU (e.g., WTRU 102) is configured in DRX, the TX WTRU (e.g., WTRU 102) may maintain an inactivity timer associated with the RX WTRU (e.g., WTRU 102) to which it is transmitting. A TX WTRU (e.g., WTRU 102) may use an inactivity timer (and other timers such as an on duration timer or a retransmission timer) to determine whether it may perform a new transmission and/or retransmission to the particular RX WTRU (e.g., WTRU 102). For example, in the event that one of an inactivity timer, an on duration timer, or a retransmission timer is running (e.g., in this case), a TX WTRU (e.g., WTRU 102) may perform a new transmission and/or retransmission (e.g., only) to an RX WTRU (e.g., WTRU 102).

c)The activation of the inactivity timer by the TX WTRU (e.g., WTRU 102) may occur at different times

According to an embodiment, a TX WTRU (e.g., WTRU 102) may start an inactivity timer to any of the following times:

-after initial transmission of a new TB (e.g. resource) (e.g. at time):

for example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer in a first time slot after transmission of a SCI associated with a new transmission.

For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer in a first time slot after a (pre) configured number of time slots after transmission of an SCI associated with a new transmission.

After receiving the HARQ feedback (e.g., at the time), wherein this may further depend on the type of HARQ feedback:

for example, if a TX WTRU (e.g., WTRU 102) receives an harq ack or NACK, the TX WTRU (e.g., WTRU 102) may start an inactivity timer. However, if the TX WTRU (e.g., WTRU 102) decodes DTX on the PSFCH resource, the TX WTRU (e.g., WTRU 102) may not start the inactivity timer.

For example, if a TX WTRU (e.g., WTRU 102) receives an harq ack, the TX WTRU (e.g., WTRU 102) may 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 start the inactivity timer.

-after retransmission of the last indication of the new TB in SCI:

for example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer in the first time slot after transmission of the SCI associated with the last retransmission indicated in the previous SCI.

For example, a TX WTRU (e.g., WTRU 102) may start an inactivity timer at multiple (pre) configured slots after transmission of the SCI associated with the last retransmission indicated in the previous SCI.

-after retransmission of the nth indication of the new TB in the SCI, wherein N may be (pre) configured or predefined as:

for example, N may further depend on QoS (e.g., priority).

According to an embodiment, a TX WTRU (e.g., WTRU 102) may start an inactivity timer at different times (any of the times described above) based on any of the following specific factors:

whether HARQ feedback is enabled/disabled in a new transmission where an inactivity timer should be started.

Based on CBR/CR measured and/or reported by an RX WTRU (e.g., WTRU 102).

QoS (e.g., priority) of the transmission.

For example, in the case where a TX WTRU (e.g., WTRU 102) receives a HARQ ACK or NACK in the case where HARQ feedback is enabled for transmission (e.g., in this case), the TX WTRU may start an inactivity timer, but if HARQ feedback is not enabled, the TX WTRU may start the inactivity timer after the initial transmission of the TB.

d)A TX WTRU (e.g., WTRU 102) determines the duration of an inactivity timer to be used

According to an embodiment, the inactivity timer initiated by the TX WTRU (e.g., WTRU 102) may have the same value as that configured at the RX WTRU (e.g., WTRU 102). According to an embodiment, the inactivity timer initiated by the TX WTRU (e.g., WTRU 102) may have a value that is shorter than a value configured at the RX WTRU (e.g., WTRU 102). For example, a TX WTRU (e.g., WTRU 102) may be (pre) configured with a different inactivity timer for use. According to an embodiment, a TX WTRU (e.g., WTRU 102) may shorten a configured inactivity timer used at an RX WTRU (e.g., WTRU 102) to account for different start times for the inactivity timer. Specifically, if a TX WTRU (e.g., WTRU 102) starts an inactivity timer after receiving HARQ feedback (e.g., while):

the TX WTRU (e.g., WTRU 102) may shorten the inactivity timer (as compared to the value used at the RX WTRU (e.g., WTRU 102)) for the initial transmission (or relative to the (hypothesized) start time of the initial transmission received at the RX WTRU (e.g., WTRU 102)) and/or the time between the first ACK or NACK received by the TX WTRU (e.g., WTRU 102) to the transmission/retransmission of the TB (or any other TB).

e)An RX WTRU (e.g., WTRU 102) is configured with a single inactivity timer, or for each peer (e.g. E.g., TX) WTRU (e.g., WTRU 102)/L2 Multiple inactivity timers for ID

In the case where there are multiple unicast links and/or multiple L2 destination IDs of interest corresponding to unicast/multicast, different implementations are possible for maintaining an inactivity timer at an RX WTRU (e.g., WTRU 102).

According to embodiments, a WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may maintain an inactivity timer for each ID or set of IDs, such as WTRU ID, logical Channel (LCH) ID, L2ID, etc. For example, the WTRU may maintain an inactivity timer for each unicast link (source/destination L2ID pair) and/or L2ID of interest for multicast/broadcast. Whenever the WTRU receives a transmission associated with a source/destination L2ID, the WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may set/reset an inactivity timer associated with the source/destination L2 ID.

According to embodiments, a WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may maintain a single inactivity timer for all unicast links (source/destination ID pairs) and/or, for example, for all L2 IDs associated with multicast/broadcast communications. In particular, a WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may set/reset the inactivity timer after receiving any side link transmissions (e.g., while). To illustrate different DRX configurations, e.g., associated with different unicast links and/or multicast L2 source/destination IDs, a WTRU may:

-setting the value of the inactivity timer (in case the inactivity timer is set/reset (e.g. in this case)) to a different value depending on which L2 source/destination ID received the transmission (which caused the timer to be reset);

specifically, a WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may be (pre) configured with a different value of inactivity timer for each source/destination L2 ID (e.g., via any of PC5-RRC, uu RRC, pre-configuration, SIB, etc.). After receiving a transmission associated with a particular source/destination L2 (e.g., upon receipt of a transmission associated with the source/destination L2), the RXWTRU (e.g., WTRU 102) may set the value of the inactivity timer to the value configured for that source/destination L2 ID; and/or

-differently determining an action during decoding of the inactivity timer based on the source/destination L2 ID of which transmission starts the inactivity timer, which action may comprise any one of the following:

monitoring different sets of SL resources;

using different rules/priorities to determine whether to monitor SL or UL; and/or

Determining whether a transmission can be performed during the timer run.

The embodiments described herein in relation to inactivity timers are applicable to any of the embodiments described above.

f)An RX/TX WTRU (e.g., WTRU 102) processes uncertainty of MACPDU decoding to start an inactivity timer

The inactivity timer is typically restarted (e.g., only) for new transmissions, while retransmissions are handled by the HARQ RTT/retransmission timer (as in Uu). However, determining whether a transmission is associated with a new transmission may require/use decoding of the MAC PDU (which has some variable delay associated therewith).

A DRX related timer (e.g., inactivity timer, HARQ RTT timer, or retransmission timer) may be started after (e.g., upon) receiving the SCI, and/or whether or not to start such a timer may be conditioned on (e.g., only) information (e.g., HARQ process ID, new Data Indicator (NDI), L1 ID) carried in the SCI. Alternatively, such a timer may be started after (e.g., upon) decoding of the MAC PDU and/or conditional on information in the MAC PDU (e.g., L2 ID, LCH ID). Alternatively, the starting of such a timer may be conditioned on information in both the MAC PDU and/or the SCI, but the timer may represent the time that has elapsed after receiving the SCI. Furthermore, a WTRU (e.g., TX WTRU (e.g., WTRU 102) or RX WTRU (e.g., WTRU 102)) may have different behaviors for different timers.

g)An RX WTRU (e.g., WTRU 102) starts an inactivity timer at the PHY layer and/or may decode Stopping inactivity timer after PDU

According to an embodiment, an RX WTRU (e.g., WTRU 102) may start an inactivity timer based on conditions related to decoding the SCI at the PHY layer. After the PHY layer starts the inactivity timer, the MAC layer may perform MAC PDU decoding and/or may stop the inactivity timer or continue to run the inactivity timer according to the decoding result. For example:

a- (e.g., RX) WTRU (e.g., WTRU 102) (PHY layer) may start an inactivity timer if it receives a SCI (e.g., in this case), where any of the following is satisfied:

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 currently configured unicast link at the WTRU.

The received transmission corresponds to a multicast transmission and/or the L1 destination ID in the SCI matches the L1 destination ID of any multicast/broadcast service of interest.

NDI (in SCI) is switched and/or HARQ process(s) (in SCI) are associated with the currently allocated HARQ process (e.g., a new transmission is indicated for that HARQ process).

HARQ in SCI is not currently allocated at the WTRU (indicating a new transmission for a new HARQ process).

The received transmission corresponds to a new transmission (e.g., NDI is switched).

The received transmission corresponds to a retransmission (e.g., NDI is not switched), but the RXWTRU (e.g., WTRU 102) does not receive/decode the initial transmission associated with the retransmission.

-the (e.g. RX) WTRU (e.g. WTRU 102) (MAC layer) may stop the inactivity timer if any of the following occurs:

the o PDU is associated with unicast and/or the L2 source/destination ID obtained by decoding the MAC PDU does not match the L2 source/destination ID of any established unicast link at the WTRU.

The o PDU is associated with broadcast/multicast and/or the L2 destination ID obtained by decoding the MAC PDU does not match the L2 destination ID of any established unicast link at the WTRU.

The MAC layer cannot decode MAC PDUs.

The MAC layer decodes the MAC PDU, but the MAC PDU (e.g., only) contains CSI report MAC CEs.

The PDU corresponds to the SCI that starts to start the inactivity timer (e.g., in the case where the PHY layer starts the inactivity timer (e.g., in this case), the inactivity timer is not running at that time).

While decoding of the current PDU is ongoing, the inactivity timer is not started (restarted) by another PDU.

For example, in the event that the L2 source/destination ID in the MAC header does not match any of the source/destination IDs of interest at the WTRU (e.g., in this case), the RX WTRU (e.g., WTRU 102) may stop the inactivity timer upon decoding the PDU and/or the inactivity timer is running because the inactivity timer is started (and not restarted) by receiving the SCI corresponding to the PDU. Specifically, in the event that the L2 source/destination ID in the MAC header does not match any of the source/destination IDs of interest at the WTRU (e.g., in this case), the RX WTRU (e.g., WTRU 102) may stop the inactivity timer and/or in the event that the inactivity timer is started by receiving a PDU (e.g., in this case), the inactivity timer has not previously been run. For example, in the event that the L2 source/destination ID in the MAC header does not match any of the source/destination IDs of interest at the WTRU (e.g., in this case), the RX WTRU (e.g., WTRU 102) may stop the inactivity timer upon decoding the PDU and/or the inactivity timer may not have been started (restarted) between the time it was started by the currently decoded PDU and/or the time the WTRU determines that the L2 source/destination ID in the MAC header does not match any of the source/destination IDs of interest at the WTRU.

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

h)Multiple concurrent inactivity timers may be run/stopped for each new transmission while determining whether decoding was successful

According to an embodiment that may be used in addition to another embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) (PHY layer) may start multiple concurrent inactivity timers (e.g., only) for each new transmission (e.g., HARQ process, L1 ID, NDI) identified by the WTRU based on SCI decoding. After each such timer starts, the MAC layer may stop the corresponding timer if any of the conditions associated with stopping the timer in the previous solution are met (e.g., in this case). For example, a (e.g., RX) WTRU (e.g., WTRU 102) may operate according to any one or a combination (and/or) of the following examples:

-in case SCI associated with a new transmission is received (e.g. in this case), starting a first inactivity timer. Such new transmissions may not be successfully decoded by the MAC layer. The first inactivity timer may remain running after a MAC decoding failure.

-in case SCI associated with a different new transmission is received (e.g. in this case), starting a second inactivity timer. Such new transmissions may not be successfully decoded by the MAC layer. The first inactivity timer may remain running after a MAC decoding failure.

Upon receiving the SCI for the same HARQ process as the first new transmission, the mac pdu may be successfully decoded, but the L2 ID may not match the desired L2 ID at the WTRU. A WTRU (e.g., WTRU 102) (MAC) may stop the inactivity timer associated with the first new transmission but keep the inactivity timer associated with the second retransmission.

Upon receiving the SCI for the same HARQ process as the second new transmission, the mac pdu may be successfully decoded and/or the WTRU (e.g., the RX) may repeat the same process to determine whether to stop or continue the inactivity timer associated with the second new transmission.

An RX WTRU (e.g., WTRU 102) may be active with respect to side link monitoring as long as at least either of the inactivity timers (either the first inactivity timer or the second inactivity timer) is running.

i)An RX WTRU (e.g., WTRU 102) starts an inactivity timer at the MAC layer, but may compensate for decoding delays

According to an embodiment, an RX WTRU (e.g., WTRU 102) may start an inactivity timer based on conditions related to decoding SCI and/or conditions related to decoding MAC PDU.

For example, an RX WTRU (e.g., WTRU 102) may start an inactivity timer if any of the conditions associated with SCI (described in other embodiments) are met, the PDU is successfully decoded, and/or the conditions associated with the decoded MAC PDU are also met. The conditions associated with the decoded MAC PDU may include any one of the following or a combination (and/or) thereof:

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 any established unicast link at the WTRU.

The PDU is associated with broadcast/multicast and/or the L2 destination ID obtained by decoding the MAC PDU matches the L2 destination ID of any established unicast link at the WTRU.

The MAC layer decodes the MAC PDU and/or the MAC PDU (e.g., contains no CSI reporting MAC CE (e.g., there is at least one LCH in the MAC PDU associated with the data) only.

For example, an RX WTRU (e.g., WTRU 102) may start an inactivity timer (e.g., only) after successful decoding of a MAC PDU, which may occur after multiple retransmissions associated with the MAC PDU. An RX WTRU (e.g., WTRU 102) may start an inactivity timer at any of the following times:

in case the above defined conditions indicate a successfully decoded new transmission (e.g. in this case), the HARQ ACK is transmitted on the PSFCH.

-a plurality of symbols/slots (e.g. (pre) configured or predefined) after receiving SCI associated with transmission/retransmission in which the MAC layer successfully decodes the new transmission.

The number of symbols/slots may be 0. In this case, the MAC layer may start a timer and/or compensate (e.g., add an elapsed time value) for the time between SCI reception and/or MAC pdu decoding.

The time instance of SCI reception may be indicated by the PHY layer to the MAC layer.

A number of symbols/slots (e.g., (pre) configured or predefined) after the last retransmission resources used by the TX WTRU (e.g., WTRU 102) to transmit the PDU or reserved as retransmission resources in the SCI for transmitting the initial transmission.

According to an embodiment, a TX WTRU (e.g., WTRU 102) may start its own inactivity timer (associated with an RX WTRU (e.g., WTRU 102)) at any one of the following times:

-if HARQ feedback is enabled, upon receipt of a HARQ ACK after a new transmission;

-a (pre) configured or predefined) plurality of slots following a first transmission of a PDU by a TX WTRU (e.g., WTRU 102); and/or

A number of time slots (e.g., (pre) configured or predefined) after the last retransmission resources used by the TX WTRU (e.g., WTRU 102) to transmit the PDU or reserved as retransmission resources in the SCI for transmitting the initial transmission.

In particular, if the on duration timer is no longer running after an initial transmission of a PDU by a TX WTRU (e.g., WTRU 102), the TX WTRU (e.g., WTRU 102) may delay the transmission of other PDUs to the time associated with the retransmission resources for that PDU or an indication of HARQ ACKs associated with the new transmission.

2.2Maintenance of inactivity timers at RX and/or TX WTRUs (e.g., WTRU 102) suitable for multicasting

The described embodiments may be defined for example for multicasting but may also be applicable to unicast and/or broadcast.

a)An RX/TX WTRU (e.g., WTRU 102) (e.g., only) is activated/caused based on certain conditions related to multicasting By inactivity timers

According to an embodiment, an RX and/or TX WTRU (e.g., WTRU 102) in multicast may start/assume/use an inactivity timer associated with DRX (e.g., only) under certain conditions. Specifically, a TX WTRU (e.g., WTRU 102) may maintain an inactivity timer associated with the transmission if any of the following conditions are met:

-conditions based on the broadcast type:

for example, a TX/RX WTRU (e.g., WTRU 102) may start/use (e.g., only) an inactivity timer for transmissions associated with a particular situation (e.g., unicast (e.g., only)) or unicast and/or multicast.

For example, a TX/RX WTRU (e.g., WTRU 102) may combine other conditions with (e.g., only) certain broadcast types:

■ For example, a TX/RX WTRU (e.g., WTRU 102) may start/use an inactivity timer for unicast or for multicast whenever a multicast transmission is associated with a HARQ feedback type for multicast as follows.

-QoS based conditions:

for example, a TX/RX WTRU (e.g., WTRU 102) may start/use (e.g., only) an inactivity timer for transmissions where the priority of the transmission is below a threshold.

-conditions based on whether HARQ is enabled/disabled and/or the type of HARQ feedback report for multicast enabled/disabled (ACK/NACK report or (e.g. NACK only):

for example, a TX WTRU (e.g., WTRU 102) may start/use an inactivity timer (e.g., only) if the transmission by the TX WTRU (e.g., WTRU 102) is HARQ enabled (e.g., in this case).

For example, a TX WTRU (e.g., WTRU 102) may start/use an inactivity timer (e.g., only) if the transmission is associated with enabling HARQ and/or if a positive-negative acknowledgement multicast HARQ type is used (e.g., in this case).

For example, an RX WTRU (e.g., WTRU 102) may start an inactivity timer, e.g., associated with an L2ID, if (e.g., only) the received transmission is HARQ enabled (e.g., in this case).

For example, an RX WTRU (e.g., WTRU 102) may start an inactivity timer, e.g., associated with the L2ID, if the received transmission is (e.g., only) a HARQ-enabled multicast positive-negative acknowledgement type (e.g., in this case).

-conditions based on member IDs configured by upper layers:

for example, if a TX WTRU (e.g., WTRU 102) and/or an RX WTRU (e.g., WTRU 102) is configured with a member ID associated with such multicast transmission, the TX WTRU (e.g., WTRU 102) and/or the RX WTRU (e.g., WTRU 102) may use an inactivity timer for the particular multicast transmission (e.g., associated with the multicast L2 ID).

-a condition based on group size:

for example, if the number of groups is not greater than the configured number of PSFCH resources, the TXWTRU (e.g., WTRU 102) and/or the RX WTRU (e.g., WTRU 102) may use the inactivity timer for a particular multicast transmission (e.g., associated with the multicast L2 ID).

-MCR (minimum communication range) based conditions:

for example, if the transmission is configured with an MCR, the TX WTRU (e.g., WTRU 102) and/or the RX WTRU (e.g., WTRU 102) may use the inactivity timer for a particular multicast transmission:

■ In particular, if at least one of the SLRBs for transmission is configured with an MCR, a TX WTRU (e.g., WTRU 102) may operate (e.g., assuming) with an inactivity timer associated with the transmission to the L2 ID. Specifically, after transmission, when any of the timers associated with the active time of the L2 ID is running, the TX WTRU (e.g., WTRU 102) may start an inactivity timer whenever the TX WTRU (e.g., WTRU 102) performs a transmission to the L2 ID (or receives an acknowledgement of the transmission). Otherwise, if the MCR is not configured, the TXWTRU (e.g., WTRU 102) may not start the inactivity timer under such conditions and/or may not maintain the inactivity timer-based conditions (e.g., may allow transmission (e.g., only) if the on duration timer is running or the retransmission timer is running (e.g., in this case).

■ Similarly, an RX WTRU (e.g., WTRU 102) may define its active time for an L2 ID if it receives at least one packet associated with an MCR for the L2 ID, or if it is configured with an SLRB for a transmission to the L2 ID that is configured with an MCR.

For example, if the MCR configured for any SLRB is below a threshold, the TXWTRU (e.g., WTRU 102) and/or the RX WTRU (e.g., WTRU 102) may use the inactivity timer for a particular multicast.

A similar behaviour to the example above would then be expected.

-conditions based on MCR and/or HARQ feedback enablement:

for example, whenever HARQ feedback is enabled, the RX and/or RX WTRU (e.g., WTRU 102) may use the inactivity timer for the particular multicast transmission configured with the MCR.

■ For example, if at least one SLRB for transmission to the L2 ID is configured with MCR and/or HARQ enablement, a TX WTRU (e.g., WTRU 102) may use an inactivity timer.

■ For example, if all SLRBs for transmission to a multicast L2 ID are configured with MCR and/or HARQ enabled, a TX WTRU (e.g., WTRU 102) may use an inactivity timer for the L2 ID, otherwise the TX WTRU will not use the inactivity timer for the L2 ID.

According to an embodiment, a TX/RX WTRU (e.g., WTRU 102) may stop the currently running inactivity timer if one of the conditions or parameters used to support the inactivity timer change. For example, if the group size and/or member ID indicated by higher layers changes at the WTRU, a TX/RX WTRU (e.g., WTRU 102) may stop the inactivity timer that has been run.

b)RX WTRU (e.g., WTRU 102) resets the inactivity timer based on the MCR of the received transmission

According to an embodiment, an RX WTRU (e.g., WTRU 102) may determine whether to reset an inactivity timer associated with, for example, a multicast transmission based on a location of the RX WTRU (e.g., WTRU 102) and/or an MCR associated with the transmission. Specifically, in the case of a new transmission of an MCR having any of the following conditions (e.g., in this case), an RX WTRU (e.g., WTRU 102) may reset the inactivity timer (e.g., only) after receiving such a new transmission (e.g., while):

MCR is absent.

-MCR is present.

The determined distance between the transmitter and/or the receiver is less than (less than or equal to) MCR.

The determined distance between the transmitter and/or the receiver is smaller (smaller or equal) than the MCR plus or minus the increment of the (pre) configuration.

Such increments may further depend on any of the following:

■ Such as priority, WTRU speed, CBR, number of WTRUs in the group, power saving preference at the RX WTRU (e.g., WTRU 102), WTRU capabilities associated with the RX WTRU (e.g., WTRU 102).

The consideration of the distance to the MCR may also be based on a change in distance to the MCR observed by the RX WTRU (e.g., WTRU 102) from a previous transmission. Specifically, if the distance between two WTRUs or the difference in such distances compared to MCR decreases with each subsequent transmission for an L2 ID, an RX WTRU (e.g., WTRU 102) may restart the inactivity timer.

c)A TX WTRU (e.g., WTRU 102) maintains a TX WTRU with each RX WTRU (e.g., WTRU 102) A set of timers (e.g., for WTRU 102)

According to an embodiment, a TX WTRU (e.g., WTRU 102) may determine whether to transmit to a particular WTRU (unicast) or to a group of WTRUs (e.g., multicast L2 ID) based on the maintenance of a timer similar to an RX WTRU (e.g., WTRU 102). Specifically, if at least one of the inactivity timers associated with a particular group of WTRUs is running, a TX WTRU (e.g., WTRU 102) may transmit to the group.

According to an embodiment, a TX WTRU (e.g., WTRU 102) may maintain a set of timers corresponding to timers for an RX WTRU (e.g., WTRU 102). In particular, a TX WTRU (e.g., WTRU 102) may maintain an inactivity timer for each L2 source/destination ID (for unicast), L2 destination ID (for multicast), and/or for each priority/QoS level for each address, for example. The TX WTRU (e.g., WTRU 102) may use the related (but different) values of such timers to compensate for delays in performing transmissions and/or performing reliable transmissions. A TX WTRU (e.g., WTRU 102) may start/stop such a timer earlier/later than a TX WTRU (e.g., WTRU 102). For example:

a TX WTRU (e.g., WTRU 102) may be configured with a shorter on duration timer, HARQ RTT timer, or retransmission timer than an RX WTRU (e.g., WTRU 102); and/or

A TX WTRU (e.g., WTRU 102) may be configured to start an on duration timer earlier in the DRX cycle than an RX WTRU (e.g., WTRU 102).

d)A TX WTRU (e.g., WTRU 102) starts upon receiving HARQ feedback from one or more WTRUs in the group (restarting) inactivity timer

According to an embodiment, a TX WTRU (e.g., WTRU 102) may start (restart) an inactivity timer based on receiving HARQ feedback from one or more WTRUs.

According to an embodiment, a TX WTRU (e.g., WTRU 102) may maintain a single inactivity timer (with respect to its own transmission to the group) for all RX WTRUs in the group (e.g., WTRU 102). A TX WTRU (e.g., WTRU 102) may start an inactivity timer under any of the following conditions:

-in case the TX WTRU receives HARQ feedback (e.g., ACK or NACK) from the first (e.g., RX) WTRU (e.g., in this case);

in the case (e.g., in this case) where the TX WTRU receives HARQ feedback (e.g., ACK or NACK) from most WTRUs in the group (e.g., WTRUs above a threshold number or percentage);

-in case the TX WTRU receives HARQ feedback from all WTRUs in the group (e.g., in this case);

in the case where the TX WTRU receives HARQ feedback from a particular subset of WTRUs in the group (e.g., in this case), the particular subset of WTRUs is associated with, for example, a preconfigured pattern or set of member IDs (e.g., IDs closest to its own ID, or IDs 1-x);

-in case the TX WTRU receives HARQ feedback within a period of initial transmission (e.g., in this case); and/or

In case the TX WTRU receives HARQ feedback at the latest after the x-th transmission (retransmission) of the PDU (e.g., in this case).

For example, in the case where a TX WTRU (e.g., WTRU 102) receives HARQ feedback (ACK or NACK) from all RX WTRUs in the group (e.g., WTRU 102), the TX WTRU may start an inactivity timer (e.g., in this case).

For example, whenever a TX WTRU (e.g., WTRU 102) receives HARQ feedback from all RX WTRUs (e.g., WTRU 102) in the group (e.g., in this case), the TX WTRU may start an inactivity timer whenever the TX WTRU receives HARQ feedback within the first x milliseconds after the initial transmission or within the first y retransmissions of PDUs by the TX WTRU (e.g., WTRU 102).

According to an embodiment, a TX WTRU (e.g., WTRU 102) may maintain inactivity timers associated with each of the RX WTRUs in the group (e.g., WTRU 102). In the event that a TX WTRU (e.g., WTRU 102) receives HARQ feedback from a particular (e.g., RX) WTRU (e.g., WTRU 102), the TX WTRU may start an RX WTRU (e.g., WTRU 102) specific inactivity timer for the (e.g., RX) WTRU (e.g., WTRU 102). In this solution, a TX WTRU (e.g., WTRU 102) may transmit a subsequent new transmission for the L2 ID (or to the group) whenever any of the following conditions are met:

-an inactivity timer associated with each RX WTRU (e.g., WTRU 102) is running;

the inactivity timers associated with most WTRUs in the group (e.g., WTRUs above a threshold number or percentage) are running;

-an inactivity timer associated with at least one WTRU in the group is running; and/or

-an inactivity timer associated with a specific subset of WTRUs in the group is running, wherein such subset may correspond to a preconfigured pattern or set of member IDs.

e)TX WTRU (e.g., WTRU 102) is at different times for the group where feedback is possible compared to impossible +. Transmission start inactivity timer

According to an embodiment, a TX WTRU (e.g., WTRU 102) may have different criteria for starting an inactivity timer based on transmissions for a group. Such criteria may depend on any of the following:

HARQ feedback enabled/disabled.

-a broadcast type.

HARQ feedback types (positive-negative feedback and (e.g. only) negative feedback).

-MCR presence and/or value.

Whether the PSFCH resources are configured in a resource pool.

For example, in the case where the transmission is associated with a multicast with positive-negative acknowledgements (e.g., in this case), the TX WTRU (e.g., WTRU 102) may start an inactivity timer (according to previous embodiments) after receiving the HARQ feedback (e.g., while) and/or may otherwise start the inactivity timer after an initial transmission (e.g., to the WTRU or group) (e.g., while).

f)TX WTRU (e.g., WTRU 102) (e.g., only) using a mechanism to improve the transmission when feedback is not possible Reliability of

According to an embodiment, a TX WTRU (e.g., WTRU 102) may use different values of the inactivity timer for different starting criteria of the inactivity timer. Further, a TX WTRU (e.g., WTRU 102) may employ a mechanism for improving reliability of transmissions during inactivity times or near the end of an on duration, such as any of the following:

-increasing the transmission power;

for example, a (e.g., TX) WTRU (e.g., WTRU 102) may increase the transmission power of transmissions that occur outside of the on-duration, or the transmission power of transmissions that some of the retransmissions will fall outside of the on-duration;

-increasing the number of retransmissions;

for example, a (e.g., TX) WTRU (e.g., WTRU 102) may increase the number of retransmissions of transmissions that occur outside of the on duration, or the number of retransmissions of transmissions where some of the retransmissions may fall outside of the on duration;

-ensuring that the retransmission falls within the on-duration or a subset of the resources in the on-duration;

for example, a (e.g., TX) WTRU (e.g., WTRU 102) may perform resource selection such that multiple retransmission resources fall within an on duration, e.g., where the number of resources may further depend on QoS and/or CBR. For example, a (e.g., TX) WTRU (e.g., WTRU 102) may be configured with multiple (e.g., required) retransmission resources to be performed during an on duration based on priority and/or CBR. For example, in the case where a QoS and/or CBR based TX WTRU (e.g., WTRU 102) inactivity timer is running (e.g., in this case), the (e.g., TX) WTRU (e.g., WTRU 102) may be configured with multiple retransmission resources to be performed, where the number of retransmissions may be different depending on:

In a general example, a (e.g., TX) WTRU (e.g., WTRU 102) may be configured with a different number of allowed/minimum/required retransmissions to be performed, which may vary depending on which timer is running:

■ For example, in the case where the on duration timer at the TX WTRU (e.g., WTRU 102) is running (e.g., in this case) compared to the case where the on duration timer is not running (e.g., in this case);

■ For example, in the case where an inactivity timer at a TX WTRU (e.g., WTRU 102) is running (e.g., in this case) compared to the case where the inactivity timer is not running (e.g., in this case);

-increasing the modulation and/or coding scheme (MCS) of the transmission.

A (e.g., TX) WTRU (e.g., WTRU 102) may use such a mechanism (e.g., only) for transmissions with certain criteria for starting an inactivity timer. In particular, a TX WTRU (e.g., WTRU 102) may not use the reliability mechanism for multicast transmissions with positive-negative acknowledgements, but rather use it for other multicast transmissions.

A TX WTRU (e.g., WTRU 102) may use such a mechanism, for example, in the case where the PSFCH is not configured (e.g., in this case). If the PSFCH is configured, the TX WTRU (e.g., WTRU 102) may always enable HARQ feedback or set the HARQ feedback mode to a positive/negative acknowledgement to ensure reliability.

Furthermore, whether mechanisms and/or parameters/thresholds/increases/etc (e.g., number of retransmissions, increase in transmission power, MCS, etc.) are applied may further depend on congestion in the link. For example, for a higher CBR, it may be higher or lower.

In the case of unicast, a (e.g., TX) WTRU (e.g., WTRU 102) may use such mechanisms (e.g., only) for disabling HARQ transmissions and/or use other mechanisms herein for enabling HARQ transmissions.

g)TX WTRU (e.g., WTRU 102) performs transmission during active time

According to an embodiment, for example, for a transmission associated with HARQ feedback (e.g., a unicast transmission that enables HARQ), a TX WTRU (e.g., WTRU 102) may perform the transmission at least K slots before an inactivity timer, an on duration timer, a retransmission timer (or any timer associated with an active transmission at an RX WTRU (e.g., WTRU 102)) expires. K may be associated with a delay associated with HARQ feedback. Specifically, K may be any one of the following:

-a time difference between a transmission and/or one (or more, or all, for multicast) PSFCH resources for HARQ feedback associated with the transmission;

-a (pre) configuration value allowing (e.g. TX) WTRUs (e.g. WTRU 102) to schedule retransmissions before such a timer expires (in case of DTX);

-time between initial transmission and/or first retransmission;

-time between initial transmission and/or nth retransmission, where N may depend on CBR, qoS, etc.;

-time between initial transmission and/or last retransmission indicated in SCI for initial transmission; and/or

-time between initial transmission in SCI and/or PSFCH resources associated with the last retransmission indicated in SCI.

h)TX WTRU (e.g., WTRU 102) forces/enables a target to RX in DRX WTRU (e.g., WTRU 102) HARQ feedback of certain transmissions of (a)

According to an embodiment, a TX WTRU (e.g., WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., WTRU 102) in DRX regardless of the configuration in which LCH HARQ feedback is enabled. This may ensure that the TX WTRU (e.g., WTRU 102) may accurately start the inactivity timer based on receiving HARQ feedback from the TX WTRU (e.g., WTRU 102).

A TX WTRU (e.g., WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., WTRU 102) for all transmissions to the RX WTRU (e.g., WTRU 102). Alternatively, a TX WTRU (e.g., WTRU 102) may enable HARQ feedback to an RX WTRU (e.g., WTRU 102) under any of the following conditions:

-a transmission in which the on duration timer is not running.

-a transmission in which an inactivity timer is running.

-wherein (e.g., TX) WTRU (e.g., WTRU 102) still has a transmission of data in its buffer, the WTRU planning/configured to transmit before the next on-duration of the RX WTRU (e.g., WTRU 102).

Transmission associated with the last grant in the on duration associated with an RX WTRU (e.g., WTRU 102).

Transmission associated with the last grant in an inactivity timer associated with an RX WTRU (e.g., WTRU 102).

Wherein (e.g., TX) WTRUs still have transmissions of data in their buffers, wherein the data may have a high priority (e.g., priority above a threshold).

-wherein (e.g. TX) the WTRU still has a transmission of data in its buffer, wherein the PDB is less than the time until the next on duration.

-wherein (e.g. TX) WTRUs still have transmissions of data in their buffers, wherein LCHs for which there is available data are configured to ensure that HARQ feedback enabled transmissions are enabled prior to those LCHs transmissions.

2.3Handling inactivity timers for UL prioritized or half duplex cases

a)An RX WTRU (e.g., WTRU 102) may initiate inactivity timing under conditions not related to data reception Device for preventing and treating cancer

According to an embodiment, an RX WTRU (e.g., WTRU 102) may start/restart an inactivity timer without receiving a transmission. Specifically, an RX WTRU (e.g., WTRU 102) may start/restart the inactivity timer after (e.g., while) performing one or more transmissions (UL transmissions or SL transmissions), or after (e.g., while) decoding another interface (Uu or SL on a different carrier) that would render such (e.g., WTRU 102) incapable of decoding on a side link with the transmission.

According to an embodiment, an RX WTRU (e.g., WTRU 102) may start/restart an inactivity timer at a time instance when it performs a transmission/reception that would render the (e.g., RX) WTRU (e.g., WTRU 102) incapable of decoding on a side link. This may occur during an activity monitoring time/period of a (e.g., RX) WTRU (e.g., WTRU 102), which may be when an on duration timer is running, an inactivity timer is running, or any other timer defining active side link monitoring is running. Alternatively, a (e.g., RX) WTRU (e.g., WTRU 102) may start an inactivity timer at a (pre) configured or predefined time instance within any of an on duration (defined by an on duration timer), an inactivity timer duration, etc., based on one of the following conditions. For example, an RX WTRU (e.g., WTRU 102) may start/restart the inactivity timer after one of the following conditions is met (e.g., when):

-at a (pre) configured or predefined time slot within an on duration or an inactivity timer duration;

-at the last time slot associated with an on duration or an inactivity timer duration; and/or

-at a number of (preconfigured or defined) time slots before the end of the last time slot associated with the on-duration or the inactivity timer duration.

According to an embodiment, a (e.g., RX) WTRU (e.g., WTRU 102) may start/restart an inactivity timer without receiving a transmission associated with a condition related to a side link (to actively extend the activity timer). Such conditions may be related to any one of the following:

-conditions related to CBR:

for example, if CBR is greater than a configured threshold, a (e.g., RX) WTRU (e.g., WTRU 102) may start/restart an inactivity timer.

-conditions related to the number/amount/percentage of side link decoding opportunities missed during the active time:

for example, if a (e.g., RX) WTRU (e.g., WTRU 102) misses decoding of a side link for at least N slots or at least X% slots during an on duration, or misses an inactivity timer that is currently running, the WTRU may start/restart the inactivity timer, where N and/or X% may be (pre) configured.

Conditions relating to QoS of desired data, which may be determined based on PC5 QoS identifiers (PQI) of one or more established QoS flows, configuration of one or more SLRBs (e.g., for reception), priority of one or more recent transmissions (e.g., transmissions that start an inactivity timer currently running), etc.:

for example, a WTRU (e.g., WTRU 102) may determine whether to start/restart the inactivity timer based on the QoS of the desired data (e.g., start/restart the inactivity timer if the QoS of the desired data is above a threshold QoS).

For example, a (e.g., RX) WTRU (e.g., WTRU 102) may determine one of N or X% in the above example based on the QoS of the desired data.

-conditions related to (e.g., RX) WTRU (e.g., WTRU 102) type or power saving preference:

for example, if a (e.g., RX) WTRU (e.g., WTRU 102) is a particular WTRU type or has a particular power saving preference that is valid when another of the above conditions is triggered, the WTRU may start/restart the inactivity timer.

Fig. 6 is a diagram illustrating an example of a method 600 implemented by a first WTRU (e.g., an RX WTRU) for side link communication between the first WTRU (e.g., an RX WTRU) and/or a second WTRU (e.g., a TX WTRU).

According to an embodiment, in step 610, a first WTRU (e.g., an RX WTRU) may be configured to receive SCI indicating one or more transmission resources for side-link communications from a second WTRU (e.g., a TX WTRU).

According to an embodiment, in step 620, a first WTRU (e.g., an RX WTRU) may be configured to assign HARQ processes to one or more transmission resources by the first WTRU (e.g., an RX WTRU).

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

According to an embodiment, in step 640, the first WTRU (e.g., RX WTRU) may be configured to initiate a DRX retransmission cycle associated with the HARQ process upon expiration of the HARQ RTT period and/or if the HARQ process is not decoded by the first WTRU (e.g., RX WTRU).

For example, a first WTRU (e.g., an RX WTRU) may be configured to monitor one or more transmission resources for retransmission from a second WTRU (e.g., a TX WTRU) for sidelink communications based on a DRX retransmission cycle.

For example, a HARQ RTT timer is started at a time slot following transmission of side link feedback channel information associated with one or more transmission resources.

For example, a first WTRU (e.g., an RX WTRU) may be configured to receive a resource allocation pattern for side-link communication between the first WTRU (e.g., an RX WTRU) and/or a second WTRU (e.g., a TX WTRU).

For example, a first WTRU (e.g., an RX WTRU) may be configured to determine a value of a HARQ RTT timer based on any of: a resource allocation pattern for side link communication between a first WTRU (e.g., an RX WTRU) and/or a second WTRU (e.g., a TX WTRU); and/or an indication of additional retransmission resources reserved for the HARQ process by the received SCI or another SCI previously received.

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

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

For example, the side link communication is unicast communication.

Fig. 7 is a diagram illustrating an example of a method 700 implemented by a first WTRU (e.g., an RX WTRU) for side link communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

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

According to an embodiment, in step 720, a first WTRU (e.g., an RX WTRU) may be configured to determine a sleep period of the first WTRU (e.g., an RX WTRU) ending before a reception time of a retransmission of the D2D communication, wherein the sleep period is based on the second information.

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

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

For example, the first WTRU (e.g., an RX WTRU) may be further configured to obtain a sleep period value, and wherein the determined sleep period is based on the obtained sleep period value if the second information does not indicate that at least one second transmission resource is reserved for retransmission of D2D communications.

For example, a first WTRU (e.g., an RX WTRU) may be further configured to obtain the sleep period value by receiving network configuration information indicating the sleep period value.

For example, obtaining the sleep period value may be further configured to obtain the sleep period value by determining the sleep period value based on the pre-configured value.

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

For example, the determined sleep period starts at a time slot after the reception of the D2D control information.

For example, the determined sleep period starts at a time slot after the transmission of the D2D feedback information under the condition that the transmission of the D2D feedback information is enabled.

For example, the determined sleep period starts at a time slot after reception of the D2D control information under the condition that transmission of the D2D feedback information is disabled.

For example, the determined sleep period starts at a predetermined instance of time or at an instance of time indicated in the received D2D control information.

For example, the determined sleep period begins at a time instance based on a broadcast type of the D2D communication.

For example, D2D communication is side link communication.

Fig. 8 is a diagram illustrating an example of a method 800 implemented by a first WTRU (e.g., an RX WTRU) for side link communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

According to an embodiment, in step 810, a first WTRU (e.g., an RX WTRU) may be configured to receive D2D control information from a second WTRU (e.g., a TX WTRU), 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 whether transmission of D2D feedback information associated with the first transmission resource is enabled.

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

According to an embodiment, in step 830, a first WTRU (e.g., an RX WTRU) may be configured to receive a retransmission of the D2D communication after the determined sleep period ends.

Fig. 9 is a diagram illustrating an example of a method 900 implemented by a first WTRU (e.g., an RX WTRU) for side link communication between the first WTRU (e.g., an RX WTRU) and a second WTRU (e.g., a TX WTRU).

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

According to an embodiment, in step 920, a first WTRU (e.g., an RX WTRU) may be configured to determine a sleep period ending before a reception time of a retransmission of the D2D communication, wherein the determined sleep period starts at a time slot after reception of the D2D control information.

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

Fig. 10 is a diagram illustrating an example of a method 1000 implemented by a first WTRU (e.g., TX WTRU) for side link communication between the first WTRU (e.g., TX WTRU) and a second WTRU (e.g., RX WTRU).

According to an embodiment, in step 1010, a first WTRU (e.g., TX WTRU) may be configured to transmit D2D control information to a second WTRU (e.g., RX WTRU), the D2D control information comprising: (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 the D2D communication.

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

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

Moreover, any feature, variation, or embodiment described for a method is compatible with: an apparatus comprising means for processing elements of the disclosed methods, an apparatus comprising a processor configured to process the disclosed methods, a computer program product comprising program code instructions, and a non-transitory computer readable storage medium storing program instructions.

Conclusion(s)

Although features and elements are provided above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in this patent application, which are intended as illustrations of various aspects. Many modifications and variations may be made without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Functionally equivalent methods and apparatus, other than those enumerated herein, which are 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 to be limited only by the terms of the appended claims, along with the full scope of equivalents to which such claims are entitled. It should be understood that the present disclosure is not limited to a particular method or system.

For simplicity, the foregoing embodiments are discussed with respect to the terminology and structure of infrared-capable devices (i.e., infrared emitters and receivers). However, the embodiments discussed are not limited to these systems, but may be applied to other systems using other forms of electromagnetic waves or non-electromagnetic waves (such as acoustic waves).

It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term "video" or the term "image" may mean any of a snapshot, a single image, and/or multiple images that are displayed on a temporal basis. As another example, as 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" may mean or include (i) a wireless transmit and/or receive unit (WTRU); (ii) Any of a number of embodiments of the WTRU; (iii) Devices with wireless capabilities and/or with wired capabilities (e.g., tethered) are configured with some or all of the structure and functionality of a WTRU, in particular; (iii) Wireless capability and/or wireline capability devices configured with less than the full structure and functionality of the WTRU; or (iv) etc. Details of an exemplary WTRU that may represent any of the WTRUs described herein are provided herein with respect to fig. 1A-1D. As another example, various disclosed embodiments herein above and below are described as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted real-world experience.

Additionally, the methods provided herein may be implemented in a computer program, software, or firmware incorporated in a computer readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) 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 may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. In view of the various embodiments that may be employed, it should be understood that the illustrated embodiments are examples only and should not be taken as limiting the scope of the following claims. For example, embodiments provided herein include a handheld device that may include or be used with any suitable voltage source (such as a battery or the like) that provides any suitable voltage.

Furthermore, in the embodiments provided above, processing platforms, computing systems, controllers, and other devices including processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. References to actions and symbolic representations of operations or instructions may be performed by various CPUs and memories in accordance with practices of persons skilled in the art of computer programming. Such acts and operations, or instructions, may be considered to be "executing," computer-executed, "or" CPU-executed.

Those of ordinary skill in the art will appreciate that the acts and symbolically represented operations or instructions include the manipulation of electrical signals by the CPU. The electrical system represents data bits that may result in a final transformation of the electrical signal or a reduction of the electrical signal and a retention of the data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the operation of the CPU and performing other processing of the signal. The memory location holding the data bit is a physical location having a particular electrical, magnetic, optical, or organic attribute corresponding to or representing the data bit. It should be understood that embodiments are not limited to the above-described platforms or CPUs, and that other platforms and CPUs may also support the provided methods.

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

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 the mobile unit, the network element, and/or any other computing device.

There is little distinction between hardware implementations and software implementations of aspects of the system. The use of hardware or software is often (but not always, as in some contexts the choice between hardware and software may become important) a design choice representing a tradeoff between cost and efficiency. There may be various media (e.g., hardware, software, and/or firmware) that may implement the processes and/or systems and/or other techniques described herein, and the preferred media may vary with the context in which the processes and/or systems and/or other techniques are deployed. For example, if the implementer determines that speed and accuracy are paramount, the implementer may opt for a medium of mainly hardware and/or firmware. If flexibility is paramount, the implementer may opt for a particular implementation of mainly software. Alternatively, the implementer may opt for some combination of hardware, software, and/or firmware.

The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Where 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 virtually any combination thereof. In an embodiment, portions of the subject matter described herein may be implemented via an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), and/or other integrated format. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and/or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media such as digital and/or analog communications media (e.g., fiber optic cable, waveguide, wired communications link, wireless communications link, etc.).

Those skilled in the art will recognize that it is common in the art to describe devices and/or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and/or processes into data processing systems. That is, at least a portion of the devices and/or processes described herein may be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing; a video display device; memories such as volatile memories and nonvolatile memories; a processor, such as a microprocessor and a digital signal processor; computing entities such as operating systems, drivers, graphical user interfaces, and applications; one or more interactive devices, such as a touch pad or screen; and/or a control system comprising a feedback loop and a control motor (e.g. feedback for sensing position and/or speed, a control motor for moving and/or adjusting components and/or amounts). Typical data processing systems may be implemented using any suitable commercially available components, such as those typically found in data computing/communication and/or network computing/communication systems.

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

With respect to substantially any plural and/or singular terms used herein, those having skill in the art can translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly listed herein.

It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). It will be further understood by those with skill in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, where only one item is contemplated, the term "single" or similar language may be used. To facilitate understanding, the following appended claims and/or descriptions herein may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation object by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation object to embodiments containing only one such recitation object. Even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and/or "an" should be interpreted to mean "at least one" or "one or more"). The same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). In addition, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction has the meaning that one having skill in the art would understand the convention (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B and C together, etc.). It should also be understood by those within the art that virtually any separate word and/or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" will be understood to include the possibilities of "a" or "B" or "a and B". In addition, as used herein, the term "… …" followed by listing a plurality of items and/or a plurality of item categories is intended to include items and/or item categories "any one of", "any combination of", "any multiple of" and/or any combination of multiples of "alone or in combination with other items and/or other item categories. Furthermore, as used herein, the term "group" is intended to include any number of items, including zero. Furthermore, as used herein, the term "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "multiple".

Additionally, where features or aspects of the disclosure are described in terms of markush groups, those skilled in the art will recognize thereby that the disclosure is also described in terms of any individual member or subgroup of members of the markush group.

As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible sub-ranges and combinations of sub-ranges thereof. Any listed range can be readily identified as sufficiently descriptive and so that the same range can be divided into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be readily divided into a lower third, a middle third, an upper third, and the like. As will also be understood by those skilled in the art, all language such as "up to", "at least", "greater than", "less than", etc., include the recited numbers and refer to ranges that may be subsequently divided into sub-ranges as described above. Finally, as will be understood by those skilled in the art, the scope includes each individual number. Thus, for example, a group having 1 to 3 units refers to a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units refers to a group having 1, 2, 3, 4, or 5 units, or the like.

Furthermore, the claims should not be read as limited to the order or elements provided, unless stated to that effect. In addition, use of the term "means for … …" in any claim is intended to invoke 35U.S. C. ≡112,6 or device plus function claims format, and any claims without the term "device for … …" are not intended to be so. />

Claims

1. A method implemented by a first wireless transmit/receive unit (WTRU) for device-to-device (D2D) communication between the first WTRU and a second WTRU, the method comprising:

receiving D2D control information from the second WTRU, the D2D control information comprising: (1) First information indicating one or more first transmission resources reserved for transmission of the D2D communication; and (2) second information indicating whether at least one second transmission resource is reserved for retransmission of the D2D communication;

determining a sleep period of the first WTRU ending before a receive time of the retransmission of the D2D communication, wherein the sleep period is based on the second information; and

the retransmission of the D2D communication is received after the determined sleep period ends.

2. The method of claim 1, wherein the determined sleep period is based on timing information associated with the reserved at least one second transmission resource on a condition that the second information indicates that at least one second transmission resource is reserved for retransmission of the D2D communication.

3. The method of claim 1, further comprising: a sleep period value is obtained, and wherein the determined sleep period is based on the obtained sleep period value, on the condition that the second information does not indicate that at least one second transmission resource is reserved for retransmission of the D2D communication.

4. The method of claim 3, wherein obtaining a sleep period value comprises: network configuration information indicating the sleep period value is received.

5. The method of claim 3, wherein obtaining a sleep period value comprises: the sleep period value is determined based on a preconfigured value.

6. The method of any of claims 3 to 5, wherein the D2D control information further comprises information indicating whether transmission of D2D feedback information associated with the first transmission resource is enabled.

7. The method of any of claims 1-2, wherein the determined sleep period begins at a time slot following the reception of the D2D control information.

8. The method of claim 6, wherein the determined sleep period begins at a time slot after the transmission of the D2D feedback information on condition that the transmission of the D2D feedback information is enabled.

9. The method of claim 6, wherein the determined sleep period begins at a time slot after the reception of the D2D control information on condition that the transmission of the D2D feedback information is disabled.

10. The method of any of claims 3 to 5, wherein the determined sleep period starts at a predetermined instance of time or at an instance of time indicated in the received D2D control information.

11. The method of any of claims 3-5, wherein the determined sleep period begins at a time instance based on a broadcast type of the D2D communication.

12. The method of any one of claims 1 to 11, wherein the D2D communication is a side link communication.

13. A first wireless transmit/receive unit (WTRU) for device-to-device (D2D) communication between the first WTRU and a second WTRU, the first WTRU comprising circuitry including a transmitter, a receiver, a processor, and a memory, the first WTRU configured to:

14. The first WTRU of claim 13, wherein the determined sleep period is based on timing information associated with the reserved at least one second transmission resource on a condition that the second information indicates that at least one second transmission resource is reserved for retransmission of the D2D communication.

15. The first WTRU of claim 13, wherein the circuitry is further configured to: a sleep period value is obtained, and wherein the determined sleep period is based on the obtained sleep period value, on the condition that the second information does not indicate that at least one second transmission resource is reserved for retransmission of the D2D communication.

16. The first WTRU of claim 15, wherein the circuitry is further configured to receive network configuration information indicating the sleep cycle value.

17. The first WTRU of claim 15, wherein the circuitry is further configured to determine the sleep cycle value based on a pre-configured value.

18. The first WTRU of any of claims 15-17, wherein the D2D control information further comprises information indicating whether transmission of D2D feedback information associated with the first transmission resource is enabled.

19. The first WTRU of any of claims 13-14, wherein the determined sleep period begins at a time slot after the reception of the D2D control information.

20. The first WTRU of claim 18, wherein the determined sleep period starts at a time slot after the transmission of the D2D feedback information on condition that the transmission of the D2D feedback information is enabled.

21. The first WTRU of claim 18, wherein the determined sleep period starts at a time slot after the reception of the D2D control information on a condition that the transmission of the D2D feedback information is disabled.

22. The first WTRU of any of claims 15-17, wherein the determined sleep period starts at a predetermined time instance or at a time instance indicated in the received D2D control information.

23. The first WTRU of any of claims 15-17, wherein the determined sleep period begins at a time instance based on a broadcast type of the D2D communication.

24. The first WTRU of any of claims 13-23, wherein the D2D communication is a side link communication.