Method, device and system for supporting HARQ on V2X

Abstract

The invention provides a method, a device and a system for supporting HARQ on V2X, and specifically provides a WTRU device and an operation method thereof. The method may include receiving a mapping rule from a network, the mapping rule indicating HARQ feedback characteristics to be employed for QoS levels and channel loads. The WTRU may determine a QoS level of the data buffered for transmission, and may further determine a channel load of the channel. Based on the QoS level and channel load, HARQ feedback characteristics may be determined. The WTRU may then transmit an SCI indicating the HARQ feedback characteristic to another WTRU. In one embodiment, the mapping rule may indicate that a HARQ feedback format is to be used for HARQ feedback of the data. The data may be transmitted, and HARQ feedback regarding the data may be received according to the HARQ feedback format. Multicast data may be transmitted to a plurality of WTRUs and feedback may be received.

Description

This application is a divisional application of Chinese patent application No. 201980062312.6, whose application date is September 25, 2019 and entitled “Methods, devices and systems for supporting HARQ on V2X”. The contents of the parent application are incorporated herein by reference. CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62 / 736,296, filed on September 25, 2018, U.S. Provisional Application No. 62 / 736,788, filed on September 26, 2018, and U.S. Provisional Application No. 62 / 787,991, filed on January 3, 2019, the contents of each of which are incorporated herein by reference. Summary of the invention

[0002] A wireless transmit / receive unit (WTRU) apparatus and method of operating the same are provided. The method may include receiving a mapping rule from a network, the mapping rule indicating a hybrid automatic repeat request (HARQ) feedback characteristic to be adopted for a quality of service (QoS) level and a channel load. The WTRU may determine a QoS level of data buffered for transmission, and may further determine a channel load of a channel. Based on the QoS level and the channel load, a HARQ feedback characteristic may be determined. The WTRU may then transmit sidelink control information (SCI) indicating the HARQ feedback characteristic to another WTRU. In one embodiment, the mapping rule may indicate that a HARQ feedback format is to be used for HARQ feedback of the data. The data may be sent, and HARQ feedback about the data may be received according to the HARQ feedback format. Multicast data may be transmitted to multiple WTRUs and feedback may be received. In one embodiment, the WTRU may determine whether a group member of a WTRU group successfully receives the multicast sidelink data based on a feedback resource and an intra-group identifier of the group member of the WTRU group. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals represent like elements, and in which:

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

[0005] Figure 1B is a diagram showing that according to one embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown.

[0006] Figure 1C is a diagram showing that according to one embodiment, Figure 1A System diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system is shown.

[0007] Figure 1D is a diagram showing that according to one embodiment, Figure 1A System diagram of another example RAN and another example CN used within the communication system shown.

[0008] Figure 2 is a timing diagram illustrating an example hybrid automatic repeat request (HARQ) feedback determination method;

[0009] Figure 3 is a flow chart illustrating a method performed by a transmitting WTRU;

[0010] Figure 4 is a diagram showing a sidelink time slot for two separate sidelink HARQ acknowledgement (HARQ-ACK) feedback transmissions;

[0011] Figure 5 is a timing diagram illustrating an exemplary HARQ timing determination based on a transmission time of a first transmission;

[0012] Figure 6 is a flow chart illustrating sidelink control information (SCI) transmission, data transmission, and HARQ feedback reception for sidelink communication;

[0013] Figure 7 is a diagram of example dedicated and shared resource pools for feedback;

[0014] Figure 8 is a diagram of example feedback resources, where the resources are multiplexed with scheduling assignments (SA) or data resources through frequency division multiplexing (FDM) or time division multiplexing (TDM);

[0015] Fig.9A is a diagram of an example feedback resource, where the resource is multiplexed with SA or data resources by FDM or TDM;

[0016] Fig. 9B is a diagram of an example feedback resource, where the resource is TDM multiplexed with a control or data resource;

[0017] Fig.10 is a diagram of an example single FDM feedback resource shared by group members;

[0018] Fig.11 is a diagram of an example single TDM feedback resource shared by group members;

[0019] Fig.12is a flow chart of an example method for an NR Mode 2 WTRU to select resources and transmit sidelink data;

[0020] Fig.13 is a flow chart of an example method for a WTRU to receive sidelink data transmission and / or send feedback;

[0021] Fig.14 is a diagram of a semi-persistent scheduling (SPS) configuration with both SA or data resources and feedback resources;

[0022] Fig.15 is a diagram of an example group resource allocation with different resource allocations for different group members;

[0023] Fig.16 is a graph showing block error rate (BLER) performance of channel quality information (CQI) entries on a tapped delay line (TDL)-A channel model with 30 ns delay spread and ideal channel estimation; and

[0024] Fig.17 is a flow chart for sending data when HARQ feedback is enabled or disabled. DETAILED DESCRIPTION

[0025] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access the content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may use one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT-spread OFDM (ZT UW DTS-sOFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0026] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments encompass 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. By way of example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA”, which may be configured to transmit and / or receive wireless signals, and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscriber-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0027] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks (e.g., the CN 106 / 115, the Internet 110, and / or the network 112). By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, 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.

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

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

[0030] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the 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 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

[0034] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN).

[0035] Figure 1AThe base station 114b in the example may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may use any suitable RAT for facilitating wireless connectivity in a local area, such as a business district, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, or the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may use a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-APro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106 / 115.

[0036] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, Internet, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although Figure 1A Although not shown, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may employ NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0040] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B 1. The processor 118 and the transceiver 120 are described as separate components, but it should be understood that the processor 118 and the transceiver 120 may be integrated together into an electronic package or chip.

[0041] The transmit / receive element 122 may be configured to transmit signals to a base station (e.g., base station 114a) or to receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. For example, in one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another 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.

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

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

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

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

[0046] The processor 118 may also be coupled to the 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 the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more neighboring base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

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

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

[0049] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As described above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0050] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the 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 for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

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

[0052] Figure 1C The CN 106 shown in FIG. 1 may include a mobile management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the foregoing elements is described as being 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.

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

[0054] The SGW 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may also perform other functions, such as anchoring the user plane during inter-eNode-B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

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

[0056] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) 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 or wireless networks owned and / or operated by other service providers.

[0057] Although the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.

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

[0059] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distributed system (DS) or other types of wired / wireless networks that transfer traffic to and / or out of the BSS. Traffic originating from outside the BSS to a STA may be reached through the AP and may be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to each destination. Traffic between STAs within a BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a 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 (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to as an "ad-hoc" communication mode.

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

[0061] A high throughput (HT) STA may communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[0062] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining continuous 20MHz channels. A 160MHz channel can be formed by combining 8 continuous 20MHz channels or by combining two discontinuous 80MHz channels (which can be referred to as 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be completed on each stream respectively. These streams can be mapped to two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0063] Sub-1 GHz operation modes are supported by 802.11af and 802.11ah. The channel operation bandwidth and carrier in 802.11af and 802.11ah are reduced relative to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter type control / machine type communication for MTC devices such as in macro coverage areas. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include batteries having a battery life above a threshold (e.g., to maintain a very long battery life).

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

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

[0066] Figure 1D 1 is a system diagram showing the RAN 113 and the CN 115 according to an embodiment. As described above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0067] The RAN 113 may include gNBs 180a, 180b, 180c, but it should be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, 180c may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one 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 gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers may be on an unlicensed spectrum, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0069] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN (e.g., the eNode-Bs 160a, 160b, 160c). For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

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

[0071] exist Figure 1DThe CN 115 shown in FIG. 1 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the aforementioned elements is described as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0072] The AMF 182a, 182b may be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, termination of NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRU 102a, 102b, 102c based on the type of service the WTRU 102a, 102b, 102c is utilizing. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or similar services. The AMF 162 may provide control plane functionality for switching between the RAN 113 and other RANs (not shown) using other radio technologies (e.g., LTE, LTE-A, LTE-A Pro, and / or non-3rd Generation Partnership Project (3GPP) access technologies such as WiFi).

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

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

[0075] 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 one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local data network (DN) 185a, 185b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b through the UPF 184a, 184b.

[0076] refer to Figures 1A-1D as well as Figures 1A-1D In accordance with the description of the present invention, one or more or all of the functions described herein may be performed by one or more simulated devices (not shown) for one or more of the following: WTRU 102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. A simulated device may be one or more devices configured to simulate one or more or all of the functions described herein. For example, a simulated device may be used to test other devices and / or emulate network and / or WTRU functions.

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

[0078] One or more simulation devices may perform one or more functions including all functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device may be utilized in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and or wireless communication network to implement testing of one or more components. One or more simulation devices may be test devices. The simulation device may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0079] LTE supports vehicular communications where V2X WTRUs can communicate directly with each other. LTE V2X is designed to support broadcast type communications. Unicast and multicast communications are also supported by V2X, but not at the physical (PHY) layer. Instead, unicast and multicast type communications can be supported by using a layer 2 (L2) destination identifier (ID). The receiving WTRU can process packets received on the RX resource pool and filter the packets based on the destination ID. For unicast, the WTRU needs to check if its ID is on the destination ID for each packet received. This is inefficient because the packet must be processed by the PHY and moved up the stack before the WTRU confirms the destination ID.

[0080] Since unicast communication is not supported at the physical layer in LTE V2X, sidelink link adaptation is also not supported in LTE V2X. In addition, LTE does not support feedback channels to adapt transmission parameters, such as the number of retransmissions, power control parameters, etc. In addition, in LTE V2X, channel state information reporting is not standardized. In order to increase the reliability of transmission, LTE V2X supports blind retransmission, in which a transport block is repeated without receiving HARQ feedback from the receiver of the transport block.

[0081] The first implementation of NR Release-15 was completed in December 2017. NR supports multiple use cases, including enhanced mobile broadband (eMBB), ultra-reliable and low-latency communications (URLLC), and massive machine type communications (MMTC). 3GPP has started a study project to investigate support for enhanced V2X (eV2X) communications in NR. eV2X in NR is expected to support new services for safety and non-safety scenarios. For example, eV2X is expected to support autonomous / remote driving, sensor sharing, and vehicle platooning. Each service has different performance requirements.

[0082] NR V2X is expected to support new use cases. In particular, the following use cases are to be supported:

[0083] Vehicle platooning enables vehicles to dynamically form groups that travel together. All vehicles in a vehicle platoon receive periodic data from the lead vehicle for vehicle platoon operation. This information allows the distance between vehicles to be small, i.e., the gap distance converted into time can be very low (sub-second). Platooning applications can allow following vehicles to be autonomously driven. In vehicle platooning, groups of vehicles can be operated in a tightly linked manner so that the vehicles move like a train with a virtual string attached between the vehicles. To maintain vehicle distance, vehicles can share state information between them. By using platooning, the distance between vehicles and the number of drivers required can be reduced. This can reduce overall fuel consumption.

[0084] Advanced driving enables semi-autonomous or fully autonomous driving. Assuming long distances between vehicles. Each vehicle and / or RSU shares data obtained from its local sensors with nearby vehicles, allowing vehicles to coordinate their trajectories or maneuvers. In addition, each vehicle shares its driving intentions with nearby vehicles. The benefits of this group of use cases are safer driving, collision avoidance, and improved traffic efficiency.

[0085] Extended sensors enable the exchange of raw or processed data collected by local sensors or through live video data shared between vehicles, remote sensor units (RSUs), pedestrian devices, and V2X application servers. The vehicle can enhance its perception of its environment beyond what its own sensors can detect and have a more comprehensive view of the local situation.

[0086] Remote driving enables remote drivers or V2X applications to operate remote vehicles for passengers who cannot drive themselves or in hazardous environments. For situations where changes are limited and routes are predictable, such as public transportation, cloud-based driving can be used. In addition, for this use case group, access to cloud-based backend service platforms can be considered.

[0087] The new QoS requirements for NR V2X are captured in TS22.186. New key performance indicators (KPIs) are specified with the following parameters: payload (bytes); transmission rate (messages / second); maximum end-to-end latency (ms); reliability (%); data rate (Mbps); and minimum required communication range (meters). These QoS characteristics can be represented by the 5G Quality of Service Indicator (5QI) as defined in Technical Specification (TS) 23.501. In V2X, the 5QI is renamed V2X Quality Indicator (VQI) and takes into account QoS parameters related to V2X.

[0088] For unicast case, PC5 QoS parameters are negotiated at the establishment of one-to-one communication procedure, so the one-to-one communication establishment procedure defined in TS23.303 is enhanced to support PC5 QoS parameter negotiation between two WTRUs. After the PC5 QoS parameter negotiation procedure, the same QoS can be used in both directions.

[0089] During the RAN1#94 meeting, RAN1 agreed to study sidelink enhancements for unicast and / or multicast communications for NR V2X. At least the following were agreed to be studied: HARQ feedback; CSI acquisition; open-loop and closed-loop power control; link adaptation; and multi-antenna transmission schemes.

[0090] In addition, it is agreed to support at least Mode 1 (where the network schedules one or more sidelink resources to be used by the WTRU for sidelink transmission) and Mode 2 (where the WTRU determines one or more sidelink resources in one or more sidelink resource pools configured or preconfigured by the network). These two agreed modes have an impact on supporting HARQ feedback for sidelink communications.

