Reliable HARQ-ACK transmission in unlicensed spectrum

Abstract

Methods and apparatus for selective one-time hybrid automatic repeat request (HARQ) feedback at priority levels are described herein. For example, a wireless transmit / receive unit (WTRU) may determine a priority associated with each transport block (TB). Each TB may correspond to a respective HARQ process associated with a downlink transmission from a base station (BS). The WTRU may receive, from the BS, a request for the one-time HARQ feedback with an indication of a priority selected for the one-time HARQ feedback. The WTRU may generate a HARQ codebook for transmission of the one-time feedback. The HARQ codebook may include one or more information bits corresponding to one or more TBs determined based on the indicated priority. The WTRU may determine a transmission power based on a number of the one or more information bits, and transmit the one-time feedback including the generated HARQ codebook at the transmission power.

Description

[0001] This application is a divisional application, the parent application of which is entitled "Reliable HARQ-ACK Transmission in Unlicensed Spectrum", filed on February 11, 2021, with application number 202180019024.X.

[0002] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 62 / 975,535, filed February 12, 2020, and U.S. Provisional Application No. 63 / 060,960, filed August 4, 2020, the contents of which are incorporated herein by reference. Background Technology

[0003] Wireless transmit / receive units (WTRUs) supporting Ultra-Reliable Low-Latency Communication (URLLC) services can operate in 5G NR (NR-U) in unlicensed spectrum. Such WTRUs can benefit from all hybrid Automatic Repeat Request (HARQ) mechanisms (e.g., Type 2 or Type 3 codebooks) introduced for both URLLC and NR-U operation. However, under such HARQ mechanisms, ensuring reliable transmission of high-priority HARQ-acknowledgments (ACKs) may require high transmission power when the HARQ-ACK payload exceeds several bits. Furthermore, reporting HARQ-ACK information for all HARQ processes can lead to interference, power scaling, and / or a loss of reliability for the URLLCHARQ-ACK codebook. Therefore, methods and devices for reliable HARQ-ACK transmission are needed. Summary of the Invention

[0004] This document describes methods and apparatus for selective one-off Hybrid Automatic Repeat Request (HARQ) feedback based on priority levels. For example, a Wireless Transmit / Receive Unit (WTRU) may determine a priority associated with each Transport Block (TB). Each TB may correspond to a corresponding HARQ process associated with a downlink transmission from a Base Station (BS). The priority associated with each TB may be determined based on the priority of the corresponding previous Physical Downlink Shared Channel (PDSCH) transmission, the downlink transmission type (e.g., dynamic or semi-persistent scheduling), or a dynamic indication received from the BS (e.g., Downlink Control Information (DCI) or Medium Access Control (MAC) Control Element (MAC CE)). The WTRU may receive from the BS a request for one-off HARQ feedback with an indication of a priority selected for one-off HARQ feedback. The WTRU may generate a HARQ codebook for transmitting the one-off HARQ feedback. The HARQ codebook may include one or more information bits (e.g., Acknowledgment (ACK) bits and / or Negative Acknowledgment (NACK) bits) corresponding to one or more TBs determined based on the indicated priority. The WTRU can determine the transmission power based on the number of one or more information bits, and then transmit a one-time HARQ feedback including the generated HARQ codebook at that transmission power. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B This illustrates the implementation scheme. Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C This illustrates the implementation scheme. Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D This illustrates the implementation scheme. Figure 1A The system diagram shown illustrates another exemplary RAN and another exemplary CN used within the communication system. Figure 2 This is a diagram illustrating an example selective one-time hybrid automatic repeat request (HARQ) feedback procedure based on priority levels using the HARQ codebook; Figure 3 This is a diagram illustrating another example of a selective one-time HARQ feedback procedure; Figure 4A This is a diagram illustrating an exemplary HARQ feedback indexed; and Figure 4B This is a diagram illustrating an exemplary compression of indexed HARQ feedback. Detailed Implementation

[0006] Figure 1A This is a diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. Communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, broadcasting, etc., to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0007] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user 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 wearable devices, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0008] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112, etc. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation NodeBs such as gNode Bs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0010] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0012] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0013] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0014] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0015] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate Evolution of GSM (EDGE), GSMEDGE (GERAN), etc.

[0016] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106.

[0017] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0020] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving 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 peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0021] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0024] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

[0025] The processor 118 of WTRU 102 may be coupled to and receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any suitable type of memory (such as non-removable memory 130 and / or removable memory 132) and store data in such suitable memories. 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 user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in such memory.

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

[0027] 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) about 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 air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0028] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth.® Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0029] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception) may be concurrent and / or simultaneous.

[0030] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0031] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0032] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0034] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0035] The SGW 164 can connect to each of the evolved Node Bs 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0036] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0037] CN 106 may facilitate communication with other networks. For example, CN 106 may provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or may communicate with such an IP gateway. Furthermore, CN 106 may provide WTRUs 102a, 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.

[0038] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0039] In a representative implementation, the other network 112 may be a WLAN.

[0040] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that brings traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the AP and passed to the STA. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the 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 can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0041] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0042] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0043] Very High Throughput (VHT) STAs support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segmented parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream individually. These streams can be mapped to two 80MHz channels, and data can be transmitted via a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0044] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the Television White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., support only) specific bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0045] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs supporting (e.g., only supporting) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available bands remain idle.

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

[0047] Figure 1DThis is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can use NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0048] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In another implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an implementation, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0049] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0050] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as evolved Node B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node B 160a, 160b, and 160c. In a non-standalone configuration, evolved Node B 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0051] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, 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. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0052] Figure 1D The CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. AMF 182a and 182b can provide control plane functions for handover between RAN104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0054] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0055] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0056] CN 106 may facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or may communicate with such an IP gateway. Furthermore, CN 106 may provide WTRUs 102a, 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. In one embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local DNs 185a and 185b.

[0057] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the following, one or more of the functions described herein may be performed by one or more emulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B160a-160c, MME 162, SGW 164, PGW 166, gNB180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0059] One or more simulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device may be used in test scenarios within a test laboratory and / or a non-deployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation device to transmit and / or receive data.

[0060] To better support operations with different types of services such as URLLC and eMBB, mechanisms may exist to ensure that certain transmissions can be received with higher levels of latency and reliability. For example, depending on the priority level assigned to HARQ-ACK, HARQ-ACK can be transmitted according to one of two possible Physical Uplink Control Channel (PUCCH) configurations. This, for example, allows high-priority HARQ-ACK to be transmitted at a higher power level than low-priority HARQ-ACK.

[0061] Specifically, when operating in NR unlicensed spectrum (NR-U), there may be mechanisms for better implementation of HARQ-ACK transmission. A first mechanism, known as the "enhanced Type 2 codebook," allows the scheduler to request the transmission of HARQ-ACK information for certain PDSCH transmissions identified by the Physical Downlink Shared Channel (PDSCH) group. A second mechanism, known as the "Type 3 codebook" or "one-time feedback," allows the scheduler to request HARQ-ACK information for all HARQ processes and serving cells.

[0062] In some scenarios, WTRUs supporting Ultra-Reliable Low-Latency Communication (URLLC) services can operate in unlicensed spectrum (e.g., NR-U). Such WTRUs can benefit from all HARQ-ACK enhancements introduced for both URLLC and NR-U operation. However, if the HARQ-ACK payload exceeds a few bits, ensuring reliable transmission of high-priority HARQ-ACKs may require excessively high transmission power levels. For example, when a WTRU reports HARQ-ACK information using a Type 3 codebook (e.g., one-time feedback), the WTRU transmits HARQ-ACK information for all HARQ processes and cells. This can lead to excessive interference and / or power scaling, in which case Type 3 codebook reporting may not be effectively used. In some cases, enhanced Type 2 codebook mechanisms may not take into account HARQ-ACK priority. This may cause, for example, the WTRU to group high-priority HARQ-ACKs into resources unsuitable for this purpose.

