HARQ Subcodebook for Delayed HARQ Feedback

Abstract

A wireless transceiver unit (WTRU) can receive configuration information that includes at least one predefined value for at least one sidelink (SL) data characteristic. The WTRU can receive an SL grant allocation, for example, from a network. Based on the fact that at least one predefined value for at least one SL data characteristic is satisfied for the SL grant allocation, the WTRU can transmit SL hybrid HARQ information in a first HARQ mode. The first HARQ mode may include acknowledgment / denial responses. Based on the fact that at least one predefined value for at least one SL data characteristic is not satisfied for the SL grant allocation, the WTRU can transmit SL HARQ information in a second HARQ mode. The second HARQ mode may include delayed HARQ. The first HARQ mode may include a two-state HARQ mode, and / or the second HARQ mode may include a three-state HARQ mode.

Description

Background Art

[0001] Cross - reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 445,316, filed on February 14, 2023, the entire content of which is incorporated herein by reference.

[0002] Unlicensed spectrum can include frequency resources that can be freely used by different operators and, in some cases, using different wireless technologies. A transmitter can transmit on the unlicensed spectrum if channel access is successful (e.g., listen - before - talk (LBT) is successful). When LBT fails, the transmitter can back off for a certain duration and attempt to access the channel at a later opportunity. The transmitter can continue to attempt until the channel becomes idle. This procedure can cause a delay for transmission and may introduce some uncertainty as to when the transmission will be successfully delivered.

[0003] New Radio (NR) sidelinks can support two resource allocation modes: Mode 1, where the gNB is responsible for allocating resources for sidelink transmissions; and Mode 2, where the wireless transmit / receive unit (WTRU) autonomously selects resources for sidelink transmissions. In Mode 1, the WTRU can request one or more resources for sidelink data transmissions using a Buffer Status Report (BSR) in the Media Access Control (MAC) control element (CE), which indicates the logical channel group (LCG) for the requested grant. The WTRU can then receive a Downlink Control Information (DCI) scheduling sidelink grant from the gNB, which indicates a physical uplink control channel (PUCCH) resource, on which the WTRU can report the hybrid automatic repeat request (HARQ) status for the sidelink grant transmission. In Mode 2, the WTRU can autonomously select resources for transmissions using sensing techniques. [Overview of the project]

[0004] A WTRU can be configured to report one or more (e.g., two) HARQ subcodebooks, where the first HARQ subcodebook can carry two-state HARQ feedback for one or more (e.g., all) scheduled sidelink grants, and the second HARQ subcodebook can carry additional information for sidelink grants where three-state HARQ is enabled (e.g., only that). The WTRU can determine whether to use three-state HARQ-acknowledgment (ACK) or two-state HARQ-ACK for a sidelink grant. The WTRU can use legacy behavior to determine the size of the first HARQ-ACK subcodebook.

[0005] The WTRU can determine the size of the second HARQ subcodebook based on the number of sidelink grants configured using 3-state HARQ and the corresponding physical sidelink feedback channel (PSFCH) information received before the HARQ codebook transmission time. In a sidelink using 3-state HARQ, if the corresponding sidelink PSFCH showing an ACK is received from the receiver (Rx) WTRU before the HARQ codebook transmission time, the WTRU may not report any information in the second HARQ subcodebook. If the corresponding sidelink PSFCH showing a non-acknowledgement (NACK) is received from the Rx WTRU before the HARQ codebook transmission time, the WTRU may report a value of 0 in the second HARQ subcodebook. If the corresponding sidelink PSFCH is not received from the Rx WTRU before the HARQ codebook transmission time, the WTRU may report a value of 1 in the second HARQ subcodebook. The bit order in the second HARQ subcodebook can follow the order of the scheduled sidelink grants.

[0006] A WTRU can determine whether to report two HARQ subcodebooks on the same uplink resource or on separate resources, based on the gNB indication in the DCI. A WTRU can send two HARQ subcodebooks to the gNB. A WTRU can receive sidelink HARQ feedback from an Rx WTRU after a delay. A WTRU can be configured to report HARQ feedback for previously delayed HARQ feedback by using a DCI that triggers previously delayed HARQ feedback and / or by appending delayed HARQ feedback to a HARQ codebook that will be sent X ms after the initial transmission of the HARQ codebook.

[0007] A WTRU can report a group of sidelink HARQ feedbacks using one or more (e.g., two) HARQ subcodebooks, where the first HARQ subcodebook may contain two-state HARQs for one or more (e.g., all) sidelink grants in the group, and the second HARQ subcodebook may contain several sidelink grants from the group using three-state HARQs.

[0008] The WTRU can receive configuration information. The configuration information may include at least one predefined value for at least one sidelink (SL) data characteristic. The WTRU can receive sidelink (SL) grant allocations from, for example, the network. The WTRU may transmit SL hybrid HARQ information in a first HARQ mode based on, for example, that at least one predefined value for at least one SL data characteristic is met for an SL grant allocation. The first HARQ mode may include acknowledgment / non-acknowledgment (ACK / NACK). The WTRU may transmit SL HARQ information in a second HARQ mode based on, for example, that at least one predefined value for at least one SL data characteristic is not met for an SL grant allocation. The second HARQ mode may include delayed HARQ. The first HARQ mode may include a two-state HARQ mode, and / or the second HARQ mode may include a three-state HARQ mode.

[0009] A WTRU may determine, for example, whether to use a first HARQ mode and / or a second HARQ mode based on whether at least one predefined value for at least one SL data characteristic is met for an SL grant allocation. An SL data characteristic may include at least one of the following: a packet delay budget (PDB) value, a quality of service (QoS) value associated with a packet quality indicator (PQI), supported logical channels, supported slots, physical sidelink feedback channel (PSFCH) location, physical uplink (UL) control channel (PUCCH) transmission time, or an indication in downlink control information (DCI). SL HARQ information may include an indication of whether at least one SL resource is requested (for example, by a WTRU).

[0010] The WTRU can generate at least one of a first HARQ subcodebook for a first HARQ mode and / or a second HARQ subcodebook for a second HARQ mode. The first HARQ subcodebook may contain SL HARQ information, and / or the second HARQ subcodebook may contain SL HARQ information. The WTRU may decide to use the second HARQ mode and / or add one bit to the second HARQ subcodebook. The WTRU may decide to use the first HARQ mode and / or add two bits to the first HARQ subcodebook. The WTRU may receive a second SL grant allocation from the network after, for example, adding one bit to the second HARQ subcodebook and / or adding two bits to the first HARQ subcodebook. The WTRU can, for example, determine whether to transmit at least one of the first HARQ subcodebook and / or the second HARQ subcodebook based on a physical sidelink feedback channel (PSFCH) transmission.

[0011] The WTRU can generate a first HARQ subcodebook. The first HARQ subcodebook may include HARQ feedback for one or more sidelink transmissions, for example, according to a first HARQ mode. The WTRU may determine that a second HARQ mode is enabled for one or more sidelink transmissions. The WTRU can determine the size of a second HARQ subcodebook. The second HARQ subcodebook may include HARQ feedback for one or more sidelink transmissions, for example, according to a second HARQ mode. The WTRU can generate a second HARQ subcodebook. The WTRU may transmit the first HARQ subcodebook and / or the second HARQ subcodebook to a network, for example.

[0012] The first HARQ mode may include a two-state HARQ mode, and / or the second HARQ mode may include a three-state HARQ mode. The two-state HARQ mode may include acknowledgment / non-acknowledgment (ACK / NACK), and / or the three-state HARQ mode may include delayed HARQ. When a WTRU determines the size of a second HARQ subcodebook, for example, it can determine the number of subsets of one or more sidelink transmissions for which non-acknowledgment (NACK) was received or for which no response was received. Based on indications in DCI, for example, a WTRU can determine whether the first and second HARQ subcodebooks should be transmitted on the same uplink (UL) resource or on different UL resources. A WTRU can determine the size of the first HARQ subcodebook. A WTRU may receive a PSFCH transmission, for example, from another WTRU. A PSFCH transmission may include HARQ feedback. A WTRU can report HARQ feedback to the network, for example. The WTRU can determine the size of a second HARQ subcodebook based on the number of sidelink grants in a subset of one or more sidelink transmissions. The order of bits contained in the second HARQ subcodebook can be based on the order of the number of sidelink grants in a subset of one or more sidelink transmissions. [Brief explanation of the drawing]

[0013] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments are implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that can be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C]This is a system diagram showing an exemplary radio access network (RAN) and core network (CN) used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and CN that can be used in the communication system of Figure 1A according to one embodiment. [Figure 2] This is an illustrative flowchart showing the procedure for activating a 3-state HARQ. [Figure 3] This figure shows an example of using two HARQ subcodebooks. [Figure 4] This figure shows an example of a WTRU receiving a PSFCH after the transmission time of the first HARQ codebook. [Figure 5] This is an illustrative flowchart showing how WTRU determines whether it should send two HARQ subcodebooks. [Figure 6] Here is another illustrative flowchart showing how WTRU decides whether to send two HARQ subcodebooks. [Modes for carrying out the invention]