[0091] Sidelink HARQ feedback for unicast and / or multicast communications has the potential to increase the reliability of data transmission and reduce latency compared to handling packet error detection at higher layers (e.g., the radio link control (RLC) layer). However, supporting HARQ on the sidelink may come at the expense of high load on the sidelink channel. For autonomous mode (where the WTRU autonomously selects the sidelink resources), supporting a feedback channel will increase the probability of collisions between WTRUs. In addition, since the HARQ feedback will be sent on the same sidelink bandwidth, the available resources for sidelink data transmission will be reduced.

[0092] In network controlled resource allocation, the WTRU may need to request sidelink resources for retransmission and feedback transmission, and / or send feedback to the network. In this case, overhead may be incurred on the Uu link. An embodiment may be adopted that supports sidelink HARQ feedback for both autonomous mode and network controlled mode while reducing the load on the sidelink channel.

[0093] The WTRU may use a HARQ feedback channel format for transmission. In one embodiment, the HARQ feedback may be sent using a timing relationship according to the QoS. For example, the QoS of a data packet may indicate when the HARQ feedback is sent. The feedback may be sent on one or more resource pools. For all embodiments disclosed herein, the timing between the WTRU's sidelink transmission and the WTRU's sidelink retransmission, and / or the timing between the WTRU's sidelink transmission and the HARQ feedback, whether signaled by the WTRU or implicitly determined by the WTRU, may be derived from the QoS associated with the data transmission. Specifically, the WTRU may use a VQI, or may derive a packet delay budget (PDB) and / or priority from the VQI, to determine the timing relationship. Based on this relationship, the WTRU may perform resource selection, retransmission, HARQ transmission, or timing indication as applicable in each embodiment.

[0094] HARQ feedback may be sent on a physical sidelink control channel (PSCCH). The WTRU may transmit the HARQ feedback in a sidelink control information (SCI). In one embodiment, the WTRU may transmit the HARQ feedback using the same SCI format as defined for scheduling sidelink data. With this embodiment, the blind decoding work may be reduced when the WTRU receives HARQ feedback because the WTRU does not need to monitor multiple SCI formats that potentially have different sizes. The WTRU may use an identifier to distinguish between an SCI carrying scheduling information and an SCI carrying HARQ feedback. For example, the WTRU may use a bit in the SCI to indicate the intention of the SCI transmission, for example, using a value of 0 for HARQ feedback and a value of 1 for scheduling information. A WTRU carrying HARQ feedback using such an SCI may repeat the HARQ acknowledgment (HARQ-ACK) bit to reach the configured size of the SCI. For example, if the SCI size is N bits and the WTRU is transmitting 1-bit feedback, the WTRU may repeat the HARQ feedback bit N times. Alternatively, padding may be used to fill the remaining unused bit fields. Alternatively, the WTRU may include HARQ feedback for multiple transmissions into a single SCI in order to fill the SCI size. A WTRU receiving HARQ feedback may first check the identifier bit(s) and then decode the SCI accordingly. The SCI bit field interpretation may therefore depend on the identifier carried in the SCI.

[0095] In one embodiment, the WTRU may use a new SCI format to transmit the HARQ feedback. With this embodiment, the reliability parameters of the HARQ-ACK feedback are kept separate from the SCI of the scheduled data. For example, the HARQ-ACK feedback may have a different target block error rate (BLER) than the SCI of the scheduled data. Therefore, different SCI formats may be used to send these two signals. The new SCI format may have a fixed size or a variable size, depending on the HARQ feedback. In the case of a variable size, the WTRU transmitting the feedback may determine the size of the SCI based on the length of the feedback size of the number of bits or symbols used. The WTRU receiving the HARQ feedback may attempt to decode the SCI based on the expected HARQ feedback size assuming the SCI size.

[0096] In one embodiment, the WTRU may use one SCI to transmit HARQ feedback along with scheduling information. The WTRU may be configured with an SCI format that includes HARQ feedback information and scheduling information. The WTRU may indicate transmission parameters and HARQ feedback for data transmission in the same control message. In order to support situations where HARQ is not sent in the SCI, a one-bit field may be configured in the SCI to indicate the presence / absence of the feedback. For example, the WTRU may be configured with a bidirectional unicast link and may transmit HARQ feedback while transmitting a packet. The WTRU may then use the SCI that schedules the packet to feed HARQ acknowledgments about previously received packets. In another example, the WTRU may select resources for HARQ retransmissions and transmit scheduling information about the selected resources to the transmitting WTRU, i.e., the WTRU receiving the feedback.

[0097] HARQ feedback may be provided on a new physical channel. In some embodiments, the WTRU may be configured with a new physical channel to transmit HARQ-ACK feedback. Such a channel may consist of a plurality of physical resource blocks (PRBs), a starting PRB, a plurality of symbols, and a starting symbol within a time slot, or may consist of a plurality of PRBs, a starting PRB, a plurality of symbols, and a starting symbol within a time slot. The WTRU may be (pre)configured with a plurality of resources, each of which may contain a different number of PRBs, symbols, and starting positions. The WTRU may autonomously select transmission parameters (e.g., PRB sets, symbols, and duration) for HARQ feedback based on one or more of the following or any combination of the following: the number of HARQ-ACK bits; the reliability of the data associated with the feedback; the latency of the data associated with the feedback; the communication range; the measurement results; the time slot structure; and / or an ID that may uniquely identify the unicast / multicast link for which the HARQ feedback is being sent, and / or the HARQ process within the link.

[0098] For example, by using the number of HARQ-ACK bits, the WTRU may select the number of PRBs and / or symbols based on the HARQ codebook payload. For example, by using the reliability of the data associated with the feedback, the WTRU may be configured to transmit HARQ feedback on highly reliable data using a high number of PRBs to meet a lower BLER. For example, by using the latency of the data associated with the feedback, the WTRU may transmit feedback on a smaller number of symbols to meet the latency requirements of the data associated with the received packet.

[0099] The WTRU may be configured to perform measurements to determine the HARQ physical channel parameters before selecting the HARQ resource parameters. For example, the WTRU may measure the high load in the HARQ feedback resources by measuring the channel busy ratio (CBR), and thus the WTRU may select fewer PRBs to transmit feedback. In another example, the WTRU may select the starting OFDM symbol to avoid collisions with other transmissions.

[0100] Using the slot structure, the WTRU may select the starting symbol and duration for HARQ feedback based on the slot format indication received from the network or other WTRUs. An ID may also be used that uniquely identifies the unicast / multicast link, and / or HARQ process within a link, for which the HARQ feedback is being sent. For example, the WTRU may select resources for HARQ feedback on a particular link based on a unique ID to avoid conflicts with other HARQ feedback from other WTRU(s). The WTRU expecting the feedback may determine the HARQ-ACK feedback resources and parameters based on the same conditions as described above for the WTRU transmitting the feedback.

[0101] The HARQ feedback may be based on a sequence-based signal. In some embodiments, the WTRU may be configured to transmit the HARQ feedback using a sequence-based signal (e.g., a pseudo-random sequence). In one embodiment, the WTRU may be configured to have 2 N In another embodiment, the WTRU may be configured with 2 N The bit sequence length may be 1000x10 to carry N1 bits of HARQ feedback, such that N is greater than N1, and repetition of HARQ-ACK bits may be used by the WTRU to ensure higher reliability of the feedback.

[0102] In some embodiments, the WTRU may be configured to generate a specific sequence for HARQ feedback based on, for example, one or a combination of the geographical distance between the transmitter WTRU and the receiver WTRU, a group ID within a multicast communication (intra-group ID), and / or measurement results.

[0103] If the WTRU generates a specific sequence for HARQ feedback based on the geographical distance between the transmitter WTRU and the receiver WTRU, i.e., the geographical distance between the WTRU expecting feedback and the WTRU transmitting feedback, the WTRU may, for example, be configured with a mapping table or function between the distance and the sequence and / or offset to generate the HARQ feedback. For example, the WTRU may be configured with a sequence set {S1, S2, ..., S N}. The WTRU may select a sequence based on the distance between the transmitter and the receiver. As an example, the WTRU may be configured with a mapping table that provides a mapping between distances and sequences as shown in Table 1. The WTRU may be configured with 3 sequences, each corresponding to a distance threshold. In another example, as shown in Table 2, the WTRU may be configured with a sequence of length M and may offset N based on the distance from the transmitter. i The WTRU may select a sequence from a set of sequences and may apply different offsets to the selected sequence for different distances. The distance may be measured in terms of signal timing or signal power (e.g., timing advance or transmit power level). The distance may also be a measure of actual distance in terms of location, positioning, etc.

[0104] If the WTRU generates a specific sequence for HARQ feedback based on a group ID used in multicast communication or a group ID for multicast communication, the WTRU may, for example, be configured with mapping rules between the group ID, sequence and / or offset, and may select the sequence and / or offset based on the group ID or other ID.

[0105] If the WTRU generates a specific sequence for HARQ feedback based on measurement results, the WTRU may, for example, be configured with a set of sequences and may select a sequence from the set of sequences based on the measurement results (e.g., CBR results). For example, the WTRU may be configured with an association between CBR thresholds, thresholds for different measurements, sequences, and / or offsets. distance sequence <![CDATA[d≤d1]]> <![CDATA[S1 <!-- 13 -->]]> <![CDATA[d1<d≤d2]]> <![CDATA[S2]]> <![CDATA[d2<d]]> <![CDATA[S3]]> Table 1: Mapping rule configuration between distance and sequence distance Offset <![CDATA[d≤d1]]> <![CDATA[N1]]> <![CDATA[d1<d≤d2]]> <![CDATA[N2]]> <![CDATA[d2<d]]> <![CDATA[N3]]> Table 2: Mapping rule configuration between distance and offset

[0106] In some embodiments, the WTRU can be configured to determine and / or estimate the distance based on one or a combination of the power level of the SCI, the power level of a reference signal within a sidelink control and / or data transmission, a geolocation indication, a location reference signal and / or a sidelink synchronization signal received by the transmitter.

[0107] If the WTRU is configured to determine and / or estimate the distance based on the power level of the SCI, then in some examples, the WTRU may be configured with the transmit power of the SCI, and based on the received power of the SCI, the WTRU may determine the path loss and the distance between the transmitter and the receiver.

[0108] If the WTRU is configured to determine and / or estimate the distance based on a geolocation indication, then in some examples the WTRU may receive an indication of its geographic area / location from a transmitter (e.g., via an explicit indication in the SCI), or by implicitly using a resource pool, e.g., the WTRU may determine the geolocation based on the resources used by the transmitter.

[0109] HARQ feedback may be sent on a physical sidelink shared channel (PSSCH). In some embodiments, the WTRU may transmit sidelink HARQ feedback on a sidelink data channel. The WTRU may autonomously determine the number of resource elements to be used from the resources selected for data transmission. For example, rate matching or puncturing parameters may be autonomously determined by the WTRU transmitting the feedback. The WTRU may determine the number of resource elements based on one or more of: reliability requirements of the HARQ feedback; reliability requirements of the data to be multiplexed with the HARQ feedback; and / or delays associated with the feedback channel. For example, the WTRU may select the first symbol from the data transmission resources in the front-end loaded HARQ feedback method. In one embodiment, the WTRU may be configured from the network to have the number of resource elements to be used from the sidelink data channel.

[0110] The WTRU transmitting the feedback may use a bit field in the SCI to indicate whether the HARQ feedback is piggybacked on the data channel.The WTRU receiving the feedback may then determine the number of resource elements(s) based on the above conditions.

[0111] The HARQ feedback may be sent on a physical uplink control channel (PUCCH) or a physical uplink shared channel (PUSCH). In some embodiments, the following examples may be applied to a WTRU generating a HARQ-ACK, i.e., receiving a transport block, or to a WTRU receiving a HARQ-ACK, i.e., transmitting the transport block.

[0112] In some embodiments, the WTRU may be configured to transmit HARQ feedback regarding a sidelink transmission to the network. A WTRU operating in Mode 1 (where the network schedules resources to the WTRU) may be configured to transmit sidelink feedback to the gNB. For example, the WTRU may be configured with PUCCH resources to transmit HARQ feedback for a given unicast communication. A Mode 1 WTRU using a sidelink unicast link may be known to the network. In this case, the network may relay the HARQ feedback regarding the sidelink communication to a destination WTRU. The destination WTRU may receive explicit HARQ feedback from the network using a downlink control message (e.g., using an explicit bit field in a DCI that schedules a sidelink grant), or alternatively, the WTRU may receive an implicit indication. Such an implicit indication may include: the WTRU receiving a sidelink grant from the network (which indicates a new transmission or retransmission of a HARQ process for which the network expects to receive feedback), or, for example, the WTRU not receiving a sidelink grant for a retransmission.