[0063] Figure 2 An example selective one-off HARQ feedback procedure 200 based on priority levels using the HARQ codebook is shown, which can be used in conjunction with any other implementation described herein. Figure 2 As shown, the BS can transfer multiple (e.g., 16) TBs 205, 215, and 225 to the WTRU associated with the BS. Each TB (e.g., TB1 205, TB2 215, and TB3 225) can be associated with a HARQ process for HARQ feedback. Each HARQ process can be associated with a HARQ process ID (PID) (e.g., HARQ PID1, HARQ PID2, and HARQ PID3). Each HARQ process or HARQ PID can be associated with a corresponding priority. Figure 2As shown, the BS can, for example, use downlink control information (DCI) to indicate to the WTRU that TB1 / HARQ PID1 205 and TB2 / HARQ PID2 215 are associated with priority 0 (i.e., low priority). The BS can also, for example, use DCI to indicate to the WTRU that TB3 / HARQ PID3 225 is associated with priority 1 (i.e., high priority). After receiving multiple TBs (e.g., TB1-3205, 215, 225) from the BS, the WTRU can transmit HARQ feedback 210, 220 associated with the corresponding HARQ PIDs (i.e., HARQ PID1 and HARQ PID2). In one example, the WTRU can determine the priority associated with the HARQ process based on RRC configuration or dynamic downlink indications (such as DCI and MAC-CE). In the event that the WTRU misses RRC configuration or dynamic downlink indications, the WTRU can use different methods to determine the priority associated with the HARQ process. Examples of different approaches may include, but are not limited to, using the priority of the most recent PDSCH transmission with the received HARQPID, the downlink (DL) transmission type (such as dynamic assignment or semi-persistent scheduling), and / or the associated scheduling control resource set (CORESET) or search space.

[0064] The WTRU may fail to transmit HARQ feedback 230 for TB3 / PID3 due to a failure of pre-talk listening (LBT), or may discard the feedback due to a conflict with a higher priority transmission. Alternatively or separately, the BS may fail to receive HARQ feedback 230 for any reason. The WTRU may receive from the BS a request 235 for one-time HARQ feedback with an indication of a priority level (e.g., priority 1). The request 235 for one-time HARQ feedback may be included in, for example, a scheduled DCI or an unscheduled DCI with an indication of a priority level. Specifically, a tag indicating one-time HARQ feedback and another tag indicating the priority level may be transmitted to the WTRU in a scheduled DCI or an unscheduled DCI.

[0065] Upon receiving request 235 for a one-time HARQ feedback request with an indication of a priority level (e.g., priority 1), the WTRU can generate a HARQ codebook based on the indicated priority. Although in Figure 2Not shown, but assuming the WTRU can receive up to 16 TBs in total from the cell, it can determine a subset with priority 1 (e.g., TB3 / PID3 and TB10 / PID10). The HARQ codebook generated by the WTRU may include one or more ACK or NACK bits associated with TB3 / PID3 and TB10 / PID10. The codebook size may be determined based on the number of HARQ processes associated with the indicated priority (i.e., HARQ processes in the priority subset). In one example, the HARQ codebook may include ACK or NACK bits of HARQ processes (in the priority subset) where the priority associated with the HARQ process is equal to or higher than the indicated priority from the BS. In another example, when using or configuring a semi-static codebook size, the HARQ codebook may also include one or more NACK bits of HARQ processes in a non-priority subset, in addition to the ACK or NACK bits of HARQ processes in the priority subset. In this case, the priority (or priorities) associated with the HARQ processes in the non-priority subset is lower than the indicated priority. Once a HARQ codebook is generated based on the indicated priority, the WTRU can transmit a selective one-time HARQ feedback 240 to the BS, including the generated codebook.

[0066] Figure 3Another example of a selective one-time HARQ feedback procedure 300 is shown, which can be used in conjunction with any other implementation described herein. At step 305, the WTRU may receive a configuration from the BS, including the number of HARQ processes associated with a downlink transmission, via Radio Resource Control (RRC) signaling or a dynamic indication such as DCI or MAC-CE. At step 310, the WTRU may determine the priority associated with each TB. Each TB may correspond to a corresponding HARQ process associated with a downlink transmission. If the WTRU is configured with RRC signaling or receives a dynamic indication such as DCI or MAC-CE, the WTRU may determine the priority based on the RRC configuration, DCI, or MAC-CE. If the WTRU is not configured with RRC signaling or misses a dynamic indication such as DCI or MAC-CE, the WTRU may determine the priority based on the priority of a previous PDSCH transmission, the downlink transmission type, the associated scheduling CORSET, or the search space. When the WTRU determines the priority of a TB based on the priority of a previous PDSCH transmission, the WTRU may select the previous PDSCH transmission for the same HARQ process associated with the TB. For example, assuming TB3 is associated with HARQ process 3 and TB10 is associated with HARQ process 10, if WTRU determines the priorities of TB3 and TB10 based on previous PDSCH transmissions, then WTRU uses different previous PDSCH transmissions associated with HARQ process 3 and HARQ process 10, respectively, to determine the priorities of TB3 and TB10.

[0067] After determining the priority associated with the HARQ process or HARQ PID, at step 315, the WTRU may receive from the BS a request for one-off HARQ feedback with an indication of the priority selected for one-off HARQ feedback. The WTRU may receive the request for one-off HARQ feedback when it is unable to transmit HARQ feedback due to LBT failure, or when the BS does not receive HARQ feedback for a certain period of time. At step 320, the WTRU may generate a HARQ codebook for transmitting one-off feedback based on the received indicated priority. The generated HARQ codebook may include one or more information bits corresponding to one or more TBs or HARQ processes determined based on the indicated priority. These TBs or HARQ processes determined based on the indicated priority may form a priority subset. For example, TBs or HARQ processes with priorities equal to or higher than the indicated priority may be included in the priority subset. One or more information bits may include an acknowledgment (ACK) bit or a negative acknowledgment (NACK) bit. The generated HARQ codebook may include one or more ACK or NACK bits for TB or HARQ processes in a priority subset, wherein each priority associated with a TB or HARQ process in the priority subset is higher than or equal to the indicated priority. If the HARQ codebook size is determined or configured semi-statically, the HARQ codebook may also include one or more NACK bits for a non-priority subset, wherein each priority associated with a TB or HARQ process in the non-priority subset is lower than the indicated priority.

[0068] At step 325, the WTRU can determine the transmission power for the one-time HARQ feedback. This transmission power can be determined, for example, based on the number of information bits in the generated codebook, or based on the number of information bits of the highest priority in the generated codebook, or based on the number of information bits in each priority subset of the generated codebook. At step 330, the WTRU can transmit the one-time HARQ feedback, including the HARQ codebook generated based on the indicated priority, to the BS using the determined transmission power.

[0069] In one implementation, the WTRU may transmit a one-off HARQ-ACK feedback for a subset of the HARQ process associated with a priority level and / or serving cell to improve transmission reliability. This subset may be referred to herein as the “priority subset.” The report may be referred to as a “selective one-off HARQ feedback.”

[0070] Given its relaxed latency timeline, it may also be beneficial to bundle HARQ feedback for lower-priority transmissions while maintaining unbundled (e.g., normal) HARQ feedback for prioritized transmissions. This reduces the number of times HARQ feedback conflicts with other higher-priority uplink control information (UCI) or physical uplink shared channel (PUSCH) transmissions. Furthermore, this reduces the number of discarded HARQ feedbacks while allowing the network room to request HARQ feedback from the WTRU for more relaxed latency transmissions. This may also be a useful tool for the network to request feedback on discarded low-priority HARQ-ACK transmissions (e.g., due to conflicts with higher-priority transmissions) without retransmitting the associated TB, as the BS (e.g., gNB) is aware of missing some HARQ-ACK feedback due to, for example, intra-WTRU or inter-WTRU prioritization.

[0071] In some cases, there may be explicit indications for HARQ feedback. If a HARQ process is indicated by L1, MAC, or RRC signaling, the HARQ process may be included in or associated with a priority subset. Alternatively or separately, a HARQ process may be included in or associated with a priority subset indicated by a DCI that triggers a one-time HARQ feedback transmission. Indications to include a given HARQ process in a priority set / associate a given HARQ process with that priority set may include one or more of RRC signaling or dynamic signaling.