[0014] Figure 1A is a system diagram showing an exemplary 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, and broadcast to multiple radio users. The communication system 100 can enable multiple radio users to access such content through the sharing of system resources, including radio bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0015] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d may all be referred to as “stations” and / or “STAs” and may be configured to transmit and / or receive radio signals, and may include (or be) user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UEs.

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

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

[0018] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 may be any suitable radio 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).

[0019] More specifically, as described above, the communication system 100 can be a multi-connection system and can employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in RAN104 / 113, and the WTRU102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish the air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High Speed Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA can include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).

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

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

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

[0023] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, 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) for mobile communications, Enhanced Data Rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0024] In Figure 1A, base station 114b may be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones, for example), and roads. In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRU 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any small cell, picocell, or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0025] RAN104 / 113 may communicate with CN106 / 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 WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing one of the following technologies: GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0026] CN106 / 115 can also act as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 114 or a different RAT.

[0027] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which can employ cellular-based radio technology and may be configured to communicate with base station 114b which can employ IEEE 802 radio technology.

[0028] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while remaining consistent with one embodiment.

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

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

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

[0032] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0034] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 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.), a solar cell, a fuel cell, etc.

[0035] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of when signals are received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information via any preferred location determination method while remaining consistent with one embodiment.

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

[0037] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of a signal may be parallel and / or simultaneous, associated with a specific subframe for both an uplink (for transmission, for example) and a downlink (for reception, for example). The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing either through hardware (e.g., chokes) or through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU102 may include a half-duplex radio, which is for the transmission and reception of some or all of a signal (e.g., associated with a specific subframe for either an uplink (for transmission, for example) or a downlink (for reception, for example).

[0038] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0039] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining consistent with one embodiment. Each of enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, enodes B160a, 160b, and 160c can implement MIMO technology. Thus, enode B160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.

[0040] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0041] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the above elements is shown as part of CN106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the CN operator.

[0042] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0043] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0044] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0045] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and legacy landline communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0046] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0047] In a typical embodiment, the other network 112 may be a WLAN.

[0048] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with distributed systems (DSs) or other types of wired / wireless networks that carry traffic during and / or from the BSS. Traffic originating outside the BSS to the STAs may arrive through the APs and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the APs to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the APs; for example, a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS is considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (for example, all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the “ad-hoc” communication mode in this specification.

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

[0050] A high-throughput (HT) STA can use a 40MHz wide channel for communication, for example, via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0051] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, data can be passed through a segment parser that, after channel encoding, can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, entities, etc.

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

[0053] 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 the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode from among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could be available.

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

[0055] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

[0056] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while remaining consistent with one embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c can implement MIMO technology. For example, the gNB180a and 180b can utilize beamforming to transmit signals to and / or receive signals from the WTRU102a, 102b, and 102c. Thus, the gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU102a. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c can implement coordinated multi-point (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0057] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may differ for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (including, for example, a varying number of OFDM symbols and / or a varying length of absolute time that persists).

[0058] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (such as e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0060] The CN115 shown in Figure 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the above elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0061] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, mobility management, etc. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service being utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

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

[0063] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can 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, and providing mobility anchoring.

[0064] CN115 can facilitate communication with other networks. For example, CN115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a,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, WTRU102a,102b,102c may be connected to DN185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b, and an N6 interface between UPF184a,184b and local data networks (DN) 185a,185b.

[0065] In view of Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein with respect to any of the WTRU 102a to d, base stations 114a to b, e-nodes B160a to c, MME 162, SGW 164, PGW 166, gNB 180a to c, AMF 182a to b, UPF 184a to b, SMF 183a to b, DN 185a to b, and / or any other (one or more) elements / devices described herein may be implemented by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0066] Emulation devices may be designed to implement one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in a communication network. One or more emulation devices may perform one or more, or all, of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for testing purposes and / or tests may be performed using over-the-air wireless communication.

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

[0068] A gNB can allocate resources for a sidelink (SL). The gNB can schedule retransmissions (one or more) if necessary, so for example, when the gNB is allocating resources for a sidelink, it may be aware of the status of a transmission (e.g., an acknowledgment (ACK) or a negative acknowledgment (NACK)). A WTRU can send an SL Hybrid Automatic Retransmission Request (HARQ) to the gNB. For example, a Transmitter (Tx)WTRU can send SL HARQ information to the gNB using a Physical Uplink Control Channel (PUCCH). The SL HARQ information may include an indication of whether one or more SL resources are requested. The SL HARQ information may include an indication of one or more additional SL resources.

[0069] For example, if Listen Before Talk (LBT) fails and / or channel occupancy time (COT) sharing is not used to send sidelink HARQ-ACK feedback to the transmitter WTRU, the receiver WTRU may not transmit an SL HARQ-ACK (for example, when the NR sidelink is deployed in an unlicensed spectrum). For example, if the sidelink HARQ-ACK is not received by the transmitter WTRU, there may be a problem regarding what to send to the gNB on PUCCH as SL HARQ feedback. HARQ feedback can be delayed, for example, to resolve these issues. For example, HARQ feedback can be delayed on an unlicensed channel.

[0070] A third state of HARQ feedback can be supported. This third state of HARQ feedback may include a delayed HARQ feedback value. The transmitter WTRU may report a delayed HARQ feedback value to the gNB, for example, if the sidelink HARQ feedback is not received by the transmitter WTRU. The gNB may, for example, wait for the SL HARQ feedback at a later opportunity without assuming an ACK and / or NACK. The transmitter WTRU may report the SL-HARQ feedback to the gNB, for example, when it is available.

[0071] A sidelink grant may not tolerate additional delays for retransmission. For example, if the required latency for transmitting sidelink data is small, waiting for delayed HARQ feedback to request additional resources for transmitting sidelink data may not be acceptable. A two-state HARQ may include an ACK and / or NACK, which may be reported to the gNB, for example. A third state of the HARQ may increase uplink control signaling overhead, as it may report two or more bits, for example. The HARQ codebook size may increase. For example, the HARQ codebook size may double if two bits of feedback are reported per sidelink grant. For example, when the reporting of delayed HARQ values ​​should be enabled so that feedback can be efficiently transmitted with reduced uplink overhead can be disclosed herein.

[0072] A Tx WTRU can report sidelink HARQ feedback to the gNB. The WTRU can report SL HARQ to indicate whether additional sidelink resources are desired (e.g., whether they are needed). A delayed HARQ value can be included in the message. The message can indicate that conventional HARQ feedback (e.g., ACK or NACK) is not available for transmission. For example, the message can be a separate message from conventional HARQ feedback. A WTRU that supports reporting delayed HARQ values ​​can support three values. The three values ​​can include an ACK value, a NACK value, and / or a delayed HARQ value. An ACK value can indicate successful decoding of the transmission and / or that the WTRU is in the ACK state. A NACK value can indicate unsuccessful decoding of the transmission and / or that the WTRU is in the NACK state. A delayed HARQ value can indicate that more time is needed to report ACK and / or NACK, and / or that the WTRU is in the delayed HARQ state.

[0073] A sidelink Tx WTRU can, for example, transmit data on a sidelink channel with sidelink HARQ feedback enabled. A Tx WTRU can receive (for example, expect to receive) sidelink HARQ feedback from a receiver (Rx) WTRU. A Tx WTRU can, for example, report the ACK value to the gNB if it receives an ACK from the Rx WTRU. A Tx WTRU can, for example, report the NACK value if it receives a NACK from the Rx WTRU. A Tx WTRU can, for example, determine (for example, assume) that sidelink HARQ feedback is delayed and / or report the delayed HARQ value to the gNB if sidelink HARQ feedback is enabled for sidelink data transmission and / or sidelink HARQ feedback is not received from the Rx WTRU. A WTRU may determine (for example, assume) that sidelink HARQ feedback is delayed if the Tx WTRU does not receive sidelink HARQ feedback before the PUCCH transmission time. For example, a WTRU may be configured with a duration, which may precede the PUCCH transmission time, and for example, the WTRU may determine (for example, assume) that sidelink HARQ feedback is delayed during that time.

[0074] Sidelink HARQ feedback may be reported to the gNB for each HARQ feedback corresponding to a sidelink grant transmission. SL HARQ feedback may include one or more ACK / NACK values. Additionally or alternatively, delayed HARQ values ​​may be reported. A WTRU may decide to report ACK or NACK values ​​(for example, expected to be reported at a later opportunity) if the WTRU reports delayed HARQ values ​​to the gNB. Sidelink channels may be deployed in the unlicensed spectrum. Additionally or alternatively, sidelink channels may be deployed in the licensed spectrum.