[0113] The WTRU may be configured with a PUCCH resource set, for example, using radio resource control (RRC) signaling, to transmit HARQ-ACK(s) regarding one or more sidelink transport blocks. In some embodiments, the WTRU, after receiving a DCI from a gNB scheduling sidelink resources for data and / or sidelink control, determines the PUCCH resource to be the PUCCH resource set, or determines the PUCCH resource based on the PUCCH resource set, where the sidelink feedback should be relayed to the network on the PUCCH resource set. Note that the PUCCH resource set may be configured by the network; for example, using RRC or a system information block (SIB). The DCI may carry an explicit indication, such as one or more bits and / or fields regarding the PUCCH resources within the PUCCH resource set. Alternatively, the DCI may implicitly indicate the PUCCH resource. For example, a timing indication regarding a PUCCH transmission may implicitly indicate the PUCCH resource. In some examples, each PUCCH resource in the PUCCH resource set may be associated with a timing offset. The timing offset may be in units of slots, symbols or symbol groups.

[0114] In some embodiments, the WTRU may be configured to autonomously select PUCCH resources from the PUCCH resource set. Note that the PUCCH resource set may be configured by the network; for example, by using RRC signaling or SIB. The WTRU may select PUCCH resources based on one or a combination of: QoS characteristics of the transport block, reference signal received power (RSRP) measured from the serving cell, and / or the timing between the reception of the sidelink grant and the reception of the sidelink HARQ feedback from the sidelink WTRU.

[0115] In the example of QoS characteristics based on transport blocks, for packets with short PDB, the WTRU may select a PUCCH format with a short duration, such as a PUCCH with a duration of 2 symbols. For packets with high reliability requirements, the WTRU may select a more reliable PUCCH format, such as a PUCCH with a longer duration. The QoS characteristics may include at least priority, reliability, latency, and / or required communication range. In the example based on RSRP measured from the serving cell, a WTRU with a high RSRP may select a short PUCCH format.

[0116] In some embodiments, the WTRU may be configured to transmit HARQ feedback only for NACK states. In such a case, the WTRU may select PUCCH resources based on the number of NACK(s) to be reported for the sidelink transport block(s). For example, a V2X WTRU may be configured with multiple unicast sessions, where the HARQ protocol is enabled in more than one unicast session. After receiving sidelink feedback including multiple NACKs (e.g., M1 NACKs) from other sidelink WTRUs, the WTRU may select PUCCH resources based on the number of received NACKs (e.g., M1 NACKs to be reported for the sidelink transport block) reaching a threshold. Note that if no NACK is received, then M1=0 in this example.

[0117] In some embodiments, the WTRU may apply a combination of autonomous resource selection and dynamic indication from the network to select the PUCCH resources.

[0118] In an exemplary embodiment, a WTRU that receives a grant for a sidelink transmission and one or more retransmissions may determine whether it needs to perform a retransmission in a grant associated with the retransmission(s), which may be based on whether a subsequent grant for resources in the same timeslot as the retransmission occurs. Specifically, if the WTRU receives a DCI for a sidelink resource that occurs in the same timeslot as the retransmission resource, the WTRU may assume an ACK for the initial transmission and use a new grant for transmitting new data. If the WTRU does not receive a grant for resources in the same timeslot as the retransmission, the WTRU assumes a NACK for the initial transmission and transmits the retransmission using the granted retransmission resources.

[0119] The HARQ feedback resource format determination may be made based on one or more factors. The WTRU may be configured to autonomously determine the channel format (including whether on a sidelink data channel or on a sidelink control channel) or SCI format for HARQ feedback. The WTRU may determine the HARQ channel format and / or SCI format based on one or more of the following. The WTRU may determine the HARQ channel format and / or SCI format based on the reliability of the HARQ feedback. For example, the WTRU may be indicated by the transmitter WTRU about the target BLER of the feedback. Such an indication may be carried explicitly in a bit field of the SCI, or may be implicitly determined from: a resource pool for transmitting the sidelink control and / or sidelink data. For example, the resource pool may be associated with: a given BLER target; a bandwidth portion for transmitting sidelink control and / or sidelink data; an SCI format for carrying scheduling information for data to be confirmed; a modulation and coding scheme (MCS) table and / or MCS index for data to be confirmed; unicast link characteristics, for example, when establishing a radio bearer, two WTRUs establish reliability parameters associated with the link. For example, if at the time of HARQ-ACK transmission, the WTRU is transmitting data to a WTRU that expects HARQ feedback, the WTRU may transmit sidelink HARQ feedback on the PSSCH.

[0120] For example, using the measurement results, the WTRU may be configured to perform measurements to select resources for SCI transmission, and may then determine that there is a high load on the sidelink control channel. The WTRU may then decide to combine the HARQ feedback and the SCI scheduling data in the same message. The HARQ feedback timing or channel determination may be a function of the feedback reliability. For example, the WTRU may select a new HARQ channel format with fewer symbols instead of transmitting the feedback with the data due to the long duration of the data transmission. In addition, the WTRU may determine the HARQ channel format and / or the SCI format based on the HARQ codebook size, for example, the WTRU may select the SCI format based on the number of HARQ-ACK bits to be transmitted; via an indication from another WTRU (e.g., a WTRU acting as a local manager or a WTRU expecting feedback); and / or geographic location information (e.g., the WTRU may be configured to use a specific HARQ format within a specific location) to select the SCI format.

[0121] Table 3 shows an example mapping between reliability, channel load, and HARQ feedback channel format. In one example, when the reliability of data transmission is considered low, feedback may not be used regardless of the channel load. When data transmission is determined to have medium reliability, HARQ format 0 may be used only in the case of low channel load. When data transmission is determined to require high reliability, HARQ format 1 may be used when the channel load is low, HARQ format 2 may be used when the channel load is medium, and HARQ format 3 may be used when the channel load is high. Low channel loading Medium channel load High channel load Low reliability No feedback No feedback No feedback Medium reliability HARQ Format 0 No feedback No feedback High reliability HARQ Format 1 HARQ Format 2 HARQ Format 3 Table 3 Feedback format selection based on reliability and channel load

[0122] Figure 2 2 is a timing diagram 200 illustrating an example HARQ feedback determination method. Figure 2 In the example shown, the WTRU may determine that one or more HARQ feedback channels have a low load at time 202. Due to the low load on the HARQ feedback channel, the WTRU may transmit an SCI indicating the low load 204. Subsequently, the WTRU may transmit data 206 and receive HARQ feedback from another WTRU 208. Due to the experienced load, the HARQ feedback may be in a first format that spans a longer period of time than a second format.

[0123] At time 210, the WTRU may measure a high load on the feedback channel. In the example shown, the data reliability requirements may be high, so the WTRU may choose to use a shorter HARQ feedback format accordingly. Therefore, the WTRU transmits an SCI 212 indicating that a shorter HARQ feedback format should be used. Data is transmitted 214 by the WTRU, and HARQ feedback is subsequently received 216 in the shorter HARQ feedback format. In one embodiment, the shorter HARQ feedback format may be a format that is shorter than another format. In one embodiment, the shorter HARQ feedback format may be the shortest available format. The short HARQ feedback format may be defined by the number of resource units used by the format.

[0124] At time 218, the WTRU may measure a high load on the feedback channel while determining that the data reliability requirement is low. In this case, the WTRU may determine to avoid HARQ feedback altogether and may indicate this in the transmitted SCI 220. Data transmission 222 may follow and the WTRU may not receive HARQ feedback. In this example, after a period of time or after a feedback channel is subsequently measured, the communicating WTRU may revert to using HARQ feedback again. Although Figure 2 Two HARQ feedback formats are shown, but other formats or numbers of formats may be used as desired.

[0125] Figure 3 300 is a flow chart illustrating a method performed by a transmitting WTRU. The WTRU may determine 302 the channel load by sensing or performing other measurements. In one embodiment, the WTRU may sense a fixed or variable number of symbols of a slot to determine the CBR. The WTRU may then determine 304 feedback characteristics, such as characteristics of buffered packets, using rules that may be configured by the network. The rules may be configured via RRC or other signaling methods.

[0126] HARQ feedback may be provided for multicast type communications. The WTRU may be configured to transmit HARQ-ACK feedback when operating in multicast mode. The WTRU may communicate with a group of WTRUs on a sidelink. Each of the WTRUs may send and / or receive multicast data. Instead of sending HARQ feedback for each multicast packet on different channels (one or more), the WTRU may combine the HARQ feedback in a HARQ codebook and transmit the HARQ codebook on a single channel. In one embodiment, in order for the WTRUs belonging to the group to determine their HARQ-ACK feedback in the HARQ codebook, different HARQ process IDs may be assigned to different WTRUs. In an example scenario, N WTRUs communicate in multicast mode and use M HARQ processes. Each WTRU may be configured to use HARQ processes. In an exemplary embodiment, a WTRU may determine its set of HARQ processes based on its ID within the group. For example, a WTRU within the group is identified by IDi,i∈{1,..,N}. A WTRU with IDi may use HARQ processes In another example, a WTRU within the group or a WTRU within the network may assign a HARQ process ID to other WTRUs within the group.

[0127] The WTRU may be configured to aggregate multicast HARQ-ACK feedback based on one or more of the following triggers: identical HARQ-ACK timing for the multicast messages; measurement results, e.g., the WTRU may measure the CBR on the feedback channel and determine that there is a high load on the HARQ feedback channel and therefore use this method in that case; an indication from the multicast manager WTRU; and / or an indication from the network.

[0128] The HARQ-ACK codebook may be used for unicast transmissions. In one embodiment, the WTRU may be configured to combine sidelink HARQ-ACK feedback for multiple transport blocks into one HARQ-ACK codebook. The WTRU may determine when to combine the feedback based on one or more of the following: the HARQ-ACK timing for different transport blocks is the same, for example, if two HARQ-ACK feedbacks must be transmitted on the same time slot, the WTRU may combine the two HARQ-ACK feedbacks; the priority requirements for HARQ-ACK feedback for different transport blocks are the same, for example, if feedback for two or more transport blocks targets the same BLER, the WTRU may combine the feedback; and latency requirements.

[0129] Figure 4 4 is a diagram of a side link time slot 400 in which feedback is sent. Figure 4 As shown, the time slot 400 spans 14 symbols 402-428. The WTRU may determine to transmit low latency feedback 430 in the first symbol 402 and the second symbol 404 of the time slot 400. Alternatively, other symbols may be selected, for example, the second symbol 404 and the third symbol 406. After the low latency feedback, other control information or data that may or may not include feedback information may be sent in a fixed or variable number of symbols (e.g., symbols 406-412). Tolerable delay feedback 432 (e.g., feedback that is not as urgent as the low latency feedback 430) may be sent at or near the end of the side link time slot 400 (e.g., in symbols 414-428). Alternatively, other symbols may be selected. Other time slot configurations may vary in size.

[0130] For example, by using a latency requirement or threshold, the WTRU may not combine two HARQ-ACK feedbacks even if they must be transmitted on the same timeslot due to different latency requirements. The WTRU may then transmit the low latency feedback 402 on fewer symbols at the beginning of the timeslot and the second feedback 404 on a longer duration, such as Figure 4 shown.

[0131] The transmitting WTRU or the receiving WTRU may perform the resource selection / allocation for the feedback and retransmission. In some embodiments, the WTRU transmitting the HARQ feedback may be configured to select one or more HARQ feedback resources. In one embodiment, the WTRU transmitting the feedback may select the HARQ resource (one or more) from a resource set known to the WTRU expected to receive the feedback. For example, a HARQ side link resource set may be associated with a side link data transmission. This association may be configured (pre) from the network or indicated by the WTRU transmitting the data. On the receiver side, the WTRU may blindly decode all HARQ resources within the resource set. The WTRU transmitting the feedback may include its ID in the HARQ feedback to allow the receiving WTRU to determine the resources for the HARQ feedback. For example, the WTRU may scramble the cyclic redundancy check (CRC) attached to the HARQ codebook with its ID or the destination WTRU ID. Alternatively, the WTRU transmitting the feedback may explicitly indicate the selected resources to the WTRU monitoring the HARQ feedback.

[0132] In another embodiment, the WTRU that expects to receive the HARQ feedback may be configured to select HARQ feedback resources and transmit a resource indication to the WTRU that will transmit the feedback. Such an indication may be sent together with the SCI indicating the transmission of the data resource and / or may be implicitly derived from the time and / or frequency position of the data resource. In this embodiment, the WTRU may also reserve the resource by sending a control signal indicating the transmission time, frequency, or channel of the HARQ feedback. Other side link WTRUs may avoid selecting the reserved resource at the indicated time. In this embodiment, the transmitting WTRU that performs resource selection may attempt to ensure the availability of resources for data transmission and for HARQ feedback via a resource selection mechanism. In one example, the transmitting WTRU that selects resources for HARQ feedback may select from a subset of the time / frequency resources used for the HARQ transmission. The resource subset may be implicitly associated with the timing of the data transmission, while the actual resource to be used for the HARQ feedback may be explicitly indicated in the SCI, for example, by using an index, or a bitmap, etc.

[0133] In some embodiments, the WTRU may receive a resource assignment for a HARQ transmission from another WTRU. For example, a local manager WTRU may be configured to assign HARQ feedback channels and / or resources to other WTRUs. In another example, a queue leader WTRU may assign HARQ feedback to queue member WTRUs. In an exemplary embodiment, the WTRU may be configured to request HARQ feedback resources from another WTRU. Such a request may be sent using a special SCI format designed for this purpose. The assigned HARQ feedback resources may be configured to the WTRU in a semi-persistent manner, or may be changed dynamically.