[0072] For example, the WTRU can be configured via RRC signaling to include a subset of HARQ processes as part of a one-off HARQ feedback, or possibly as part of a priority subset (if dynamically indicated). The RRC can also configure the mapping between HARQ process IDs and PDSCH group indices, or, more generally, configure a set of HARQ processes for which feedback can be reported together upon receiving an associated one-off HARQ feedback request. The RRC can configure the WTRU regarding the applicability of selective one-off feedback. The RRC can configure one or more priority levels for the WTRU that can be applied to one-off HARQ feedback.

[0073] In an example of dynamically triggering one-off HARQ feedback, the WTRU may receive a downlink control information (DCI) or media access control (MAC) control element (CE) indicating which HARQ process IDs are part of a priority subset. For example, the WTRU may receive a bitmap of HARQ process IDs, where 1 or 0 indicates whether a HARQ process ID is included in a priority subset. The WTRU may then include HARQ feedback only for the indicated HARQ processes that are part of a priority subset, such as after triggering a one-off HARQ feedback. In another example, the WTRU may receive a DCI or MAC CE indicating a set of priority levels or PDSCH group indices. Upon receiving a one-off HARQ feedback request indicating certain priority levels or PDSCH groups, the WTRU may include the HARQ processes associated with those priority levels or PDSCH groups as part of a "priority subset," for which the WTRU will provide HARQ feedback, for example, after triggering a one-off HARQ feedback.

[0074] Dynamic signaling can indicate a PDSCH group index configured by RRC or a set of HARQ processes. Upon receiving such a group index, the WTRU may consider mapping HARQ process IDs to the group index as part of a priority subset. The WTRU may associate HARQ processes with group indexes based on the mapping configured by RRC, or by maintaining the group indexes assigned to each PDSCH of the schedule. In one example, dynamic signaling can indicate a state index (e.g., a state for (de)activation of an SPS) associated with one or more DL semi-persistent schedules (SPSs) or configured authorized resources. Upon receiving such a state index, the WTRU may consider the HARQ process ID (PID) associated with that state as part of a priority subset.

[0075] Dynamic signaling can override a previously configured subset of priorities via RRC. For example, a WTRU can be configured with a default subset of priorities by RRC, which is used by default after triggering or receiving a one-time HARQ feedback request. If dynamic signaling indicates a different subset of priorities, the WTRU can override or temporarily suspend the default subset.

[0076] In some implementations, one-off HARQ feedback can be dynamically determined by receiving subsequent scheduling for the same HARQ PID or the same HARQ PID group. In one example, the WTRU can trigger one-off HARQ feedback and provide HARQ feedback for all HARQ process IDs mapped to the same PDSCH group index configured by RRC after receiving a retransmission of a HARQ PID belonging to the same PDSCH group index. In another example, the WTRU can trigger one-off feedback after receiving all HARQ process IDs for which the New Data Indicator (NDI) has not been switched after receiving a retransmission of a DL TB associated with the same PDSCH group index (e.g., the TB is pending in the HARQ buffer for these HARQ process IDs).

[0077] In some implementations, HARQ processes may be associated with certain serving cells. In one example, the WTRU may receive a one-time HARQ feedback request for a set of HARQ processes associated with a subset of serving cells. The WTRU may receive cross-carrier requests for HARQ feedback. For example, the WTRU may receive a one-time HARQ feedback request with a carrier index or control format indicator (CFI) field that indicates a carrier different from the carrier on which the request was received. Upon receiving such a request, the WTRU may include the HARQ PID (e.g., a subset of priorities) associated with the requested cell.

[0078] In another example, the WTRU may exclude HARQ PIDs associated with a different serving cell from the priority subset that received the one-off HARQ feedback request on. For example, the WTRU may be configured or may determine the mapping between each serving cell and a subset of HARQ processes; the WTRU may then exclude HARQ processes mapped to serving cells other than the serving cell on which the one-off HARQ feedback request was received.

[0079] In another example, the WTRU may determine cell priority based on associated services, data radio bearers (DRBs), or logical channels. For instance, the WTRU may receive a one-time HARQ feedback request for a certain priority level, and the WTRU may subsequently include the HARQ PID associated with that priority level for the same cell. In one example, the WTRU may determine cell priority based on configured LCH-to-cell constraints and / or the LCH-to-priority-level mapping configured by the RRC.

[0080] In some implementations, there may be HARQ processes or HARQ PIDs associated with certain HARQ-ACK priority levels. WTRU can track which HARQ processes (or HARQ PIDs) are associated with a particular priority level or codebook. A HARQ process may be included in a priority subset based on at least one aspect of the use of the HARQ process or the transmission associated with it.

[0081] In one example, one aspect of the transmission could be the priority level associated with the HARQ-ACK. For instance, after receiving a one-time HARQ feedback request for a subset of priorities, the WTRU could provide one-time HARQ feedback for one or more HARQ processes associated with that priority level. The WTRU can track the priority levels associated with the scheduled PDSCH to determine which HARQ processes match the indicated priority level.

[0082] In one example, one aspect of the transmission could be a PDSCH group or a codebook index. For instance, upon receiving a PDSCH group-based dynamic feedback request along with, or in the same time slot as, a one-off HARQ feedback request, the WTRU may exclude one or more HARQ processes or HARQ PIDs not associated with the indicated PDSCH group index from the priority subset. In a different example, if one-off HARQ feedback for those HARQ processes has already been provided in the same time slot in response to a PDSCH group-based dynamic feedback request, the WTRU may exclude one or more HARQ processes or HARQ PIDs from the priority subset. In another example, if the New Field Indicator (NFI) value for the HARQ process corresponding to its indicated PDSCH group has been switched, the WTRU may exclude one or more HARQ processes or HARQ PIDs from the priority subset. In different examples, WTRU can exclude one or more HARQ processes or HARQ PIDs that are not associated with the HARQ feedback codebook index or type (associated with a one-time HARQ feedback request), where the codebook type can be determined based on dynamic signaling, priority level, and / or whether the associated PUCCH resource occupies the entire time slot or sub-time slot.

[0083] In one example, one side of the transmission could be a PDSCH to HARQ-ACK (K1) value, such as whether K1 is a numerical value.

[0084] In one example, one aspect of the transmission may be a control resource set (CORESET) for indicating the transmission using a DCI. For instance, if the nature of the PDCCH resources (e.g., CORESET, RNTI, search space) associated with the scheduling of the PDSCH is associated with a given priority level or subset of priorities and / or meets reliability suitability criteria configured by the RRC, the WTRU may associate a HARQ process or HARQ PID with a priority level or include it in a priority subset. In another example, the WTRU may be configured to have multiple transmit and receive points (TRPs) within the serving cell, whereby each TRP may be associated with a PDCCH, a subset of PDCCH resources, or a subset of coresets. The WTRU may receive a one-off HARQ feedback request from a TRP. The WTRU may include a HARQ process (or HARQ PID) associated with the TRP from which it receives a one-off HARQ feedback request portion of a priority subset. In different examples, the WTRU may include a HARQ process (or HARQ PID) associated with a TRP that is different from the TRP of the same WTRU, such as a TRP that receives a subset of priority from which it receives a one-time HARQ feedback request portion after receiving an indication.

[0085] In one example, one aspect of the transmission could be whether the HARQ process has successfully decoded and provided HARQ feedback. For instance, if the WTRU has provided HARQ feedback for the associated TB and the TB has been successfully decoded, the WTRU can exclude the HARQ PID from the priority subset. In different examples, the WTRU may include the HARQ process in the priority subset only if the associated TB has not yet been successfully decoded.

[0086] In one example, one side of the transfer could be an NDI, where the WTRU could include the HARQ process (or HARQ PID) in a priority subset if the HARQ process’s NDI has not been switched and there are pending TBs in the associated HARQ buffer.

[0087] In one example, one aspect of the transport could be a PDSCH resource type. For instance, the WTRU could include a HARQ PID for semi-persistent scheduling (SPS), or it could exclude dynamic assignments from the priority subset. In different examples, the WTRU could include HARQ processes in the priority subset if the associated PDSCH resource meets a certain reliability criterion.