[0075] One or more of the following terms may be used herein: “ACK state” may refer to a case where an ACK value is reported. “NACK state” may refer to a case where a NACK value is reported. “Delayed HARQ state” may refer to a case where a delayed HARQ value is reported. “HARQ feedback” may refer to an ACK value, a NACK value, and / or a delayed HARQ value. “HARQ feedback” may refer to multiple HARQ feedbacks. “2-state HARQ” (e.g., “2 states HARQ”) may refer to a case where an ACK value / NACK value (e.g., only those) can be reported. “3-state HARQ” (e.g., “3 states HARQ”) may refer to a case where an ACK value / NACK value / delayed HARQ value can be reported. “HARQ mode” may refer to whether the WTRU is using 2-state HARQ or 3-state HARQ for the sidelink grant. A sidelink grant using 3-state HARQ can refer to a case where 3-state HARQ is enabled for a sidelink grant. The HARQ codebook may include a set of bits indicating HARQ feedback for a group of sidelink grants.

[0076] Delayed HARQ states can be enabled. Cell support for delayed HARQ reporting can be disclosed herein. A WTRU can be configured to determine, for example, whether a serving cell supports reporting delayed HARQ values ​​to the gNB as feedback for one or more (e.g., several) sidelink transmissions. A WTRU can receive one or more (one or more) RRC signaling, SIB, and / or MIB signaling that can indicate, for example, whether a serving cell supports delayed HARQ values. If a cell supports delayed HARQ values, a WTRU can determine whether 3-state HARQ is supported for (e.g., each) sidelink transmission. A WTRU can receive an RRC configuration that can indicate whether a cell supports reporting delayed HARQ values. When reporting sidelink feedback to the gNB, a WTRU can determine whether sidelink grant 2-state HARQ and / or 3-state HARQ should be used. The WTRU may receive an RRC configuration that indicates, for example, that a cell does not support reporting a 3-state HARQ for sidelink HARQ feedback reporting. In that case, the WTRU may report a 2-state HARQ to the gNB (for example, always) for sidelink data transmissions. The WTRU may receive a configuration that could include an indication of whether a cell (for example, a neighbor) supports reporting delayed HARQ values ​​to the gNB as feedback for some sidelink transmissions. A serving cell may indicate to the WTRU, for example, during handover, whether a neighboring cell supports a 3-state HARQ.

[0077] Sidelink data characteristics configured using a 3-state HARQ can be disclosed herein. A WTRU can be configured to use a 3-state HARQ for sidelink data transmissions that may have, for example, (some specific) packet delay budget (PDB) values. A WTRU can be configured with a set of PDB values ​​such that the corresponding data transmission can use a 3-state HARQ. For example, a WTRU can be configured to use a 3-state HARQ for data transmissions with PDB values ​​greater than a PDB threshold. For example, a 2-state HARQ can be used for sidelink data transmissions with PDBs smaller than a threshold. For example, a 3-state HARQ can be used for sidelink data transmissions with PDBs greater than a threshold. Data transmissions with large delay budgets may, in some examples, tolerate additional delays to receive feedback. Transmissions with small delay budgets may, in some examples, not tolerate additional delays.

[0078] A WTRU can be configured to use a 3-state HARQ for sidelink data transmissions. SL data transmissions can have specific QoS characteristics. A WTRU can be configured with a set of QoS flows, for example, that the corresponding data transmission can use a 3-state HARQ. For example, a WTRU can be configured to use a 3-state HARQ for data transmissions with QoS flow identifiers in a pre-configured set of one or more values. For example, a 2-state HARQ can be used for sidelink data transmissions with QoS flow identifiers that do not belong to a pre-configured set. Sidelink data transmissions can use a 3-state HARQ (for example, if they do not otherwise). A WTRU can be configured with a sidelink radio bearer. Sidelink data transmissions can use a 3-state HARQ on the SL radio bearer.

[0079] A WTRU can be configured, for example, to use a 3-state HARQ for sidelink data transmissions within several specific logical channels (LCHs) and / or logical channel groups (LCGs). A WTRU can be configured with a set of logical channels and / or logical channel groups on which the corresponding data transmissions can use a 3-state HARQ. For example, a WTRU can be configured to use a 3-state HARQ for data transmissions with LCG identifiers (IDs) in a pre-configured set of one or more values.

[0080] A WTRU can be configured with slots for sidelink data within a Channel Occupancy Time (COT) structure that can use a 3-state HARQ, for example. For example, a WTRU can be configured with the last slot in a COT structure that can use a 3-state HARQ for sidelink transmissions. A WTRU can select a COT structure and / or report the COT structure to the gNB, and / or the gNB can configure the WTRU with the COT structure to be used for sidelink transmissions. A WTRU can receive a configuration of a set of slots in a COT structure that can use a 3-state HARQ. The configuration can be received while receiving the COT structure configuration / sidelink grant allocation and / or can be fixed in the specification. For example, the Channel Occupancy Time (COT) can use a 3-state HARQ. A slot in the COT (e.g., the last slot) can use a 3-state HARQ.

[0081] A WTRU can determine whether a 3-state HARQ should be used for a scheduled sidelink grant. A 2-state HARQ may include an ACK and / or NACK, for example, reported to the gNB. A 3-state HARQ may include an ACK, a NACK, and one or more delayed HARQ values. A WTRU can be configured to determine whether a 3-state HARQ or a 2-state HARQ should be used for each scheduled sidelink grant. For example, if a WTRU determines that a 3-state HARQ should be used for a sidelink data transmission, it may report three HARQ feedback values ​​to the gNB (e.g., an ACK and / or NACK and / or delayed HARQ). A WTRU can determine whether a 3-state HARQ should be used for a scheduled sidelink grant based on one or more sidelink data characteristics. One or more sidelink data characteristics may include one or more of the following: PDB value, QoS, logical channel, slot location (one or more), physical sidelink feedback channel (PSFCH) location, downlink control information (DCI), and / or PUCCH transmission time. The PDB value may be associated with the sidelink data to be transmitted within a scheduled sidelink grant. QoS may be associated with the data that can be transmitted within a scheduled sidelink grant. The logical channel may be associated with the data that can be transmitted within a scheduled sidelink grant. The slot location (one or more) may be associated with sidelink data transmission within a COT. The PSFCH location may be associated with sidelink data transmission within a captured COT. The DCI may include scheduling of the sidelink grant indicating whether a 3-state HARQ or a 2-state HARQ should be used.The PUCCH transmission time can be configured to report sidelink HARQ feedback to the gNB. For example, there may be a PDB threshold. If the PDB is below the threshold, a two-state HARQ can be used. If the PDB is equal to or greater than the threshold, a three-state HARQ can be used. A QoS identifier can be associated with a two-state HARQ or a three-state HARQ. A logical channel ID can be associated with a two-state HARQ or a three-state HARQ.

[0082] SL grant assignments can be received from the network in the WTRU. For example, SL grant assignments can be received in the DCI. Sidelink assignment indices can be used. For example, indications of the SL assignment index can be received from the network (for example, in the DCI). The WTRU can determine the values ​​of the counter sidelink assignment indicator and / or total sidelink assignment indicator, for example, in a subsequent DCI. An SL grant assignment may include one or more predefined values ​​for one or more sidelink (SL) data characteristics. For example, the predefined values ​​may include one or more of PDB, QoS, and logical channel values. The predefined values ​​may be associated with two-state HARQs and / or three-state HARQs.

[0083] A WTRU can generate one or more HARQ subcodebooks (for example, a first HARQ subcodebook and a second HARQ subcodebook). One or more HARQ subcodebooks can contain SL HARQ information about a HARQ mode. For example, a first HARQ subcodebook can contain SL HARQ information about a first HARQ mode, and / or a second HARQ subcodebook can contain SL HARQ information about a second HARQ mode. A first HARQ mode can be a two-state HARQ mode, where the two states can be ACK / NACK. A second HARQ mode can be a three-state HARQ mode, where the three states can be delayed HARQ, ACK, and NACK.

[0084] The WTRU may determine, for example, whether a first HARQ mode and / or a second HARQ mode should be used (enabled) based on whether one or more predefined values ​​for one or more SL data characteristics are met for an SL grant allocation. The WTRU may, for example, decide to add one bit to the HARQ codebook if it determines that three-state HARQ is not enabled. The WTRU may, for example, decide to add two bits to the HARQ codebook if it determines that three-state HARQ is enabled.

[0085] A WTRU can transmit SL HARQ information based on whether one or more predefined values ​​for one or more SL data characteristics are met for an SL grant allocation. For example, a WTRU can transmit SL HARQ information in a first HARQ mode based on whether one or more predefined values ​​for one or more SL data characteristics are met for an SL grant allocation. In addition or alternatively, a WTRU can transmit SL HARQ information in a second HARQ mode based on whether one or more predefined values ​​for one or more SL data characteristics are not met for an SL grant allocation.