[0134] A WTRU that selects HARQ feedback resources, whether a transmitting WTRU, a receiving WTRU, or another WTRU, may reserve HARQ resources for the expected duration of a unicast transmission. In one embodiment, the WTRU that selects the HARQ feedback resources may be a local manager or a queue manager. The selected resources may be used for subsequent HARQ-ACK feedback sent during the unicast session. Alternatively, the WTRU may be configured to dynamically (re)select resources upon one or more feedback transmissions. The WTRU may (re)select the resources based on one or more of the following triggers and conditions: collision detection, interference detection, feedback reliability, feedback priority, timer expiration; indications received from the network or other WTRUs, geographic location information, channel state information, or other information.

[0135] In the case where the WTRU may (re)select resources based on conflict detection, for example, the WTRU may determine based on SCI detection that one or more other WTRUs are using the resources, for example by receiving an SCI indicating the same resources. In this case, the WTRU may compare its expected feedback priority or the priority of the data to be acknowledged with the reliability of the conflicting feedback. In some embodiments, the WTRU may determine to ignore other transmissions when the feedback to be transmitted has a higher priority.

[0136] In the case where the WTRU may (re)select resources based on interference detection, for example, the WTRU may select the HARQ feedback resource if the energy sensed on the fed back time-frequency resource is detected to be at or above a configured threshold.

[0137] In the case where the WTRU may (re)select resources based on feedback reliability, for example, if the reliability requirement of a subsequent HARQ feedback is lower than the reliability of the first transmitted HARQ feedback, the WTRU may select a HARQ feedback resource and keep it for said subsequent HARQ-ACK feedback transmission. The WTRU may be configured to reselect a HARQ feedback resource if the BLER requirement of the feedback or the BLER requirement of the data associated with the feedback is lower than the BLER for which the resource was selected. In another example, the WTRU may be configured with multiple resource pools for HARQ-ACK transmission, each resource pool may be associated with a BLER target or a set of BLER targets.

[0138] For example, in the case where the WTRU may (re)select resources based on feedback priority, the WTRU may be configured with mapping rules between HARQ process ID and feedback priority. The WTRU may use the HARQ process ID to determine the priority of the HARQ feedback.

[0139] For example, in the case where the WTRU may (re)select a resource based on the expiration of a timer, the WTRU may be configured to periodically reselect the HARQ resource using a timer. When the feedback resource is first selected, the WTRU may start the timer. Upon expiration of the timer, the resource may be reselected.

[0140] In some cases, the WTRU may (re)select a resource based on an indication from the network to reselect a HARQ feedback resource. In the case where the WTRU may (re)select a resource based on an indication from another WTRU, for example, the WTRU may include a local manager or queue leader for reselecting HARQ feedback resources.

[0141] In the case where the WTRU may (re)select resources based on a change in geographic location information, for example, the WTRU may be configured with multiple resource pools, each resource pool corresponding to a geographic location region. If the WTRU moves to a geographically different location, the WTRU may (re)select resources for HARQ feedback.

[0142] In a case where the WTRU may (re)select resources based on the channel status of the previously transmitted(s) data transmission, for example, assuming channel reciprocity, the WTRU may reselect HARQ feedback if the signal-to-noise ratio (SNR) or signal-to-interference and noise ratio (SINR) of the data transmission is below a threshold.

[0143] HARQ feedback resource assignment may be made by the network and provided to the WTRU transmitting feedback. In some embodiments, the WTRU transmitting feedback may receive a resource assignment for HARQ transmission from the network. The WTRU may be configured to request sidelink HARQ feedback transmission resources from the network. In an exemplary embodiment, the WTRU may transmit a sidelink HARQ request using a scheduling request (SR) signal. For example, the WTRU may be configured with an SR PUCCH resource for a sidelink HARQ resource request. The WTRU may be configured with a multi-bit SR to indicate the number of HARQ-ACK bits required for the sidelink transmission. Alternatively, the WTRU may be configured with multiple SR PUCCH configurations, each configured to request a different number of sidelink HARQ bits. In an exemplary embodiment, the WTRU may transmit the sidelink HARQ resource request using a buffer status report (BSR). For example, the WTRU may be configured to use a given logical channel group ID for a sidelink HARQ feedback request, and the BSR size associated with the logical channel group (LCG) ID reflects the number of bits required for the HARQ transmission. The WTRU may be configured with multiple LCGs, each LCG being associated with a side link HARQ reliability.

[0144] The HARQ feedback resource assignment may be made by the network and provided to the WTRU receiving the feedback. In another embodiment, the WTRU that desires to receive feedback may receive a resource assignment for HARQ transmission from the network and may then transmit a resource indication to the WTRU that will transmit the feedback. The WTRU may transmit the request together with a sidelink data resource request. For example, the WTRU may be configured to map the logical channel ID for which HARQ feedback is required to a specific logical channel group ID (one or more). The WTRU may also indicate HARQ QoS characteristics, such as reliability and latency, to the network using the same MAC control element (MAC CE), or the network may assume the same QoS characteristics as those indicated or included in the BSR. The WTRU may implicitly request sidelink HARQ resources by indicating the type of communication (e.g., unicast, multicast, or groupcast).

[0145] In another embodiment, a data transmitting WTRU (i.e., a WTRU that desires to receive HARQ feedback) may receive multiple semi-persistent scheduling (SPS) configurations for a unicast link. Each configuration may include one or more resources for HARQ feedback. A data receiving WTRU (i.e., a WTRU that transmits feedback) may obtain the SPS configuration via the transmitting WTRU or directly via the network. In the case where the transmitting WTRU transmits the SPS configuration to the receiving WTRU, such a message may be sent during the unicast setup phase. This method may be motivated to avoid frequent sending of HARQ feedback information between the data transmitting and receiving WTRUs.

[0146] In one embodiment, the WTRU may be configured to determine the HARQ-ACK feedback transmission timing. The WTRU may indicate the timing as an offset from the first transmission of the HARQ process ID or as an offset from the time of transmitting or receiving the SCI. Alternatively, the WTRU may indicate a time window in which the HARQ may be transmitted. The WTRU may be (pre)configured with one or more sets of allowable HARQ timing configurations (one or more) and may determine the applicable timing based on one or more of: QoS characteristics of the packet, transport block size, transmission time of the first / previous transmission, subcarrier spacing, channel structure of the sidelink data, indications from the network, and / or timing configuration of transmissions scheduled by the network to relay sidelink feedback to the PUCCH resources of the network.

[0147] For example, with respect to the QoS characteristics of the packet, the WTRU may be configured to determine the HARQ timing of the transport block based on the VQI parameters of the TB packet. The QoS characteristics may include, for example, at least the packet delay budget (PDB) and reliability. With respect to the transmission time of the first / previous transmission, for example, the WTRU may receive a packet with a required PDB from its higher layers.

[0148] Figure 5 500 is a transmission timing diagram showing the timing of transmissions over a plurality of time slots 502-514. When the WTRU receives 516 a packet with a PDB, the WTRU may perform measurements and may select 518 a sidelink resource for an initial transmission, such as time slot 506. In one embodiment, the selected resource may be a resource that is 2 time slots later after the measurement, i.e., after time slots 502, 504. To meet the required PDB for the packet, the WTRU may determine the HARQ timing 520 accordingly. In this embodiment, the HARQ timing 520 may be an offset from the initially selected resource 518. The WTRU may then transmit feedback 522 based on the determined HARQ timing 520. The HARQ timing 520 may span time slots 508, 510, and the feedback transmission may start at or near the first symbol of time slot 512.

[0149] Regarding indications from the network, for example, a WTRU operating in network controlled mode may receive a sidelink grant for an initial transmission and any potential retransmission(s). The WTRU may determine the HARQ timing based on the time difference between the first transmission and the retransmission(s).

[0150] Regarding the timing configuration of the transmission of the PUCCH resources scheduled by the network to relay the sidelink feedback to the network, for example, the WTRU may receive a sidelink grant and a PUCCH resource carrying the sidelink HARQ feedback. The WTRU may thereafter indicate the sidelink HARQ feedback timing to the receiving WTRU so that the sidelink feedback is received prior to the PUCCH transmission.

[0151] In an exemplary embodiment, a WTRU that is expected to receive sidelink feedback may determine the HARQ timing and transmit an indication to the WTRU that it will transmit the feedback. For example, in a network controlled mode, the timing indication may be configured from the network and a WTRU that receives the sidelink grant may transmit an indication to the WTRU to transmit the HARQ feedback. In another embodiment, the WTRU may autonomously determine the feedback timing and transmit the HARQ at the determined time.

[0152] The WTRU may be configured to autonomously select resources for HARQ retransmission(s). In one embodiment, a WTRU receiving data, i.e., transmitting HARQ-ACK feedback regarding the data, may determine resources for retransmission and indicate them to the transmitter of the data. The WTRU may select the retransmission resources based on one or more of: measurement results; channel status; and / or whether the WTRU detects a higher priority transmission that conflicts with resources used for an initial / previous transmission.

[0153] For example, the WTRU may determine that resources used for a first or previous transmission are used by other WTRUs. Alternatively, the WTRU may indicate to other WTRUs that the resources are being used by the transmitting WTRU. This approach may alleviate the hidden node problem. For example, the WTRU may determine that the channel conditions experienced in the first or previous transmission (one or more) are insufficient for the transmission parameters. In one embodiment, the WTRU may determine whether it has detected a higher priority transmission that conflicts with the resources used for the initial or previous transmission. The WTRU may then determine the transmission parameters for one or more subsequent transmissions. The transmission parameters may include one or more of the following: modulation and coding scheme (MCS); PRB allocation; power control parameters and redundancy version (RV).

[0154] In one embodiment, the WTRU may use the same transmission parameters for any HARQ retransmission(s) as used for the initial transmission. Alternatively, the WTRU may change the transmission parameters of the HARQ retransmission(s) to ensure the QoS requirements of the packet. In one example, if the priority of the initial transmission is higher, the WTRU may change the MCS, increase the resource size and / or increase the transmit power. This approach may help ensure that high priority packets can reach the destination in a timely manner. In another example, the WTRU may reduce the reliability and / or priority of the HARQ retransmission(s) compared to the initial transmission. This approach may help to support a packet prioritization scheme, where the WTRU may reduce the priority of a retransmission if it has the same priority as the initial transmission.

[0155] In another embodiment, a WTRU transmitting data, i.e., a WTRU that desires to receive feedback regarding the reception of the data, may select resources for retransmission and indicate them to the receiving WTRU. The WTRU may reserve resources for both transmission and retransmission(s) at the same time. Depending on the HARQ state, the reserved resources may be used for retransmission or for new transmission. For example, the data may be successfully decoded into packets on the first transmission, and the reserved resources may be used by the transmitting WTRU or the receiving WTRU for a new transmission.

[0156] In another embodiment, the WTRU may receive from the network sidelink resources for retransmission(s) and one or more resources for initial transmission. The WTRU may be configured to request the resources and indicate the need for the retransmission(s) resources. Alternatively, the WTRU may indicate to the network the QoS characteristics associated with the sidelink data to be transmitted, and the network may determine whether retransmission is required.

[0157] The WTRU may receive sidelink resources for retransmissions from another WTRU, such as a local manager or a vehicle queue leader. The WTRU may be configured to send a sidelink resource request for one or more retransmissions to another WTRU. The WTRU may send QoS parameters with the sidelink resource request. The local manager WTRU may assign resources based on the QoS characteristics. For example, the local manager WTRU may receive a scheduling request and a VQI associated with a transmission. Based on the VQI, the local manager may assign one or more resources, HARQ feedback formats, and transmission parameters. The transmission parameters may include one or more of the following: MCS; PRB allocation; power control parameters; and / or RV.

[0158] HARQ retransmissions may be performed for multicast communications. In the case of multicast communications, the WTRU may be configured to determine whether to perform HARQ retransmission(s) based on the HARQ feedback status received from one or more WTRUs that are members of the multicast link and the QoS requirements of the packet. For example, if the priority of the packet is high, the WTRU may perform HARQ retransmissions if it receives at least one HARQ NACK. Alternatively, if the priority of the packet is low, the WTRU may perform HARQ retransmissions if it receives at least X HARQ NACKs. The value of X may depend on the priority of the packet and the number of WTRUs in the multicast. For example, assuming that the HARQ retransmissions are also multicast, if there are a small number of WTRUs in the multicast, there may be less need for HARQ retransmissions than for a very large number of WTRUs.

[0159] The HARQ process management may be performed by a receiving WTRU or a transmitting WTRU, ie, the WTRU transmitting the HARQ ACK / NACK feedback or the WTRU receiving the HARQ ACK / NACK feedback.