[0088] In one example, one aspect of the transmission could be a cell or a bandwidth portion (BWP). For instance, if the corresponding PDSCH for certain HARQ processes (or HARQPIDs) is scheduled on a different BWP and / or cell than the one that received the one-off HARQ feedback request, the WTRU may exclude one or more of these HARQ processes from the priority subset. In another example, the one-off HARQ feedback request may indicate a cell or BWP; the WTRU may include only the HARQ process ID associated with the indicated cell and / or BWP in the priority subset.

[0089] In one example, one aspect of the transfer could be that the WTRU includes one or more HARQ processes (or HARQ PIDs) associated with the same processing timeline, a pipeline, and / or a processing chain in a priority subset to match the processing pipeline, processing capacity, and / or scheduling timeline indicated or determined by the DCI.

[0090] In one example, one aspect of the transmission could be whether HARQ feedback is disabled. In some systems, HARQ feedback can be disabled over the network for certain HARQ processes or HARQ PIDs, such as via RRC or dynamic signaling. The WTRU may assume that HARQ PIDs with disabled HARQ feedback are excluded from the priority set. In different examples, the WTRU may include only HARQ processes or HARQ PIDs with disabled HARQ feedback in the priority set after receiving a one-time HARQ feedback request.

[0091] As described above, downlink transmissions considered for HARQ feedback may include, but are not limited to, at least one of the following: the last PDSCH transmission before triggering a one-off HARQ feedback; the PDSCH in the last downlink portion of the radio frame configuration in TDD; the PDSCH in the last scheduled Channel Occupancy Time (COT); the PDSCH scheduled within a time window before evaluating a subset of priorities (e.g., a subset of the HARQ process for which the WTRU provides HARQ-ACK feedback); the PDSCH scheduled within a time window before receiving a DCI requesting one-off HARQ feedback, and / or more generally, before triggering a one-off HARQ feedback; downlink TBs for which the time since the initial transmission has not exceeded a certain time threshold, which may be predefined or semi-statically configured by RRC; the PDSCH for which the WTRU has sufficient time to process the TB and determine the HARQ-ACK value; and / or any previously scheduled PDSCHs for which the TB is stored in the HARQ process buffer.

[0092] When determining which processes to include in HARQ feedback for a given priority level, the time can be based on the time of receiving the DCI for a one-time HARQ feedback, or the earliest possible time of transmitting the feedback (e.g., in some cases where LBT is not used, or if WTRU processing makes the transmission possible). Additionally, the time of the initial HARQ transmission and / or the last transmission (e.g., DCI reception or actual transmission) for a given process can be considered.

[0093] In some implementations, HARQ feedback for DL ​​semi-persistent (SPS) transmissions may be present. In one example, the WTRU may be configured to use selective one-off HARQ feedback to send HARQ-ACK feedback and / or SPS release acknowledgments for semi-persistent (SPS) downlink transmissions. For example, the WTRU may be configured with multiple selective one-off HARQ feedbacks, each with a given priority. The WTRU can then use configuration parameters of the DL SPS to determine the priority of the DL SPS. In one example, the semi-static configuration of the DL SPS may include priority parameters that can be mapped to selective one-off HARQ feedbacks, or the configuration may directly map the configuration to selective one-off HARQ feedbacks. In another example, the WTRU may dynamically determine selective one-off HARQ feedbacks based on, for example, the HARQ PID used for DL ​​transmissions. For example, the WTRU may be configured with DL SPS resources for which a time-dependent formula is used to calculate the HARQ PID associated with the PDSCH transmission. The WTRU may also be configured with selective one-off HARQ feedback based on HARQ PIDs, such as selective one-off HARQ feedback for a subset of HARQ PIDs. After determining the HARQ process (or HARQ PID) for a given PDSCH transport, WTRU can use the corresponding selective one-time feedback to confirm the HARQ process.

[0094] In another example, the WTRU may determine a selective one-time HARQ feedback to associate / transmit an acknowledgment of the SPS release using a DCI indicating the SPS release. Such a DCI may reuse some bit fields from existing bit fields to indicate the associated selective one-time HARQ feedback. In one example, the Time Domain Resource Allocation (TDRA) field may be reused to indicate the associated selective one-time HARQ feedback. For example, the WTRU may be configured with a mapping between TDRA code points in the DCI and the selective one-time feedback. Such a mapping may be semi-statically configured using RRC configuration or alternatively fixed in the specification.

[0095] In one example, upon receiving the DCI indicating the release of the SPS configuration, the WTRU can be triggered to transmit a selective one-off HARQ feedback associated with the ACK / NACK of the SPS release. The WTRU can use the PUCCH resource indication and HARQ-ACK feedback timing indicated in the DCI. The WTRU can then transmit all ACK / NACK bits of the previously transmitted PDSCH associated with the indicated selective one-off HARQ feedback. If the indicated PUCCH resource overlaps with a PUSCH, the WTRU can be configured to piggyback the selective one-off HARQ feedback on the PUSCH. The WTRU can be configured to piggyback the selective one-off HARQ only if the PUSCH grant satisfies one or more of the following: the priority associated with the PUSCH grant is equal to or higher than the priority associated with the selective one-off feedback; and / or the time difference between the end symbol of the indicated PUCCH and the end symbol of the PUSCH is less than a configured threshold.

[0096] In some implementations, there may be a maximum number of processes for selective one-time HARQ feedback. Specifically, there may be a maximum number of HARQ processes (or HARQ PIDs) that can be included in a priority subset.

[0097] The WTRU can construct a dynamic or semi-static HARQ feedback codebook for a one-off HARQ feedback request using a priority subset. For a dynamic codebook, the WTRU can determine the maximum number of HARQ processes (or HARQ PIDs) to be included in the priority set based on the total downlink assignment index (DAI) value. For example, if the total DAI is signaled in part of a one-off HARQ feedback request for a given priority set, the WTRU can determine the number of HARQ processes in the evaluation period based on the {cDAI, tDAI} values ​​previously scheduled for each PDSCH.

[0098] The WTRU can determine the maximum number of HARQ processes (or HARQ PIDs) that can be semi-statically included in a priority subset, such as based on the number of HARQ processes configured for each serving cell. In one example, the WTRU can be configured with 3 serving cells, and 16 HARQ processes per cell. Assuming one cell is not suitable for priority level x or codebook index x, the WTRU can assume a maximum of 32 HARQ processes in the codebook built for a one-time HARQ feedback for priority level x. Assuming all cells support any priority level, the WTRU can assume a maximum of 48 HARQ processes. In another example, the WTRU can be configured by RRC such that only 8 of the 16 HARQ processes in a cell can be included in the priority set; under such a configuration, the WTRU can assume a maximum of 8 HARQ processes per cell in the codebook built for a one-time HARQ feedback. WTRU can further deduce the number of HARQ processes that are disabled based on the determined maximum number of HARQ processes (or HARQ PIDs) that can be included in the priority subset.

[0099] In one example, the WTRU can be configured via RRC to have a maximum number of HARQ processes that can be included in the priority subset; however, in some cases, the WTRU may have already determined a larger number of HARQ processes that meet the priority subset inclusion criteria. In such a configuration, the WTRU can sort the HARQ processes in the priority subset by priority order, time since the initial transfer, time since K1, highest LCH priority, and / or HARQ PID index.

[0100] In some implementations, selective one-time HARQ feedback and power settings can be encoded. The WTRU can be scheduled using DL transmissions with different priorities. The WTRU can use the priority of the DL transmissions to determine the associated priority level of the feedback. The WTRU can be configured to report feedback from all TBs (e.g., HARQ processes and / or serving cells) for a specific priority (e.g., all TBs forming a subset of the priority).

[0101] In some cases, multiple sets of HARQ processes (or HARQ PIDs) and serving cells can be configured (e.g., semi-statically configured) for transmissions of a specific priority and can form semi-static priority subsets. The WTRU can be requested to provide feedback for all HARQ processes (or HARQ PIDs) and serving cells associated with one or more priority subsets. In another case, HARQ processes (or HARQ PIDs) and / or serving cells can be used for transmissions in any of multiple priority levels. In this case, the HARQ processes (or HARQ PIDs) and serving cells constituting the priority subsets can be dynamically changed.