[0086] The WTRU can determine whether to use three - state HARQ for a scheduled sidelink grant based on, for example, the PDB value of the sidelink data that can be transmitted within the scheduled sidelink grant. The WTRU can report sidelink feedback to the gNB using three - state HARQ if, for example, the PDB of the sidelink data transmission to be sent using the scheduled sidelink has a PDB value belonging to a configured set of PDB values for which three - state HARQ can be used. The WTRU can use two - state HARQ (for example, if not). The WTRU can determine whether to use three - state HARQ or two - state HARQ using the minimum PDB value of the multiplexed data if, for example, the WTRU determines to multiplex sidelink data with different PDB values within the same sidelink grant. For example, if the WTRU multiplexes two logical channels in the same grant, the first logical channel is associated with a first PDB (for example, has PDB1) and the second logical channel is associated with a second PDB (for example, has PDB2) (for example, PDB1 < PDB2), the WTRU can use PDB1 to determine whether three - state HARQ is enabled. If the smaller PDB value (for example, PDB1) is within the set of PDB values for which, for example, three - state HARQ can be used, the WTRU can report sidelink feedback to the gNB using three - state HARQ.

[0087] A WTRU can determine whether to use 3-state HARQ for a scheduled sidelink grant based on the QoS of the data that can be transmitted within the scheduled sidelink grant. For example, a WTRU will use 3-state HARQ if the QoS flow for the sidelink data transmission to be transmitted using the scheduled sidelink grant has QoS flows that correspond to a set of QoS flows configured to use 3-state HARQ. If a WTRU decides to multiplex data using multiple QoS flows within the same sidelink grant, it may use 3-state HARQ if, for example, one or more (e.g., all) QoS flows to be multiplexed are within a set of QoS flows configured to support 3-state HARQ.

[0088] A WTRU can determine whether to use a 3-state HARQ for a scheduled sidelink grant, for example, based on the logical channels of data that can be transmitted within the scheduled sidelink grant. If the logical channel ID and / or logical channel group of the sidelink data transmission to be transmitted within the scheduled sidelink grant corresponds to one or more logical channels and / or logical channel groups configured to use a 3-state HARQ, for example, then the WTRU can use a 3-state HARQ.

[0089] The WTRU can determine whether to use a 3-state HARQ for a scheduled sidelink grant based on the location of one or more slots for sidelink data transmission within the COT. The WTRU can be configured with one or more slots within the COT that can, for example, use a 3-state HARQ. The WTRU can determine the slots based on pre-configuration and / or upon receiving the sidelink grant and / or COT configuration.

[0090] The WTRU can determine whether to use a 3-state HARQ for a scheduled sidelink grant based on whether the physical sidelink feedback channel (PSFCH) location corresponding to the sidelink data transmission is within the captured COT. For example, the transmitter WTRU can initiate the COT and / or provide the gNB with the COT structure (e.g., a set of slots for sidelink data transmissions and a set of slots for PSFCH transmissions). Additionally or alternatively, the gNB can determine (e.g., know) the location of the PSFCH, for example, based on the resource pool configuration. The WTRU and / or gNB can determine (e.g., know) the location of the PSFCH within the COT. (e.g., may then) the WTRU can enable a 3-state HARQ for a sidelink grant, for example, if the sidelink data transmission has a corresponding PSFCH outside the COT.

[0091] The WTRU can determine whether a 3-state HARQ should be used for a scheduled sidelink grant based on the indication in the DCI for scheduling the sidelink grant. An indication in the DCI for scheduling an SL grant can indicate whether a 3-state HARQ or a 2-state HARQ should be used. The DCI can include bitfields, which can indicate the activation of 3-state HARQ feedback. Additionally or alternatively, the DCI format used to schedule a sidelink grant can indicate the activation of a 3-state HARQ. For example, when scheduling a sidelink grant is triggered, a given DCI format can be used for (e.g., only for) a 3-state HARQ.

[0092] The WTRU can determine whether to use a 3-state HARQ for a scheduled sidelink grant based on the PUCCH transmit time configured to report sidelink HARQ feedback to the gNB. The WTRU can be configured with multiple values ​​of transmit PUCCH timing (e.g., semi-statically configured) and / or (e.g., any) and can use a 3-state HARQ when indicated to be used for PUCCH transmits to report sidelink feedback to the gNB. The PUCCH transmit time associated with the 3-state HARQ can be indicated in the WTRU and / or fixed in the specification. For example, a 3-state HARQ or a 2-state HARQ can be used by the WTRU for PUCCH transmit times (e.g., k1, k2, and / or k3). For example, for a PUCCH at k1, the WTRU can use a 2-state HARQ. For example, for PUCCHs at k2 and / or k3, the WTRU can use a 3-state HARQ. The configuration could, for example, indicate a PUCCH transmission timing threshold, above which the WTRU can enable a 3-state HARQ.

[0093] A sidelink allocation index can be used. The WTRU can determine (e.g., assume) that, for example, if the WTRU enables 3-state HARQ for sidelink grants and / or if the WTRU is configured with a dynamic HARQ-ACK codebook (e.g., a Type 2 HARQ codebook), the values ​​of the counter sidelink allocation indicator and / or total sidelink allocation indicator will be incremented by 2 in the next DCI format for scheduling sidelink grants. The WTRU can determine (e.g., expect) that, for example, if the WTRU is configured with a semi-static HARQ codebook (e.g., a Type 3 HARQ codebook), the total sidelink allocation indicator will count sidelink grants using 3-state HARQ with a first value (e.g., 2) and sidelink grants using 2-state HARQ with a second value (e.g., 1).

[0094] A WTRU can report HARQ codebooks to the gNB. For example, when a WTRU reports HARQ feedback to the gNB using a HARQ codebook, it can report sidelink HARQ feedback using one or more bits (e.g., two) for sidelink grants using 3-state HARQ and / or one or more bits (e.g., one) for sidelink grants with 2-state HARQ enabled. A WTRU can include (e.g., mix) 3-state HARQ and 2-state HARQ within the same HARQ codebook. A WTRU can order HARQ feedback for different sidelink grants based, for example, the DCI order for scheduling sidelink grants. A WTRU can be configured to append HARQ feedback for sidelink grants using 3-state HARQ to the end of the HARQ codebook. WTRU can utilize HARQ feedback for sidelink grants using two-state HARQ, and / or add HARQ feedback for sidelink grants using three-state HARQ (for example, after the two-state HARQ feedback).

[0095] A HARQ codebook can contain one or more (e.g., two) subcodebooks. For example, a WTRU can generate two subcodebooks. A subcodebook can contain HARQ feedback for (one or more) SL transmissions according to a HARQ mode (e.g., a second HARQ mode). A second HARQ mode can contain a three-state HARQ mode. The three states can contain ACK, NACK, and delayed HARQ. A subcodebook can contain HARQ feedback for (one or more) SL transmissions according to a HARQ mode (e.g., a first HARQ mode). A first HARQ mode can contain a two-state HARQ mode. The three states can contain ACK and NACK.

[0096] The WTRU can determine, for example, whether a second HARQ mode is enabled for a subset of SL transmissions. A subset of SL transmissions may include SL transmissions for which HARQ feedback is reported, for example, to the gNB. The WTRU can determine the size of the (e.g., first and / or second) HARQ subcodebooks. The size of the (e.g., first and / or second) HARQ subcodebooks may be based on the number of subsets of (one or more) SL transmissions for which a NACK was received and / or no response was received. The number of subsets may be based on the number of SL grants (e.g., including them). The HARQ subcodebooks (e.g., the first and / or second HARQ subcodebooks) may have a bit order. The bit order may be based on the order of the number of sidelink grants in a subset of one or more sidelink transmissions. A (for example, second) HARQ subcodebook may include HARQ feedback for a subset of SL transmissions according to a HARQ mode (for example, a second HARQ mode). A (for example, second) HARQ mode may include a three-state HARQ mode, which may include delayed HARQ and / or ACK / NACK.

[0097] A WTRU can determine one or more UL resources for transmitting (one or more) HARQ subcodebooks. For example, a WTRU can determine, for instance, based on an indication from the network, whether a first HARQ subcodebook and a second HARQ subcodebook should be transmitted on the same uplink (UL) resource or on different UL resources. The indication from the network may be included in the DCI. A WTRU can receive transmissions from other WTRUs. A transmission may be a PSFCH transmission. A transmission may include HARQ feedback. A WTRU can report (e.g., transmit) HARQ feedback to the network.