[0160] HARQ feedback may be enabled and disabled by a transmitting WTRU or a receiving WTRU. In some embodiments, the WTRU may be configured to manage the HARQ protocol. In a first embodiment, the WTRU may be configured to enable / disable HARQ feedback transmission. For example, the WTRU may send an indication to the receiving WTRU that the HARQ protocol is not supported for the entire unicast session. In another example, the WTRU may send an indication to the receiving WTRU that feedback is not sent for a given HARQ process ID. The WTRU may convey such an indication explicitly using a bit field in the SCI or implicitly using one of the following indicators:

[0161] One or more HARQ process IDs may be reserved for HARQ-free transmissions. For example, ID0 may be used for all transmissions that do not require HARQ feedback. The receiving WTRU may flush the buffer after receiving the decoded TB. Another indicator includes the QoS requirements for the unicast link. Another indicator includes the transmission resources used for the initial transmission. For example, the transmitting WTRU may be configured to have a set of resource pools, and a subset of the resource pool may be used for HARQ-free transmissions. The receiving WTRU may determine whether HARQ-ACK is required based on the resource pool used for the initial transmission. The WTRU may be provided with a HARQ feedback timing indication. For example, the WTRU may be configured to determine the number of retransmissions of a given HARQ process and whether HARQ feedback is required based on measurement results and QoS characteristics. For example, if the CBR is higher than a configurable threshold on the feedback channel, the WTRU may detect a high load on the feedback channel, and the WTRU may determine to postpone the HARQ retransmission for a preconfigured time period. In another example, if the CBR is higher than a threshold, the WTRU may determine to discard the retransmission. In another example, the WTRU may be configured with multiple thresholds, each threshold corresponding to a specific action, such as dropping a retransmission, reducing the number of retransmissions, or deferring a retransmission. For example, the WTRU may determine the number of retransmissions based on the reliability of the packet.

[0162] In an embodiment, the WTRU may be configured to autonomously manage the HARQ soft buffer. If a HARQ process reaches the configured number of retransmissions, the WTRU may purge the HARQ process from its buffer. In this case, the WTRU may send an indication to the receiving WTRU (i.e., the WTRU sending the HARQ-ACK feedback) using, for example, a bit field in the SCI for a given HARQ process.

[0163] In some embodiments, the WTRU may be configured to purge some HARQ processes from its buffer even before the maximum number of allowed retransmissions is reached. For example, the WTRU may be operating at its maximum buffer size and needs to transmit a high priority packet arriving from a higher layer. The WTRU may be configured to purge the HARQ process IDs with lower priority packets. In this case, the WTRU may be preconfigured with a mapping rule to associate high priority data with a HARQ process set. For example, the WTRU may be configured to map high priority data to a lower HARQ ID.

[0164] In other embodiments, the WTRU may be configured to purge the HARQ process from its buffer after receiving an indication from the network. Such an indication may be sent using a DCI format that schedules sidelink transmission resources. For example, the WTRU may receive a sidelink resource assignment for each HARQ process ID from the network. The gNB may use the New Data Indicator (NDI) bit to indicate whether a HARQ process is to be purged.

[0165] In some embodiments, the WTRU may be configured to implicitly indicate the HARQ state of a given HARQ process. In an exemplary embodiment, if no HARQ feedback is received within a preconfigured time, the WTRU may be configured to assume NACK. Alternatively, if no feedback is received within a preconfigured time, the WTRU may assume ACK. In another embodiment, the WTRU may be configured to determine whether a transport block is correctly decoded based on a channel quality information (CQI) report. For example, two WTRUs communicating in unicast mode may be configured to send CQI reports to each other. If the CSI resource configuration associated with the CQI report is quasi-co-located with the data resources used for data transmission, the WTRU transmitting the HARQ feedback may discard the HARQ feedback and transmit the CQI report. If the WTRU expecting the feedback receives the CQI report, the WTRU may therefore determine that implicit feedback is sent.

[0166] Figure 6 600 is a flow chart illustrating SCI transmission, data transmission, and HARQ feedback reception for sidelink communication. In one embodiment, the WTRU may receive 602 a mapping rule from the network indicating a HARQ feedback characteristic to be adopted for a given QoS level and channel load. The WTRU may determine 604 the QoS level of the data buffered for transmission. The WTRU may also determine 606 the channel load of the channel. The determination may be performed via sensing 608 or via channel measurement 610. Based on the QoS level of the buffered data, the channel load, and the mapping rule, the WTRU may determine 612 the HARQ feedback characteristic. The WTRU may transmit 614 an SCI indicating the HARQ feedback characteristic to another WTRU. The WTRU may then transmit 616 some or all of the buffered data to the other WTRU on the resources indicated by the SCI. Feedback regarding the data transmission may be received 618 from the other WTRU in a HARQ feedback format corresponding to the HARQ feedback characteristic.

[0167] V2X has been discussed in the context of various wireless technologies, including, for example, 5G, Long Term Evolution (LTE), and New Radio (NR). For example, vehicle blocking scenarios for 5G V2X have been examined. Vehicle blocking may result in a reduction in signal strength, especially for high carrier frequencies (e.g., above 6 GHz). To mitigate the reduction in signal strength, vehicle blocking may be considered a separate state in addition to line-of-sight and non-line-of-sight states.

[0168] In LTE V2X, a vehicle may be in transmission mode 3 or transmission mode 4. A mode 3 user or vehicle may directly use resources allocated by a base station for sidelink communications between vehicles or, for example, between a vehicle and a pedestrian. A mode 4 user may obtain a list of candidate resources allocated by a base station and may select resources for sidelink communications from the candidate resources. In NR V2X, a mode 1 user may be similar to a mode 3 user of LTE V2X, and in NR V2X, a mode 2 user may include a mode 4 user. As used herein, the terms user and wireless transmit / receive unit (WTRU) may be used interchangeably and may refer to a vehicle or a user of a vehicle.

[0169] In LTE, downlink control information (DCI) format 5A and several sidelink control information (SCI) format 1 fields can be used to schedule the physical sidelink shared channel (PSSCH). The payload of DCI format 5A includes carrier indicator bits (e.g., 3 bits), the lowest index bit of the subchannel assignment to the initial transmission (e.g., bits), SCI format 1 field (including frequency resource locations for initial transmission and retransmission and time gap between initial transmission and retransmission), and sidelink index (e.g., 2 bits, which is only present in the case of time division duplex (TDD) operation with uplink-downlink configurations 0-6). When the format 5A cyclic redundancy check (CRC) is scrambled with the sidelink SPS V2X radio network temporary identifier (SL-SPS-V-RNTI), the following fields may be present: sidelink SPS configuration index (e.g., 3 bits) and activation / release indication (e.g., 1 bit).

[0170] If the number of information bits in format 5A mapped to a given search space is less than the payload size of format 0 mapped to the same search space, zeros may be appended to format 5A until the payload size is equal to the payload size of format 0 including any padding bits appended to format 0; in addition, if format 5A CRC is scrambled by SL-V-RNTI and the number of information bits in format 5A mapped to the given search space is less than the payload size of format 5A mapped to the same search space with a CRC scrambled by SL-SPS-V-RNTI, and format 0 is not defined on the same search space, zeros may be appended to format 5A until the payload size is equal to the payload size of format 5A with a CRC scrambled by SL-SPS-V-RNTI.

[0171] In LTE, SCI format 1 can be used to schedule PSSCH. The payload of SCI format 1 can include: priority bits (e.g., 3 bits), resource reservation bits (e.g., 4 bits), frequency resource locations for initial transmission and retransmission The time gap between the initial transmission and the retransmission (e.g., 4 bits), the modulation and coding scheme (e.g., 5 bits), and the retransmission index (e.g., 1 bit). Reserved information bits may be added until the size of SCI format 1 is equal to 32 bits. The reserved bits may be set to zero.

[0172] In LTE, resource selection for a Mode 4 WTRU may include determining a transmission window between [n+T1, n+T2] by selecting appropriate T1 and T2 values ​​based on latency requirements. x,y denoted by , and the candidate resource set may be denoted by S. The candidate resource set may be determined by sensing a received signal strength indicator (RSSI). The total number of candidate resources is M total The set S may be determined from the S based on the RSRP levels of the candidate resources. A Specifically, if a candidate resource in S has an RSRP level above a certain threshold, it is saved to S A If the resource R x,y If there is a conflict with its own transmission or other WTRU's reserved resources (e.g., mode 3 reserved resources), then the candidate resource set S A Remove the resource R x,y If S A The number of remaining candidate resources in is no more than 0.2*M total , the set S can be determined again based on the RSRP level of the candidate resources using a smaller threshold A Otherwise, the resource set S can be selected based on the average received signal strength indication (RSSI) value over the past several time slots.A Ranked in the top 0.2*M total resources (e.g., S B ) can be reported to higher layers for final resource selection.

[0173] In LTE V2X, the sidelink may be broadcast and therefore feedback may not be required. However, in NR V2X, the sidelink may be unicast or multicast and therefore feedback is required, for example to achieve more reliable transmission and / or higher spectral efficiency for given channel conditions. The feedback may include, for example, HARQ-ACK information, CQI, and multiple-input multiple-output (MIMO) related parameters (e.g., precoding matrix indicator (PMI) and / or rank indicator (RI)). The embodiments described herein may define resources and / or resource pools for transmitting such required feedback information, provide corresponding acquisition schemes, provide content of the feedback, and provide processes for feedback channels. For the multicast sidelink, a sharing mechanism for feedback resources among all group members is also described.

[0174] For NR unicast or multicast side links, HARQ-ACK or CSI feedback may be required to ensure reliable transmission or retransmission. The feedback information may include HARQ-ACK, CSI or other information. The resources used for feedback may have various relationships with the resources used for control and / or data transmission. Here, the control information may refer to the SCI sent on the physical sidelink control channel (PSCCH).

[0175] One option for the feedback resource may be to use an exception resource pool. In LTE V2X, under certain special conditions, for example, when T310 or T311 is running, an exception resource pool is designed for sidelink data transmission. For NR V2X, the exception resource pool may be used to transmit feedback.

[0176] Another option for the feedback resource may be to use a new resource pool. The feedback resource pool may be associated with a resource pool used for data transmission, or may be associated with a set of resource pools used for data transmission.

[0177] Figure 7 is a diagram of example dedicated and shared resource pools for feedback. Figure 7 The left hand side 700 of FIG. 1 shows an example where a resource pool, namely resource pool 1 702 for scheduling assignments (SA) and data, has an associated and dedicated feedback resource pool 704. Another resource pool for SA and data resources, namely resource pool 2 706, is also shown, which has an associated and dedicated feedback resource pool 708. The association relationship between the resource pool and the feedback resource pool can be defined in one or more resource pool configurations. Figure 7Another example is shown on the right side 720 where resource pool 1 722 and resource pool 2 724 share a common feedback resource pool 726 .

[0178] Separating the feedback resource pool from the resource pool used for data transmission may allow for an optimal design of the feedback resource pool, which may be tailored to the content and process of the feedback information. However, this may require the WTRU to have the ability to dynamically switch between different pools.

[0179] Each resource in the feedback resource pool may have a different size in frequency and time domain than the resources in the pool used for data transmission. A single resource size suitable for the feedback information (e.g., HARQ-ACK bits) format may be applied. For example, an NR physical uplink control channel (PUCCH) format for one or two HARQ-ACK bits may be applied.

[0180] A subset of NR PUCCH formats can be reused for sidelink unicast, and another subset of NR PUCCH formats can be reused for sidelink multicast. The selection of NR PUCCH formats for the sidelink may depend on the data quality of service (QoS) requirements, which may include latency, reliability, and priority. For example, for data with low latency requirements, NR PUCCH formats 0 or 2 can be reused because they occupy 1 to 2 orthogonal frequency division multiplexing (OFDM) symbols and resource selection for them can be easily implemented. For data with high reliability requirements and relaxed latency requirements, NR PUCCH formats 1 or 3 can be reused. Table 3 shows an example of HARQ feedback format selection criteria.

[0181] Another option for the feedback resource may be that the resource pool for feedback is a separate region in the resource pool for data transmission. Each feedback resource in the separate resource pool region may be associated with a resource for data transmission or may not be associated with a resource for data transmission. For example, if the resource for data transmission is selected as time t and starting subchannel n, the corresponding feedback resource in the resource pool region for feedback may be selected at time t+t offset At n+n, and the starting subchannel can be offst Here, the value t offset and n offset It may be fixed or configured, or the value may be indicated in the SCI for initial data transmission.Here, each subchannel of the feedback resource may be smaller in the number of subcarriers than the number of subcarriers of the SA or data resource.

[0182] Figure 8 is a diagram of an example feedback resource, where the resource is FDM or TDM multiplexed with SA or data resources. Figure 88, the example on the left hand side 800 shows resource pool 1 802 and resource pool 2 804 with specific feedback areas, where feedback resources are FDM multiplexed with SA or data resources. In the top diagram 802 of the left hand side 800, all feedback resources can be concentrated in a specific frequency domain area. In the bottom diagram 804 of the left hand side 800, each feedback resource can be adjacent to an SA or data resource in the frequency domain. In this case, the SA or data resource and the feedback resource can be considered as a mixed resource. Figure 8 The example on the right hand side 820 of FIG. 1 shows some examples where resource pools (e.g., resource pool 1 822 and resource pool 2 824) have examples of specific feedback regions in which feedback resources are TDM multiplexed with SA or data resources. In the time domain, each single (resource pool 2 824) or multiple (resource pool 1 822) SA or data resources may be allocated consecutively before a single or multiple feedback resources.