[0102] The WTRU can receive one-time HARQ feedback requests from the network associated with one or more priority levels (e.g., priority subsets). When the priority subset is configured semi-statically, the size of the codebook used to report the HARQ feedback is likely clear to both the WTRU reporting the feedback and the BS (e.g., gNB) detecting / decoding the feedback. When the priority subset is dynamically determined by the WTRU based on scheduling information transmitted for each specific DL, if the WTRU erroneously detects one or more scheduled DCIs, the WTRU and the BS (e.g., gNB) may interpret the codebook size and the location of a specific HARQ-ACK value within the codebook differently.

[0103] In some implementations, a downlink assignment index (DAI) may exist for each priority subset, where a priority subset-specific DAI (e.g., a counter or total DAI) can be indicated to the WTRU in each scheduling instance. Based on the priority subset-specific DAI, the WTRU may be able to determine whether one or more DCIs were misdetected for that priority subset, and more importantly, how many DCIs were misdetected within the HARQ feedback codebook and where they were located. A one-time feedback request may also indicate to the WTRU the expected size of the codebook (e.g., the final total DAI).

[0104] In some implementations, the WTRU may be instructed to report HARQ processes (or HARQ PIDs), where the WTRU may provide an index for each HARQ-ACK feedback or a set of HARQ-ACK feedback reports. For example, upon receiving a request for a subset of transmission priorities for a one-time HARQ feedback, the WTRU may construct a codebook based on feedback from all HARQ processes and serving cells that have received scheduling at that priority level. The WTRU may include an index in the first set of bits indicating the HARQ processes and serving cells that provide HARQ-ACK values. The WTRU may include feedback from all HARQ processes and serving cells that have a priority equal to or higher than the requested priority for DL ​​transmissions.

[0105] In another example, the index can be applied to a subsequent set of HARQ-ACK bits. For instance, the index could point to a set of HARQ processes and / or serving cells, and subsequent bits could provide the HARQ-ACK status of that set of HARQ processes and / or serving cells. In such an example, the WTRU could report feedback for all HARQ process groups and / or serving cells, ensuring that all HARQ processes and / or serving cells with the desired priority level are reported.

[0106] If some HARQ processes and / or serving cells are not actually used for DL ​​transports, the WTRU may include NACKs for such HARQ processes / serving cells. In this example, some HARQ processes and / or serving cells may not actually be used for DL ​​transports at the requested priority level, but may have been used for transports at lower (or higher) priority levels. In this case, the WTRU may report HARQ-ACKs or NACKs for those processes.

[0107] In some instances, there may be feedback requests indicating HARQ process groups. It is also possible that a one-time HARQ feedback request explicitly requests the WTRU to provide feedback for the HARQ process group in the one-time HARQ feedback. For example, the WTRU may be configured with M groups of HARQ processes and serving cells. The WTRU may receive one-time HARQ feedback requests that explicitly request feedback for one or more groups of HARQ processes within the M groups (e.g., regardless of the priority level of each transmission within each fixed group).

[0108] After requesting HARQ-ACK feedback for one or more groups of HARQ processes in a pre-configured set of M groups of HARQ processes, the WTRU may construct a codebook of appropriate size (e.g., the sum of all elements of the requested group). The WTRU may also append HARQ-ACK feedback for a specific priority subset of HARQ processes not included in the request. For example, the WTRU may be requested to report feedback for a first group covering all HARQ processes in a first serving cell. The WTRU may also schedule high-priority DL transmissions on HARQ processes in a second cell. The WTRU may report (e.g., in the first cell) all feedback statuses of the requested group of HARQ processes and may append HARQ-ACKs of high-priority HARQ processes transmitted in the second cell to the codebook. Feedback transmitted by the WTRU may include a bit string indicating the appended high-priority HARQ-ACK feedback. Feedback transmitted by the WTRU may also include an index identifying each or the group of appended high-priority HARQ-ACK feedbacks.

[0109] In one scenario, a one-time HARQ feedback request may provide the WTRU with a set of HARQ processes for which it has reported HARQ-ACK feedback. Furthermore, a one-time HARQ feedback request may include the priority level (or subset of priorities) for which the WTRU should provide the required feedback (possibly by appending to the codebook). The WTRU may report feedback for the requested priority level and / or potentially higher priority levels for all HARQ processes.

[0110] Figure 4A An exemplary indexed HARQ feedback 400 is shown, which can be used in conjunction with any other implementation described herein. Figure 4A As shown, an exemplary HARQ feedback 400 for multiple HARQ processes may include HARQ process index types 405, 420, 435, HARQ process index fields (HPIF) 410, 425, 440, and HARQ-ACK bit strings 415, 430. Each of the HARQ process index types 405, 420, 435 may include bits indicating 0 or 1. Bit 0 in the HARQ process index types 405, 420, 435 may indicate that the HARQ process ID associated with the subsequent HARQ-ACK bit string can be determined based on the preceding HARQ index value and / or HPIF. Bit 1 in the HARQ process index types 405, 420, 435 may indicate that the HARQ process ID associated with the subsequent HARQ-ACK bit string is not explicitly indicated, and (i.e., HPIF is not included), and the HARQ process ID associated with the subsequent HARQ-ACK bit string may be determined as the value immediately following the previous HARQ process ID in the codebook. Each of HPIFs 410 and 425 may include an index value of the HARQ process associated with HARQ-ACK bit strings 415 and 430, respectively. Reserved HPIF values ​​can be used to indicate the end of the codebook. For example, HPIF 440 may include 0000 as an index value to indicate that it is the end of the codebook. HPIFs 410 and 425 may not exist if the preceding HARQ process index type is 1. In one example, if the WTRU needs to report HARQ-ACK feedback for the 3rd, 7th, and 10th HARQ processes, the WTRU may include the index values ​​and HPIFs associated with the 3rd, 7th, and 10th HARQ processes in the HARQ-ACK feedback. In this case, the preceding HARQ process index type of the HPIFs associated with the 3rd, 7th, and 10th HARQ processes is 0.

[0111] Figure 4BAn exemplary comparison 450 of indexed one-time HARQ feedback is shown, which can be used in conjunction with any other implementation described herein. To reduce feedback overhead, the WTRU may not report an index for each HARQ-ACK feedback it reports. Figure 4B As shown, an exemplary codebook may include HARQ feedbacks 465, 475, and 490 for the 3rd, 4th, and 10th HARQ processes. In this example, if the HARQ-ACK feedback is not a direct follow-up to a previous HARQ-ACK feedback, the WTRU may only report the index of the HARQ-ACK feedback it reports. For example, if the WTRU needs to report HARQ-ACK feedback for the 3rd, 4th, and 10th HARQ processes, the HARQ-ACK feedback may include index 460 (i.e., 0011) for the 3rd HARQ process, exclude the index for the 4th HARQ process (e.g., considering that there are no other HARQ processes that can provide feedback between the two HARQ processes), and include index 485 (i.e., 0110) for the 10th HARQ process. As described above, bit 1 in HARQ process index type 470 may indicate that the index value or HPIF associated with the 4th HARQ process is not present in the codebook. The index can also be absolute (e.g., indicating an absolute HARQ PID) or relative (e.g., indicating a HARQ PID relative to the immediately preceding HARQ-ACK value). For each HARQ-ACK feedback, the WTRU can report the first bit indicating the index type (e.g., HARQ process index type 455, 470, 480, 495), followed by the bit string indicating the index (e.g., HPIF 460, 485, 497), and finally the actual HARQ-ACK value (e.g., HARQ-ACK bit string 465, 475, 490). For example, for the case of transmitting HARQ-ACK feedback for the 3rd, 4th, and 10th HARQ processes, the WTRU can construct as follows: Figure 4B The codebook shown.

[0112] The bit indicating the index type can also indicate whether an index is provided for HARQ-ACK feedback. Furthermore, the index can be used to indicate that no other HARQ-ACK feedback exists in the codebook. The index can also provide the identity of a subsequent set of HARQ-ACK feedbacks, making it possible for each HARQ process to not require an index or index type bit.