[0098] Figure 2 is a flowchart 200 of an exemplary procedure for enabling 3-state HARQ. In 202, the WTRU and / or serving cell can support 3-state HARQ when, for example, reporting sidelink HARQ to the gNB. For example, the WTRU and / or serving cell can determine whether to support 3-state HARQ. The WTRU can be configured using RRC signaling when, for example, the serving cell supports 3-state HARQ when reporting sidelink HARQ feedback to the gNB (for example, in a sidelink unlicensed spectrum). In 204, the WTRU can report either an ACK or a NACK (for example, always) for scheduled sidelink grants if, for example, the serving cell does not support 3-state HARQ. In 206, the WTRU can be configured using one or more sidelink data characteristics if, for example, the WTRU and / or serving cell supports 3-state HARQ. A WTRU can be configured using one or more of the following: a set of PDB values, QoS, logical channels, logical channel groups (LCGs), sidelink data slots, and / or PSFCHs of sidelink data slots. Sidelink data transmission can use a 3-state HARQ.

[0099] In 208, the WTRU can receive sidelink grant allocations, for example, from the gNB. For example, a sidelink allocation index can be used. Indications for the SL allocation index can be received from the network (for example, in the DCI). The WTRU can determine the values ​​of the counter sidelink allocation indicator and / or total sidelink allocation indicator, for example, in a subsequent DCI. An SL grant allocation may include one or more predefined values ​​for one or more sidelink (SL) data characteristics. The WTRU can determine (for example, assume) that the values ​​of the counter sidelink allocation indicator and / or total sidelink allocation indicator will be increased by 2 in the next DCI format that schedules the sidelink grant, for example, if the WTRU enables 3-state HARQ for sidelink grants and / or if the WTRU is configured with a dynamic HARQ-ACK codebook (for example, a type 2 HARQ codebook). WTRU can be determined (for example, expected) that, if WTRU is configured using a semi-static HARQ codebook (for example, a Type 3 HARQ codebook), the total sidelink allocation indicator will count sidelink grants using a 3-state HARQ with a first value (for example, 2) and sidelink grants using a 2-state HARQ with a second value (for example, 1).

[0100] In 210, the WTRU can determine, for example, whether to use 3-state HARQ reporting (for example, whether to use 2-state HARQ reporting) for a scheduled sidelink grant. The WTRU can determine whether to use 3-state HARQ or 2-state HARQ based on one or more SL data characteristics. For example, the WTRU can decide to use 3-state HARQ reporting if one or more of the following conditions are met. One or more conditions may include one or more of the following: a PDB value for a sidelink transmission corresponding to a pre-configured value that can support 3-state HARQ; a QoS flow for a sidelink transmission corresponding to a pre-configured packet quality indicator (PQI) that can support 3-state HARQ; an LCH for a sidelink transmission corresponding to a pre-configured LCH that can support 3-state HARQ; a slot for sidelink data transmission within the captured COT being configured with 3-state HARQ; no PSFCH location corresponding to sidelink data transmission being within the captured COT; a PUCCH transmission time K1 indicating a value earlier than the PSFCH reception time; and / or a DCI scheduling the grant having a flag with a value indicating the enablement of 3-state HARQ.

[0101] In step 212, the WTRU can determine whether the 3-state HARQ is enabled. In step 214, the WTRU can decide to add one bit to the HARQ codebook, for example, if the WTRU determines that the 3-state HARQ is not enabled. In step 216, the WTRU can decide to add two bits to the HARQ codebook, for example, if the WTRU determines that the 3-state HARQ is enabled. The procedure can then return to step 208, for example, after steps 214 and / or 216.

[0102] The WTRU can report a sidelink HARQ codebook to the gNB using one or more (e.g., two) bits for sidelink grants associated with a 3-state HARQ and one or more (e.g., one) bits for sidelink grants associated with a 2-state HARQ (e.g., a two-state HARQ). The same (e.g., one) HARQ codebook may have both a 3-state HARQ and a 2-state HARQ.

[0103] A HARQ subcodebook can be used for delayed HARQ feedback. The WTRU can be configured to determine whether a 2-state HARQ or a 3-state HARQ should be used for each scheduled grant. The WTRU can then group the HARQ feedback for a group of sidelink grants into a single HARQ codebook. The HARQ codebook can include a set of bits that indicate the HARQ feedback for a group of sidelink grants. The WTRU can determine a group of sidelink grants for which the HARQ feedback should be reported in the same HARQ codebook, for example, if the transmission times for the HARQ feedback are the same for all sidelink grants. For example, the WTRU can be configured in slot n1 with a first sidelink grant, and / or the HARQ feedback can be transmitted (or required to be transmitted) in slot k1. As an addition or alternative, in slot n2, the WTRU may be configured with a second sidelink grant and / or with HARQ feedback transmission in slot k1. The WTRU may, for example, use the same HARQ codebook to report HARQ feedback for the first and second grants in the slot (e.g., slot k1).

[0104] HARQ feedback from sidelink grants can be combined and reported to the gNB. For example, some sidelink grants may use a two-state HARQ, while others may use a three-state HARQ. A WTRU (e.g., a Tx WTRU) can transmit over a sidelink channel using a sidelink grant and / or (e.g., then) receive sidelink HARQ feedback about the sidelink grant from an Rx WTRU. Sidelink HARQ feedback can be combined and reported to the gNB using the same HARQ codebook.

[0105] One or more (e.g., two) HARQ subcodebooks can be used. The WTRU can be configured to report one or more (e.g., two) HARQ subcodebooks when 3-state HARQ is enabled for at least one of the sidelink grants, as shown, for example, in Figure 3. Figure 3 shows an example of HARQ codebook 302 300, which includes two HARQ subcodebooks 304, 306.

[0106] For example, if at least one sidelink grant uses a 3-state HARQ, the WTRU can report two HARQ subcodebooks 304, 306. The WTRU can report a 2-state HARQ for one or more (e.g., all) of the scheduled sidelink grants in the first subcodebook 304, regardless of whether the 3-state HARQ is enabled for the sidelink grant. The WTRU reports one bit (e.g., ACK or NACK) for each scheduled grant in the first HARQ-ACK subcodebook 304, and / or can order the ACK / NACK bits in the first HARQ-ACK subcodebook 304 using, for example, the DCI order for scheduling the sidelink grants. If the 3-state HARQ is enabled for a sidelink grant, the WTRU can report an ACK or NACK for that sidelink grant in the first HARQ subcodebook 304. For example, a WTRU may report an ACK if the sidelink grant is successfully decoded (e.g., the PSFCH indicates an ACK for the sidelink grant), or a NACK if the sidelink grant is not successfully decoded. For example, a PSFCH may indicate a NACK for a sidelink grant, and / or the PSFCH corresponding to the sidelink grant may not be received before the transmission time of the first HARQ subcodebook 304 (e.g., a delayed HARQ). A WTRU may report an ACK value for a sidelink grant, for example, if the sidelink grant uses a three-state HARQ and the corresponding PSFCH is received before the transmission time of the first HARQ subcodebook 304, and / or the PSFCH indicates an ACK.

[0107] Table 1 shows exemplary values ​​that WTRU can report for different cases.

[0108] [Table 1]

[0109] For example, a WTRU may be configured with one or more (e.g., four) sidelink grants, one or more (e.g., three) first sidelink grants using a two-state HARQ, and one or more (e.g., a fourth) sidelink grants using a three-state HARQ. The WTRU may report an ACK or NACK in the first HARQ subcodebook 304 for one or more (e.g., all) of the sidelink grants, including the fourth sidelink grant. For example, if the WTRU does not receive a PSFCH corresponding to the fourth grant, the WTRU may report a NACK for the fourth grant in the first HARQ subcodebook 304. The WTRU may also report a NACK for the fourth grant in the first HARQ subcodebook if, for example, the WTRU receives a PSFCH corresponding to the fourth grant and the PSFCH shows a NACK. For example, if the WTRU receives a PSFCH corresponding to the fourth grant and the PSFCH indicates an ACK, the WTRU can report an ACK for the fourth grant in the first HARQ subcodebook 304.

[0110] The WTRU may use the second HARQ subcodebook 306 for sidelink grants that use a 3-state HARQ (for example, only for that grant). For example, if one or more (for example, all) of the sidelink grants that should be reported in the HARQ codebook use a 2-state HARQ, the WTRU may report the first HARQ subcodebook 304 (for example, only for that grant). For example, if several sidelink grants that should be reported in the HARQ codebook 302 use a 3-state HARQ, the WTRU may report both the first HARQ subcodebook 304 and the second HARQ subcodebook 306. For a sidelink grant using a 3-state HARQ, the WTRU may transmit additional information in the second HARQ subcodebook 306 if, for example, the corresponding PSFCH was not received before the transmission time of the first HARQ subcodebook 304, and / or if the PSFCH was received before the transmission time of the first HARQ subcodebook 304 and the PSFCH indicates a NACK.