[0183] Since the feedback resource area may be used only for unicast or multicast but not for broadcast, the number of feedback resources may be smaller than the number of SA or data resources.

[0184] Fig.9A is a diagram of example feedback resources, where the resources are FDM or TDM multiplexed with SA or data resources. In the example shown, fewer feedback resources are used than SA or data resources. Fig.9A On the left hand side 900 of FIG. 1 , resource pool 1 902 and resource pool 2 904 show FDM multiplexed feedback resources. As can be seen from resource pool 1, all feedback resources are configured to occupy a different frequency than the resources used for data. In resource pool 2 904, the feedback resources are interspersed in frequency with the frequencies of the data resources or interleaved with the data resources. Resource pool 2 904 also has a TDM multiplexing component, i.e., the feedback resources vary in time. Fig.9A In the resource pool 922 on the right hand side 920, feedback resources are TDM and FDM multiplexed with data resources.

[0185] Fig. 9B 940 is a diagram of example feedback resources 940, where the resources are TDM multiplexed with control or data resources. In resource pool 1 942, feedback resources are configured at the end of every other time slot in time. In resource pool 2 944, feedback resources are configured at the end of each time slot. Feedback resources can span all symbols of a time slot, or a portion of symbols, etc.

[0186] Different schemes for SA or data resources and feedback resources can be configured via radio resource control (RRC) signaling. This semi-static resource configuration method can be adapted to data types and QoS requirements. For example, during a specific time period and / or in a specific area, unicast data or multicast data can dominate, and more feedback resources can be assigned. For another time and / or in another area, broadcast data can be dominant, and fewer feedback resources can be assigned. This flexibility can promote resource utilization.

[0187] Each SA or data resource may have a fixed association with a feedback resource. Alternatively, such an association between SA or data resources and feedback resources may be dynamically indicated in the SCI, or may be semi-statically configured via RRC signaling in one or more resource pool configurations.

[0188]

[00136] In NR V2X sidelink multicast, when a transmitting WTRU sends multicast data, it may expect each receiving group member to send HARQ-ACK feedback. Group-based HARQ-ACK feedback may require more than one feedback resource. The selected feedback resource may be a function of the HARQ characteristics indicated to the receiving WTRU. The WTRU may send multicast data and may expect feedback to be returned in a format corresponding to Table 3 in the example. Each WTRU may send feedback in the format already indicated in the SCI. Feedback may be received from the WTRU in the same format or in a different format.

[0189] Some or all group members may share a common feedback resource and feedback may be multiplexed in different feedback formats based on the HARQ characteristics. If all of the receiving WTRUs send their HARQ-ACK feedback in the common feedback resource, for example in a given time slot, each receiving WTRU may not be aware of the feedback of other receiving WTRUs due to half-duplex constraints. However, not receiving feedback from other WTRUs may not pose a substantial problem to the receiving WTRUs, and sharing the common feedback resource by some or all receiving WTRUs in the group may have the advantage of saving resources. The selection of the common feedback resource may be a function of one or more indicated HARQ characteristics.

[0190] In one example of resource sharing, the transmission of HARQ feedback from a group of WTRUs may be in the form of FDM. Each group member may be assigned a sub-resource for its HARQ feedback. The assignment of sub-resources to WTRUs may depend on the ID of the WTRUs in the group, or may depend on the RNTI of the WTRUs. For example, the jth sub-resource may be assigned to the jth member of the group.

[0191] Fig.101000 is a diagram of a time slot 1002 where a single feedback resource is shared by a group of WTRUs. In this example, each WTRU has its own associated subcarrier. Fig.10 , a single feedback resource is a time slot 1002 that spans multiple subchannels 1004. In one example, an ACK-NACK 1006 for group member 1 is sent on the first subchannel; an ACK-NACK 1008 for group member j is sent on the jth subchannel; and in one example, an ACK-NACK 1010 for group member n is sent on the nth subchannel.

[0192] Another way of sharing the resources may be performed such that symbols containing HARQ information of group members may be interleaved on the feedback resources (in subcarriers). Different group members may have different starting subcarriers for the same interleaving operation. The starting subcarrier for group members may depend on the WTRU's ID or Radio Network Temporary Identifier (RNTI). Frequency hopping may also be applied if the feedback spans several symbols.

[0193] In another example of resource sharing, the transmission of HARQ feedback from a group of WTRUs may be in the form of TDM. Each group member may be assigned one or more OFDM symbols in the feedback resource for its HARQ feedback. The assignment of symbols in the resource to the WTRUs may depend on the ID of the WTRU in the group or its RNTI. For example, the jth group member may be assigned the jth symbol unit in the feedback resource.

[0194] Fig.11 is a diagram 1100 of an example of a single feedback resource shared by a group of WTRUs, where each WTRU has its own associated OFDM symbol(s). For example, NR PUCCH format 2 consists of 1 or 2 OFDM symbols, where there is no user multiplexing on the same time resource. Fig.11 In the illustrated diagram 1100, multiple ACK-NACKs may be sent in a slot 1102 comprised of multiple subchannels 1104. An ACK-NACK 1106 for group member 1 may be sent in the first OFDM symbol of slot 1102. An ACK-NACK 1008 for group member j may be sent in the jth subsequent OFDM symbol. An ACK-NACK 1110 for group member n may be sent in the nth OFDM symbol. In an embodiment, the ACK-NACKs for group members may span multiple symbols. The symbol configuration and group member ordering may be a function of the HARQ characteristics indicated in the SCI.

[0195] In another example of resource sharing, the transmission of HARQ feedback from a WTRU group may be in the form of CDM. Different codes or sequences may be used for different group members for their HARQ transmissions. The code or sequence may be associated with the ID or RNTI of the WTRU in the group. For example, PUCCH format 0 is based on orthogonal sequences, and user multiplexing on the same resources is possible. TDM, FDM or CDM schemes may be applied jointly.

[0196] In each of the examples shown, the allocation of sub-resources for feedback for each WTRU may be associated with the ID of the WTRU in the group or the RNTI of the WTRU. On the other hand, the assignment of WTRU feedback to certain sub-resources may be determined by the transmitting WTRU and may be signaled to the receiving WTRU in the transmitted SCI. The dynamic signaling may be based on some configured feedback resource assignment rules.

[0197] Retransmissions may occur in the event that some group members did not decode the data in the initial transmission. For retransmissions, the WTRU that decoded the data in the initial or previous transmission may not need to send feedback for the retransmission. Only the WTRU that did not decode the data in the initial or previous transmission may need to send feedback for the retransmission. In this way, the WTRU may send at most a single ACK for each data transmission. The transmitting WTRU may only need to count the total number of ACKs it receives for each data transmission. If the total number of ACKs is equal to the group size minus 1, it may stop retransmitting. Otherwise, it may continue retransmitting. The transmitting WTRU may not need to identify which WTRU did not decode the data in which (re)transmission.

[0198] Each group member may or may not send ACK or NACK feedback for one or more data transmissions. In one embodiment, the WTRU may use ACK or NACK, which may be set as a default. For example, in the case where ACK is set as a default, if the WTRU decodes the data, the WTRU may not need to send any feedback bits. The WTRU may only feedback NACK when it has not decoded the data. For another example, in the case where NACK is set as a default, if the WTRU has not decoded the data, the WTRU may not need to send any feedback bits. The WTRU may only feedback ACK when it has decoded the data.

[0199] In a multicast sidelink with feedback, the transmitting WTRU may or may not retransmit the same TB based on the group HARQ-ACK feedback. In general, the transmitting WTRU may retransmit when all receiving WTRUs feed back NACK, or may not retransmit when all receiving WTRUs feed back ACK. If some WTRUs feed back ACK and other WTRUs feed back NACK, the transmitting WTRU may or may not retransmit the same transport block (TB). Assume that the percentage of NACKs in the transmission is P. If P>Thre, the WTRU may retransmit the data. Otherwise, the WTRU may not retransmit the data. The value of Thre may depend on the data QoS. For example, one or more of the following parameters may be considered when determining retransmission: reliability, priority, and latency. With respect to reliability, the threshold may be lower for data with higher reliability requirements and higher for data with lower reliability requirements. With respect to priority, the threshold may be lower for data with higher priority and higher for data with lower priority. Regarding latency, the threshold may be higher for data with lower latency requirements and lower for data with higher latency requirements.In case of one or several NACK feedbacks, the transmitting WTRU may even apply unicast transmission for the corresponding receiving WTRU.

[0200] Fig.12 1200 is a flow chart of an example NR Mode 2 WTRU process for resource selection and sidelink data transmission. When a Mode 2 WTRU has some sidelink data to send, it may first check if the data is for broadcast 1202, which does not require any HARQ feedback from a receiving WTRU. If the data is for broadcast, the WTRU performs 1204 a resource selection process and sends 1206 the sidelink data in the selected resources, such as in LTE V2X. If the data is not for broadcast, but for groupcast or unicast, which may require some HARQ feedback from a receiving WTRU, the transmitting WTRU may first determine 1208 the number of group members to which HARQ feedback may be sent. Based on this number, it may determine the resource size for HARQ feedback. It may then perform resource selection 1210 for both data and HARQ feedback. The WTRU may send 1212 the sidelink data and receive HARQ 1214 from the selected feedback resources. If necessary, the WTRU may schedule 1216 a retransmission of the data. The transmitting WTRU may indicate the HARQ characteristics to use for data retransmission.

[0201] The resources used for SA or data transmission and the resources used for feedback transmission may be in different resource pools or in different regions within the same resource pool. Therefore, the resource selection process for different resource pools or different regions within the same resource pool may be independent. The resource selection window for feedback resources may be delayed for a period of time from the resource selection window for data resources. The delay value may depend on the decoding and processing capabilities of the receiving WTRU. For example, if the resource selection window for SA or data resources is set to [n+T1,n+T2], the resource selection window for feedback resources may be set to [n+T1+T2]. 1,offset ,n+T2+T 2,offset ], where T 1,offset and T 2,offset It may be fixed, configured based on WTRU capabilities / classification, or depend on the WTRU implementation.

[0202] Although the resource selection process for SA or data and for feedback may be performed independently, the final decision on the resources for data and the resources for HARQ feedback should be made jointly. This is to avoid the selected HARQ resources being before the selected data resources, or the selected HARQ resources being very close to the selected data resources so that the receiving WTRU can generate HARQ feedback within this short processing window.

[0203] When the resources for SA or data and feedback are determined, the Mode 2 WTRU may send sidelink SA or data on the selected resources. The SCI information may include an indication of both the SA or data resources and the feedback resources. The transmitting WTRU may then receive HARQ from the selected HARQ resources and may schedule data retransmissions if necessary.

[0204] The resource selection process for SA or data transmission and feedback transmission may be related. If the SA or data resource and the feedback resource follow a certain pattern, the scheme may be applicable. For example, the selected feedback resource may have to be 4 time slots after the selected data resource. Based on a given pattern, a pair of resources for SA or data and feedback should be identified together. In this case, the SCI may not indicate the location of the feedback resource, or may only indicate reduced information for the feedback resource.

[0205] Fig.131300 is a flow chart of an example WTRU process for receiving a sidelink data transmission and / or sending feedback. The receiving WTRU may first receive an SCI 1302 indicating HARQ feedback characteristics. Based on the SCI, it may find resources for data transmission, or alternatively, may find resources for feedback transmission for unicast or multicast. The receiving WTRU may then decode 1304 the PSSCH. If the data is determined to be broadcast data 1306, the receiving WTRU may take no further action 1308. Otherwise 1310, it may need to determine 1312 feedback resources. The feedback resources may be indicated in the received SCI, or the WTRU may be configured to follow a pattern based on the resources used for SA or data transmission. In addition, for multicast, the receiving WTRU may determine the sub-resources used for its feedback. The receiving WTRU may send 1314 the feedback on its assigned (sub-)resources.

[0206] In NR V2X, the gNB schedules resources for Mode 1 WTRUs. The scheduling can be dynamic or semi-persistent (i.e., SPS scheduling). The SPS scheduling can be activated or deactivated by DCI.

[0207] In LTE V2X, the SPS scheduling is only used for data transmission, because in the case of broadcast sidelink transmission, feedback is not required. In NR V2X, unicast and multicast sidelinks are supported. In order to facilitate SPS scheduling for unicast or multicast sidelink transmission, a new SPS configuration can be provided, which includes both SA / data resources and feedback resources for unicast or multicast sidelink transmission. In the configured SPS resources, the periodicity of the feedback resources can be the same as the periodicity of the SA / data resources. This can ensure that each data transmission is associated with ACK / NACK feedback.

[0208] Fig.14 is a diagram of example SPS configurations 1400, 1420 having both SA or data resources and feedback resources. Fig.14 The top SPS configuration 1400 shows that the periodicity of the feedback resources is the same as the periodicity of the SA or data resources. In this example, the regions of resources 1402-1408 for SA / data transmission are each followed by resources 1410-1416 for feedback transmission.