[0113] In some implementations, CBG-level feedback may be present. WTRU can be configured with different types of feedback for different priority levels. For example, TB-level feedback can be used for high-priority HARQ processes, and CBG-level feedback can be used for lower-priority HARQ processes. In this case, WTRU can use duplicate feedback for HARQ processes using TB-level feedback. This ensures that all feedback for all HARQ processes uses the same amount of payload. Using duplicate feedback for high-priority feedback improves the reliability of such feedback.

[0114] In some implementations, a power setting may exist. The WTRU may use a predetermined and potentially configurable codebook size to report one-off HARQ feedback. The WTRU may have fewer bits for feedback than the predetermined codebook size provides. Therefore, the WTRU may fill the codebook (e.g., with NACK values ​​or bits) at locations mapped to HARQ processes for which the WTRU does not need to provide feedback. For example, this may occur in situations where the WTRU provides indices pointing to multiple HARQ processes, but the WTRU does not have feedback for all the HARQ processes pointed to by those indices. When determining the power setting for transmitting feedback, the WTRU may consider only the payload size as the number of bits used for the actual feedback, regardless of the padding bits.

[0115] The power setting can be determined based on the number of HARQ-ACK bits for a specific priority subset. For example, the power setting can be determined based on the number of bits used to feed back the HARQ-ACK for the highest priority transmission. In another example, the power setting can be determined based on the number of bits used to feed back the HARQ-ACK for the highest priority transmission and the total codebook size or total number of information bits. In yet another example, the power setting can be determined based on the number of bits used to feed back the HARQ-ACK for requested, predetermined, or configurable priority transmissions, as well as any other possible higher priority transmissions.

[0116] In another example, the power setting can be determined based on the number of HARQ processes in the requested priority subset, regardless of whether there is actual feedback for all such HARQ processes.

[0117] In another example, the power setting can be determined by the last received DAI (e.g., total DAI). Such a value can be obtained from the most recently scheduled DL transmission or from a one-time HARQ feedback request.

[0118] The PUCCH resource configuration can be obtained from the PUCCH configuration corresponding to the priority associated with the HARQ-ACK included in the codebook. This resource configuration includes at least PUCCH resources, sub-slot configurations, and PUCCH power control parameters. Alternatively or separately, the WTRU may have a separate PUCCH configuration for each configuration of selective one-off HARQ feedback, such as each priority level.

[0119] In some implementations, there may be techniques for triggering selective one-off HARQ feedback. The WTRU may be configured with multiple selective one-off HARQ feedbacks, each associated with a given priority. In some cases, the WTRU may be configured to transmit selective one-off HARQ feedback upon the occurrence of at least one event or a combination of events.

[0120] An event of transmitting selective one-off HARQ feedback can occur after receiving a DCI. For example, a WTRU can be configured to transmit selective one-off HARQ feedback after receiving a DCI for a HARQ process that is scheduled to be associated with a high-priority transmission. Such a DCI may carry an explicit indication to trigger feedback, or alternatively, receiving such a DCI alone may trigger selective one-off HARQ feedback. In another example, the WTRU might receive a DCI for an unscheduled PDSCH (e.g., an unscheduled DCI). For example, a DCI that triggers an aperiodic CSI report can also be used to trigger one-off feedback.

[0121] One such event regarding the transmission of selective one-off HARQ feedback can occur after a failure to receive a HARQ retransmission. For example, the WTRU receives the first transmission of a HARQ PID within a priority subset (e.g., a subset of the DL HARQ process). The WTRU may then fail to correctly decode the transmission and report a NACK to the BS (e.g., gNB). The WTRU may autonomously transmit one-off HARQ feedback after a timer expires. This timer may be semi-statically configured for the WTRU or fixed in the specification. The timer duration may depend on the priority of the downlink transmission. In another example, the WTRU may transmit one-off HARQ feedback if the Channel Occupied Time (COT) ends without a HARQ retransmission. The COT may be initiated by the BS (e.g., gNB) or the WTRU and shared with the BS (e.g., gNB). In yet another example, the WTRU may trigger autonomous one-off HARQ feedback after a certain number of failed retransmissions for the same TB, where the number of failed transmission thresholds is predetermined or semi-statically configured.

[0122] One such event regarding the transmission of selective one-off HARQ feedback can occur after a failure to access the channel. For example, due to a failure of pre-talk listening (LBT), the WTRU is unable to transmit HARQ-ACK feedback (e.g., one-off HARQ feedback or HARQ codebook). The WTRU then autonomously transmits selective one-off HARQ feedback on the next available opportunity to access the channel.

[0123] One such event regarding the transmission of selective one-off HARQ feedback can occur after a HARQ-ACK is a NACK for a HARQ PID within a priority subset (a subset of DL HARQ processes), and the WTRU autonomously transmits one-off HARQ feedback. For example, the WTRU can be configured with multiple selective one-off HARQ feedbacks corresponding to a subset of HARQ processes. If only one NACK for a subset of HARQ processes is determined, the WTRU can transmit a prioritized one-off HARQ feedback. In another example, if the number of NACKs in the applicable priority subset exceeds a certain threshold, the WTRU can trigger an autonomous one-off HARQ feedback.

[0124] One such event regarding the transmission of selective one-off HARQ feedback can occur after preemption and / or failure in transmitting HARQ-ACK feedback. The WTRU may discard HARQ-ACK transmissions and transmit selective one-off HARQ feedback. For example, the WTRU may be configured with HARQ-ACK transmission resources that overlap with higher-priority uplink transmissions. In another example, WTRU HARQ-ACK transmission resources may overlap with higher-priority downlink transmissions.

[0125] One such event regarding the transmission of selective one-time HARQ feedback can occur after a decision related to discarding a scheduled HARQ-ACK is made due to priority allocation between or within WTRUs. For example, a WTRU may trigger autonomous selective one-time HARQ feedback after discarding a scheduled HARQ-ACK and / or after canceling priority allocation during HARQ-ACK transmissions for one or more HARQ processes in a priority subset.

[0126] One such event regarding the transmission of selective one-off HARQ feedback can occur after a failure to receive a DL signal / channel. For example, a WTRU can be configured to monitor COT structure indications from a BS (e.g., gNB) over a set of monitoring slots. After failing to receive a COT indication for N consecutive time slots, the WTRU can autonomously transmit selective one-off HARQ feedback. This approach can be useful if a NACK-to-ACK error occurs and no DL traffic is scheduled for the WTRU.

[0127] One such event regarding the transmission of selective one-time HARQ feedback can occur after a timer expires. The WTRU can be configured with a timer that is updated based on a subset of the HARQ PIDs. For example, the timer is reset after receiving a downlink schedule with a HARQ PID from a subset of the HARQ PIDs. In another example, the WTRU can reset the timer each time it receives a DCI schedule. The timer value can be semi-statically configured by RRC. The WTRU can start the timer based on the priority level and / or the value of the PDSCH group index indicating the PDSCH.

[0128] In some implementations, there may be techniques for resource selection for selective one-off HARQ feedback. The WTRU can determine the resources on which the feedback will be transmitted based on the content and priority of the feedback. For example, the WTRU may have a set of feedback resources, and some feedback resources may be associated with specific priority levels. If the feedback includes feedback that is only for transmission to, or at least for, the associated priority level, then the WTRU can only use such feedback resources.

[0129] The WTRU can be configured with different feedback resource types. For example, the WTRU can be configured with PUCCH resources, cell group (CG) resources, scheduling request (SR) resources, and random access resources (e.g., for 2-step or 4-step RA). The WTRU can determine the resource type available for UCI feedback (e.g., HARQ-ACK feedback) based on the priority level of the transmitted feedback. For example, for the highest priority subset of feedback, the WTRU can use any feedback resource type and therefore can select the first available feedback resource. In another example, for feedback of different priority subsets, the WTRU can only select either the PUCCH or CG resource type and can determine the appropriate feedback resource timing based on the timing of the last DL transmission of the feedback report.