[0111] Figure 4 shows an example 400 in which the WTRU receives a PSFCH after the transmission time of the first HARQ codebook 402. As shown in Figure 4, there may be three sidelink transmissions using a three-state HARQ. One of the PSFCHs may be received after the transmission time of the first HARQ codebook 402. The WTRU may report a two-state HARQ for one or more (e.g., all) of the scheduled sidelink grants in the first subcodebook 404, regardless of whether the three-state HARQ is enabled for the sidelink grant. The WTRU may use the second HARQ subcodebook 406 for sidelink grants that use a three-state HARQ (e.g., for only that grant).

[0112] For example, if PSFCH is not received, the WTRU may report a value of 1 in the second HARQ subcodebook 406. For example, if PSFCH is received and shows a NACK, the WTRU may report a value of 0 in the second HARQ subcodebook 406. For one or more (e.g., all) sidelink grants using a three-state HARQ, if PSFCH is received and shows an ACK value, the WTRU may report the first HARQ subcodebook 404 (e.g., only that). For example, if a WTRU decides to report HARQ information about a sidelink grant using a three-state HARQ (e.g., only that), and / or the PSFCH corresponding to the sidelink grant is received before the transmission time of HARQ codebook 402, and / or all PSFCHs show an ACK value, then the WTRU may report a first HARQ subcodebook 404 (e.g., only that), and / or may not transmit a second HARQ subcodebook 406.

[0113] The sidelink timing may include one or more SL grants reported in 408. For example, one or more SL grants may include SL grants using three states. The SL grants may be reported to a network, e.g., a gNB. One or more SL grants may be reported in one or more PSSCH transmits 410, 412, 414. The WTRU may receive SL HARQ feedback in 416. The SL HARQ feedback may be received in one or more PSFCH transmits 418, 420, 422. For example, an ACK may be received in PSFCH transmit 418. Additionally or alternatively, a NACK may be received in PSFCH transmit 420.

[0114] Table 2 shows exemplary values ​​that WTRU can report for different cases.

[0115] [Table 2]

[0116] A WTRU can order HARQ information in a second HARQ subcodebook 406 based, for example, on the DCI's reception time for scheduling sidelink grants. A WTRU can consist of one or more (e.g., five) sidelink grants that have HARQ feedback to report at the same HARQ transmission time. A WTRU can report HARQ feedback for one or more (e.g., five) sidelink grants to the gNB using the same HARQ codebook. A WTRU can determine that one or more (e.g., the first, second, and third) sidelink grants are using a three-state HARQ, and / or that one or more (e.g., the fourth and fifth) sidelink grants are using a two-state HARQ. A WTRU can transmit sidelink grants and / or monitor the corresponding PSFCH transmissions that the Rx WTRU should transmit. An Rx WTRU can refer to different receiver WTRUs, or (for example, if all sidelink grants are delegated to the same Rx WTRU) to the same Rx WTRU.

[0117] For example, if a WTRU is configured with five sidelink grants, the WTRU may receive a PSFCH from the Rx WTRU for the first sidelink grant indicating an ACK, and / or a PSFCH for the second sidelink grant indicating a NACK. In some examples, the WTRU may not receive a PSFCH for the third sidelink grant. The WTRU may receive a PSFCH from the Rx WTRU, for example, for the fourth grant indicating an ACK, and / or a PSFCH for the fifth grant indicating a NACK. (For example, therefore) the WTRU may report two HARQ subcodebooks 404, 406. The first HARQ subcodebook 404 may contain (ACK, NACK, NACK, ACK, NACK). The second HARQ subcodebook 406 may contain (0, 1). For example, the WTRU and / or gNB (for example, both) can determine (for example, know) which sidelink grants will use 3-state HARQ feedback and / or which sidelink grants will use 2-state HARQ feedback. For example, in a sidelink grant using 3-state HARQ feedback, if the first HARQ subcodebook 404 indicates NACK, the second HARQ subcodebook 406 may carry additional information. The order of the additional information in the second HARQ subcodebook 406 may be based on the order of reception by the sidelink grant. (For example, thus) the HARQ codebook 402 to report to the gNB may include (ACK, NACK, NACK, ACK, NACK, 0, 1).

[0118] For example, if a WTRU is configured with five sidelink grants, the WTRU may receive a PSFCH from the Rx WTRU for the first sidelink grant indicating a NACK, and / or a PSFCH for the second sidelink grant indicating a NACK. In some examples, the WTRU may not receive a PSFCH for the third sidelink grant. The WTRU may receive a PSFCH from the Rx WTRU for the fourth grant indicating an ACK, and a PSFCH for the fifth grant indicating a NACK. (For example, therefore) the WTRU may report two HARQ subcodebooks 404, 406. The first HARQ subcodebook 404 may contain (NACK, NACK, NACK, ACK, NACK). The second HARQ subcodebook 406 may contain (0, 0, 1). (For example, therefore) a HARQ codebook 402 to report to gNB may include (NACK, NACK, NACK, ACK, NACK, 0, 0, 1).

[0119] For example, if a WTRU is configured with five sidelink grants, the WTRU may receive from the Rx WTRU a PSFCH for the first sidelink grant showing ACK, and / or a PSFCH for the second sidelink grant showing ACK, and / or a PSFCH for the third sidelink grant showing ACK. The WTRU may also receive from the Rx WTRU a PSFCH for the fourth grant showing ACK, and a PSFCH for the fifth grant showing NACK. (For example, therefore) the WTRU may report (for example, one) HARQ subcodebooks 404, 406. HARQ subcodebooks 404, 406 may include the first HARQ codebook 404 (for example, only that), which includes (ACK, ACK, ACK, ACK, NACK). (For example, therefore) the HARQ codebook 402 to be reported to the gNB may include (ACK, ACK, ACK, ACK, NACK).

[0120] The WTRU can determine the sizes of HARQ subcodebooks 404 and 406. The WTRU can determine the size of HARQ codebook 402 to be reported to the gNB based on a multi-step (e.g., two-step) methodology. The WTRU can determine the size of the first HARQ subcodebook 404 (e.g., in the first step). The WTRU can determine the size of the first HARQ subcodebook 404 by determining the size of HARQ codebook 402, for example, if HARQ codebook 402 is equal to the first HARQ subcodebook 404. For example, the WTRU can determine the size of the HARQ codebooks using a counter sidelink allocation index and / or (e.g., a total) sidelink allocation index. The WTRU can determine whether or not to use a second HARQ subcodebook 406, as described herein (e.g., as the second step). As described herein, a WTRU may use a second HARQ subcodebook 406 if, for example, for at least one sidelink grant using a 3-state HARQ, the corresponding PSFCH shows a NACK and / or the corresponding PSFCH is not received before the transmission time of the first HARQ subcodebook 404. For example, if a WTRU uses a second HARQ subcodebook 406, the size of the second HARQ subcodebook 406 may be equal to the number of sidelink grants using a 3-state HARQ minus the number of PSFCHs corresponding to sidelink grants using a 3-state HARQ, showing an ACK value, and received before the transmission time of the first HARQ subcodebook 404. For example, a WTRU may be configured with one or more (e.g., five) sidelink grants using a 3-state HARQ. A WTRU may receive one PSFCH (e.g., only one) showing an ACK before the transmission time of the first HARQ-ACK subcodebook 404. (For example, therefore) the size of the second HARQ subcodebook 406 can be 4.The size of HARQ codebook 402 can be equal to the sum of the sizes of the first HARQ subcodebook 404 and the second HARQ subcodebook 406.

[0121] The WTRU can be constructed using the (e.g., exact) size of the second HARQ subcodebook 406, regardless of the number of sidelink grants using the three-state HARQ where the PSFCH shows a NACK and / or the PSFCH is not received. If the WTRU determines that the number of sidelink grants using the three-state HARQ where the PSFCH shows a NACK and / or the PSFCH is not received is less than the constructed size of the second HARQ subcodebook 406, it can add padding bits to the determined number and / or report the second HARQ subcodebook 406 with the constructed size. For example, if the WTRU has more bits to report in the second HARQ subcodebook 406, it can report up to the constructed size and may not report the remaining information bits.

[0122] A WTRU can be constructed using the maximum size of the second HARQ subcodebook 406. (For example, therefore) in some examples, a WTRU may not exceed its maximum constructed size when reporting the second HARQ subcodebook 406. For example, if a WTRU has more bits to report in the second HARQ subcodebook 406, the WTRU may report up to its constructed maximum number and not report the remaining information bits.