[0209] Alternatively, the periodicity of the feedback resource may be greater than the periodicity of the data transmission resource. The scheme may be supported by cascaded ACK / NACK bits in a single feedback resource for multiple TBs, wherein the multiple TBs are sent on several semi-persistent resources. This is shown in the bottom example SPS configuration 1420. As shown in the example SPS configuration 1420, feedback resources 1430, 1432 are not always closely followed by SA / data 1422-1428. Resource 1432 follows resource 1426 and resource 1428.

[0210] In addition to the periodicity of the feedback resource, it may be necessary to specify the initial feedback resource location. This may take the form of a relative time and frequency offset between the data resource and the feedback resource. Other methods of indicating the feedback resource are also possible.

[0211] In another example, two associated SPS configurations may be configured separately. One SPS configuration may be designed for data transmission, and another SPS configuration may be designed for feedback transmission. This configuration may have the following advantages: for broadcast services, only one SPS configuration is activated or deactivated. For unicast or multicast services, two SPS configurations may be activated or deactivated. Therefore, the DCI format may include activating or deactivating two or more SPS configurations simultaneously.

[0212] Considering the feedback resources, the above SPS configuration can be mainly used for NR mode 1 users. For NR mode 2 users, a type 1 configuration of the permission configuration can be used, which can be completely configured by RRC without layer 1 activation / deactivation. These two separate configurations (one for data transmission and one for feedback) can be applied to the type 1 configuration of the permission configuration.

[0213] For NR downlink transmission, the feedback may contain one or more HARQ-ACK bits and a 4-bit CQI, where the CQI table used may contain 16 entries. The feedback CQI index is useful for downlink data transmission when selecting or adjusting the MCS index. Link adaptation may not be present in LTE V2X sidelink transmission.

[0214] In NR V2X with unicast or multicast sidelink transmission, the HARQ-ACK bit can be fed back together with the compact CQI. Instead of a 4-bit CQI for a given CQI table, a 1-bit compact CQI can be used to indicate an increase or decrease in the CQI index relative to the MCS index used for data transmission. For example, a bit "0" can indicate a decrease in the CQI index relative to the MCS index used, while a bit "1" can indicate an increase in the CQI index relative to the MCS index used. The decrease in the CQI index may mean that the channel conditions are poor and the coding rate or modulation order needs to be reduced to maintain the BLER level. The increase in the CQI index may mean that the channel conditions are good, and the coding rate or modulation order can be increased to achieve higher spectral efficiency. The step size of the increase or decrease on the MCS table can be "1" each time, or it can be performed using other values.

[0215] Alternatively, a 2-bit CQI adjustment may be used to indicate an increase or decrease or maintenance of a CQI index relative to an MCS index for data transmission. For example, a bit "00" may indicate a decrease in a CQI index, a bit "01" may indicate maintenance of a current CQI index, and a bit "10" may indicate an increase in a CQI index.

[0216] The compact CQI index may be used in conjunction with the ACK / NACK bit. For example, an increase in the CQI may occur only when the current data is successfully decoded or the current transmission is acknowledged (ACK-ed). A decrease in the CQI may occur only when the current data is not decoded or the current transmission is negatively acknowledged (NACK-ed). The maintenance of the current CQI index may be performed for the ACK or NACK of the current transmission.

[0217] Therefore, two levels of HARQ-ACK are defined: ACK with an increased CQI / MCS index and ACK with the current CQI / MCS index. In the case where the TB is successfully decoded (i.e., ACK), the receiving WTRU can measure how much more spectral efficiency it can achieve. The determination between these two HARQ-ACK levels may depend on the channel estimate. For example, the channel estimate may indicate that the current channel is much better than the current MCS level. The determination between these two HARQ-ACK levels may also depend on the decoding complexity. For example, the number of iterations in low-density parity check (LDPC) decoding may be less than a certain value, and the receiving WTRU may think that the MCS index can be increased. Otherwise, the receiving WTRU may think that the MCS index should be maintained. All of these conditions may occur when the decoding of the current data is successful (i.e., ACK).

[0218] Similarly, two levels of HARQ-NACK are defined: NACK with current MCS index and NACK with reduced MCS index. If the WTRU fails to decode a TB (i.e., NACK), the receiving WTRU may measure how far it is from successful data decoding. This may depend on the channel estimation or LDPC decoding complexity.

[0219] The two-stage HARQ-ACK and two-stage HARQ-NACK may be as shown in Table 4. Table 4: Example joint HARQ-ACK and compact CQI feedback indication

[0220] Based on the above scheme, 2-bit ACK / NACK and compact CQI can be used for the feedback. The transmitter can have link adaptation based on the feedback. For unicast sidelink communication, the transmitter can simply adjust the MCS for the next transmission, for example, if the next transmission occurs within a time period from the feedback. This may be because if the time gap between the feedback and the next transmission is long, the feedback information may no longer be valid due to channel changes.

[0221] For multicast sidelink communications with feedback, the transmitter may have certain rules to adjust the MCS level. For example, if more than a certain number / percentage of receiving WTRUs decode the data and request an increase in the MCS level, the transmitting WTRU may increase the MCS level for the next transmission. If a certain number / percentage of receiving WTRUs cannot successfully decode the data, the transmitting WTRU may decrease the MCS level for the next transmission. If a certain number / percentage of receiving WTRUs cannot decode the data and request a decrease in the MCS level, the transmitting WTRU may decrease the MCS level for the next transmission.

[0222] Based on Table 4, the transmitting WTRU may adjust its MCS level as follows: If the percentage of "11" or "01" > Thres_1 or the percentage of "11" > Thres_2, then Increase the MCS level for the next transmission Otherwise if the percentage of "00" or "01" > Thres_3 or the percentage of "00" > Thres_4, then reduce the MCS level for the next transmission otherwise The MCS level is maintained for the next transmission.

[0223] The above decision rules may also be applied to independent ACK / NACK and CQI feedback. Based on the CQI feedback received from all group members, the transmitting WTRU may decide whether to increase, decrease, or maintain the MCS level for future data transmission. The MCS for its future data transmission may be set to: the average CQI index of all fed-back CQI indices, a particular percentile of reported CQI indices, an increased CQI index (for one or more steps) if more than a certain percentage of reported CQI indices are greater than the current MCS index, a decreased CQI index (for one or more steps) if more than a certain percentage of reported CQI indices are lower than the current MCS index, or otherwise the current MCS index. In the case where the MCS for future data transmission is set to a certain percentage of reported CQI indices, for example, for data at a reliability level of 99%, the transmitting WTRU may set the MCS to the highest CQI index of the 90% of the reported CQI indices, and for data at a reliability level of 99.99%, the transmitting WTRU may set the MCS to the highest CQI index of the 95% of the reported CQI indices. In case the CQI index is increased or decreased, the step size of the CQI index increase / decrease may also depend on the data QoS.

[0224] The density of one or more reference signals used for sidelink transmissions, such as a demodulation reference signal (DMRS) or a phase tracking reference signal (PTRS), may be dynamically adjusted. The reference signal density may be controlled by the transmitting WTRU. However, the receiving WTRU may feed back its desired reference signal pattern to the transmitting WTRU.

[0225] If a list of reference signal patterns (RSPs) is provided and ordered based on density, the receiving WTRU may feedback the index of a specific RSP. Otherwise, it may compress the index information and only feedback an increase, decrease, or maintain of the current RSP index. In this case, only 2 bits may be required.

[0226] The compact RSP index may be combined with the HARQ-ACK bit. For example, the reduction of the RSP index may occur only when the current data is successfully decoded or confirmed in the current data transmission. The increase of the RSP index may occur only when the current data is not decoded or the current transmission is not confirmed. The maintenance of the current RSP index may occur in the current transmission being confirmed or negatively confirmed. In this way, only 2 bits may still be needed for both the HARQ-ACK and the RSP index.

[0227] For the multicast side link, the transmitting WTRU may adjust the RSP based on statistics of group feedback with an increase, decrease or maintenance of the current RSP index.Similar rules as the link adaptation scheme described above may be used for RSP adaptation.

[0228] Other feedback parameters, such as power control related parameters, may also be included for reliable transmission. These parameters may be encoded jointly or separately with HARQ-ACK, CQI and / or RSP.

[0229] For the multicast side link, the group leader may reserve a set of resources for the entire group. Each group member may use the reserved resources for group communications. For a vehicle platoon, the platoon leader may reserve SPS resources for the entire group. These SPS resources may also include feedback resources as described. Alternatively, the vehicle platoon leader may be an NR Mode 2 WTRU, which may select and reserve periodic resources for the entire group.

[0230] It may be necessary to notify all group members of the reservation. The use of the reserved resources may be controlled by the group leader, or may be distributed among group members.

[0231] For the case of centralized control, the group leader may inform each group member which resource is assigned to it for its transmission. Scheduling based on the group leader may be signaled semi-statically and may depend on the needs of the group transmission.

[0232] For example, the group leader may be the first vehicle in the vehicle train and may have the best view of the road conditions ahead. Therefore, it may occupy the largest percentage of all reserved resources among all vehicles in the vehicle train. On the other hand, the last vehicle in the vehicle train may observe the road conditions behind and, therefore, may occupy the second largest percentage of the total reserved resources among all vehicles in the vehicle train. If a group member in the vehicle train is a truck or bus, it may have a better view than other group members. It may occupy the third largest percentage of the total reserved resources. It is possible for the group leader to configure several group communication resource usage modes. The selection among these resource usage modes may then be dynamically indicated by the group leader, for example, via the SCI.

[0233] Each group member may be assigned a separate period for its multicast. For example, the assignment may be obtained from the group leader based on the location or type of each group member or based on the needs of each group member. It may further be adjusted by the group leader based on the request of each group member. For example, if a group member believes that it needs more resources for transmission, it may indicate it to the group leader. The indication may be included or indicated in the SCI or the data it transmits.

[0234] Fig.15 1500 is a diagram of an example group resource allocation 1500, where different group members have different resource allocations. In this example, a group reserved time period 1502 is indicated. Group leader WTRU 1 occupies a time period 1512 equal to half of the reserved group resources 1504-1542. WTRU 2, which may be the last vehicle in the queue of vehicles, occupies a time period 1506 equal to one-quarter of the reserved group resources. WTRU 3 and WTRU 4, which may be in the middle of the queue, may occupy one-eighth of the reserved group resources, i.e., WTRU 3 is configured with time period 1508 and WTRU 4 is configured with time period 1510. Other options for reserved time periods may apply. In an embodiment, a queue may occupy more or fewer WTRUs.

[0235] like Fig.15 As shown, WTRU 1 may transmit on resources 1512, 1516, 1520, 1524, 1528, 1532, 1536, and 1540. WTRU 2 may transmit on resources 1514, 1522, 1530, and 1538. WTRU 3 may transmit on resources 1518 and 1534. WTRU 4 may transmit on resources 1526 and 1542.

[0236] HARQ-ACK feedback may also be supported for unicast sidelink transmissions. For sidelink multicast transmissions, the feedback may be activated or not. This is because all group members may need to send HARQ-ACK feedback, which may occupy a large amount of feedback resources. In addition, the transmission of feedback from group members may disable their monitoring and sensing of the channel, which may limit resource access in the NR Mode 2 sensing and resource selection process. Therefore, an optimal design for feedback for multicast sidelink transmissions may be desired.

[0237] Under certain conditions, feedback may be required for multicast side link transmission, while under other conditions, feedback may not be required for multicast side link transmission. These conditions may be related to data QoS and other factors. For data with high reliability requirements, feedback for group communication may be required. This feedback may trigger the retransmission of lost data to certain receiving WTRUs, thereby enhancing transmission reliability. For data with low latency requirements, feedback for group communication may not be required. This may be because the delay caused by the HARQ-ACK feedback from all group members and subsequent retransmissions may have exceeded the latency requirement. For data with low latency requirements in group communication, HARQ-free repetition can be directly applied to ensure reliable data transmission. For data with high priority, feedback for group communication may be required. This is because the data is important to the receiver, and although it takes up more resources and causes large delays, group feedback may still be necessary to match the importance of the data.

[0238] For groups with a small number of members, feedback for group communication may be required. This is because the resources for feedback may be limited and the impact of the feedback may be limited. For groups of vehicles with high speeds, feedback for group communication may be required. This can mitigate the impact of rapidly changing channel conditions. In an embodiment, retransmissions may be performed to select members of the group.

[0239] The activation or deactivation of feedback in group communications may need to be signaled so that the receiving WTRU knows whether to send HARQ feedback and the transmitting WTRU knows whether to receive HARQ feedback.

[0240] An indication of optional feedback may be provided in a semi-static manner, for example, using an RRC configuration. For example, the configuration may specify that group feedback is required if the data reliability requirement is greater than a threshold, the data latency requirement is greater than a threshold, the data priority level is less than a threshold, the number of group members is greater than a threshold, and / or the vehicle speed is greater than a threshold. Otherwise, group feedback is not required. Therefore, it may be assumed that the data reliability, latency and priority levels, number of group members, and vehicle speed are known to the receiving WTRU. This information may be provided in the SCI or may be provided to the receiving WTRU at a higher layer.