[0130] WTRUs can use dynamically scheduled PUSCH resources to transmit UCIs (e.g., HARQ-ACK feedback). The selection of such PUSCH resources can be determined based on whether the WTRU is scheduled to feed back UCIs in the same time slot. In another example, the selection of such PUSCH resources can be determined based on the priority of HARQ-ACK feedback and the timing of the PUSCH resources. For example, the WTRU may have a HARQ-ACK codebook consisting of high-priority feedbacks. WTRUs can be scheduled using PUSCHs that appear before the timing of the next upcoming available feedback resource. WTRUs can autonomously transmit UCIs on the scheduled PUSCHs. Such decisions to autonomously multiplex UCIs onto PUSCHs can depend on the priority level of the UCIs. This can also depend on the timing of the PUSCH transmission. For example, this might be feasible (e.g., the only feasible) for the first PUSCH with a certain Channel Occupancy Time (COT).

[0131] The WTRU can provide the BS (e.g., gNB) with an indication that the UCI is included in the PUSCH. In another example, the DCI that schedules the PUSCH can also trigger a HARQ-ACK feedback report, which may include a subset of the expected priorities.

[0132] WTRU can determine the appropriate power setting parameters (e.g., β offset) for UCI based on the priority of UCI and the priority of PUSCH transmission.

[0133] The WTRU can autonomously determine the transmission of a UCI based on the presence of any pending high-priority UCIs for transmissions scheduled with a non-numerical K1 value. For example, when an associated DL transmission is scheduled with a non-numerical K1 value, the WTRU may always include the UCI of the high-priority data in the first available PUSCH resource. In such an example, the WTRU may accumulate HARQ-ACK feedback for all high-priority transmissions scheduled with a non-numerical K1 value and may transmit the UCI of that set at either the first available feedback resource or the PUSCH resource.

[0134] In some implementations, overlapping selective one-off HARQ feedbacks may exist. In one instance, the WTRU may be configured to prioritize selective one-off HARQ feedbacks and / or selective one-off HARQ feedbacks and other HARQ-ACK codebooks (e.g., dynamic HARQ-ACK codebooks or semi-static HARQ-ACK codebooks) in the event of uplink resource overlap. In one case, the WTRU may be configured to prioritize only a HARQ feedback using the priority associated with it. The priority associated with a selective one-off HARQ feedback may be determined based on one or more methods disclosed herein, such as those presented above. In another case, the WTRU may be configured to prioritize the last triggered one-off HARQ feedback. For example, the WTRU may receive a request to transmit a first selective one-off HARQ feedback in slot n, and subsequently receive another request for a second selective one-off HARQ feedback. The WTRU may prioritize the triggered second selective one-off HARQ feedback.

[0135] In another example, the WTRU can be configured to multiplex multiple selective one-off HARQ codebooks within a single HARQ codebook. The WTRU can sort the scheduled selective one-off HARQ feedbacks in ascending order and determine the number of HARQ feedbacks to be multiplexed based on one or more of the following: the last indicated PUCCH resource (e.g., the WTRU can determine how many HARQ codebooks to multiplex based on the payload of the last indicated PUCCH resource); and / or, in the case of multiplexing UCI on a PUSCH, the resources within the PUSCH available for HARQ-ACK UCI (e.g., a beta factor for HARQ transport indications within the PUSCH).

[0136] In one implementation, there may be PDSCH packets with multiple HARQ-ACK priorities. In some cases, the WTRU may be configured with a dynamic HARQ-ACK codebook for each priority (e.g., where the size of the HARQ-ACK codebook can change dynamically for each priority). One example of a dynamic HARQ-ACK codebook for each priority may be based on PDSCH packets specified in the NR (Not Allowed). Another example may be based on a dynamic HARQ-ACK codebook specified in the NR. As described herein, there may be methods that support a dynamic HARQ-ACK codebook for each priority using existing PDSCH packet implementations.

[0137] In some implementations, a mapping may exist between PDSCH groups and service / priority types. In one instance, the WTRU can be configured to semi-statically associate one or more PDSCH groups with service / priority types. For example, the WTRU can use RRC signaling to receive the mapping between PDSCH group indices (e.g., the g parameter used in NR-U) and service / priority types. In other instances, dynamic indications of service / priority types can be used to dynamically indicate the association between PDSCH groups and service / priority types. For example, the WTRU can be configured to support multiple (e.g., two) types of service / priority and multiple (e.g., two) PDSCH groups. After determining the service type of a scheduled PDSCH, the WTRU can use the PDSCH group indication used in the PDSCH scheduling and associate the service type with the PDSCH group index. This allows for a reduction in the overhead of URLLC type services scheduled in DCI format. For example, if compact DCI is used, the WTRU may not receive an indication of which PDSCH group a scheduled PDSCH is associated with. The WTRU can use the service / priority indication and then associate the feedback with the configured PDSCH group for the URLLC.

[0138] In cases where there is a dynamic mapping between PDSCH groups and service / priority types, the WTRU can be configured to reset / refresh the HARQ-ACK bits of the PDSCH group when it receives a downlink assignment with the same PDSCH group index but a different priority / service type. For example, in the first COT, the WTRU can schedule traffic with a PDSCH associated with priority 1 (e.g., eMBB type traffic) of PDSCH group 1. In subsequent COTs, the WTRU can schedule traffic with a PDSCH associated with priority 2 (e.g., URLLC type traffic) of PDSCH group 1. The WTRU can then refresh, for example, the HARQ-ACK codebook 1 associated with PDSCH group 1 and use that codebook for traffic with priority 2. This solution can be useful if high-priority services scheduled in the DCI format do not have a New Feedback Indicator (NFI). For example, a compact DCI can be used to schedule URLLC type services. To keep the DCI size small, such a DCI may not support the NFI bit field. The WTRU can be configured to receive NFI only in a subset of the DCI format. Upon receiving a DCI with the same PDSCH group index and NFI bit fields, the WTRU may follow the NFI instructions from the network. In other cases, the WTRU may be configured to autonomously switch NDI / reset / refresh the HARQ-ACK codebook for a PDSCH group after a timer expires and no PDSCH scheduling has been received for that PDSCH group associated with a given priority / service type (e.g., URLLC). The timer value may be configured by RRC or fixed in the specification.

[0139] In some implementations, there may be a triggering event for transmitting the HARQ-ACK codebook of a PDSCH group. The WTRU can be configured to autonomously transmit a dynamic HARQ-ACK codebook for each priority based on the triggering event described for a one-time HARQ feedback. Furthermore, the WTRU can be configured to autonomously transmit the HARQ-ACK codebook of a PDSCH group when the WTRU determines that the service / priority type associated with the PDSCH group has changed. For example, the WTRU may schedule a PDSCH belonging to PDSCH group 1, and this PDSCH is associated with priority 2 (e.g., an eMBB type service). In a subsequent transmission, the WTRU receives a PDSCH belonging to PDSCH group 1, and this PDSCH is associated with priority 1 (e.g., a URLLC type service). The WTRU can then transmit the HARQ-ACK codebook associated with the previously constructed PDSCH group 1 and reset / refresh the HARQ-ACK codebook.

[0140] In some implementations, there may be joint transmissions of multiple (e.g., two) HARQ-ACK codebooks for different PDSCH groups. In some instances, the WTRU may determine whether to jointly transmit two HARQ-ACK codebooks for two different PDSCH groups based on a PUCCH resource indication (PRI). For example, in the case of using a compact DCI-scheduled WTRU, there may be no bit field indicating the joint transmission of HARQ codebooks. In one example, the WTRU may be configured to transmit two HARQ-ACK codebooks based on the payload of the indicated PRI. In another example, the WTRU may be semi-statically configured with a subset of PUCCH resources for jointly transmitting HARQ-ACK codebooks. If the PRI indicates a resource from the subset, the WTRU may transmit two HARQ-ACK codebooks. In another instance, if a PUSCH is used to transmit HARQ feedback (e.g., piggybacking UCI on the PUSCH), the WTRU may determine whether to jointly transmit two HARQ-ACK codebooks. In one example, the WTRU may first determine whether to piggyback UCI on the PUSCH, and then use the parameters for piggybacking indicated by the BS (e.g., gNB) to determine whether to jointly transmit two HARQ-ACK codebooks. For example, if a β factor greater than a threshold is indicated to the WTRU, the WTRU may transmit two HARQ-ACK codebooks.