[0123] A WTRU can transmit HARQ subcodebooks 404, 406 using an uplink resource. A WTRU can be configured to transmit one or more (e.g., two) HARQ subcodebooks 404, 406 as described herein using the same uplink resource. A WTRU can receive an indication in DCI and transmit, for example, two HARQ subcodebooks 404, 406 using the same uplink resource. For example, the resource may include a PUCCH resource and / or a PUSCH resource. A WTRU can determine the PUCCH resource based on the size of HARQ codebook 402, which is the sum of the first HARQ subcodebook 404 and the second HARQ subcodebook 406, if the WTRU has decided (e.g., is transmitting) to transmit HARQ subcodebooks 404, 406 using the PUCCH resource. If a WTRU decides (for example, is sending) to send HARQ subcodebooks 404 and 406 using PUSCH resources, the WTRU can determine how many resources to use from PUSCH for HARQ codebook 402 based on the sizes of the first HARQ subcodebook 404 and the second HARQ subcodebook 406.

[0124] A WTRU can be configured to transmit one or more (e.g., two) HARQ subcodebooks 404, 406 using separate uplink resources. For example, a first HARQ subcodebook 404 can be transmitted using a first PUCCH resource, and a second HARQ subcodebook 406 can be transmitted using a second PUCCH resource. A first HARQ subcodebook 404 can be transmitted using a PUCCH resource, and a second HARQ subcodebook 406 can be transmitted using a PUSCH resource. A first HARQ subcodebook 404 can be transmitted using a PUSCH resource, and a second HARQ subcodebook 406 can be transmitted using a PUCCH resource. A first HARQ subcodebook 404 can be transmitted using a first PUSCH resource, and a second HARQ subcodebook 406 can be transmitted using a second PUSCH resource.

[0125] The WTRU can determine which uplink resources to use to transmit the first and second resources based on the determined sizes of the HARQ subcodebooks 404 and 406. For example, if the sum of the sizes of the HARQ subcodebooks is greater than or equal to a (e.g., configured) threshold, the WTRU can decide to use separate uplink resources for the first HARQ subcodebook 404 and the second HARQ subcodebook 406. The threshold can be indicated using sidelink grant scheduling and / or alternatively, it can be pre-configured using RRC signaling or fixed in the specification.

[0126] A WTRU can be configured with uplink resources to send a second HARQ subcodebook 406 after, for example, sending a first HARQ subcodebook 404. For example, a WTRU can report the first HARQ subcodebook 404 (for example, only) using uplink resources configured for HARQ codebook 402. For example, after reporting the first HARQ subcodebook 404, the WTRU can monitor a DCI to trigger and / or allocate uplink resources for sending the second HARQ subcodebook 406.

[0127] A WTRU can transmit HARQ information about a previously acknowledged sidelink grant as a delayed HARQ. After reporting the delayed HARQ value to the gNB, the WTRU can monitor the PSFCH corresponding to the sidelink data for which the delayed HARQ was reported to the gNB, for example, on the sidelink channel. The WTRU can receive a PSFCH with either an ACK or NACK value. For example, the WTRU can report the PSFCH information received after reporting the delayed HARQ value to the gNB. The WTRU can receive a DCI. A DCI can trigger the transmission of previously delayed HARQ feedback. A DCI can trigger one or more previously delayed HARQ feedbacks (e.g., reported as delayed HARQs). The triggering DCI may indicate the uplink resource and / or transmission time for which the HARQ feedback should be reported.

[0128] A WTRU can be configured to append HARQ feedback for a previously delayed HARQ to a subsequent HARQ codebook. The subsequent HARQ codebook may include a HARQ codebook configured for transmission X milliseconds (ms) after the transmission time of the HARQ codebook that reported the delayed HARQ information. The DCI that triggers the HARQ transmission for the previously delayed HARQ may indicate a value of X. A WTRU can be configured using an RRC with one or more sets of X values, and / or the DCI may indicate one of those values. For example, a WTRU may use a first HARQ codebook to report a delayed HARQ value. (For example, then) the WTRU may receive a PSFCH corresponding to an acknowledged sidelink grant as the delayed HARQ. The WTRU may monitor a DCI indicating a transmission opportunity for the delayed HARQ. The WTRU may receive a DCI indicating the X ms after which the delayed HARQ feedback should be transmitted. For example, a WTRU can be configured to send (e.g., exactly) X ms after the transmission time of the HARQ codebook reporting the delayed HARQ information. In another example, a WTRU can be configured to send within X ms after the transmission time of the HARQ codebook reporting the delayed HARQ information (e.g., the transmission may occur before X ms, but should not exceed X ms).

[0129] A WTRU can be configured to report previously acknowledged HARQ feedback as delayed HARQ values, for example using one-shot HARQ feedback. A WTRU can be configured with selective one-shot HARQ feedback. A WTRU can report HARQ feedback for a previously acknowledged sidelink grant (for example, only that) as delayed HARQ, for example (for example, selective) one-shot HARQ feedback. Selective one-shot HARQ feedback can be triggered using a pre-configured DCI format and / or using bit fields in the DCI.

[0130] A WTRU may be configured not to send HARQ feedback for sidelink grants that have already been acknowledged as delayed HARQs, and / or instead to send scheduling requests and / or buffer status reports (BSRs). For example, after reporting delayed HARQ values ​​for one or more sidelink grants, the WTRU can monitor the PSFCH at a later opportunity. For example, when the WTRU receives feedback, it can determine whether additional sidelinks are needed. (For example, the WTRU can then) send a BSR to request additional resources for sidelink transmissions using scheduling requests and / or uplink grants.

[0131] Figure 5 is an exemplary flowchart 500 of the WTRU process for determining whether to send two HARQ subcodebooks. In 502, the WTRU may be configured to report one or more (e.g., two) HARQ subcodebooks. The first HARQ subcodebook may carry two-state HARQ feedback for one or more (e.g., all) scheduled sidelink grants. The second HARQ subcodebook may carry additional information for sidelink grants (e.g., only) for which three-state HARQ has been enabled. In 504, the WTRU may generate feedback for the (e.g., first) HARQ subcodebook. In 506, the WTRU may determine whether to use a three-state HARQ-ACK or a two-state HARQ-ACK for a sidelink grant, for example. The WTRU may determine the size of the first HARQ-ACK subcodebook, for example, using the (e.g., total) sidelink allocation index. Sidelink assignment indexes can reside within and / or be associated with DCI. Sidelink assignment indexes can indicate the (e.g., total) size of HARQ codebooks and / or subcodebooks.

[0132] In 508, the WTRU can determine whether a sidelink grant using the 3-state HARQ is enabled. In 510, the WTRU can transmit the first HARQ subcodebook if, for example, a sidelink grant using the 3-state HARQ is not enabled. The WTRU can determine the size of the second HARQ subcodebook based on the number of sidelink grants configured using the 3-state HARQ and the corresponding PSFCH information received before the HARQ codebook transmission time. In 512, the WTRU can determine, for example, if a sidelink grant using the 3-state HARQ is enabled, whether the PSFCH for the sidelink grant indicates a NACK and / or is not received before the HARQ codebook transmission time. In a sidelink using the 3-state HARQ, if, for example, the corresponding sidelink PSFCH indicating an ACK is received from the Rx WTRU before the HARQ codebook transmission time, the WTRU may not report any information in the second HARQ subcodebook. In 514, the WTRU may transmit (e.g., the first) HARQ subcodebook if, for example, the PSFCH for a sidelink grant does not show a NACK (e.g., shows an ACK) and / or is received before the HARQ codebook transmission time. For example, if the corresponding sidelink PSFCH showing a NACK is received from the Rx WTRU before the HARQ codebook transmission time, the WTRU may report a value of 0 in the second HARQ subcodebook. For example, if the corresponding sidelink PSFCH is not received from the Rx WTRU before the HARQ codebook transmission time, the WTRU may report a value of 1 in the second HARQ subcodebook. The order of bits in the second HARQ subcodebook may follow the order of the scheduled sidelink grants.

[0133] In 516, the WTRU may decide to send the first HARQ subcodebook and / or the second HARQ subcodebook (e.g., both) if, for example, the PSFCH for a sidelink grant indicates a NACK and / or is not received before the HARQ codebook transmission time. The WTRU may decide, for example, based on gNB indications in DCI, whether the two HARQ subcodebooks should be reported for one or more of the same uplink resources and / or for one or more separate resources. The WTRU may send the two HARQ subcodebooks to the gNB. The WTRU may receive sidelink HARQ feedback from the Rx WTRU after a delay. WTRU can be configured to report HARQ feedback about previously delayed HARQ feedback, for example, by using DCI to trigger previously delayed HARQ feedback and / or by appending delayed HARQ feedback to HARQ codebooks that can be sent X ms after the initial transmission of the HARQ codebook.