[0241] In an embodiment, HARQ feedback may be enabled or disabled based on data latency requirement(s), data reliability requirement(s), one or more group sizes, and / or the speed or velocity of travel of the vehicle or other vehicles within the group. For example, the speed may be determined based on the transmitter or receiver speed. The speed may be determined based on the speed at which the transmitter and receiver are accelerating toward or away from each other.

[0242] One way to indicate whether a groupcast requires feedback is by using a group ID. For a certain range of group IDs, the feedback may be assumed, while for other ranges of group IDs, the feedback may not be assumed. Group ID assignment may occur during the process of group establishment. During the group establishment process, the group leader may know the group type, such as vehicle platooning, sensor information sharing, and / or maximum group size. Typically, for groups with relatively dynamic shaping (e.g., sensor information sharing) and / or large group sizes, the group ID may be in a range that does not support feedback. For groups with relatively static shaping (e.g., vehicle platooning) and / or groups with small group sizes, the group ID may be in a range that supports feedback.

[0243] The indication about the optional feedback can be provided dynamically, for example, by using an SCI indication. For example, a single bit in the SCI can indicate whether group feedback is required. The indication can be combined with another field (e.g., the RV indicated in the SCI). In another example, the HARQ process ID can be associated with the feedback indication. For a unified design between multicast and unicast, the HARQ process ID can always be included in the SCI. For example, a HARQ process ID equal to a default value (e.g., a value of 0) can mean that feedback is not required. For feedback in a multicast side link, the HARQ process ID can start from 1. Other options for implicitly indicating group feedback can be associated with scrambling of control or data transmission or reference signals. For example, if one RNTI is used to scramble the control, data, or reference signal, group feedback may be required. If other RNTIs are used to scramble the control, data, or reference signal, group feedback may not be required. Another example may be that RNTI scrambling at different parts of the CRC bit can indicate whether feedback is required.

[0244] In LTE V2X, the sidelink can be broadcast without feedback. Repeated transmission of a TB can be performed by configuring the number of repetitions to 0 or 1 in the SL-PSSCH-TxParameters IE. This can support up to 1 repetition-based retransmission of the same TB.

[0245] In NR V2X, the multicast side link can have HARQ-ACK feedback enabled or not. The number of repetitions can be adjusted depending on whether HARQ-ACK feedback is supported. For example, if HARQ-ACK feedback is supported in group communication, the number of repetitions can be 0. This may be because the HARQ retransmission process has improved the reliability level. If HARQ-ACK feedback is not supported in group communication, the number of repetitions can be greater than 0.

[0246] The number of repetitions may be configured to depend on HARQ-ACK feedback. The number of repetitions may then be adjusted accordingly based on the dynamic enabling or disabling of group HARQ-ACK feedback. Alternatively, the number of repetitions may be indicated in the physical layer (e.g., via an explicit SCI indication or an implicit indication using another field of the SCI). The HARQ process ID may be included in all repeated transmissions of the same TB and set to a common value.

[0247] For sidelink unicast, the number of repetitions may be set to 0, since the HARQ-ACK scheme may always be applied. Alternatively, even if the HARQ-ACK scheme is used, the number of repetitions may be set to a number greater than 0. This may be to address some low-latency and / or high-reliability applications, where successful data delivery may be desired in the initial transmission. For example, if the data reliability requirement is very high and / or the data latency requirement is very low, a repetition scheme may be applied. Otherwise, a repetition scheme may not be applied.

[0248] Link adaptation is possible using feedback in the NR V2X sidelink unicast or multicast. The transmitting WTRU can adjust its modulation and coding rate to suit the channel conditions for retransmission or new TB transmission. This link adaptation can ensure that the BLER level reaches a given target, thereby achieving reliable transmission. On the other hand, repetitions are supported in LTE V2X (without feedback), with a maximum of 1 repetition. Although the MCS remains the same between multiple repetitions, the catch-up combining gain can increase the effective SNR and achieve reliable transmission. In NR V2X, the number of repetitions can be configurable or can be dynamically adjusted, for example based on the data QoS. The dynamic adjustment of the number of repetitions can be performed in conjunction with link adaptation. For example, if the channel conditions become worse, the MCS index can be reduced using a lower coding rate and modulation order, and / or the number of repetitions can be increased to increase the effective SNR.

[0249] When choosing between these two methods, the transmitting WTRU may evaluate the gain resulting from the number of repetitions. For example, if the WTRU increases the number of repetitions from 0 to 1, the effective SNR increases by 3dB. If the WTRU increases the number of repetitions from 1 to 2, the effective SNR increases by 1.76dB. If the WTRU increases the number of repetitions from 2 to 3, the effective SNR increases by 1.25dB.

[0250] On the other hand, the transmitting WTRU may evaluate the gain resulting from the reduction in the MCS index. This may depend on the BLER performance of the LDPC code for different MCS values ​​and TBS. It may also depend on the target BLER level or data reliability requirements.

[0251] Fig.1616 is a graph 1600 showing BLER performance of CQI entries on a tapped delay line (TDL)-A channel model with 30 ns delay spread and ideal channel estimation. The x-axis of the graph 1600 shows SNR 1602, and the y-axis represents BLER 1604. The graph 1600 shows coding rates (CR) CR30 1606, CR50 1608, CR78 1610, CR116 1612, and CR194 1614. From Fig.16 It can be seen that the reduction in the coding rate from 193 / 1024 to 30 / 1024 results in - 1 There is an 8dB increase in effective SNR at the BLER level, but this results in a 10 -5 There is an effective SNR increase of 13dB at the BLER level.When choosing between the two methods, the noise floor issue of the LDPC codes at low BLER levels should also be considered.

[0252] Generally speaking, a decrease in the MCS index can result in a higher target BLER level (e.g., 10 -1 ) than at a relatively low target BLER level (e.g., 10 -5 ) more effective SNR gain. Therefore, when the channel condition becomes worse, for data with low reliability requirements, the MCS index reduction method can be selected instead of the repetition number increase method. In addition, for data with high reliability requirements, the repetition number increase method can be selected instead of the MCS index reduction method.

[0253] Alternatively, the two methods may be used in conjunction. For example, if the channel condition becomes extremely bad, the transmitting WTRU may decrease the MCS index and increase the number of repetitions.

[0254] NR URLLC service may use two or more MCS tables. This may mean that NR V2X may also use these two or more MCS tables. Based on the CQI feedback, the transmitting WTRU may want to switch one or more MCS tables for the next transmission or for retransmission. For example, even at the maximum number of repetitions, the spectral efficiency of the current MCS table may still not be suitable for the current channel conditions. The indication about the MCS table switch may also be associated with the number of repetitions. For example, if the current transmission is based on an MCS table with high spectral efficiency entries, and if the channel conditions become worse, it is possible to switch to an MCS table with low spectral efficiency entries without repetition, because the low code rate or modulation order itself can work for poor channel conditions. Alternatively, the switch to an MCS table with lower spectral efficiency entries can be accompanied by increased repetitions to jointly achieve reliable data transmission under extremely poor channel conditions.

[0255] In one embodiment, if the percentage of NACKs is less than a threshold, the WTRU may switch to a unicast retransmission mode when retransmitting to the WTRU reporting the NACK. The specific threshold(s) selected may depend on the QoS of the initial transmission. For example, if the QoS is lower, the WTRU may retransmit again in multicast mode. However, if the QoS is higher, the WTRU may retransmit in unicast mode. Once a transmission block is acknowledged once by the receiving WTRU, the transmission block may be counted as acknowledged by the receiving WTRU, regardless of whether the receiving WTRU also successfully acknowledges subsequent retransmissions. In an embodiment, the receiving WTRU that reports the first ACK may not report subsequent ACKs when a retransmission is received.

[0256] Fig.17 1700 is a flow chart for sending data when HARQ feedback is enabled or disabled. The WTRU may receive 1702 a resource pool configuration indicating resource multiplexing for control, data and / or feedback resources. The WTRU may receive 1704 a multicast configuration including a set of rules and criteria and thresholds for determining whether to enable or disable HARQ. Enabling or disabling HARQ may be determined implicitly, for example, via a set of rules, criteria and thresholds, or explicitly via an indication (e.g., a dynamic indication), or a semi-static configuration, or via a combination of the two. The WTRU may determine 1706 that some sidelink multicast data is buffered for transmission. The WTRU may determine 1708 whether to enable or disable HARQ feedback based on the threshold received 1704, indicated, or configured. A determination 1710 may be made whether to disable HARQ feedback. If HARQ feedback is disabled, the WTRU may compile an SCI and send 1720 the SCI via the RNTI, e.g., via a CRC masked with the RNTI, a CRC scrambled with the RNTI, including the RNTI in the payload, etc., indicating that there is no HARQ feedback. Sidelink control and / or data may then be sent 1722.

[0257] If HARQ feedback is not disabled, the WTRU may send 1712 an SCI via the RNTI, e.g., via a CRC masked with the RNTI, a CRC scrambled with the RNTI, including the RNTI in the payload portion, etc., indicating that HARQ feedback is requested. The WTRU may send sidelink control information and / or data and may receive 1714 HARQ feedback in response. The WTRU may determine 1716 feedback from each receiving WTRU based on resource sharing (e.g., TDM, FDM, or CDM resource sharing) and / or an intra-WTRU group ID. Based on the received feedback, the WTRU may switch 1718 from a groupcast transmission mode to a unicast transmission mode for one or more data or control retransmissions. Some rules and / or criteria may be used to trigger the transmission mode and / or feedback mode. For example, if the percentage of NACKs is less than a threshold or the number of NACKs is less than a threshold, etc., the transmission mode and / or HARQ (retransmission) transmission mode may be triggered to switch to a unicast retransmission or to a unicast HARQ (retransmission) transmission mode for the WTRU(s) sending the NACKs. When a particular WTRU transmits a NACK above a threshold amount, the transmission mode and / or HARQ (retransmission) transmission mode may be triggered to switch to unicast retransmission or switch to unicast HARQ (retransmission) transmission mode for the WTRU(s) sending the NACK. One or more thresholds may be configured or indicated. The thresholds may be associated with QoS. For example, each threshold may be associated with one QoS or QoS set. More than one threshold may be associated with a QoS or QoS set, and so on.

[0258] When a TB is acknowledged by the receiving WTRU initially or during any retransmission, all subsequent retransmissions (one or more) of the same TB may be counted as "acknowledged" for the WTRU, regardless of the result of the subsequent HARQ feedback received. For example, even when a NACK is received for a subsequent retransmission of the HARQ for the TB, the WTRU may discard the received NACK and consider the TB to be in the "acknowledged" state.

[0259] Although the features and elements are described above in a specific combination or order, it will be recognized by those skilled in the art that each feature or element may be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware that is incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via 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, buffer memory, semiconductor storage 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 software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method performed by a wireless transmit / receive unit WTRU, the method comprising: receiving information, wherein the information is associated with hybrid automatic repeat request (HARQ) information; determining one or more characteristics based on the information; as well as A message associated with the one or more characteristics is sent.

2. The method according to claim 1, wherein: The HARQ information includes HARQ feedback.

3. The method according to claim 1, wherein: The one or more characteristics include an indication of a determination regarding whether HARQ feedback is enabled.

4. The method of claim 1, wherein the message associated with the one or more characteristics is transmitted to another WTRU.

5. The method according to claim 1, wherein: The information is received using Radio Resource Control, RRC, signaling.

6. The method according to claim 1, wherein: The information is received from a base station. The method of claim 1 , wherein the information is associated with vehicle-to-vehicle (V2V) information.

8. A wireless transmit / receive unit WTRU, the WTRU comprising a processor, the processor being configured to: receiving information, wherein the information is associated with hybrid automatic repeat request (HARQ) information; Based on the information, determining one or more characteristics; and A message associated with the one or more characteristics is sent.

9. The WTRU of claim 8, wherein the HARQ information comprises HARQ feedback.

10. The WTRU of claim 8, wherein the one or more characteristics include an indication for determining whether to enable HARQ feedback.

11. The WTRU of claim 9, wherein the message associated with the one or more characteristics is transmitted to another WTRU.

12. The WTRU of claim 8, wherein the information is received using Radio Resource Control (RRC) signaling.

13. The WTRU of claim 8, wherein the information is received from a base station.

14. The WTRU of claim 8, wherein the information is associated with vehicle-to-vehicle (V2V) information.

15. A wireless transmit / receive unit WTRU, the WTRU comprising a processor, the processor being configured to: Determine the transmission side link data; If the sidelink data is not for broadcast data, determining a number of other WTRUs to send hybrid automatic repeat request (HARQ) feedback; Identify data resources and feedback sources; sending sidelink data, the sidelink data including sidelink channel information SCI indicating the data resource and the feedback resource; and HARQ feedback associated with the selected feedback resource is received.

16. The WTRU of claim 15, wherein the processor is configured to: determining to resend the sidelink data; and The sidelink data is retransmitted with an indication of one or more HARQ characteristics.

Images