[0141] In some instances, the WTRU may determine whether to jointly transmit two HARQ-ACK codebooks based on the HARQ-ACK feedback timing indication of the scheduled PDSCH group and / or the HARQ-ACK transmission time of the previous PDSCH group. For example, the WTRU may receive the first DL assignment and the first HARQ-ACK codebook transmission timing associated with PDSCH group 1 in t1. In subsequent DL transmissions, the DL PDSCH is associated with PDSCH group 2 and the HARQ-ACK feedback timing t2. In one example, the WTRU may determine whether to jointly transmit two HARQ-ACK codebooks based on the time difference between t1 and t2 (e.g., t2-t1). For example, if t2-t1 is higher than a configured threshold, the WTRU may jointly transmit two HARQ-ACK codebooks. In another example, if t2-t1 is lower than a configured threshold, the WTRU may transmit two HARQ-ACK codebooks.

[0142] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information for providing Hybrid Automatic Repeat Request (HARQ) feedback, wherein the configuration information indicates one or more serving cells associated with a HARQ feedback group; Receive downlink control information (DCI), the downlink control information (DCI) instructing the WTRU to transmit one or more HARQ feedback bits corresponding to the HARQ feedback group; and A one-time HARQ feedback transmission is transmitted, wherein the one-time HARQ feedback transmission includes one or more HARQ feedback bits corresponding to HARQ feedback groups corresponding to the one or more serving cells.

2. The WTRU of claim 1, wherein the configuration information indicates that the HARQ feedback group is associated with one or more HARQ procedures.

3. The WTRU of claim 2, wherein the configuration information uses a bitmap to indicate the one or more HARQ procedures.

4. The WTRU of claim 1, wherein the configuration information is received via Radio Resource Control (RRC) signaling.

5. The WTRU of claim 1, wherein the DCI includes an index indicating the HARQ feedback group.

6. The WTRU of claim 5, wherein the configuration information is associated with an index indicating the HARQ feedback group.

7. The WTRU of claim 1, wherein the configuration information indicates that the serving cell is associated with the HARQ feedback group.

8. The WTRU of claim 1, wherein the DCI does not schedule Physical Downlink Shared Channel (PDSCH) transmissions.

9. The WTRU of claim 1, wherein the WTRU is configured to multiplex HARQ feedback for multiple HARQ groups in transmissions sent on the Physical Uplink Control Channel (PUCCH) resource.

10. The WTRU of claim 1, wherein the HARQ feedback group is associated with a priority level, and the priority level is associated with a HARQ codebook.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information for providing Hybrid Automatic Repeat Request (HARQ) feedback, wherein the configuration information indicates one or more serving cells associated with a HARQ feedback group; Receive downlink control information (DCI), the downlink control information (DCI) instructing the WTRU to transmit one or more HARQ feedback bits corresponding to the HARQ feedback group; and A one-time HARQ feedback transmission is transmitted, wherein the one-time HARQ feedback transmission includes one or more HARQ feedback bits corresponding to HARQ feedback groups corresponding to the one or more serving cells.

12. The method of claim 11, wherein the configuration information indicates that the HARQ feedback group is associated with one or more HARQ processes.

13. The method of claim 12, wherein the configuration information uses a bitmap to indicate the one or more HARQ procedures.

14. The method of claim 11, wherein the configuration information is received via Radio Resource Control (RRC) signaling.

15. The method of claim 11, wherein the DCI includes an index indicating the HARQ feedback group.

16. The method of claim 15, wherein the configuration information is associated with an index indicating the HARQ feedback group.

17. The method of claim 11, wherein the configuration information indicates that the serving cell is associated with the HARQ feedback group.

18. The method of claim 11, wherein the DCI does not schedule Physical Downlink Shared Channel (PDSCH) transmissions.

19. The method of claim 11, wherein the WTRU is configured to multiplex HARQ feedback for multiple HARQ groups in transmissions sent on the Physical Uplink Control Channel (PUCCH) resource.

20. The method of claim 11, wherein the HARQ feedback group is associated with a priority level, and the priority level is associated with a HARQ codebook.

21. A wireless transmit / receive unit (WTRU) comprising a processor configured to perform the following operations: Receive configuration information indicating a mapping, the mapping including a priority value associated with each of the multiple Physical Downlink Shared Channel (PDSCH) groups; Determine the service type of the scheduled PDSCH transmission; The priority value associated with the service type of the scheduled PDSCH transmission is determined based on the mapping; and The PDSCH transmission is received based on the priority value.

22. The WTRU of claim 21, wherein the configuration is received via a Radio Resource Control (RRC) message, and wherein the processor is configured to support one or more PDSCH groups for one or more service types.

23. A wireless transmit / receive unit (WTRU) comprising a processor configured to perform the following operations: Receive configuration information corresponding to feedback from one or more transmissions; and Send messages based on the configuration information.

24. The WTRU of claim 23, wherein the configuration information indicates one or more serving cells associated with a Hybrid Automatic Repeat Request (HARQ) feedback group, and wherein the processor is configured to receive downlink control information (DCI) instructing the WTRU to transmit one or more HARQ feedback bits corresponding to the HARQ feedback group.

25. The WTRU of claim 24, wherein the configuration information indicates one or more serving cells associated with the HARQ feedback group, and wherein the processor is configured to transmit a one-time HARQ feedback transmission to send the message, and wherein the one-time HARQ feedback transmission includes one or more HARQ feedback bits corresponding to the HARQ feedback group corresponding to the one or more serving cells.

26. The WTRU of claim 24, wherein the DCI includes an index indicating the HARQ feedback group.

27. The WTRU of claim 25, wherein the processor is configured to determine one or more HARQ feedback bits for one or more serving cells associated with the indicated HARQ feedback group.

28. The WTRU of claim 25, wherein the processor is configured to perform a dynamic or semi-static HARQ feedback codebook associated with the one-time HARQ feedback.

29. The WTRU of claim 25, wherein the processor is further configured to determine that the DCI is a non-scheduled DCI.

30. The WTRU of claim 23, wherein the configuration information is received via Radio Resource Control (RRC) signaling.

31. The WTRU of claim 23, wherein the WTRU is configured to multiplex HARQ feedback for one or more HARQ groups in transmissions transmitted on the Physical Uplink Control Channel (PUCCH) resource.

32. The WTRU of claim 23, wherein the processor is further configured to determine the number of serving cells and the number of HARQ processes associated with each serving cell.

33. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information corresponding to feedback from one or more transmissions; as well as Send messages based on the configuration information.

34. The method of claim 33, wherein the configuration information indicates one or more serving cells associated with a Hybrid Automatic Repeat Request (HARQ) feedback group, and wherein the method further includes receiving downlink control information (DCI) indicating that the WTRU is to transmit one or more HARQ feedback bits corresponding to the HARQ feedback group.

35. The method of claim 34, wherein the configuration information indicates one or more serving cells associated with the HARQ feedback group, and wherein the method further comprises transmitting a one-time HARQ feedback transmission to send the message, and wherein the one-time HARQ feedback transmission includes one or more HARQ feedback bits corresponding to the HARQ feedback group corresponding to the one or more serving cells.

36. The method of claim 34, wherein the DCI includes an index indicating the HARQ feedback group.

37. The method of claim 34, further comprising determining one or more HARQ feedback bits for one or more serving cells associated with the indicated HARQ feedback group.

38. The method of claim 34, further comprising performing a dynamic or semi-static HARQ feedback codebook associated with the one-time HARQ feedback.

39. The method of claim 34, wherein the processor is further configured to determine that the DCI is a non-scheduled DCI.

40. The method of claim 33, wherein the configuration information is received via Radio Resource Control (RRC) signaling.

41. The method of claim 33, further comprising multiplexing HARQ feedback for one or more HARQ groups in transmissions transmitted on the Physical Uplink Control Channel (PUCCH) resource.

42. The method of claim 33, further comprising determining the number of serving cells and the number of HARQ processes associated with each serving cell.

Images