[0134] Figure 6 is another exemplary flowchart 600 showing how a WTRU decides whether to send two HARQ subcodebooks. In 602, the WTRU can generate a first HARQ subcodebook. The first HARQ subcodebook may include HARQ feedback for one or more sidelink transmissions, for example, according to a first HARQ mode. The first HARQ mode may include a two-state HARQ mode. The two states may include ACK / NACK. The WTRU can decide whether a second HARQ mode is enabled. In 604, the WTRU may decide that a second HARQ mode is enabled for one or more sidelink transmissions, for example. In 606, the WTRU can determine the size of the second HARQ subcodebook. The size of the (e.g., first and / or second) HARQ subcodebooks may be based on, for example, the number of subsets of (one or more) SL transmissions for which a NACK was received and / or no response was received. The number of subsets may be based on the number of SL grants (for example, including them). The second HARQ subcodebook may include HARQ feedback for one or more sidelink transmissions, for example, according to a second HARQ mode. In 608, the WTRU may generate the second HARQ subcodebook. In 610, the WTRU may transmit the first HARQ subcodebook and / or the second HARQ subcodebook to the network, for example.

[0135] The first HARQ mode may include a two-state HARQ mode, and / or the second HARQ mode may include a three-state HARQ mode. The two-state HARQ mode may include acknowledgments / non-acknowledgments (ACK / NACK), and / or the three-state HARQ mode may include delayed HARQ. When determining the size of the second HARQ subcodebook, for example, the WTRU may determine the number of subsets of one or more sidelink transmissions for which non-acknowledgments (NACK) were received or for which no response was received. Based on indications in DCI, for example, the WTRU may determine whether the first and second HARQ subcodebooks should be transmitted over the same uplink (UL) resource or over different UL resources.

[0136] A WTRU can determine the size of a first HARQ subcodebook. The size of the first and / or second HARQ subcodebook may be based on, for example, the number of subsets of (one or more) SL transmissions for which a NACK was received and / or no response was received. The number of subsets may be based on the number of SL grants (for example, including them). A WTRU may receive a PSFCH transmission, for example, from another WTRU. A PSFCH transmission may contain HARQ feedback. A WTRU may report HARQ feedback to the network, for example. A WTRU can determine the size of a second HARQ subcodebook based on the number of sidelink grants in a subset of one or more sidelink transmissions. The order of bits contained in the second HARQ subcodebook may be based on the order of the number of sidelink grants in a subset of one or more sidelink transmissions. A (for example, second) HARQ subcodebook may include HARQ feedback for a subset of SL transmissions according to a HARQ mode (for example, a second HARQ mode). A (for example, second) HARQ mode may include a three-state HARQ mode, which may include delayed HARQ, ACK, and NACK.

[0137] The processes and means described herein can be applied in any combination and can be applied to other wireless technologies and other services.

[0138] A WTRU can refer to physical device identification information, or user identification information such as subscription-related identification information, e.g., MSISDN, SIP URI. A WTRU can also refer to application-based identification information, such as a username that can be used on an application-by-application basis.

[0139] The processes described above can be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as CD-ROM discs and / or digital multi-purpose discs (DVDs). Software-related processors can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A method implemented by a wireless transceiver unit (WTRU), The steps include receiving configuration information that includes one or more predefined values ​​for one or more sidelink (SL) data characteristics, The steps include receiving an SL grant allocation from the network, A step of transmitting SL Hybrid Automatic Retransmission Request (HARQ) information in a second HARQ mode based on the fact that one or more predefined values ​​for one or more SL data characteristics are satisfied for the SL grant allocation, wherein the second HARQ mode includes a delayed HARQ. A step of transmitting SL HARQ information in a first HARQ mode based on the fact that one or more predefined values ​​for one or more SL data characteristics are not met for the SL grant allocation, wherein the first HARQ mode includes an acknowledgment / negation response (ACK / NACK) A method that includes [a certain feature].

2. A step to determine whether to use the first HARQ mode or the second HARQ mode, based on whether the one or more predefined values ​​for one or more SL data characteristics are satisfied for the SL grant allocation. The method according to claim 1, further comprising:

3. The method according to claim 1 or 2, wherein the one or more SL data characteristics include one or more of the following: a packet delay budget (PDB) value, a quality of service (QoS) value associated with a packet quality indicator (PQI), a supported logical channel, a supported slot, a physical sidelink feedback channel (PSFCH) location, a physical uplink (UL) control channel (PUCCH) transmission time, or an indication in downlink control information (DCI).

4. Steps to generate one or more of the following: a first HARQ subcodebook containing the SL HARQ information for the first HARQ mode, or a second HARQ subcodebook containing the SL HARQ information for the second HARQ mode. The method according to any one of claims 1 to 3, further comprising:

5. The step of determining whether to use the first HARQ mode or the second HARQ mode based on whether the one or more predefined values ​​for the one or more SL data characteristics are satisfied for the SL grant allocation includes deciding to use the first HARQ mode, The method according to claim 4, further comprising the step of adding one bit to the first HARQ subcodebook.

6. The step of determining whether to use the first HARQ mode or the second HARQ mode based on whether the one or more predefined values ​​for the one or more SL data characteristics are satisfied for the SL grant allocation includes deciding to use the second HARQ mode, The method according to claim 4, further comprising the step of adding two bits to the second HARQ subcodebook.

7. The step of receiving an SL grant allocation from the network includes receiving a first SL grant allocation from the network. The step of receiving a second SL grant allocation from the network, after one or more of the steps of adding one bit to the second HARQ subcodebook, or adding two bits to the first HARQ subcodebook. The method according to claim 5 or 6, further comprising:

8. Steps to determine whether to transmit one or more of the first HARQ subcodebooks or the second HARQ subcodebooks based on the physical sidelink feedback channel (PSFCH) transmission. The method according to any one of claims 4 to 7, further comprising:

9. The method according to any one of claims 1 to 8, wherein the SL HARQ information includes an indication of whether one or more SL resources are requested.

10. The method according to any one of claims 1 to 9, wherein the first HARQ mode includes a two-state HARQ mode, and the second HARQ mode includes a three-state HARQ mode.

11. A wireless transceiver unit (WTRU) equipped with a processor, wherein the processor is Receive configuration information that includes one or more predefined values ​​for one or more sidelink (SL) data characteristics, Receive SL grant allocation from the network, Based on the fact that the one or more predefined values ​​for the one or more SL data characteristics are satisfied for the SL grant allocation, SL hybrid automatic retransmission request (HARQ) information is transmitted in a second HARQ mode, the second HARQ mode includes a delayed HARQ, Based on the fact that one or more predefined values ​​for one or more SL data characteristics are not met for the SL grant allocation, the SL HARQ information is transmitted in a first HARQ mode, and the first HARQ mode includes an acknowledgment / negation response (ACK / NACK). A well-structured WTRU.

12. The WTRU according to claim 11, further configured to determine whether to use the first HARQ mode or the second HARQ mode based on whether the one or more predefined values ​​for the one or more SL data characteristics are satisfied for the SL grant allocation.

13. The WTRU according to claim 11 or 12, wherein the one or more SL data characteristics include one or more of the following: a packet delay budget (PDB) value, a quality of service (QoS) value associated with a packet quality indicator (PQI), a supported logical channel, a supported slot, a physical sidelink feedback channel (PSFCH) location, a physical uplink (UL) control channel (PUCCH) transmission time, or an indication in downlink control information (DCI).

14. The WTRU according to any one of claims 11 to 13, wherein the processor is further configured to generate one or more of the following: a first HARQ subcodebook containing the SL HARQ information for the first HARQ mode, or a second HARQ subcodebook containing the SL HARQ information for the second HARQ mode.

15. The processor configured to determine whether to use the first HARQ mode or the second HARQ mode based on whether one or more predefined values ​​for one or more SL data characteristics are satisfied for the SL grant allocation includes the processor configured to determine whether to use the first HARQ mode, The WTRU according to claim 14, further configured to add one bit to the first HARQ subcodebook.

16. The processor configured to determine whether to use the first HARQ mode or the second HARQ mode based on whether one or more predefined values ​​for one or more SL data characteristics are satisfied for the SL grant allocation includes the processor configured to use the second HARQ mode, The WTRU according to claim 14, further configured to add two bits to the second HARQ subcodebook.

17. The processor configured to receive SL grant allocations from the network includes the processor configured to receive a first SL grant allocation from the network, The WTRU according to claim 15 or 16, wherein the processor is further configured to receive a second SL grant allocation from the network.

18. The WTRU according to any one of claims 14 to 17, further configured to determine whether to transmit one or more of the first HARQ subcodebooks or the second HARQ subcodebooks based on a physical sidelink feedback channel (PSFCH) transmission.

19. The WTRU according to any one of claims 11 to 18, wherein the SL HARQ information includes an indication of whether one or more SL resources are requested.

20. The WTRU according to any one of claims 11 to 19, wherein the first HARQ mode includes a two-state HARQ mode, and the second HARQ mode includes a three-state HARQ mode.

Images