Method and apparatus for enhancing HARQ feedback performance of eMBB when affected by low-latency traffic

Abstract

Methods and apparatuses are described herein for providing single-bit hybrid automatic repeat request (HARQ) feedback and multi-bit HARQ feedback in a wireless transmit / receive unit (WTRU). For example, the WTRU may receive downlink control information (DCI) via a physical downlink control channel (PDCCH). The DCI may include a field for indicating a code block group (CBG)-based retransmission related to at least one transport block (TB). If the DCI does not contain the field, then the WRTU may transmit single-bit HARQ feedback for TB-based retransmissions via a physical uplink control channel (PUCCH). If the DCI contains the field, then the WTRU may transmit multi-bit HARQ feedback for the CBG-based retransmissions via the PUCCH. The WTRU may be configured to provide the single-bit HARQ feedback for the TB-based retransmissions and the multi-bit HARQ feedback for the CBG-based retransmissions.

Description

[0001] This application is a divisional application of a Chinese patent application with an application date of May 2, 2018, an application number of 201880028797.2, and an invention title of "Method and apparatus for enhancing HARQ feedback performance of eMBB when affected by low-latency traffic".

[0002] Cross-reference to related applications

[0003] This application claims the benefit of U.S. Provisional Application No. 62 / 615,744, filed on Jan. 10, 2018, U.S. Provisional Application No. 62 / 543,047, filed on Aug. 9, 2017, U.S. Provisional Application No. 62 / 519,372, filed on Jun. 14, 2017, and U.S. Provisional Application No. 62 / 500,938, filed on May 3, 2017, the contents of which are incorporated herein by reference. Background art

[0004] Hybrid automatic repeat request (HARQ) is a combination of soft combining error correction processing and ARQ error control processing. Through soft combining error correction technology, data packets that are not correctly decoded are no longer discarded. Instead, the received data is saved in a buffer and combined with the next retransmission. The receiver that detects a corrupted message requests a new message (i.e., a retransmission) from the sender by transmitting a feedback message. These feedback messages are transmitted from the receiver to the sender respectively to indicate that the previous transmission was received well (i.e., an affirmative acknowledgment) or poorly (i.e., a negative acknowledgment). In Long Term Evolution (LTE), these retransmissions are based on transport blocks (TBs), which are data from the higher layer and given to the physical layer. If the received TB is not correctly decoded (i.e., is corrupted), then the wireless transmit / receive unit (WTRU) can transmit a negative acknowledgment (NACK), thereby requesting the base station (BS) to retransmit the entire TB. For New Radio (NR), in the face of enhanced mobile broadband (eMBB) traffic, the BS needs to give priority to serving ultra-reliable low-latency (URLLC) traffic. If the entire TB is retransmitted again because of a small number of errors detected in the TB, it will be very inefficient. Therefore, it would be highly desirable to have a more flexible retransmission scheme that provides feedback messages based on code blocks (CBs), code block groups (CBGs), or transport blocks according to network / device configuration. Summary of the invention

[0005] Methods and apparatuses are described herein for providing single-bit hybrid automatic repeat request (HARQ) feedback and multi-bit HARQ feedback in a wireless transmit / receive unit (WTRU). For example, a WTRU may receive downlink control information (DCI) via a physical downlink control channel (PDCCH). The DCI may include a field for indicating a codeblock group (CBG)-based retransmission related to at least one transport block (TB). If the DCI does not include a field for indicating a CBG-based retransmission related to at least one TB, then the WRTU may transmit single-bit HARQ feedback for a TB-based retransmission via a physical uplink control channel (PUCCH). If the DCI includes a field for indicating a CBG-based retransmission related to at least one TB, then the WTRU may transmit multi-bit HARQ feedback for a CBG-based retransmission via the PUCCH. The multi-bit HARQ feedback may include a plurality of bits for indicating whether to request retransmission of at least one CBG in the at least one TB. Each of the plurality of bits is respectively mapped to each of the at least one CBG of the at least one TB. The multi-bit HARQ feedback may also be semi-statically configured to have a maximum number of CBGs based on a higher layer parameter. The WTRU may be configured to provide single-bit HARQ feedback for a TB-based retransmission and multi-bit HARQ feedback for a CBG-based retransmission. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A more detailed description may be had from the following detailed description given by way of example in conjunction with the accompanying drawings, in which:

[0007] Figure 1A is a system diagram showing an exemplary communication system in which one or more embodiments disclosed herein may be implemented;

[0008] Figure 1B is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in Figure 1A accordance with one embodiment;

[0009] Figure 1C is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system shown in Figure 1A accordance with one embodiment;

[0010] Figure 1D is a system diagram showing another exemplary RAN and another exemplary CN that may be used within the communication system shown in Figure 1A accordance with one embodiment;

[0011] Figure 2 is a diagram showing an exemplary code block (CB) segmentation process and a cyclic redundancy check (CRC) insertion process according to the CB;

[0012] Figure 3 is a diagram showing an exemplary process of ultra-reliable low-latency (URLLC) traffic preemption of enhanced mobile broadband (eMBB) traffic;

[0013] Figure 4A is a diagram showing an exemplary multi-bit hybrid automatic repeat request (HARQ) feedback, where the multi-bit HARQ feedback provides a CB-level retransmission granularity;

[0014] Figure 4B is a diagram showing an exemplary multi-bit HARQ feedback, where the multi-bit HARQ feedback provides a code block group (CBG)-level retransmission granularity;

[0015] Figure 4C is a diagram showing another exemplary multi-bit HARQ feedback, where the multi-bit HARQ feedback provides a CBG-level retransmission granularity;

[0016] Figure 5 is a diagram showing an exemplary signaling process for providing single-bit HARQ feedback and / or multi-bit HARQ feedback based on downlink control information (DCI);

[0017] Figure 6 is a diagram showing an exemplary process for providing single-bit HARQ feedback and / or multi-bit HARQ feedback based on downlink control information (DCI);

[0018] Figure 7 is a diagram showing an exemplary process for determining single-bit HARQ feedback and / or multi-bit HARQ feedback to be provided by a WTRU;

[0019] Figure 8 is a diagram showing an exemplary fixed-bit CBG-based HARQ feedback in contrast to an exemplary variable-bit CBG-based HARQ feedback;

[0020] Figure 9 is a diagram showing an exemplary preemption indication, where the middle part of the downlink (DL) system bandwidth is designated as a preemption area;

[0021] Figure 10 is a diagram showing an exemplary early HARQ feedback within a time slot according to micro-slot timing; and

[0022] Figure 11is a diagram illustrating an exemplary process for determining early HARQ feedback within a time slot according to micro - time - slot timing. Detailed Description

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

[0024] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, 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 components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA,” which may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription - based units, pagers, cellular telephones, personal digital assistants (PDAs), smart phones, laptop computers, netbooks, personal computers, wireless sensors, hotspots or Mi - Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head - mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., 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, and devices operating on commercial and / or industrial wireless networks, etc. The WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as UEs.

[0025] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, 102d in a wireless manner. For example, base stations 114a, 114b may be a base transceiver station (BTS), Node B, eNode B, home Node B, home eNode B, gNB, NR Node B, site controller, access point (AP), and wireless router, among others. Although each of base stations 114a, 114b is described as a single component, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0026] Base station 114a may be part of RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as a base station controller (BSC), radio network controller (RNC), relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies in a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a relatively fixed or potentially time-varying specific geographical area. 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, that is, each transceiver corresponds to a sector of the cell. In one embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

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

[0028] More specifically, as described above, the communication system 100 can be a multi-access system and can use one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c can implement a certain radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), where the technology can use Wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0029] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a certain radio technology, such as Evolved UMTS Terrestrial Radio Access (E-UTRA), where the technology can use Long-Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTA Pro (LTE-A Pro) to establish the air interface 116.

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

[0031] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c can jointly implement LTE radio access and NR radio access (e.g., using the Dual Connectivity (DC) principle). Thus, the air interfaces used by the WTURs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions to / from multiple types of base stations (such as eNBs and gNBs).

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

[0033] Figure 1A Base station 114b in may be a wireless router, a home Node B, a home eNode B, or an access point, and may use any suitable RAT to facilitate wireless connections in a local area, such as business premises, residences, vehicles, campuses, industrial facilities, air corridors (e.g., for drones), and roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d may establish a Wireless Local Area Network (WLAN) by implementing a radio technology such as IEEE 802.11. In one embodiment, base station 114b and WTRUs 102c, 102d may establish a Wireless Personal Area Network (WPAN) by implementing a radio technology such as IEEE 802.15. In yet another embodiment, base station 114b and WTRUs 102c, 102d may establish a pico cell or a femto cell by using a cellular-based RAT (such as WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As Figure 1A shown, base station 114b may be directly connected to the Internet 110. Thus, base station 114b does not need to access the Internet 110 via CN 106 / 115.

[0034] RAN 104 / 113 may communicate with CN 106 / 115, where the CN may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. This data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements, etc. CN 106 / 115 may provide call control, accounting services, location-based services, prepaid calls, Internet connectivity, video distribution, etc., and / or may perform advanced security functions such as user authentication. Although in Figure 1AThis is not shown in the figure, however, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs that use the same or different RATs as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113 that uses NR radio technology, CN 106 / 115 can also communicate with other RANs (not shown) that use GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0037] Figure 1B is a system diagram showing an exemplary WTRU 102. As Figure 1B shown, the WTRU 102 can include a processor 118, a transceiver 120, a transmit / receive component 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138. It should be understood that while remaining compliant with the embodiments, the WTRU 102 can also include any sub-combination of the foregoing components.

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

[0039] The transmit / receive component 122 can be configured to transmit or receive signals to or from a base station (such as base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive component 122 can be an antenna configured to transmit and / or receive RF signals. As an example, in another embodiment, the transmit / receive component 122 can be a radiator / detector configured to transmit and / or receive IR, UV, or visible light signals. In yet another embodiment, the transmit / receive component 122 can be configured to transmit and / or receive RF and optical signals. It should be understood that the transmit / receive component 122 can be configured to transmit and / or receive any combination of wireless signals.

[0040] Although in Figure 1B the transmit / receive component 122 is described as a single component, the WTRU 102 can include any number of transmit / receive components 122. More specifically, the WTRU 102 can use MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive components 122 (such as multiple antennas) that transmit and receive radio signals via the air interface 116.

[0041] The transceiver 120 can be configured to modulate the signals to be transmitted by the transmit / receive component 122 and to demodulate the signals received by the transmit / receive component 122. As described above, the WTRU 102 can have multi-mode capabilities. Therefore, the transceiver 120 can include multiple transceivers that allow the WTRU 102 to communicate using multiple RATs (such as NR and IEEE 802.11).

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

[0043] The processor 118 can receive power from a power supply 134 and can be configured to distribute and / or control power for other components in the WTRU 102. The power supply 134 can be any suitable device for powering the WTRU 102. For example, the power supply 134 can include one or more dry battery packs (such as nickel cadmium (Ni-Cd), nickel zinc (Ni-Zn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, and so on.

[0044] The processor 118 can also be coupled to a GPS chipset 136, which can be configured to provide location information (such as longitude and latitude) related to the current location of the WTRU 102. As a supplement or replacement to the information from the GPS chipset 136, the WTRU 102 can receive location information from a base station (such as base stations 114a, 114b) via an air interface 116, and / or determine its location based on the signal timing received from two or more nearby base stations. It should be understood that the WTRU 102 can obtain location information by means of any suitable positioning method while remaining compliant with the embodiments.

[0045] The processor 118 can also be coupled to other peripheral devices 138, where the peripheral devices can include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connections. For example, the peripheral devices 138 can include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game console modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices, and activity trackers, etc. The peripheral device 138 may include one or more sensors, and the sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geographical location sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0046] The WTRU 102 may include a full-duplex radio device, for which the reception and transmission of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio device may include an interference management unit 139 that reduces and / or substantially eliminates self-interference by means of hardware (e.g., a choke coil) or by signal processing of a processor (e.g., a separate processor (not shown) or by the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio device that transmits or receives some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)).

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

[0048] The RAN 104 may include eNodeBs 160a, 160b, 160c. However, it should be understood that the RAN 104 may include any number of eNodeBs while remaining compliant with the embodiment. Each eNodeB 160a, 160b, 160c may include one or more transceivers for communicating with the WTRU 102a, 102b, 102c over the air interface 116. In one embodiment, the eNodeBs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNodeB 160a may use multiple antennas to transmit wireless signals to the WTRU 102a and / or to receive wireless signals from the WTRU 102a.

[0049] Each eNode B 160a, 160b, 160c 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, etc. As Figure 1C shown, eNode Bs 160a, 160b, 160c can communicate with each other via the X2 interface.

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

[0051] The MME 162 can be connected to each eNode B 160a, 160b, 160c in the 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 the WTRUs 102a, 102b, 102c, performing bearer activation / deactivation procedures, and selecting a specific serving gateway during the initial attachment process of the WTRUs 102a, 102b, 102c, etc. The MME 162 can also provide a control plane function for handover between the RAN 104 and other RANs (not shown) using other radio technologies (such as GSM and / or WCDMA).

[0052] The SGW 164 can be connected to each eNode B 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. Also, the SGW 164 can perform other functions, such as anchoring the user plane during handover between eNBs, triggering paging procedures when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c, etc.

[0053] The SGW 164 can be connected to the PGW 146, which can provide packet-switched network (such as the Internet 110) access for the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0054] CN 106 can facilitate communication with other networks. For example, CN 106 can provide circuit-switched network (e.g., PSTN 108) access for WTRU 102a, 102b, 102c to facilitate communication between WTRU 102a, 102b, 102c and traditional landline communication devices. For example, CN 106 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), and the IP gateway can act as an interface between CN 106 and PSTN 108. In addition, CN 106 can provide access for WTRU 102a, 102b, 102c to other networks 112, where the network can include other wired and / or wireless networks owned and / or operated by other service providers.

[0055] Although the WTRU is described as a wireless terminal in Figures 1A - 1D it should be appreciated that in some exemplary embodiments, such terminals and the communication network can use (e.g., temporarily or permanently) a wired communication interface.

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

[0057] A WLAN operating in an infrastructure basic service set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or interface with a distributed system (DS) or another type of wired / wireless network that feeds traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for an STA can reach the STA via the AP and be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS can be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS can be sent through the AP, e.g., in a case 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. The point-to-point traffic can be sent between the source and destination STAs (e.g., directly therebetween) using direct link setup (DLS). In some exemplary embodiments, DLS can use 802.11e DLS or 802.11z tunneled DLS (TDLS). For example, a WLAN operating in an independent BSS (IBSS) mode does not have an AP, and STAs within or using the IBSS (e.g., all STAs) can communicate directly with each other. Here, the IBSS communication mode can sometimes be referred to as an "ad hoc" communication mode.

[0058] When operating in an 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can have a fixed width (e.g., a bandwidth of 20 MHz) or a width that is dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some exemplary embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) (e.g., in an 802.11 system) can be implemented. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, then the particular STA can back off. In a given BSS, at any given time, one STA (e.g., only one station) transmits.

[0059] High Throughput (HT) STAs can communicate using a channel with a width of 40 MHz (e.g., by combining a 20 MHz primary channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz channel).

[0060] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels or by combining two non - consecutive 80 MHz channels (such a combination can be referred to as an 80 + 80 configuration). For the 80 + 80 configuration, after channel coding, the data can be passed through a segmentation parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time - domain processing can be performed separately on each stream. The streams can be mapped on two 80 MHz channels, and the data can be transmitted by the STA performing the transmission. On the receiver of the STA performing the reception, the above operations for the 80 + 80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0061] 802.11af and 802.11ah support sub-1GHz operating modes. Compared with 802.11n and 802.11ac, the channel operating bandwidth and carriers used in 802.11af and 802.11ah are reduced. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication (e.g., MTC devices in a macro coverage area). MTC may have certain capabilities, such as limited capabilities including support for (e.g., only support for) certain and / or limited bandwidths. MTC devices may include a battery, and the battery life of the battery is higher than a threshold (e.g., for maintaining a long battery life).

[0062] For a WLAN system (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) that can support multiple channels and channel bandwidths, the WLAN system includes a channel that can be designated as a primary channel. The bandwidth of the primary channel may be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or restricted by a certain STA, where the STA is sourced from all STAs operating in a BSS that supports the minimum bandwidth operating mode. In an example regarding 802.11ah, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, for an STA that supports (e.g., only supports) the 1MHz mode (e.g., an MTC type device), the width of the primary channel may be 1MHz. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy (e.g., because an STA (which only supports the 1MHz operating mode) transmits to the AP), then even if most of the frequency bands remain vacant and available, the entire available frequency band may be considered busy.

[0063] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. According to the country code, the total bandwidth available for 802.11ah is 6MHz to 26MHz.

[0064] Figure 1DFIG. 0 is a system diagram showing RAN 113 and CN 115 according to one embodiment. As described above, RAN 113 may communicate with WTRUs 102a, 102b, 102c using NR radio technology over air interface 116. RAN 113 may also communicate with CN 115.

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

[0066] WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with scalable parameter configurations. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may be different for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) having different or scalable lengths (e.g., containing different numbers of OFDM symbols and / or lasting different absolute time lengths).

[0067] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c operating in stand-alone configuration and / or non-stand-alone configuration. In stand-alone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, 160c). In stand-alone configuration, the WTRUs 102a, 102b, 102c can use one or more of the gNBs 180a, 180b, 180c as a mobility anchor. In stand-alone configuration, the WTRUs 102a, 102b, 102c can use signals in the unlicensed band to communicate with gNBs 180a, 180b, 180c. In non-stand-alone configuration, the WTRUs 102a, 102b, 102c communicate / connect with gNBs 180a, 180b, 180c while communicating / connecting with other RANs (e.g., eNodeBs 160a, 160b, 160c). For example, the WTRUs 102a, 102b, 102c can communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c in a substantially simultaneous manner by implementing the DC principle. In non-stand-alone configuration, the eNodeBs 160a, 160b, 160c can act as the mobility anchor for the WTRUs 102a, 102b, 102c, and the gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to serve the WTRUs 102a, 102b, 102c.

[0068] Each of the gNBs 180a, 180b, 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, support network slicing, implement dual connectivity, implement interworking between NR and E-UTRA, route user plane data to user plane functions (UPFs) 184a, 184b, and route control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As Figure 1D shown, the gNBs 180a, 180b, 180c can communicate with each other via the Xn interface.

[0069] Figure 1DThe CN 115 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 include data networks (DN) 185a, 185b. Although each of the foregoing components has been described as part of the CN 115, it should be understood that any of these components may be owned and / or operated by entities other than the CN operator.

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

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

[0072] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, so as to provide the WTRUs 102a, 102b, 102c with access to a packet switched network (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184a, 184b can perform other functions, such as routing and forwarding packets, implementing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring processing, etc.

[0073] The CN 115 can facilitate communication with other networks. For example, the CN 115 can include or can communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the CN 108. In addition, the CN 115 can provide the WTRUs 102a, 102b, 102c with access to other networks 112, which can include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to the local data network (DN) 185a, 185b via the N3 interface connected to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b and through the UPFs 184a, 184b.

[0074] In view of Figures 1A - 1D and with respect to Figures 1A - 1D the corresponding descriptions, one or more or all of the following functions described here can be performed by one or more emulation devices (not shown): the WTRUs 102a-d, the base stations 114a-b, the eNode Bs 160a-c, the MME 162, the SGW 164, the PGW 166, the gNBs 180a-c, the AMFs 182a-ab, the UPFs 184a-b, the SMFs 183a-b, the DNs 185a-b, and / or any other devices described here. These emulation devices can be one or more devices configured to simulate one or more or all of the functions here. For example, these emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[0075] The simulation device can be designed to implement one or more tests about other devices in a laboratory environment and / or an operator network environment. For example, the one or more simulation devices can perform one or more or all functions while being implemented and / or deployed as part of a wired and / or wireless communication network in whole or in part to test other devices inside the communication network. The one or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can be directly coupled to other devices to perform the test, and / or can use over-the-air wireless communication to perform the test.

[0076] The one or more simulation devices can perform one or more functions, including all functions, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test lab and / or a test scenario of a wired and / or wireless communication network that is not deployed (e.g., tested) to implement tests on one or more components. The one or more simulation devices can be test devices. The simulation device can transmit and / or receive data using direct RF coupling and / or wireless communication with the aid of RF circuits (as an example, the circuits can include one or more antennas).

[0077] In LTE, the turbo encoder interleaver defines only a limited number of code block (CB) sizes, where the largest block size is 6144 bits. Therefore, if the transport block (TB) including the 24-bit TB cyclic redundancy check (CRC) exceeds this 6144-bit limit, each TB is split into smaller CBs before turbo encoding.

[0078] Figure 2 An example of a code block (CB) segmentation process 250 and a cyclic redundancy check (CRC) insertion process 270 according to the CB is shown, which can be used in any combination with other embodiments described herein. Figure 2As shown, the CB segment 250 in the TB 205 can be located before the turbo coding process that inserts the padding bits 260 into the CB#1 215 (i.e., the padding that makes the first CB conform to the size supported by the turbo encoder). During the CB segment processing 250, CRCs 230, 232, 234 can be appended to each CB (i.e., CB#1 215, CB#2 217, CB#M 218). The lengths of the CRCs 230, 232, 234 can also include 24 bits, but they are different from the TB CRC 210. By having each CB 215, 217, 218 with a CRC 230, 232, 234, it is possible to detect correctly decoded CBs earlier for channel coding 280, which in turn allows for the early termination of the iterative decoding process for the CBs 215, 217, 218. This process can be used to reduce the processing complexity and power consumption of the WTRU. The combination of the TB CRC 210 and the CB CRCs 230, 232, 234 can minimize the risk of not detecting errors in the decoded TB.

[0079] In LTE, based on a 20 MHz system bandwidth, the TB size (i.e., the transport block size (TBS)) can reach 97,896 bits. This may result in each TB having approximately 16 CBs. In LTE, even if the decoding of a single CB fails, the entire TB is still retransmitted. In a new radio (NR) with a system bandwidth of 100 MHz for sub-6 GHz bands and potentially up to several GHz for millimeter wave bands, the TBS is likely to be much larger. For example, based on the 20 MHz LTE bandwidth extension, it can be 80 CBs for 100 MHz.

[0080] In NR, which provides multiple use cases (such as enhanced mobile broadband (eMBB), ultra-reliable low latency communication (URLLC), and massive machine type communication (mMTC)), a way to effectively use radio resources may be required. For example, a URLLC WTRU may need to be served immediately to meet its strict latency requirements. This leads to the necessity to preempt eMBB traffic, where the resources scheduled for eMBB traffic are preempted to serve URLLC traffic. Such resource preemption can be performed at the micro-slot (i.e., symbol level), which only affects a small number of CBs. Therefore, retransmitting the entire TB (as is usually the case for LTE) is very inefficient and wasteful in terms of resources. Hence, a more flexible retransmission scheme that can work based on CBs, CB groups (CBGs), TBs, or any combination thereof is needed.

[0081] Figure 3An illustrative process is shown in which ultra-reliable low-latency (URLLC) traffic pre-empts enhanced mobile broadband (eMBB) traffic. For example, CBs 1 through 28 are initially scheduled for eMBB traffic. However, when service is needed for URLLC traffic, as shown in regions 305 and 315, the CBs scheduled for eMBB traffic can be pre-empted to service the URLLC traffic. In LTE, if a CB in the pre-emption regions 305, 315 (or any CB in the region for eMBB traffic) is not correctly decoded, the entire TB needs to be retransmitted. As described above, doing so results in inefficient use of radio resources.

[0082] To support CBG-based retransmissions, it is necessary to use multi-bit HARQ feedback. The multi-bit feedback can be used to indicate which CB / CBG or other resource (e.g., PRB or PRB group) the WTRU is requesting to be retransmitted from the base station (e.g., next generation node B (gNB)).

[0083] A WTRU or a set / group of WTRUs can be configured semi-statically or dynamically to not use HARQ feedback, use single-bit HARQ feedback, or use multi-bit HARQ. This can depend on the type / categorization of the eMBB traffic being served (e.g., live-streamed video versus non-live video content) and the frequency of URLLC traffic pre-empting the eMBB traffic. The configuration (or reconfiguration) of the feedback format of the WTRU can be determined by the BS (e.g., gNB) via a signaling message. For example, the semi-static configuration can be determined via RRC signaling and can indicate that the type of HARQ feedback provided by the WTRU or set / group of WTRUs cannot be changed for a long period of time. As an example, when a WTRU is semi-statically configured to provide multi-bit HARQ feedback in a cell, the WTRU will not change its HARQ feedback configuration until it moves to a different cell that can only accept single-bit HARQ feedback. In contrast, the dynamic configuration can be determined via DCI and can indicate that the type of HHARQ feedback provided by the WTRU or set / group of WTRUs can be changed within a short period of time as needed. For example, the DCI can contain parameters for changing the type of HARQ feedback provided by the WTRU.

[0084] In one embodiment, if the eMBB traffic mainly consists of time-sensitive traffic (such as live video streams) and the URLLC traffic load is very low, and this results in a relatively low frequency of eMBB resource preemption, then the BS (such as a gNB) can semi-statically or dynamically configure (reconfigure) the WTRU or WTRU group not to use HARQ feedback. Then, the WTRU can rely on forward error correction processing (FEC), because for such services, losing some packets is preferable to the latency associated with HARQ-based retransmissions.

[0085] As an alternative or addition, if the frequency of URLLC traffic is very high and this results in a significant preemption of eMBB resources, then the BS (such as a gNB) can semi-statically or dynamically configure (reconfigure) the affected WTRU or WTRU group to use multi-bit HARQ feedback. Once the multi-bit HARQ feedback is received, the BS can retransmit the affected data portion so that the WTRU or WTRU group can effectively decode the affected TB. These retransmissions can be CB / CBG, micro-slot level retransmissions, which allows the WTRU or WTRU group to benefit from additional data transmissions without having a significant impact on the viewer experience in terms of latency.

[0086] In another embodiment, the BS (such as a gNB) can semi-statically configure the WTRU or WTRU group to use certain predetermined mappings for multi-bit HARQ feedback. These mappings can indicate whether multi-bit HARQ feedback allows CB-level granularity, CBG-level granularity, or even time-frequency resources. An example of such a mapping is shown in Figure 4A -C.

[0087] Figure 4A An exemplary multi-bit HARQ feedback 405 is shown, which can be used in combination with any of the other embodiments described herein. As Figure 4AAs shown, multi-bit HARQ feedback 405 may allow for CB-level retransmission granularity. Here, the granularity refers to the number of CB(s) / CBG(s) included in each bit of the multi-bit HARQ feedback (i.e., each HARQ information bit). In particular, the CB-level granularity means that each bit in the multi-bit HARQ feedback 405 can represent a single CB. In this example, the multi-bit HARQ feedback 405 includes 12 HARQ information bits representing each CB (i.e., CB 1 to CB 12). These twelve HARQ information bits can indicate the corresponding CB for which the WTRU requests retransmission. For example, if CB 1 is not correctly decoded (i.e., corrupted), then the WTRU may determine the first HARQ information bit representing CB 1 to be a NACK. If CB 1 is successfully decoded, then the WTRU may determine the first HARQ information bit to be an ACK. The HARQ information bit value 0 may represent a NACK, and the HARQ information bit value 1 may represent an ACK, and vice versa. This provides maximum flexibility because the WTRU can accurately specify which CBs it has not successfully decoded. Thus, the BS can use retransmission resources minimally. This process is particularly attractive if the TB size is small. However, even if the TB size is moderately larger, this method may potentially require a large number of HARQ feedback bits, thus greatly increasing the signaling overhead.

[0088] Figure 4BAn exemplary multi-bit HARQ feedback 410 is shown, where the HARQ feedback 410 allows for retransmission granularity at the codeblock group (CBG) level and can be used in combination with any of the other embodiments described herein. CBG-level granularity means that each bit in the multi-bit HARQ feedback 410 can represent a CB group (i.e., CBG) 415, 420, 425, 430. In this example, the multi-bit HARQ feedback 410 includes 4 HARQ information bits representing each of the CBGs 415, 420, 425, 430. Each of these four HARQ information bits can indicate the corresponding CBG 415, 420, 425, 430 for which the WTRU requests retransmission. For example, the first bit in the multi-bit HARQ feedback 410 represents the first CBG 415 (i.e., the group consisting of CB1, CB2, CB3) and indicates whether retransmission of the first CBG is requested. If any of the CBs in the first CBG 415 are not correctly decoded (i.e., are corrupted), then the WTRU can determine the first HARQ information bit representing the first CBG 415 to be a NACK. If all of the CBs in the first CBG 415 are successfully decoded, then the WTRU can determine the first bit representing the first CBG 415 to be an ACK. As described above, a HARQ information bit value of 0 can represent a NACK, while a HARQ information bit value of 1 can represent an ACK, and vice versa.

[0089] Figure 4C Another exemplary multi-bit HARQ feedback 435 is shown, where the HARQ feedback 435 allows for retransmission granularity at the CBG level and this feedback can be used in combination with any of the other embodiments described herein. CBG-level granularity means that the bits in the multi-bit HARQ feedback 410 can represent CB groups (i.e., CBGs) 440, 445. As Figure 4CAs shown, each HARQ information bit is mapped to CBGs 440, 445. In this case, each of the two CBG groups has 6 CBs. For example, the first bit in the multi-bit HARQ feedback 435 represents the first CBG 440 (i.e., the group of CB1, CB2, CB3, CB4, CB5, CB6), and indicates whether a retransmission of the first CBG is requested. If all the CBs in the first CBG 415 are successfully decoded, the WTRU may determine the first bit representing the first CBG 440 as an ACK. If any of the CBs in the first CBG 440 is not correctly decoded (e.g., damaged), the WTRU may determine the first HARQ information bit representing the first CBG 440 as a NACK. In other words, an error in any of the CBs in the relevant CBG group results in a NACK feedback, thereby causing a retransmission of all the CBs in that CBG. If the WTRU correctly receives all the code blocks of a CBG, the WTRU may generate an ACK for the HARQ-ACK information bit of the CBG. If the WTRU does not correctly receive at least one code block in the CBG, the WTRU may generate a NACK for the HARQ-ACK information bit of the CBG. As described above, the HARQ information bit value 0 may represent a NACK, and the HARQ information bit value 1 may represent an ACK, and vice versa.

[0090] In one embodiment, the WTRU may be configured to use multiple HARQ feedback options. For example, the WTRU may be configured to provide both multi-bit HARQ feedback and single-bit HARQ feedback simultaneously. The WTRU can flexibly decide which of the two to use, and thereby switch between them if needed. For example, if the WTRU fails to successfully decode a small number of CBs for a specific TB, it may choose (or switch to) using multi-bit HARQ feedback to signal to the base station (e.g., gNB) which CBs to retransmit.

[0091] As an alternative or addition, if the WTRU fails to decode a large number of CBs (e.g., a large portion of all the TBs), it may indicate that the preemption process has affected multiple CBs / CBGs, and the BS (e.g., gNB) is preferably to retransmit the entire TB. In this case, the WTRU may choose (or switch to) using single-bit HARQ feedback to notify the BS (e.g., gNB) to retransmit the entire TB, while also reducing the signaling overhead. The BS (e.g., gNB) may configure a threshold parameter “δ” for the WTRU to facilitate the switch between single-bit HARQ feedback and multi-bit HARQ feedback.

[0092] To facilitate a switch between single-bit HARQ feedback requesting TB-based retransmission and multi-bit HARQ feedback requesting CBG-based retransmission, the WTRU may be configured by the BS (e.g., gNB) to use multiple PUCCH formats, each with a different payload (e.g., uplink control information (UCI)) size. The WTRU can then select an appropriate PUCCH format based on the HARQ feedback requirements. In this scenario, the BS (e.g., gNB) may have to blindly decode the PUCCH to determine which format the WTRU is using and thus which feedback option is being used.

[0093] The WTRU may be configured by radio resource control (RRC) signaling to have multiple PUCCH resource sets, which are partitioned based on UCI payload capabilities. For example, in a simple scenario it may be possible to have 'K = 2' configured resource sets. The first resource set may be defined for PUCCH formats having HARQ-ACK feedback and thus having a UCI payload size of up to 2 bits. However, the first resource set may be defined for PUCCH formats having HARQ-ACK feedback and thus having a UCI payload size greater than 2 bits. In another example, with additional granularity, the WTRU may be configured to have 'K = 3' resource sets. For example, the first resource set may be defined for a UCI payload size of up to 2 bits. The second resource set may be defined for PUCCH formats using a UCI payload size greater than 2 bits but less than 19 bits. The third resource set may be defined for a UCI payload size of 20 bits or more. In another example, the PUCCH resource sets may be 'K = 4', where the first resource set is defined for a UCI payload size of up to 2 bits, and the second resource set is defined for PUCCH formats using a UCI payload size greater than 2 bits but less than 19 bits (as in the 'K = 3' case). However, the third and fourth resource sets may provide increased granularity, where the third resource set is defined from UCI payload sizes greater than 20 but less than a value 'L' (taking L = 80 as an example), and the fourth resource set is defined for UCI payload sizes greater than L.

[0094] There may be a trade-off between the number of resource sets and the number of PUCCH resources (resource blocks) available per resource set. If there are a larger number of PUCCH resource sets, it is possible that there will be a small number of PUCCH resources per set, as the total number of PUCCH resources must now be divided among a larger number of resource sets. If a large number of WTRUs with high UCI payloads are generally expected, then having a larger number of resource sets would be very beneficial. In such cases, the distribution of these payloads is multimodal, where the PUCCH resource sets can be well adapted to the distribution of the UCI payloads, thereby allowing these resources to be used in an optimal manner. An illustrative situation where having a larger number of resource sets may be beneficial is when there is a high likelihood of significant variation in the UCI payload. For CBG-based transmissions (retransmissions), this situation may occur during HARQ feedback multiplexing, where it may be necessary to provide a single HARQ feedback response for multiple PDSCH transmissions spanning multiple time slots / CCs, etc. In such situations and especially for CBG-based transmissions (retransmissions), the number of HARQ bits can be large. For example, for a WTRU configured to have 8 CBGs per TB, if there are five CCs, the UCI payload for HARQ feedback is expected to be 40 bits, while for two CCs, the UCI payload is expected to be 16 bits. In such scenarios, having a larger number of PUCCH resource sets (e.g., 'K = 4' instead of 'K = 3') may be better, and for the case of K = 3, the distribution of PUCCH resources between the sets results in the provision of a larger number of resources, as it can be expected that the probability of providing a 40-bit HARQ feedback is much lower than the probability of providing a HARQ feedback bit between 3 bits and some intermediate value (e.g., 19 bits for the third set in the case of 'K = 4' above) and thus providing the UCI payload.

[0095] Then, the WTRU can select an appropriate resource set based on the HARQ payload (UCI) size. For example, in the scenario above where the WTRU is configured to have only 2 CBGs per TB and only a single codeword (CW), the WTRU may need to report multi-bit feedback of size 2 bits. In this case, the WTRU can select the PUCCH resource set defined for PUCCH formats for up to 2 bits of UCI (i.e., the first set in each of the examples above).

[0096] In another embodiment, a WTRU configured with 8 CBGs per TB for a single CW configuration may be required to report multi-bit feedback of size 8 bits. The WTRU may select a PUCCH resource set defined for a PUCCH format, which resource set is capable of supporting a UCI greater than 2 bits as shown in the second set in the above example.

[0097] In another embodiment, a WTRU may be configured with multiple PUCCH resource sets, where more than one resource set is defined for a PUCCH format capable of supporting a HARQ payload size (or more generally a UCI payload of a certain size). For example, a WTRU may be configured with K = 4 sets, where two sets are defined for PUCCH formats with a UCI payload of up to 2 bits, and the remaining two sets are defined for PUCCH formats with a UCI payload greater than 2 bits. In such a scenario, the WTRU may randomly select one of the two sets defined for either payload scenario. If a large number of WTRUs are assigned to each PUCCH resource set, this helps to reduce the likelihood of collisions between multiple WTRUs.

[0098] If the selected PUCCH format can have a moderate UCI (HARQ) payload and is transmitted over multiple / several symbols / micro-slots / sub-slots (e.g., a PUCCH with a long duration, such as PUCCH format 4 on a single resource block pair) to effectively utilize the PUCCH resource set, then multiple WTRUs can share the same resource block pair. Devices sharing the same resource block pair within a symbol / micro-slot can be separated by different orthogonal phase rotations of the frequency domain sequence (e.g., cyclic shifts in the time domain). As an alternative or in addition, for larger UCI payload formats (e.g., greater than 2 bits), if multiple resource block pairs are used (e.g., PUCCH format 2 or 3), the symbol / micro-slot / sub-slot multiplexing capacity can be increased by having multiple WTRUs share the same resource block pair, where each WTRU uses a different orthogonal cover sequence. Thereby, the number of PUCCH resources required for HARQ feedback can be reduced.

[0099] In addition to selecting an appropriate resource set (e.g., based on the HARQ-ACK payload size), the BS (e.g., gNB) may also fine-tune the PUCCH resources that will be used by the WTRU to provide its HARQ feedback. This process can be done by using an ACK-NACK resource indicator (ARI) field similar to the 2-bit ACK-NACK offset field (ANO) in LTE, which can be used to dynamically control the PUCCH resources and / or formats within a PUCCH resource set.

[0100] In one embodiment, 2-bit ARI may provide PUCCH resource indices as follows: 00 indexes a first PUCCH resource, 01 indexes a second PUCCH resource, 10 indexes a third PUCCH resource, and 11 indexes a fourth PUCCH resource within a selected set of PUCCH resources.

[0101] In another embodiment, ARI may provide an index for PUCCH resource indices for a particular PUCCH format. For example, if the WTRU is configured for short and long PUCCHs for UCI payloads greater than 2 bits, it may be configured with two different PUCCH formats. In one embodiment, one PUCCH format may be used for short PUCCHs and another PUCCH format may be used for long PUCCH transmissions. Then, the ARI index may be used to provide information related to PUCCH resource indices and PUCCH formats. For example, based on the ARI index, the WTRU may select a set of PUCCH resources having two PUCCH formats (e.g., PUCCHa and PUCCHb), where both of these PUCCH formats can carry UCI payloads greater than 2 bits, one format (e.g., PUCCHa) is used for short-duration PUCCH transmissions, and the other format (e.g., PUCCHb) is used for long-duration PUCCH transmissions. In particular, ARI index 00 may indicate PUCCH resource 1 for PUCCHa, index 01 may indicate PUCCH resource 2 for PUCCHa, index 10 may indicate PUCCH resource 1 for PUCCHb, and index 11 may indicate PUCCH resource 2 for PUCCHb.

[0102] In another embodiment, a WTRU configured with short and long PUCCH formats may decide on a PUCCH format based on certain predetermined criteria. For example, if the WTRU has limited power or limited coverage, then the WTRU may decide to use the long PUCCH format. In this case, a WTRU that can flexibly select the best / suitable PUCCH format may use only the ARI field in the DCI to indicate the PUCCH resource index.

[0103] In addition, if the appropriate PUCCH resources can be flexibly selected, the WTRU can be allowed to adapt to any change in the feedback granularity that may result. For example, if the BS (e.g., gNB) uses fallback DCI on the PDCCH to schedule the PDSCH, the WTRU configured to provide multi-bit HARQ feedback for CBG-based transmission (retransmission) can respond with single-bit HARQ feedback for TB-based transmission (retransmission). The fallback DCI can indicate that the BS does not support CBG-based retransmission for the transmitted transport block (TB). When the WTRU receives the fallback DCI, the WTRU can select a set of PUCCH resources configured for a PUCCH format that supports a smaller UCI payload of size 2 bits, as this will meet the need for single-bit HARQ feedback for retransmitting a single or two codewords (or TBs). In this way, the WTRU preferentially configured to provide multi-bit HARQ feedback can switch between multi-bit HARQ feedback for CBG-based retransmission (by using the resource set configured for a higher UCI payload) and single-bit HARQ feedback for TB-based retransmission (by using the resource set configured for a smaller UCI payload). For such a fallback DCI, given the fact that the WTRU has switched to a different set of PUCCH resources due to a change in the HARQ payload size (from multi-bit HARQ feedback to single-bit HARQ feedback) and a corresponding change in the PUCCH format, the BS (e.g., gNB) can provide updated PUCCH resource index information (via the ARI field). Then, the new ARI can be modified to reflect the PUCCH resource index information for the set of PUCCH resources.

[0104] In one embodiment, the WTRU transmits data on the PUSCH, where the WTRU can choose to use multi-bit HARQ feedback to provide a finer granularity for retransmission. In this embodiment, the WTRU can also switch from multi-bit HARQ feedback to single-bit HARQ feedback based on a more stringent threshold parameter 'δ s ' (where δ s > δ). This handling is more stringent compared to the case of sending HARQ on the PUCCH (e.g., δ s = 1), which means that the switch to single-bit occurs only when the entire TB is in error.

[0105] In another embodiment, the WTRU may be configured to provide multiple HARQ feedback options, such as providing multi-bit HARQ feedback and single-bit HARQ feedback to the BS (e.g., gNB) simultaneously. Providing two types of HARQ feedback may require built-in error detection and additional robustness against HARQ feedback errors. For example, for a WTRU with a single CBG affected by preemption, it may provide multi-bit HARQ feedback for the affected CBG and single-bit feedback for the TB. This means that the multi-bit HARQ feedback contains a single NACK for the affected CBG, and the single-bit HARQ feedback contains a single NACK for the TB. If either NACK bit is affected by NACK-ACK errors, the BS (e.g., gNB) can still discern that at least some part of the TB was not correctly decoded by the WTRU. In this case, the BS (e.g., gNB) can decide to retransmit the entire TB (if the single NACK for the affected CBG is flipped to ACK), or only retransmit the CBG that the received NACK is for. Although the former case (i.e., retransmitting the entire TB) may result in unnecessary transmissions, it is more preferred than the alternative (i.e., retransmitting the affected CBG) because retransmitting the affected CBG may take longer (i.e., until the entire TB is successfully received) due to potential corrective processing of the RLC protocol compared to retransmitting the entire TB.

[0106] The WTRU configured to provide multi-bit HARQ feedback may also revert to or use single-bit feedback as a fallback option as a method for reducing feedback overhead. The WTRU may be configured to have both multi-bit HARQ feedback and single-bit HARQ feedback options, and the WTRU may provide multi-bit HARQ feedback as long as a transmission (retransmission) scheduled by the BS (e.g., gNB) results in an error (i.e., NACK) for at least one transmitted (retransmitted) CBG. Once the WTRU has successfully received all CBGs (and thus the entire TB), the WTRU may send a single-bit HARQ feedback message to notify the BS (e.g., gNB) that the entire TB has now been successfully received. This switch from multi-bit HARQ feedback to single-bit HARQ feedback can reduce overhead without negatively impacting performance.

[0107] In another embodiment, if a large number of CBGs cannot be decoded due to pre-empted data (e.g., based on a threshold, such as the absolute number of CBGs or the percentage / fraction of configured CBGs), then a WTRU configured to have both multi-bit HARQ feedback and single-bit HARQ feedback options may decide to select single-bit HARQ feedback for TB-based retransmission. In such a case, the WTRU may determine that it is best to request retransmission of the entire TB. To request retransmission of the entire TB, the WTRU may send a single-bit HARQ-NACK.

[0108] In another embodiment, a WTRU configured to perform multi-bit HARQ feedback (or configured to perform both multi-bit HARQ feedback and single-bit HARQ feedback) may need to switch to (or select) single-bit feedback due to a change in the DCI used for scheduling the PDSCH. For example, if the WTRU is configured to have multi-bit HARQ feedback for CBG-based transmissions (retransmissions), and the PDSCH scheduled by the DCI does not support CBG-based transmission, then the WTRU may need to switch to (select) single-bit HARQ feedback due to the use of a fallback DCI format. In such a scenario, the process of using the fallback DCI to schedule the PDSCH can be regarded as an indication that the WTUR needs to respond using single-bit HARQ feedback for TB-based retransmissions. A regular DCI (or non-fallback DCI) can be regarded as an indication that the WTRU should respond using multi-bit HARQ feedback for CBG (or CB)-based retransmissions.

[0109] Each PDCCH may carry a message called DCI that contains resource assignments and other control information for a WTRU or group of WTRUs. For example, the DCI may transmit downlink and uplink scheduling information, a request for an aperiodic channel quality (CQI) report, or an uplink power control command for a cell and a radio network temporary identifier (RNTI). Depending on the information content, the DCI may have different DCI message formats as shown in Table 1 below.

[0110] Table 1

[0111]

[0112] As an example, DCI format 1_1 for scheduling PDSCH in a cell may include a field for indicating codeblock group (CBG)-based transmission (retransmission) for at least one transport block (TB). A regular DCI (or non-fallback DCI) may be this DCI format 1_1, whereby it is explicitly indicated that the WTRU should respond with multi-bit HARQ feedback for CBG (or CB)-based retransmission. On the other hand, DCI format 1_0 for scheduling PDSCH in a DL cell does not include a field for indicating CBG-based transmission (retransmission). In this scenario, the process of using DCI format 1_0 to schedule PDSCH can be regarded as an implicit indication that the WTRU needs to respond with single-bit HARQ feedback for TB-based transmission (retransmission). As described above, once DCI format 1_0 is received, the WTRU may switch or select single-bit HARQ feedback for CBG-based retransmission. In addition, if the WTRU receives a PDSCH scheduled by a PDCCH with DCI format 1_0, then the WTRU may generate HARQ feedback information only for the transport block in the PDSCH. The fallback DCI described above may be DCI format 1_0.

[0113] Based on whether the WTRU switches from multi-bit HARQ feedback to single-bit HARQ feedback solely based on its own decision (e.g., based on how many CBGs have errors as described above), or based on whether the switch is based on how the BS (e.g., gNB) schedules the PDSCH (e.g., fallback DCI), the WTRU may select PUCCH resources / formats in different ways. In the latter case where the switch is attributed to the DCI, the BS (gNB) may dynamically indicate the ARI of the PUCCH resource to be used from the selected set of PUCCH resources, where as described above, the set selection may be based on the UCI payload size. Then, the WTRU may use this dynamically indicated resource for single-bit HARQ feedback.

[0114] If the WTRU autonomously decides to switch from multi-bit HARQ feedback to single-bit HARQ feedback, the WTRU can use pre-configured PUCCH resources (e.g., uplink control information (UCI)). For this purpose, the BS (e.g., gNB) can semi-statically configure the PUCCH resources including an appropriate set of PUCCH resources. In this case, the set of PUCCH resources can be a set configured to handle UCI payloads less than 2 bits (PUCCH format 0 / 1). This pre-configured resource can override the PUCCH resources dynamically indicated by the ARI in the non-backoff DCI scheduling the PDSCH for CBG-based transmission (retransmission). The reason is that the PUCCH resources indicated in this DCI are dedicated to the multi-bit feedback payload size and the corresponding PUCCH resources.

[0115] As an alternative or in addition, the WTRU can use the PUCCH resources designated for multi-bit HARQ feedback to provide single-bit HARQ feedback to the BS (e.g., gNB). In this case, all two PUCCH formats (e.g., PUCCH format 0 and PUCCH format 2) can be used for the same PUCCH resource. For example, PUCCH format 0 can be designated for UCI payloads sized 1-2 bits, and PUCCH format 2 can be defined for UCI payloads greater than 2 bits.

[0116] In the previous example, the information regarding the number of configured sets of PUCCH resources and their UCI payload capabilities may limit the WTRU's ability to autonomously decide between single-bit HARQ feedback or multi-bit HARQ feedback when providing HARQ responses for the transmitted PDSCH. For example, if only a single set of PUCCH resources with a very small UCI payload capacity is configured for the WTRU, the WTRU can take this as an indication that it is expected to always respond using single-bit HARQ. However, if a set of PUCCH resources with a large UCI payload capacity capable of carrying large UCI payloads is configured for the WTRU, the WTRU can take this as an indication that it is expected to always respond using multi-bit HARQ feedback for that PDSCH.

[0117] In another embodiment, a WTRU configured with more than one set of PUCCH resources can take this as an implicit indication for the WTRU to select an appropriate feedback granularity. In this case, the BS (e.g., gNB) may need to blindly decode the PUCCH to determine which PUCCH format the WTRU has selected.

[0118] As an alternative or in addition, a WTRU configured only with the multi-bit HARQ feedback option can use this configuration to provide TB-level feedback. As Figure 2As shown, TB 205 has CRC 210, and each CB (i.e., CB#1 215, CB#2 217, CB#M 218) is appended with CRC 230, 232, 234. After the WTRU receives TB 205 that contains all CBs 215, 217, 218, if the CB-level CRC check on the WTRU passes, but the TB-level CRC check on the WTRU fails, then the multi-bit HARQ feedback field can include TB-level NACK feedback. This TB-level NACK feedback (e.g., NACK feedback bit 0) can be repeated N times, where N is the value of CBG / CB or N is the maximum value of CBG / CB. For example, a WTRU that is semi-statically configured to provide multi-bit HARQ feedback receives two TBs that contain 16 CBGs, and each TB contains 8 CBGs. For the first TB, if all CB-level CRCs and the TB-level CRC check pass, then the WTRU can generate TB-level ACK feedback by repeating the ACK information bit 8 times (i.e., 11111111). For the second TB, if all CB-level CRC checks pass, but the TB-level check fails, then the WTRU can generate TB-level NACK feedback by repeating the NACK information bit 8 times (i.e., 00000000). Since the WTRU is semi-statically configured to provide multi-bit HARQ feedback, the number of bits in the multi-bit HARQ feedback may have to be the maximum number of CBGs (16 bits in this example). Therefore, after multiplexing these two 8-bit values (i.e., 11111111 for the first TB and 00000000 for the second TB), the WTRU can generate 16-bit multi-bit HARQ feedback (i.e., 1111111100000000).

[0119] In other words, if the WTRU correctly detects each of the N CBGs and does not correctly detect the TB for these N CBGs, then the WTRU can generate NACK bits for each of these N CBGs. On the other hand, if the WTRU correctly detects each of the N CBGs and also correctly detects the TB for these N CBGs, then the WTRU can generate ACK bits for each of these N CBGs. If one or more TBs are used, it is necessary to multiplex the single HARQ codebook for each TB in order to generate multi-bit HARQ feedback. Since the WTRU has been configured to use PUCCH format for transporting the multi-bit feedback format payload, this method helps to add redundancy to the HARQ feedback, thereby reducing the probability of misdetection, shortening the latency, and not incurring additional overhead / cost.

[0120] In one embodiment, if a WTRU receives a PDSCH scheduled by a PDCCH using fallback DCI and the WTRU is semi-statically configured to provide multi-bit HARQ feedback by using a higher layer parameter, then the WTRU may repeat the HARQ ACK and NACK for a TB in the PDSCH N times (i.e., the number of CBGs or the maximum number of CBGs configured by the BS) to generate N HARQ ACK or NACK information bits.

[0121] Figure 5 An exemplary signaling procedure 500 for providing single-bit HARQ feedback and / or multi-bit HARQ feedback based on DCI is shown and can be used in any combination with other embodiments described herein. As Figure 5 shown, a WTRU 505 may receive a radio resource control (RRC) message 515 from a base station (BS) 510. The RRC message 515 may be interchangeably referred to as a higher layer message, where the layer transmitting the message is higher than the media access control (MAC) layer. The RRC layer is located in the BS (e.g., gNB / eNB) and may handle control plane protocols. As an example, the RRC layer manages procedures associated with the RAN, such as system information broadcast, connection management, mobility, or WTRU capabilities, etc. These messages may be transmitted using radio bearers mapped to common or dedicated control channels.

[0122] The RRC message 515 may include a higher layer parameter (e.g., CBG-DL = ON), where in step 520, the parameter configures the WTRU to provide multi-bit HARQ feedback based on the maximum number of CBGs for CBG-based transmission (retransmission). For example, if the WTRU is configured by a higher layer parameter that includes the maximum number of CBGs, then the WTRU may be required to use the maximum number of CBGs to generate corresponding HARQ feedback information bits for TB reception processing. As an example, if the received TB includes 8 CBGs, but the maximum number of CBGs configured by the higher layer parameter is 10, then the WTRU may generate 10 HARQ information bits for multi-bit HARQ feedback. In this case, the first 8 bits may be determined by the decoding result of the CBG (or TB), and the last two bits may be added or inserted based on dummy bits (e.g., ACK or NACK bits). The payload size of the multi-bit HARQ feedback may be determined by the number of configured CBGs. For example, the payload size of the multi-bit HARQ feedback may be the same as the maximum number of CBGs.

[0123] After receiving the RRC message 515, as described above, the WTRU 505 may be configured to provide multi-bit HARQ feedback and / or single-bit HARQ feedback. The WTRU 505 may receive regular (non-fallback) DCI 525 for PDSCH scheduling via the PDCCH. Based on the regular DCI 525, the WTRU may receive data (i.e., one or more TBs) 530 via the PDSCH. Since the WTRU 505 has received the regular DCI 525, if at least one CB in the received one or more TBs is not correctly decoded in step 535, then the WTRU 505 may transmit multi-bit HARQ feedback 540 to the BS 510 via the PUCCH. The multi-bit HARQ feedback 540 may be included in the UCI. The multi-bit HARQ feedback 540 may further include one or more HARQ NACK information bits regarding the CBGs for which the WTRU 505 requests retransmission. After transmitting the multi-bit HARQ feedback 540, the WTRU 505 may receive regular (non-fallback) DCI 545 related to one or more CBGs 550 scheduled for retransmission via the PDCCH. If the regular DCI 545 schedules the retransmission of one or more CBGs, then the DCI 545 may include a CBG transmission information (CBGTI) field. The CBGTI field may include a bit mapping that has a one-to-one mapping with each CBG of the TB. The WTRU 505 may determine whether to retransmit a CBG based on the corresponding value of the CBGTI field. For example, binary 0 represents retransmission of the corresponding CBG, and binary 1 represents non-retransmission of the corresponding CBG.

[0124] The WTRU 505 may also receive a fallback DCI 555 for PDSCH scheduling on the PDCCH. Based on the fallback DCI 555, the WTRU may receive data (i.e., one or more TBs) 560 via the PDSCH. Since the WTRU 505 receives the fallback DCI 555, when at least one CB in the received one or more TBs is not correctly decoded in step 565, the WTRU 505 may transmit a single-bit HARQ feedback 570 to the BS 510 via the PUCCH. This single-bit HARQ feedback 570 may also be included in the UCI. The single-bit HARQ feedback 570 may include a HARQ NACK information bit regarding the TB for which the WTRU 505 requests retransmission. After transmitting the single-bit HARQ feedback 570, the WTRU 505 may receive a fallback DCI 575 regarding the TB 580 scheduled for retransmission on the PDCCH. If the single-bit HARQ feedback 570 is NACK (i.e., binary 0), then the WTRU 505 may receive the corresponding TB retransmitted by the BS 510. If the single-bit HARQ feedback 570 is ACK (i.e., binary 1), then the WTRU 505 does not receive any further retransmissions from the BS 510.

[0125] Figure 6 An illustrative process 600 for providing single-bit HARQ feedback and / or multi-bit HARQ feedback based on DCI is shown, where the process may optionally be used in combination with other embodiments described herein. In step 605, as described above, the WTRU may be configured to provide multi-bit HARQ feedback and / or single-bit HARQ feedback. In step 610, the WTRU may receive DCI for PDSCH scheduling on the PDCCH. In step 615, the WTRU may receive data (i.e., TBs). In step 620, if the received DCI is a fallback DCI and at least one CB in the received TBs is not correctly decoded, then in step 625, the WTRU may transmit a single-bit HARQ feedback. If the single-bit HARQ feedback 570 is NACK (i.e., binary 0), then in step 630, the WTRU may receive the corresponding TB retransmitted by the BS 510.

[0126] In step 620, if the received DCI is a non-backoff DCI and at least one CB in the received TB is not correctly decoded, then in step 635, the WTRU may transmit multi-bit HARQ feedback. The multi-bit HARQ feedback may include one or more HARQ NACK information bits for one or more CBGs for which the WTRU requests retransmission. In step 635, after transmitting the multi-bit HARQ feedback, the WTRU may receive on the PDCCH a regular (non-backoff) DCI regarding one or more CBGs scheduled for retransmission. If the regular DCI schedules retransmission processing for one or more CBGs, then the regular DCI may include a CBG Transmission Information (CBGTI) field. The CBGTI field may include a bit mapping having a one-to-one mapping with each CBG in the TB. The WTRU may determine whether to retransmit a CBG based on the corresponding value of the CBGTI field. For example, binary 0 represents retransmission of the corresponding CBG, and binary 1 represents non-retransmission of the corresponding CBG. In step 640, based on the CBGTI field, the WTRU may receive one or more CBGs retransmitted by the BS.

[0127] Figure 7 An illustrative process 700 for determining whether a WTRU should provide single-bit HARQ feedback and / or multi-bit HARQ feedback is shown, where the process may optionally be used in combination with other embodiments described herein. In step 705, the WTRU may receive an initial (TB) transmission or a CBG-based retransmission from the BS. In step 710, the WTRU may consider which of single-bit HARQ feedback and / or multi-bit HARQ feedback the WTRU provides. In step 730, if the WTRU determines to consider both single-bit HARQ feedback and multi-bit HARQ feedback, then the WTRU may first check whether all CBGs received from the BS are error-free. If all received CBGs are error-free, then in step 720, the WTRU may generate single-bit HARQ feedback. The feedback may be a single-bit HARQ ACK. If there are errors in the received CBGs, then in step 735, the WTRU may generate single-bit HARQ feedback as well as multi-bit HARQ feedback. This process is related to the case where the WTRU provides HARQ feedback for multiple TBs (e.g., PDSCH) by means of a single HARQ feedback message by multiplexing single-bit and multi-bit HARQ feedback.

[0128] In step 710, if the WTRU determines not to consider which HARQ feedback of single-bit HARQ feedback and / or multi-bit HARQ feedback the WTRU is going to provide, then the WTRU may determine which HARQ feedback the WTRU selects by considering other factors. For example, in step 715, the WTRU may consider the fraction of error CBGs in all CBGs in the TB. If the fraction of error CBGs in all CBGs in the TB is greater than a predetermined threshold (δ), then in step 720, the WTRU may generate single-bit HARQ feedback for TB-based retransmission. If the fraction of error CBGs in all CBGs in the TB is less than the predetermined threshold (δ), then in step 725, the WTRU may generate multi-bit HARD feedback for CBG-based retransmission. Finally, in step 740, the WTRU may transmit the determined HARQ feedback to the BS.

[0129] In one embodiment, the WTRU may be configured to use only the multi-bit HARQ feedback option. The multi-bit HARQ feedback option may be based on CBs, CBGs, or may switch between CB-based and CBG-based. For example, a WTRU or a group of WTRUs may be semi-statically configured to use multi-bit HARQ for CBG-based retransmission. The network may infer over time that low-latency traffic is essentially periodic, and thus a transmission opportunity is required every "X" milliseconds, which can be translated into a limited number of CBs for the WTRU or group of WTRUs. In this case, it would be very beneficial if the system switched to CB-based multi-bit HARQ feedback. For this purpose, the BS (e.g., gNB) may dynamically configure (reconfigure) the set of affected WTRUs.

[0130] In another embodiment, a WTRU served by a BS (e.g., gNB) may be initialized by using default HARQ feedback settings. The initial / default HARQ feedback settings may be single-bit HARQ feedback or multi-bit HARQ feedback. If multi-bit HARQ feedback is the default setting, then the system may have a predefined maximum number of bits "N_max", where each bit is applied to a CB or a CBG containing multiple CBs. In addition, whether applied to a CB or a CBG, each bit can cover the maximum TB of the system. The choice of N_max may provide a trade-off between the flexibility to allow a fine enough granularity for retransmission selection while maintaining low to moderate complexity and the maximum possible value of N_max.

[0131] To allow CBG-based retransmissions, the BS (e.g., gNB) may need to schedule both the TB-based initial transmission and the CBG-based transmission (retransmission) simultaneously. The BS (e.g., gNB) may use a scheduling assignment (e.g., fallback DCI) to schedule the initial TB-based transmission, while using a separate DCI format (e.g., non-fallback DCI) to schedule the CBG-based transmission (retransmission). This scheduling assignment (i.e., DCI) may include fields such as modulation and coding scheme (MCS), redundancy version (RV), or new data indicator (NDI), etc. As an alternative or in addition, this scheduling assignment may include a CBG indicator field (CBGIF) or a CBG transmission information (CBGTI) field to explicitly indicate to the WTRU the CBG being scheduled for retransmission.

[0132] As an alternative or in addition, the BS (e.g., gNB) may use a DCI format in which the DCI format re-uses existing fields (e.g., MCS / NDI / RV, etc.) along with a single-bit flag (e.g., the existing NDI field or a new flag) to indicate whether these existing fields apply to the initial TB transmission (in which case the fields have their original meaning) or whether they apply to the CBG-based retransmission.

[0133] In one embodiment, the BS (e.g., gNB) may use the NDI and RV fields to inform the WTRU what information the MCS field or an extended version of the MCS field conveys regarding which CBGs are being transmitted. The BS (e.g., gNB) may use the NDI to inform the WTRU that the scheduled transmission is a CBG-based transmission for a previously transmitted TB and that the same RV as the initial is being transmitted. Using the NDI field or flag can be seen as an implicit indication that the terminal can interpret the MCS field as indicating the CBGIF (or CBGTI) of the CBG being transmitted and can assume that the retransmission uses the same MCS as the initial transmission.

[0134] In another embodiment, the BS (e.g., gNB) may use an extended DCI format specifically designed to schedule CBG-based retransmissions. The extended DCI format may contain the same initial fields as those used in LTE, such as MCS / RV / NDI, etc. In addition to the original fields, the extended DCI format may contain an additional CBGIF (or CBGTI) to announce the CBG being retransmitted. Since the BS (e.g., gNB) may use the MCS / RV fields for CBG-based retransmissions, with the CBGIF or CBGTI fields, the BS (e.g., gNB) may have maximum flexibility in adapting the transmission parameters between the initial transmission and the retransmission.

[0135] In another embodiment, the BS (e.g., gNB) may use a single common DCI format to schedule the initial TB transmission as well as CB-based transmissions (retransmissions). Such an approach may reduce the number of blind decoding attempts that need to be performed on the WTRU. The DCI format used may contain the same initial fields as those used in LTE (MCS / RV / HARQ process ID / PUCCH power control, etc.), and may contain an additional CBGIF or CBGTI. The CBGIF or CBGTI field may be used to indicate which CBGs will be retransmitted in the case of performing CBG retransmissions. As an alternative or in addition, the all “1” state or bit in the CBGIF or CBGTI may indicate the transmission / retransmission of the entire TB. The BS (e.g., gNB) may use a compact assignment format in order to reduce the DCI payload size for this common DCI. For example, if only contiguous resource blocks (resource allocation type 2) are supported, then the DCI payload size may be reduced at the cost of a slightly reduced scheduling flexibility.

[0136] In another embodiment, the BS (e.g., gNB) may schedule TB-based and / or CBG-based retransmissions by using a DCI format without a CBGIF and without an explicit indication as to which CBGs are being retransmitted for CBG-based scheduling assignments. The two scheduling assignments differ in terms of a flag, where the flag may either use an existing field (e.g., NDI) or may have an additional field that allows the differentiation between an initial TB-based transmission and a CBG-based retransmission. In this case, since the BS (e.g., gNB) has not indicated which CBGs are being retransmitted, the WTRU may implicitly assume that the BS (e.g., gNB) is retransmitting those CBGs that were indicated as NACK by the WTRU when it provided HARQ feedback. The scheduling assignment may keep the MCS / RV fields unaffected by the existing LTE DCI format, which may provide maximum flexibility in adapting transmission parameters (e.g., MCS / RV, etc.) as needed when transitioning from a TB-based transmission to a CBG-based retransmission.

[0137] As described above, the number of HARQ bits can be selected to provide a tradeoff between flexibility and feedback overhead. The BS (e.g., gNB) may configure the WTRU or WTRU group for multi-bit feedback to use 'N' bits, where each bit is applied to a CB or CBG. For example, CBG-level multi-bit HARQ feedback can limit the feedback overhead while providing flexibility in terms of retransmission granularity. To use a multi-bit HARQ feedback scheme with 'N' bits where each bit is applied to a CBG (where 'N' is fixed regardless of the TB), the number of CBs 'K' in the CBG can vary according to the TB, where a larger TB results in a larger 'K', and a smaller TB results in a finer retransmission granularity as 'K' will be relatively smaller.

[0138] As an alternative or in addition, the BS (e.g., gNB) may semi-statically configure the WTRU group to use 'N' bits for multi-bit HARQ feedback based on the maximum transport block size (TBS) observed by the network, and then the BS (e.g., gNB) may semi-statically adapt it. Thereafter, this process can be used to determine a process for appropriately grouping CBs into CBGs (e.g., 'K' CBs form a CBG, where 'K' is fixed and determined based on the maximally observed TBS).

[0139] In another embodiment, the BS (e.g., gNB) may use a process for fixedly grouping 'K' CBs into CBGs, where the process is selected without relying on the TB. This results in different TBs having different numbers of CBGs and thus HARQ feedback schemes having different numbers of bits ('N').

[0140] In another embodiment, the BS (e.g., gNB) may dynamically configure the WTRU for multi-bit HARQ feedback with 'N' bits by means of DCI. Both 'N' and 'K' defined above can be determined based on the initial or first transmission of the TB and do not change during all retransmissions regarding that TB.

[0141] In addition to using semi-static or dynamic HARQ feedback size configurations, the WTRU may also implicitly derive the number of CBGs (i.e., size 'N') for multi-bit HARQ feedback. This process may be done based on the UCI payload size of one or more PUCCH formats configured for the WTRU or WTRU group. For example, a WTRU configured with a format similar to PUCCH format 3 in LTE may assume 10 bits for multi-bit HARQ feedback, while a WTRU configured with a format similar to PUCCH format 1b in LTE may implicitly assume 4 bits for multi-bit HARQ feedback.

[0142] The BS (e.g., gNB) may reconfigure the multi-bit HARQ feedback size for the WTRU using semi-static and / or dynamic signaling. For example, the BS (e.g., gNB) may semi-statically configure the parameter 'N' for the WTRU, where the 'N' indicates the total number of CBGs in the TB. With the parameter 'N', the BS may also inform the WTRU that the WTRU is expected to have 'N' bits of HARQ feedback (1 bit per CBG). In addition, the BS (e.g., gNB) may dynamically indicate a different value 'N1' (where N1 <= N), thereby informing the WTRU that 'N1' bits of HARQ feedback should be provided for any retransmission. The 'N1' value may be based on the CBGs scheduled for retransmission rather than all CBGs in the TB.

[0143] As an alternative or addition, the WTRU may implicitly derive the multi-bit HARQ feedback size based on the scheduling DCI for CBG retransmissions, rather than using the number of CBGs as an explicit indication of the multi-bit HARQ feedback size. For example, if the WTRU receives a PDSCH scheduled by the PDCCH using fallback DCI, then the WTRU may generate HARQ feedback information bits only for the TB in that PDSCH. As an example, a WTRU configured with multiple PUCCH formats capable of carrying different UCI payloads may use this as an implicit indication. Thereby, the WTUR may use a PUCCH format with a smaller payload size to provide HARQ feedback for retransmitted CBGs. Information related to which CBGs are scheduled may be obtained from the CBGIF (or CBGTI) of the scheduling DCI. As long as the reliability of this variable-sized multi-bit HARQ feedback can be ensured, then this process reduces the HARQ feedback (i.e., UCI size) when responding to multiple (CBG-based) retransmissions of the same TB without affecting the overall performance.

[0144] Multi-bit HARQ feedback can be reconfigured between retransmissions. As described above, a larger number of HARQ feedback bits allows for greater flexibility in terms of retransmission granularity and improves spectral efficiency. However, the impact of multi-bit HARQ feedback on UCI should also be considered.

[0145] The process of limiting the number of HARQ feedback bits can be achieved by providing ACK / NACK feedback only for those CBGs that are explicitly scheduled for retransmission rather than for all CBGs that form part of the initial TB.

[0146] In one embodiment, the BS (e.g., gNB) can configure the WTRU or group of WTRUs to report HARQ feedback based on a fixed set of CBG assignments / scheduling (e.g., all CBGs in a TB), regardless of the number of CBGs that the BS (e.g., gNB) schedules for retransmission. This simplifies the HARQ design because the number of HARQ feedback bits is fixed and equal to the total number of CBGs used for the initial transmission of the TB and for all subsequent CBG-based retransmissions for that TB, resulting in no ambiguity as to which CBG the HARQ-ACK feedback bits apply to. In this case, the WTRU can follow a pre-defined rule for those CBGs that are not retransmitted by the BS (e.g., gNB). For example, since the WTRU successfully received (or decoded) these CBGs, the WTRU can report ACK for these CBGs. If the WTRU generates HARQ ACK feedback in response to a TB retransmission corresponding to the same HARQ process as a previous transmission of the TB, the WTRU can generate an ACK for each CBG that it correctly decoded in the previous transmission of the TB.

[0147] In another embodiment, the BS can configure the WTRU or group of WTRUs to report HARQ feedback based on the maximum number of CBGs in one or more TBs, regardless of the number of CBGs that the BS schedules for retransmission. If the WTRU is configured by a higher layer parameter that includes the maximum number of CBGs, the WTRU may need to use the maximum number of CBGs to generate the corresponding HARQ feedback information bits for the TB reception process. For example, if the received TB contains 8 CBGs, but the maximum number of CBGs configured by the higher layer parameter is 10, the WTRU can generate 10 HARQ information bits for multi-bit HARQ feedback. In this case, the first 8 bits can be determined by the result of decoding the CBG (or TB), and the last 2 bits can be added or inserted based on pseudo-bits (e.g., ACK or NACK bits). In this example, the payload size of the multi-bit HARQ feedback can be the same as the maximum number of CBGs.

[0148] In another example, the BS (e.g., gNB) may configure the WTRU or a group of WTRUs to employ a variable-bit HARQ feedback scheme, where the scheme is entirely based on the currently scheduled retransmission of CBGs. This feedback scheme can significantly reduce the HARQ feedback overhead, especially in cases where the preemption handling only affects a very small portion of the total CBGs in the initial TB transmission and any subsequent retransmissions. The WTRU may append a very small CRC (e.g., a single parity bit or a 3-bit CRC) to the multi-bit HARQ feedback reported to the BS (e.g., gNB). This process can be beneficial for variable-bit HARQ feedback methods because the number of feedback bits can change between retransmissions, and NACK-to-ACK errors can make it difficult to recover previously transmitted CBGs.

[0149] Figure 8 An illustrative process for reconfiguring multi-bit HARQ feedback based on fixed-bit CBG-based HARQ feedback 815 or variable-bit CBG-based HARQ feedback 820, 825 is shown, where this process can be used in any combination with other embodiments described herein. As described above, the multi-bit HARQ feedback may include one or more HARQ NACK information bits for one or more CBGs requested for transmission by the WTRU. After transmitting the multi-bit HARQ feedback, the WTRU may receive on the PDCCH a DCI for one or more CBGs scheduled for retransmission. The DCI may contain the bit mapping of the CBG 805 scheduled for transmission. As Figure 8 shown, the bit mapping of CBG 805 indicates that CBGs 2, 3, 4, 5, and 6 810 are the CBGs scheduled for retransmission. Once the WTRU receives the retransmitted CBGs 810 (i.e., CBGs 2, 3, 4, 5, and 6), the WTRU may reconfigure the multi-bit HARQ feedback based on fixed-bit CBG-based HARQ feedback 815 or variable-bit CBG-based HARQ feedback 820, 825.

[0150] If the WTRU is reconfigured to provide fixed-bit CBG-based HARQ feedback 815, then the WTRU may generate the multi-bit HARQ feedback (i.e., fixed-bit CBG-based HARQ feedback 815) based on the total amount of CBGs in the TB. As Figure 8As shown, the multi-bit HARQ feedback may include 12 bits for its HARQ feedback 815 based on CBGs of fixed bits. The WTRU may generate ACK or NACK bits 816 for the retransmitted CBG 810 based on the decoding result. For those CBGs (i.e., CBG 1, CBG 7-12) that were successfully received (or decoded) in the previous transmission, the WTRU may generate ACK bits 817.

[0151] If the WTRU is reconfigured to provide HARQ feedback 820, 825 based on CBGs of variable bits, then the WTRU may generate multi-bit HARQ feedback (i.e., HARQ feedback 820, 825 based on CBGs of variable bits) based on the number of scheduled CBGs. As Figure 8 shown, the multi-bit HARQ feedback may include 5 bits for its HARQ feedback 820 based on CBGs of variable bits. The WTRU may generate ACK or NACK bits 820 for the retransmitted CBG 810 based on the decoding result. In addition, the HARQ feedback 825 based on CBGs of variable bits may also include a CRC 830 for error detection. For example, a single-bit CRC 830 or a 3-bit CRC 830 may be appended to the multi-bit HARQ feedback reported to the BS (i.e., the HARQ feedback 825 based on CBGs of variable bits). As an example, if the number of scheduled CBGs is small and / or the NACK-to-ACK error probability is low, then the WTRU may choose to include only a single parity bit for error detection. As an alternative or in addition, if the number of scheduled CBGs is large and / or there is a high probability of encountering NACK-to-ACK errors, then the WTRU may choose to use a longer (e.g., 3-bit) CRC. Once the HARQ feedback is received, the BS (e.g., gNB) may verify the CRC. If the CRC verification fails, then the BS may request the WTRU to retransmit the HARQ feedback. As an alternative or in addition, if the BS can detect which (which) bit(s) is in error, then the BS may choose to retransmit only the CBG(s) corresponding to the one or more HARQ bits in error.

[0152] Even if some additional overhead bits are added to the HARQ feedback by using parity bits or a small CRC, if the scheduled retransmission is only a small number of 'k' CBGs (k << N), then such a method can also be used to replace the processing using a fixed 'N'-bit HARQ feedback scheme.

[0153] As described above, a BS (e.g., gNB) may configure a WTRU or a group of WTRUs semi-statically or dynamically to use a fixed multi-bit HARQ or a variable-bit HARQ feedback scheme. In one example, a BS (e.g., gNB) may configure a WTRU to use a PUCCH format with a larger payload similar to PUCCH format 4 or 5 in LTE to report fixed multi-bit HARQ feedback. In another example, a BS (e.g., gNB) may configure a WTRU to use a PUCCH format with a smaller payload similar to PUCCH format 1b or 3 in LTE to report variable multi-bit feedback.

[0154] In addition, a WTRU or a group of WTRUs may switch semi-statically or dynamically between fixed and variable-bit HARQ feedback reporting schemes. This switching may be facilitated by factors such as the frequency of URLLC traffic preempting eMBB traffic of the WTRU, the number of time-frequency (TF) resources affected by the preemption, or changes in observed interference, etc.

[0155] In addition to semi-static and / or dynamic HARQ feedback size configuration, a WTRU may also implicitly derive the number of bits 'N' for multi-bit HARQ feedback. This derivation may be done based on one or more configured PUCCH formats specified for the WTRU or group of WTRUs. For example, a WTRU configured with a PUCCH format having a smaller payload size may take this as an implicit indication to use a variable-bit HARQ feedback format, where the WTRU may provide HARQ feedback only for those CBGs retransmitted by the BS (e.g., gNB). As an alternative or in addition, if a WTRU is configured with a PUCCH format having a larger payload size that can accommodate all 'N' bits in the entire CBG set (the set of all CBGs in a TB), then the WTRU may instead take this as an indication to provide HARQ feedback for all CBGs in the TB.

[0156] In one embodiment, a WTRU may be configured to use multiple PUCCH formats with different UCI payload sizes and have the option to select between these formats. For example, a coverage- or power-limited WTRU may select a PUCCH format with a smaller payload, thereby providing HARQ feedback only for those CBGs retransmitted by the BS (e.g., gNB) rather than all CBGs in the TB as a means to reduce power consumption. The BS (e.g., gNB) may then need to determine the PUCCH format by blindly decoding the PUCCH and thereby determine what type of feedback (e.g., fixed or variable bit) the WTRU is providing.

[0157] In another embodiment, a WTRU configured to be capable of using fixed and variable bit HARQ feedback may use one of the options initially and then may switch to the other option based on various factors such as the frequency of pre-empted traffic, the CBGs affected by the pre-emption, the number of affected WTRUs, or interference, etc. For example, for an initial retransmission, the WTRU may provide fixed-bit HARQ feedback for the entire set of CBGs (e.g., each CBG in a TB). However, in a second transmission, if the number of retransmitted CBGs is significantly reduced, then the WTRU may determine that it is more efficient to report variable-bit HARQ feedback only for the CBGs scheduled for the current retransmission.

[0158] The BS (e.g., gNB) may semi-statically configure the WTRU to use a specific feedback option as the default feedback mode. For example, the WTRU may be configured to use fixed-bit HARQ feedback based on the entire set of CBGs. However, if this handling is proven to be inefficient from the perspective of UCI overhead, then the WTRU may switch to the variable-bit feedback option. As an example, if the BS (e.g., gNB) needs to schedule multiple retransmissions due to a small number of CBGs being in error, then a large uplink overhead will be generated because, according to the fixed-bit feedback scheme, it is necessary to send a large number of HARQ feedback bits. The default feedback option may be configured to apply to multiple TB transmissions, while the over-riding option may apply only to the current TB being transmitted.

[0159] In another embodiment, the WTRU may be configured to use the variable-bit HARQ feedback option as the default option, but may also switch to fixed-bit HARQ feedback. For example, if the WTRU needs to retransmit several variable-bit feedback messages (since these HARQ feedback messages fail the CRC check, resulting in a HARQ feedback retransmission request from the BS), then additional HARQ overhead and / or data retransmissions will be generated. In this case, it may be more efficient to have the WTRU revert to the fixed-bit HARQ feedback option.

[0160] In another embodiment, the WTRU may autonomously switch from the default feedback configuration to an alternative feedback option (e.g., from variable-bit HARQ feedback to fixed-bit HARQ feedback). This handling may be facilitated by configuring the WTRU with multiple PUCCH formats. As an alternative or in addition, the handling of switching or reconfiguring the HARQ option may be explicitly signaled via DCI or implicitly signaled based on the reconfiguration of the PUCCH, etc.

[0161] Multi-bit HARQ feedback for multiple PDSCHs is described herein. For multi-carrier scheduling, a WTRU may need to provide aggregated HARQ feedback for multiple TBs. For example, multiple time slots for DL transmission may need to be answered via a single HARQ-ACK feedback time slot. Multiple time slots for DL transmission may need to be confirmed via a single HARQ-ACK feedback time slot. Even for PUCCH formats with large payloads, the number of HARQ feedback bits available for transmission is limited by the UCI payload size. The multiple PDSCHs may be considered to be scheduled on multiple component carriers (CCs), multiple cells, multiple time slots / micro-slots / sub-slots / non-slots, or multiple bandwidth parts (BWPs), etc. The methods disclosed herein can be applied to any of the above scenarios having multiple PDSCHs that need to be answered with a single HARQ feedback message.

[0162] In one embodiment, the BS (e.g., gNB) may configure the WTRU semi-statically via RRC signaling and / or configure the WTRU dynamically via L1 / L2 layer signaling to use a fixed HARQ-ACK feedback format to provide feedback for multiple TBs. The WTRU may then multiplex the HARQ-ACK feedback for multiple PDSCH TBs, thereby sending ACK-NACK information for the entire CBG set (e.g., all CBGs in the TB) spanning all TBs in a single HARQ-ACK feedback message. Multiplexing the HARQ feedback for multiple TBs may refer to the WTRU or a group of WTRUs answering the reception of multiple TBs in the same multi-bit HARQ feedback. For example, if the WTRU receives two TBs, the WTRU may bitwise concatenate the HARQ-ACK information bits for the second TB after the HARQ-ACK information bits for the first TB. As an example, if the WTRU receives two TBs and each TB includes 8 CBGs, the multi-bit HARQ feedback may include 16 HARQ-ACK information bits for the two TBs. The first 8 bits may represent the HARQ-ACK information bits for the CBGs in the first TB, and the additional 8 bits may represent the HARQ information bits for the CBGs in the second TB. If the WTRU correctly receives all CBs in a CBG, the WTRU may generate an ACK for the HARQ-ACK information bits for that CBG. If the WTRU does not correctly receive at least one CB of a CBG, the WTRU may generate a NACK for the HARQ-ACK information bits for the CBG.

[0163] As an alternative or in addition, the BS (e.g., gNB) may configure the WTRU or WTRU group semi-statically and / or dynamically to reduce the total number of HARQ feedback bits required to provide feedback for multiple TBs by using variable-bit HARQ-ACK feedback. The WTRU may then multiplex the HARQ-ACK feedback for multiple PDSCHs and thereby send only the ACK or NACK for the CBGs scheduled for retransmission on all TBs in a single HARQ-ACK feedback message.

[0164] In another embodiment, the BS (e.g., gNB) may configure the WTRU or WTRU group to use one or more PUCCH format types with different payloads. The WTRU may then take it as an implicit indication of using a specific feedback format. As an example, if the WTRU is configured with a PUCCH format that can carry only a small amount of UCI payload, it can be regarded as an indication that the BS (e.g., gNB) only expects HARQ feedback based on TBs. The WTRU may then multiplex the ACK-NACK feedback for each TB and provide it as feedback to the BS (e.g., gNB).

[0165] In another embodiment, the BS (e.g., gNB) may configure the WTRU or WTRU group to use a single PUCCH format that can carry a large UCI payload. This can be regarded as an indication that the BS expects CBG-based HARQ feedback for each multiplexed PDSCH or a combination of CBG and TB-level feedback.

[0166] In another embodiment, a WTRU configured with multiple PUCCH resources / resource sets / formats may select one or more resources from the PUCCH resources / resource sets / formats based on the UCI payload. For example, if the WTRU needs to provide multi-bit HARQ feedback responses for several PDSCHs on multiple T-F resources (e.g., time slots, cells, CCs, or BWPs, etc.), the WTRU may select the PUCCH resource set configured for the maximum UCI payload size. However, if the WTRU needs to provide multi-bit HARQ feedback for a small number of PDSCHs, the best way is to select the PUCCH resource set configured for a slightly smaller UCI payload size to serve the WTRU. Additional details regarding PUCCH resource sets / formats and PUCCH resource selection processes are disclosed herein.

[0167] In another embodiment, a WTRU configured with multiple PUCCH format options may autonomously determine whether it will provide single-bit HARQ feedback or multi-bit HARQ feedback for a TB (e.g., by multiplexing CBG-based and / or TB-based feedback). For example, the WTRU may select an appropriate PUCCH format from among multiple PUCCH formats based on the HARQ feedback size. The appropriate PUCCH format may be a format that supports large or small UCI payload capabilities. Based on the appropriate PUCCH format and the HARQ feedback size, the WTRU may determine the type of HARQ feedback to be provided. Additionally, the BS (e.g., gNB) may then determine the type of feedback provided by blind decoding the PUCCH.

[0168] As an alternative or in addition, rather than multiplexing multi-bit HARQ feedback on CBGs for all TBs that need to be acknowledged, the BS (e.g., gNB) may provide the WTRU with the flexibility to multiplex multi-bit CBG-based HARQ feedback for a subset of all TBs with single-bit TB-based HARQ feedback for the remaining TBs. In particular, for a WTRU configured semi-statically and / or dynamically with one or more higher layer parameters, the WTRU may multiplex multi-bit CBG-based HARQ feedback for a subset of TBs while providing single-bit TB-based HARQ feedback for the remaining TBs. For example, a WTRU that receives 5 TBs via 5 component carriers (CCs) may be configured to provide multi-bit CBG-based HARQ feedback for the first three CCs and single-bit TB-based HARQ feedback for the remaining 2 CCs. This means that the WTRU may provide multi-bit HARQ feedback for the first 3 TBs received via the first three CCs and single-bit HARQ feedback for the remaining TBs received via the remaining 2 CCs. These multi-bit HARQ feedback and single-bit HARQ feedback may be multiplexed (or concatenated) in a single feedback message. This technique may be referred to as dynamic codebook design. For example, the multiplexed feedback message may include multi-bit and single-bit HARQ feedback and may be generated based on a codebook that includes a first sub-codebook and a second sub-codebook. The first sub-codebook may be determined based on TB-based PDSCH reception scheduled by fallback DCI. The second sub-codebook may be determined based on CBG-based PDSCH reception scheduled by non-fallback DCI.

[0169] CBG-based multi-bit HARQ feedback can be used for TBs affected by preemption handling, while those TBs not affected by preemption handling or successfully receiving all CBGs (i.e., correctly receiving the entire TB) can be acknowledged via TB-based single-bit HARQ feedback. The term VBG-based multi-bit HARQ feedback can be used interchangeably with multi-bit HARQ feedback, and the term TB-based single-bit HARQ feedback can be used interchangeably with multi-bit HARQ feedback.

[0170] The BS (e.g., gNB) can configure a WTRU with a feedback configuration (i.e., PUCCH format) that allows the WTRU to provide this multiplexed CBG-based multi-bit HARQ feedback and TB-based single-bit HARQ feedback for several PDSCHs in a single HARQ feedback message. For example, if the WTRU uses PUCCH format 2 or PUCCH format 3 or PUCCH format 4 to transmit HARQ feedback, then the WTRU is configured semi-statically and dynamically with a higher layer parameter to provide this single HARQ feedback message. The higher layer parameter can include an indicator (e.g., CBG-DL = ON) for indicating that the WTRU is semi-statically configured to provide HARQ feedback. The indicator (e.g., CBG-DL = OFF) can also indicate that the WTRU is dynamically configured to provide HARQ feedback. In one embodiment, although the WTRU is not configured with a higher layer parameter, the WTRU can provide the multiplexed CBG-based multi-bit HARQ feedback and TB-based single-bit HARQ feedback. The configured feedback format can provide fields for CBG-based multi-bit and TB-based single-bit HARQ feedback for each PDSCH. The WTRU can use the presence of a preemption indication transmitted by the BS (e.g., gNB) as an indication that CBG-based multi-bit HARQ feedback can better serve these PDSCHs, while those PDSCHs that fail to decode and are not preempted (i.e., no preemption indication) can be better served by retransmitting the entire TB. By using a single PUCCH format that supports both TB and CBG-level feedback, the feedback design can be simplified while providing a degree of flexibility, since the format can provide the WTRU with the flexibility to choose whether to provide CBG and / or TB-level feedback for a PDSCH based on the PDSCH without the need for any additional UL signaling. The WTRU can also use the presence of additional signaling (e.g., preemption indication) to assist in its decision-making.

[0171] The WTRU may indicate a subset of the TBs by means of a field in the PUCCH field (e.g., the TB bit mapping). It would be highly beneficial if the WTRU were allowed flexibility in determining how to respond to multiple TBs in a single HARQ-ACK feedback message, especially in cases where the power or coverage of the WTRU is limited. In such cases, by restricting the number of bits transmitted per PUCCH, the UL coverage can be enhanced while the impact on the downlink spectral efficiency is negligible.

[0172] In one embodiment, the WTRU may provide bundled HARQ feedback for all TBs or only a subset of the TBs in a single feedback message. For example, the WTRU may multiplex only the single-bit ACK for each TB from those TBs that are correctly received by the WTRU, or may multiplex the single-bit NACK from each TB that is received in error.

[0173] Similar to the case of a single PDSCH, the WTRU or group of WTRUs may decide on the HARQ feedback format based on the configured PUCCH format. For example, if the WTRU is configured with a small (or minimum) PUCCH payload format, then the WTRU may interpret this as an indication that the BS (e.g., gNB) expects to receive multiplexed TB-based single-bit HARQ feedback for all PDSCHs. However, a WTRU configured with a large PUCCH payload format may interpret this as an indication that the BS (e.g., gNB) expects to receive a single feedback message for several PDSCHs that includes both multiplexed TB-based multi-bit and CBG-based single-bit HARQ feedback.

[0174] To enable feedback options for multiple PDSCHs, various aspects of the HARQ codebook design may be considered. In one example, for CBG-based multi-bit HARQ feedback, a semi-static codebook design may be used for the CBG-based multi-bit HARQ feedback, where the size of the multi-bit HARQ feedback is fixed across all PDSCHs. This process may be based on the number of configured CBGs, e.g., the maximum number of CBGs across all PDSCHs. Such a semi-static codebook design may allow the WTRU to configure a fixed multi-bit codebook size across all PDSCHs, and this process will be combined with the process of providing feedback for all configured component carriers (i.e., all possible PDSCHs including both scheduled and unscheduled PDSCHs). Thus, such a semi-static codebook design will reduce complexity. However, the UCI payload may become too large due to the number of configured CBGs and component carriers.

[0175] As described above, a WTRU using higher layer parameters and configured semi-statically according to the serving cell may receive a PDSCH carrying a TB in a CBG. If the WTRU is configured semi-statically, the maximum number of CBGs may be configured for the WTRU according to the serving cell and via higher layer signaling to generate a semi-static codebook. This codebook may include corresponding HARQ-ACK information bits related to TB reception. Each HARQ-ACK information bit may correspond to all CBGs (including non-scheduled CBGs) in the TB. The payload size of the semi-static codebook may be the same as the number of configured CBGs (i.e., the maximum number of CBGs).

[0176] In another embodiment, the WTRU may use a dynamic HARQ codebook design to provide HARQ feedback messages, where the size of the multi-bit HARQ feedback is fixed across all PDSCHs. For example, similar to the semi-static HARQ codebook design, the size of the multi-bit HARQ feedback may be determined based on the maximum number of CBGs configured across all PDSCHs. However, in the dynamic HARQ codebook design, the WTRU may provide HARQ feedback for the scheduled PDSCHs rather than for all configured PDSCHs. This may be facilitated by using a downlink assignment index (DAI) type mechanism. This approach reduces the HARQ feedback payload size. However, other factors (such as differences in the number of CBGs configured on the scheduled PDSCHs) may offset this reduction.

[0177] Additional embodiments for efficiently using feedback resources and minimizing wasted resources may be described herein. An example is to ensure that the number of CBGs configured on a per-TB basis for multiple TBs is similar, thereby minimizing unnecessary feedback bits transmitted for a set of multiplexed PDSCHs. This process may be accomplished by configuring the same number of CBGs or a number within a certain increment value (such as 0 or 1) for all TBs on multiple PDSCHs. This results in different granularities in the number of CBs forming the CBGs across these TBs and also results in different transmission (retransmission) granularities. However, this process is more preferred than having a large feedback size for each TB (or cell / CC), especially in cases where different cells have different coverage ranges. Additionally, for coverage- and power-limited WTRUs, it is particularly important to limit the number of their feedback bits (and generally the overall feedback). Taking these factors into account, the BS (such as a gNB) may configure the number of CBGs in each TB while considering providing an optimal trade-off in terms of the HARQ feedback size (compared to the CBG transmission (retransmission) granularity) for coverage- and power-limited WTRUs.

[0178] As an alternative or in addition, the BS (e.g., gNB) may schedule the PDSCH in a manner that can reduce / optimize the number of feedback bits that the WTRU needs to send in order to respond to the scheduled PDSCH. For example, the BS (e.g., gNB) may attempt to schedule the PDSCH within a certain configured number “δ” of consecutive time slots. Doing so can significantly reduce the number of wasted or unnecessary HARQ bits. In some cases, scheduling PDSCHs of similar sizes in this manner will additionally reduce feedback. For example, if the scheduled PDSCH is not pre-empted by low-latency traffic, then the WTRU may revert or fallback to multiplexing / bundling single-bit HARQ feedback for all PDSCHs. In particular, when the number of CBGs per PDSCH (for the scheduled PDSCH) is small, such scenarios reduce the likelihood of low-latency traffic affecting these transmissions as the transmission window may be relatively small (e.g., compared to when the number of CBGs configured per PDSCH is relatively large).

[0179] If the low-latency traffic that performs pre-emption is inherently periodic, then the process of scheduling the PDSCH based on the configured number of CBGs will result in effective feedback multiplexing because doing so will either cause all scheduled PDSCHs to be affected by the low-latency traffic or cause none of the scheduled PDSCHs to be affected by the low-latency traffic. The first scenario can be one where the low-latency traffic is periodic and very frequent. The second scenario can be one where the traffic that performs pre-emption is periodic and relatively infrequent. In either case, the WTRU requires one type of feedback, e.g., multi-bit HARQ feedback for the first scenario and single-bit HARQ feedback for the second scenario. This allows the WTRU to effectively utilize the feedback resources.

[0180] As an alternative or in addition, the BS (e.g., gNB) may schedule the PDSCH based on the assigned component carrier (CC). If information on which resources may be used to schedule low-latency traffic is available, then the process of scheduling the PDSCH based on the assigned CC will be very useful. If certain CCs are designated or used to schedule high-priority low-latency traffic, then the BS (e.g., gNB) may consider either scheduling these CCs in consecutive time slots or avoiding these CCs in consecutive time slots. As a result, the process effectively multiplexes the feedback because all PDSCHs will only require multi-bit HARQ feedback (in the case where the scheduled CC transmission is pre-empted) or single-bit HARQ feedback (in the case where the scheduled PDSCH is not affected by pre-emption).

[0181] As an alternative or addition, the coverage of the CC / serving cell will be a determining factor in the process of selecting an appropriate HARQ feedback format for the scheduled PDSCH. For example, if the power of the WTRU is limited due to the coverage of several CCs, then it must revert or fallback to multiplexing, a TB-based single-bit HARQ feedback for all scheduled PDSCHs, in order to improve the UL coverage of the WTRU in these cells.

[0182] As an alternative or addition, it may be necessary to provide some combination of TB-based single-bit and / or CBG-based multi-bit multiplexed HARQ feedback for the scheduled PDSCH. This may occur for scenarios where some subsets of the PDSCH are affected by preemption. In such cases, these preemption-affected WTRUs may need to provide multi-bit HARQ feedback in order to provide feedback on individual CBGs. However, for WTRUs not affected by preemption, single-bit feedback may be sufficient. To provide both TB-based and CBG-based feedback options simultaneously, each individual feedback message may include fixed single-bit and multi-bit feedback fields. If both TB-based and CBG-based feedback can be provided for the scheduled PDSCH, then the result will be to use the transmission resources in an optimal manner and potentially to use the latency in an optimal manner, since this provides the BS (e.g., gNB) with sufficient flexibility in determining the optimal granularity (CBG vs. TB) for retransmissions. Also, similar to a single PDSCH, by using both TB-based and CBG-based feedback simultaneously, built-in error detection handling (with additional robustness) for HARQ feedback errors can also be provided. The disadvantage of such methods is that the UCI payload may be large.

[0183] The WTRU can use the presence or absence of a preemption indication transmitted by the BS (e.g., gNB) to assist it in determining whether to provide CBG-based multi-bit feedback and / or TB-based single-bit HARQ feedback for each scheduled PDSCH. For example, the WTRU can sense the presence of the signal as an explicit indication that the BS (e.g., gNB) expects CBG-based multi-bit HARQ feedback for the affected PDSCH. In another example, the WTRU can have autonomy in terms of the type of feedback format to be used. For example, if there are a large number of CBGs in a scheduled PDSCH that cannot be successfully decoded and two PUCCH formats are configured to support multiplexed TB-based single-bit HARQ feedback or multiplexed CBG-based multi-bit HARQ feedback, then the WTRU can decide that it is better to request a retransmission of all TBs of all PDSCHs. Since the WTRU decides to request a retransmission of all TBs for all PDSCHs, the WTRU can then use single-bit HARQ feedback for all PDSCHs to respond accordingly.

[0184] As described above, the various options for multiplexing HARQ feedback for scheduled PDSCHs can be applied to both semi-static and dynamic codebook designs. As a result, TB-based single-bit HARQ feedback / CBG-based multi-bit HARQ feedback for a set of multiplexed PDSCHs or a combination of both types of feedback can be used for both semi-static codebook designs and dynamic codebook designs.

[0185] For a dynamic HARQ-ACK feedback codebook design (based on the scheduled cell / CC), the BS (e.g., gNB) can indicate the codebook size by using a counter downlink assignment indicator (DAI) and / or the total DAI in each DL assignment scheduled for the PDSCH. Then, even if some DL assignments are lost, the WTRU can reliably determine the number of scheduled PDSCHs. Since the number of CBGs configured in each PDSCH is indicated to the WTRU, the WTRU can use this information in conjunction with the CBGIF bit mapping (or CBGTI bit mapping) from the scheduling DCI for each PDSCH to determine the multi-bit HARQ feedback for this PDSCH. Using the DAI type field helps in scenarios where each TB has the same multi-bit HARQ size (as described above, the size can be based on the maximum number of CBGs configured on all PDSCHs).

[0186] Similar to the case of a single PDSCH or non-multiplexed HARQ feedback, for a WTRU that is semi-statically configured to provide multiplexed multi-bit HARQ feedback for several PDSCHs via multi-bit HARQ feedback, when scheduling one or more PDSCHs that are acknowledged in their respective HARQ feedback responses with a DCI that does not support CBG transmission (retransmission) (e.g., when scheduling a PDSCH with a fallback DCI), for these PDSCHs, the WTRU may need to revert to single-bit HARQ feedback.

[0187] As described above, for a semi-static codebook design, the codebook size can depend on the number of configured CCs, the number of configured CBGs, or the HARQ timing window, etc. As an example, for a WTRU that is configured to have 6 CBGs in each TB, the WTRU may need to provide a single HARQ feedback response for five TBs. The single HARQ feedback response can be generated by multiplexing each codebook for each TB into a single codebook for the entire TB. In one example, all five TBs can be scheduled with a DCI that enables CBG-based transmission (retransmission), and the WTRU can simply respond with a 5*6 = 30-bit HARQ feedback response. However, if one or more TBs are scheduled with a fallback DCI, then the entire TB can be scheduled for TB retransmission. The WTU may need to decide whether to respond with single-bit or multi-bit HARQ feedback. If there is a mixture of single-bit and multi-bit HARQ feedback for different TBs, it may lead to misunderstanding of the feedback.

[0188] In one embodiment, the WTRU may choose to maintain the same feedback response (e.g., for all TBs, use multi-bit feedback to respond regardless of whether it is scheduled by normal or fallback DCI). For those WTRUs configured to provide multi-bit HARQ feedback but scheduled by fallback DCI, the WTRU may simply repeat the single-bit TB ACK or NACK N times to indicate whether the TB was correctly received. Here, N may be the number of CBGs in a TB or the entire TB. Doing so results in a simplified design, but at the cost of increased feedback overhead. For example, a WTRU semi-statically configured to provide multi-bit HARQ feedback may receive two TBs, each with 8 CBGs. For the first TB, if all CB-level CRC checks and the TB-level CRC check pass, the WTRU may generate a TB-level ACK feedback by repeating the ACK information bit 8 times (i.e., 11111111). For the second TB, if all CB-level CRC checks pass but the TB-level check fails, the WTRU may generate a TB-level NACK feedback by repeating the NACK information bit 8 times (i.e., 00000000). Since the WTRU is semi-statically configured to provide multi-bit HARQ feedback, it may be necessary to multiplex these two 8-bit results (i.e., 11111111 for the first TB and 00000000 for the second TB). Thus, the WTRU will transmit a multi-bit HARQ feedback message containing the first multi-bit HARQ feedback for the first TB and the second multi-bit HARQ feedback for the second TB (i.e., 1111111100000000).

[0189] In another embodiment, a WTRU with a single TB scheduled by fallback DCI may use this as an indication that it needs to respond with single-bit HARQ feedback for all TBs in the CC / HARQ timing window. For example, if the WTRU receives 5 TBs scheduled by fallback DCI in 5 different CCs, and each TB includes 6 CBGs, then, if the WTRU is configured to provide multi-bit HARQ feedback, the WTRU may need to provide 30 bits (i.e., 6 bits * 5 TBs). However, if the WTRU can provide single-bit HARQ feedback for all TBs, the number of bits in the HARQ feedback drops from 30 bits to just 5 bits. Although this results in a very low UCI payload, the drawback of such an approach is that there may be a large number of potentially unnecessary retransmissions and wasted spectral efficiency.

[0190] In another embodiment, the choice of whether to respond to multiple aggregated PDSCHs using single-bit or multi-bit HARQ feedback responses can be based on the decoding results of each PDSCH for which a response is required.

[0191] In another embodiment, if a single TB is scheduled by fallback DCI, but the WTRU determines that a large number of other PDSCHs are scheduled for CBG-based transmission (retransmission), or a large number of CBGs are affected by low-latency traffic that performs preemption, then the WTRU may decide to request a retransmission of the entire TB for these PDSCHs. As a result, the WTRU may instead use single-bit HARQ feedback to respond to all PDSCHs. This determination can be based on a certain threshold. Such thresholds can include, but are not limited to, a certain number of PDSCHs or a percentage (x%) of aggregated PDSCHs. By using this mechanism for switching between single-bit and multi-bit HARQ feedback for aggregated PDSCHs, it can result in optimal feedback resource usage (e.g., limiting the UCI payload), while also minimizing the number of unnecessary retransmissions that may result.

[0192] If the WTRU is configured with multi-bit HARQ feedback and uses a feedback format that provides one or more fields in the DCI to indicate single-bit HARQ feedback and / or multi-bit HARQ feedback as a means of enhancing HARQ reliability, then the WTRU can appropriately use these fields depending on whether the PDSCH is scheduled by fallback DCI or non-fallback DCI. For example, for a PDSCH scheduled by non-fallback DCI, the WTRU can use the multi-bit feedback field to provide HARQ feedback for each CBG. For a PDSCH scheduled by fallback DCI, the WTRU can use the single-bit feedback field (or use nothing) to provide single-bit HARQ feedback based on the decoding result of the TB. On the other hand, for a PDSCH scheduled by fallback DCI, the single-bit TB result will be relevant, and the WTRU can also choose to repeat the single-bit feedback result for the multi-bit feedback field (i.e., ACK or NACK for all CBGs based on whether the TB can be successfully decoded). This means that for fallback DCI, the single-bit field is particularly appropriate, but the multi-bit field can also be used to provide multi-bit HARQ feedback based on the TB.

[0193] In the foregoing embodiments, information regarding the number of configured PUCCH resource sets and their UCI payload capabilities may limit the ability of a WTRU to autonomously decide between single-bit or multi-bit HARQ feedback when providing HARQ feedback responses for multiple aggregated PDSCHs. For example, if a WTRU is only configured with a single PUCCH resource set having a small UCI payload capacity, the WTRU may use this as an indication that it should always respond with single-bit HARQ feedback for all aggregated PDSCHs. However, if a WTRU is configured with a PUCCH resource set having a large UCI payload capable of carrying a large UCI payload, the WTRU may use this as an explicit indication that it should always use multi-bit HARQ feedback to respond for each of the aggregated PDSCHs.

[0194] In another embodiment, a WTRU configured with more than one PUCCH resource set may use this as an explicit indication for the WTRU to select an appropriate feedback granularity. In such a case, the BS (e.g., gNB) may need to blindly decode the PUCCH to determine which PUCCH format the WTRU has selected.

[0195] In the case of a dynamic HARQ codebook, the number of CBGs configured for all scheduled PDSCHs is the same, and when a WTRU encounters a mixture of fallback and non-fallback DCI, as described above, the WTRU may choose to use only single-bit HARQ feedback and / or use multi-bit HARQ feedback for these aggregated PDSCHs.

[0196] The above dynamic codebook design can consider HARQ feedback for the scheduled cell / CC instead of all configured cells. With CBG-based scheduling, it is possible to increase the dimension in the dynamic aspect of the codebook design, which is attributed to the CBG-based scheduling / transmission granularity. The size of the multi-bit HARQ feedback can be based on the total number of CBGs in the TB (i.e., the number of configured CBGs) or the CBGs scheduled for transmission (retransmission). By determining the size based on the CBGs scheduled for transmission (retransmission), a variable number of HARQ feedback bits can be generated between retransmissions of the same TB. To account for the variable number of bits between (and within) PDSCHs, the DAI function for the dynamic codebook design can be extended to consider all possible states. For example, if 4 CBGs are configured for a PDSCH, the number of HARQ feedback bits can vary between 1 and 4. To handle consecutive missing DL assignments, the DAI may need 4 bits to support the possible 12 states. Depending on the number of configured CBGs, the DAI size and thus the DCI message may increase significantly. As an alternative or supplement, different PDSCHs configured with different numbers of CBGs may make it very difficult to effectively design the DAI field size. To allow variable-bit feedback, various techniques described here can be used while attempting to limit complexity and DCI overhead.

[0197] In one embodiment, the network can consider restricting the number of CBGs configured for each PDSCH, which in turn can limit the number of possible states that need to be covered by the DAI. As an alternative or supplement, two flavors of DCI can be used, each with a different DAI field size. If the BS (e.g., gNB) considers multiplexing PDSCHs with a similar number of configured CBGs (whether the number is large or small), then this process will be very beneficial, thereby allowing a choice between the two flavors. The process can then limit the DCI size for those PDSCHs configured with a smaller number of CBGs and provide an effective way to use the field.

[0198] In another embodiment, the two forms of DCI can be distinguished based on the variability of the feedback length. For example, one form is for the case where a fixed number of feedback bits are used in each PDSCH (in which case the 2-bit DAI field from LTE can be used as is), and the other form is for the case where there is a variable number of bits in each PDSCH, which in turn requires a DCI with a larger DAI size. Whether the WTRU needs to monitor both forms of DCI can be configured by higher layer signaling and can be done while the BS (e.g., gNB) configures the number of CBGs per TB / PDSCH on a per-WTRU basis with RRC signaling (since the DAI size directly depends on the number of CBGs in the TB).

[0199] In another embodiment, the two types of DCI can be based on the DCI format in LTE. For example, existing DCI format fields can be reused with an extended DAI field. As an example, by combining the existing 2-bit DAI and the 3-bit carrier indicator field (CIF), a 5-bit DAI field (capable of supporting 10 CBGs per TB) can be considered. Although this may result in a loss of flexibility in cross-carrier scheduling, it may not be a problem per se (e.g., when only considering macro deployments). When considering multiplexing HARQ for multiple PDSCHs, this clearly helps to reduce the feedback overhead.

[0200] The WTRU can be configured by the BS (e.g., gNB) to use multiple PUCCH formats, where each PUCCH format has a different payload (UCI) size. Then, the WTRU can consider when to select its appropriate PUCCH format based on the HARQ feedback requirements as described above. In this case, the BS (e.g., gNB) may need to blindly decode the PUCCH in order to determine the format and feedback options being used by the codebook.

[0201] The BS (e.g., gNB) can implicitly or explicitly indicate the time-frequency regions affected by preemption to the affected WTRU or group of WTRUs. The system can specify the use of a certain portion of the system bandwidth in order to accommodate low-latency traffic. The specified region can cover the entire DL system bandwidth or can be limited to a portion of the total DL system bandwidth. The specified region can also be semi-statically assigned or dynamically changing.

[0202] Figure 9An exemplary implicit preemption indication 900 is shown, where the middle part of the DL system bandwidth is designated as a preemptable region 925. As an example, the BS (e.g., gNB) may semi-statically indicate to the WTRU or a group of WTRUs via RRC signaling which parts of the total system bandwidth may be used by the BS (e.g., gNB) to accommodate low-latency traffic. Such semi-static configuration can be regarded as the implicit preemption indication 900, where the BS (e.g., gNB) does not explicitly indicate to the WTRU the resources that will be affected during the preemption process. Then, the WTRU can use this implicit preemption indication 900 to assist in decoding the affected CB / CBG / TB. For example, the WTRU configured with this information can first attempt to decode the PRBs in the designated region. If any CB / CBG in this region is in error, then the WTRU can send multi-bit HARQ feedback indicating the indices of these CBs before processing the remaining PRBs. This processing can be regarded as an early HARQ feedback mechanism based on the implicit preemption indication 900. The early HARQ feedback can trigger an early retransmission, thereby improving latency. As Figure 9 shown, the middle part of the system bandwidth can be designated as a predetermined preemptable region 925. The designated preemptable region 925 may include PRBs that contain CB2, CB3, CB6, CB7, CB14, CB15, CB18, CB19, CB22, CB23, CB26, and CB27. Among the CBs in the preemptable region 925, CB10 905, a part 915 of CB11, and CB18 910 may have been preempted to accommodate low-latency traffic. The top region 920 and the bottom region 930 can be scheduled for eMBB service CBs. For example, the top region 920 and the bottom region 930 may include CB1, CB4, CB5, CB8, CB9, CB12, CB13, CB16, CB17, CB20, CB21, CB24, CB25, and CB28. The WTRU configured with this implicit preemption indication 900 can first attempt to decode the CBs in the preemptable region 925. If the WTRU fails to decode any CB in the preemptable region 925, then the WTRU can send multi-bit HARQ feedback indicating the indices of these CBs before processing the remaining CBs.

[0203] A WTRU having the ability to quickly / actively process received CBG-based transmissions / retransmissions can use this early feedback mechanism. Such WTRUs can be classified as proactive / fast / high-performance WTRUs and can actively / quickly process / decode symbols, mini-slots, sub-slots, or non-slots, etc. within the transmitted time slot. Doing so enables the WTRU to provide early HARQ feedback (i.e., early HARQ-NACK based on early HARQ timing). Different from the normal HARQ feedback timing based on time slots, the early HARQ-NACK feedback timing can be based on symbol, mini-slot, sub-slot, or non-slot timing, etc. Thus, a WTRU capable of providing early HARQ feedback can request a faster retransmission, thereby reducing the retransmission delay.

[0204] In one embodiment, a high-performance WTRU / WTRU group semi-statically configured with a pre-emptable region can preferentially decode resources in the pre-emptable region within a time slot (e.g., symbol, mini-slot, sub-slot, or non-slot, etc.). For example, for each mini-slot, sub-slot, non-slot within a time slot, the WTRU can identify the CBGs that may have been affected by low-latency traffic that has performed pre-emption. Then, the WTRU can determine the CBs within the CBG and can continue to decode the CBs that are part of the CBG that may have been affected by pre-emption. Then, the WTRU can determine the number of CBs within the CBG that have decoding failures. If this number exceeds a certain threshold, then the WTRU will consider the CBG undecodable and thus a failure. If one or more CBGs or a certain threshold of CBGs are considered to have failed, then the WTRU can initiate an early HARQ feedback process (e.g., based on mini-slot / non-slot / sub-slot timing). The early HARQ feedback can be single-bit or multi-bit HARQ feedback. In one example, a WTRU configured with CBG-based multi-bit HARQ feedback can use this process at mini-slot timing to request retransmission of the failed CBGs. For example, a WTRU configured with 8 CBGs in each TB can include 8-bit multi-bit HARQ feedback. The WTRU can use the knowledge of the configured pre-emptable region to preferentially decode resources within these symbols or mini-slots. If the number of affected and thus failed CBGs is large based on a certain quantity (e.g., at least one CBG) or threshold (e.g., percentage or fraction of the configured CBGs), then the WTRU can use multi-bit feedback to inform the BS (e.g., gNB) to retransmit these affected (responded with NACK) CBGs.

[0205] In another embodiment, a WTRU that preferentially decodes resources within a time slot or mini-slot for a configured preemptable region may use early HARQ feedback to request (early) retransmission of an entire TB rather than a specific CBG. This may occur in scenarios where a large number of CBGs are affected by preemptive traffic. For example, if the early HARQ feedback is based on five out of eight possible (or configured) CBGs and the WTRU determines that four out of these five CBGs are corrupted, then the WTRU may send a multi-bit (8-bit) all-NACK feedback that requests the BS (e.g., gNB) to retransmit the entire TB rather than the selected CBG.

[0206] In another embodiment, a WTRU configured with multi-bit HARQ feedback may provide early HARQ feedback in the form of single-bit HARQ feedback based on the TB. For example, a WTRU configured for CBG-based transmission (retransmission) has a PDSCH scheduled by a DCI that does not support CBG-based transmission (retransmission) but supports TB-based transmission (retransmission). The WTRU may provide early HARQ feedback in the form of single-bit HARQ feedback based on the TB. For this purpose, as an example, the BS (e.g., gNB) may use a fallback DCI that does not include a CBG transmission indicator (CBGTI) field or CBG transmission information (CBGTI) field. In this case, even if the WTRU has been configured for CBG-based transmission (retransmission), the fallback DCI may act as an explicit indication for the WTRU to respond using single-bit HARQ feedback based on the TB. In such a scenario, if a single CBG is affected by preemptive traffic, then the WTRU may again use knowledge of the configured preemptable region to preferentially decode resources within these symbols / mini-slots. In this case, if any one (i.e., at least one) of the potentially affected CBGs cannot be decoded due to the preemptive traffic, then the WTRU may provide early HARQ feedback in the form of a single-bit NACK based on the TB at the mini-slot timing rather than having to wait for the normal HARQ timeline, which would cause the BS (e.g., gNB) to retransmit the entire TB faster. As described above, the fallback DCI may not include a CBGTI field for indicating support for single-bit HARQ feedback based on the TB. Conventional (non-fallback) DCI may include a CBGTI field for indicating support for multi-bit HARQ feedback based on the CBG.

[0207] As described above, a WTRU configured with multi-bit HARQ feedback can respond using TB-based single-bit HARQ feedback. In this scenario, if the WTRU notices that a large number of early CBGs are affected by pre-empted traffic, then the WTRU can autonomously select the best (i.e., most suitable) feedback format in order to request a retransmission of the entire TB (as opposed to a specific CBG) using a TB-based single-bit early HARQ-NACK feedback message. With the flexibility to autonomously switch between single-bit and multi-bit HARQ feedback formats for early HARQ feedback for micro-slot-based HARQ timing and normal HARQ feedback for normal (slot-based) HARQ timing, the WTRU can switch between PUCCH resource sets / formats / resources, whereby the WTRU can allow for an optimal use of PUCCH resources. This enables the WTRU to be evenly distributed across different PUCCH resource sets / resources (as opposed to the case where all WTRUs configured for multi-bit HARQ feedback all use either the micro-slot HARQ timing of the feedback alone or only the slot-based timing of the feedback), thereby reducing the likelihood of PUCCH collisions.

[0208] As an alternative or in addition, the window for early HARQ feedback for a WTRU may provide multiple opportunities for the WTRU to provide early HARQ feedback. Each opportunity for providing HARQ feedback may be located at one of several symbol / micro-slot / sub-slot / non-slot boundaries within the scheduled PDSCH transmission time slot. By providing multiple early HARQ feedback opportunities, optimal HARQ performance resulting in reduced retransmission latency may be provided. The early HARQ NACK feedback opportunity may be used to provide cumulative HARQ-NACK feedback. They may indicate HARQ-NACK feedback for all CBGs from the start of the PDSCH transmission up to the current / most recently decoded CBG result, thereby providing multiple possible HARQ-NACKs on a per-CBG basis. As an alternative or in addition, the early HARQ feedback opportunity may be used to provide HARQ-NACK for those CBGs that are between the last early HARQ feedback micro-slot boundary and the current HARQ feedback micro-slot boundary, thereby implying a single HARQ-NACK feedback on a per-CBG basis. The first (cumulative early feedback) option may provide higher reliability at the cost of increased overhead. In one example, a WTRU configured to have 8 CBGs per TB may have two early HARQ-NACK opportunities. The first opportunity may be based on the decoding results of the first two CBGs, and the second opportunity may be based on the decoding results of the first five CBGs. If one of the first two CBGs is corrupted due to preemption, the WTRU may respond with a multi-bit (e.g., 8-bit) HARQ feedback message indicating the NACK for the corrupted CBG at the second HARQ feedback micro-slot boundary. Between the first and second HARQ feedback micro-slot boundaries, if the WTRU recognizes that an additional two (out of three) CBGs are corrupted, the WTRU may respond with another multi-bit HARQ feedback message indicating the NACK for the three corrupted CBGs out of the five CBGs. Since two HARQ feedback messages are provided for the corrupted CBGs in an efficient and cumulative manner, this cumulative early feedback may enhance the reliability of the first two CBGs. Thus, this process may reduce the likelihood of NACK-NACK errors that may lead to increased retransmission latency or ACK-NACK errors that may lead to unnecessary retransmissions.

[0209] In addition, if it is determined that transmission of a slot-based HARQ feedback report is not necessary because a retransmission has been requested, a WTRU that may transmit an early HARQ feedback report to a BS (e.g., a gNB) may stop transmitting the slot-based HARQ feedback report. This is particularly relevant in cases where the WTRU has multiple opportunities to use early HARQ feedback and actually uses these opportunities to request retransmission of certain CBGs and / or the entire TB. The process of stopping the normal HARQ feedback response is particularly associated with cases where the set of PUCCH resources (e.g., resource blocks) used to provide early HARQ as well as normal slot-based HARQ feedback among multiple WTRUs overlaps. Doing so helps to reduce the unnecessary use of PUCCH resources and the likelihood of potential conflicts between different WTRUs.

[0210] In addition, if the WTRU knows that normal HARQ feedback is not needed because it is using early HARQ feedback, it can reduce the possible restrictions on PUCCH resources / PUCCH transmission duration, and can reduce the likelihood of conflicts between WTRUs, as well as reduce the total number of PUCCH resources required to ensure reliable PUCCH performance.

[0211] Figure 10 An exemplary early HARQ feedback timing 1000 within a slot according to mini-slot timing is shown, where this timing may be used in any combination with other embodiments described herein. As Figure 10As shown, TB (or time slot) 1001 can be configured to have a pre-emptable region 1005, where the region includes CBG2 1020, CBG4 1030, and CBGn-1 1034 for low-latency traffic. In the CBGs of the pre-emptable region 1001, some parts 1010 of CBG2 1020 and CBG4 1030 may be pre-empted to accommodate low-latency traffic (i.e., pre-empted by low-latency traffic). The WTRU has multiple (two in this case) early HARQ feedback opportunities (i.e., early HARQ1 1040 and early HARQ2 1045). For the first early HARQ opportunity (i.e., early HARQ1 1040), after the WTRU determines whether any of the first two CBGs (i.e., CBG1 1015 and CBG2 1020) is affected by low-latency traffic that performs pre-emption, the WTRU can determine whether to transmit an early HARQ-NACK response at the early HARQ1 micro-slot timing 1040. For the second early HARQ opportunity (i.e., early HARQ2 1045), after the WTRU determines whether any of the last two CBGs (i.e., CBG3 1025 and CBG4 1030) is affected by low-latency traffic that performs pre-emption or whether any cumulative CBG (i.e., CBG1 1015, CBG2 1020, CBG3 1025, and CBG4 1030) is affected by low-latency traffic that performs pre-emption. Then, as described above, the WTRU can decide whether to provide an early HARQ-NACK response at the early HARQ2 micro-slot timing 1045 only for CBG 3 and 4 1025, 1030 or for CBG 1-4 1015, 1020, 1025, 1030 (cumulative). If the WTRU chooses not to send early HARQ feedback at either the early HARQ1 micro-slot timing 1040 or the early HARQ2 micro-slot timing 1045, then the WTRU can transmit normal HARQ feedback 1050 at the normal HARQ timing 1050 for all CBGs (i.e., CBG1 1015, CBG2 1020, CBG3 1025, CBG4 1030... CBGn-1 1034 and CBGn 1035).

[0212] Figure 11 An illustrative process 1100 for determining early HARQ feedback within a time slot according to micro-slot timing is shown, where the process can be used in any combination with other embodiments described herein. As Figure 11As shown, the WTRU may determine whether to provide early HARQ NACK feedback based on the preemptible region resources within the prioritized decoding time slot. For example, at step 1105, as described above, the WTRU may be configured to have a preemptible region for low-latency traffic. At step 1110, the WTRU may prioritize decoding of resources within the preemptible region in the time slot. At step 1115, the WTRU may identify, for each mini-slot, the CBGs that may be affected by low-latency traffic. At step 1120, the WTRU may attempt to decode the CBs in the identified CBGs that may be affected. At step 1125, if the number of CBs in the identified CBGs is greater than a predetermined threshold, then at step 1130, the WTRU may further identify, for each mini-slot, the CBGs that contain failed (or corrupted) CBs. Then, at step 1135, the WTRU generates early HARQ feedback within the time slot in accordance with the mini-slot-based HARQ timing. However, at step 1125, if the number of CBs in the identified CBGs is less than the predetermined threshold, then at step 1140, the WTRU may generate normal HARQ feedback in accordance with the time-slot-based HARQ timing. The predetermined threshold may be received from the BS via a broadcast message or an RRC message. Also, the predetermined threshold may be pre-configured in the memory of the WTRU.

[0213] In one embodiment, when eMBB data is preempted by low-latency data, early HARQ feedback may be used to reduce the retransmission latency. When the WTRU cannot decode too many CBs of the CBGs in the preempted region, early HARQ feedback may be transmitted in accordance with the mini-slot HARQ timing. For example, the WTRU may first prioritize decoding of the CBs in one or more CBGs of the PDSCH transmission in the configured preemptible resources (i.e., the preemptible CBGs), where one CBG may include a set of CBs. Then, the WTRU may determine one or more preemptible CBGs in the PDSCH transport block (TB) transmission. For a preemptible CBG among the determined one or more preemptible CBGs, the WTRU may receive and attempt to decode one or more corresponding CBs. The WTRU may determine the number of CBs that decode failed in the preemptible CBG. When the number of failed CBs in the preemptible CBG exceeds the predetermined threshold, the WTRU may transmit early HARQ feedback based on the mini-slot HARQ timing. As an alternative or in addition, when the number of failed CBs in each preemptible CBG in the time slot is at or below the predetermined threshold, the WTRU may transmit regular HARQ feedback in accordance with the time-slot-based HARQ timing.

[0214] In another embodiment, in addition to semi-statically configuring (e.g., via RRC signaling) information about a designated pre-emptable region for the WTRU, the BS (e.g., gNB) may explicitly indicate the location of the affected time / frequency resources via dynamic signaling. Doing so can provide the WTRU with the explicit location of the affected time or frequency resources so that the WTRU can use it to assist in decoding the affected CB / CBG / TB. For example, similar to the case of implicit indication, the WTRU may first attempt to decode the CB in the indicated / affected PRB. Then, the WTRU may transmit HARQ feedback based on the result of that decoding, thereby allowing for early retransmission. Although this explicit indication may have a higher signaling overhead, it differs from the case of implicit indication in that it provides more precise information about the affected resources.

[0215] The BS (e.g., gNB) may dynamically provide additional timing and / or resource location information to the WTRU or a group of WTRUs for the WTRU to send an early HARQ feedback message. This information may be provided as part of the pre-emption indication signaling. The WTRU may select to send an early HARQ feedback message based on the location of the affected resources (in time and / or frequency). For example, the location of the pre-empted resources may occur very early in the scheduling time slot (e.g., one of the first few symbols). The WTRU may have information about the location of the frequency resources that are likely to be used in order to accommodate low-latency traffic. In such a scenario, the WTRU may provide early HARQ feedback based on the decoding result of the frequency resources in these symbols. As an alternative or in addition, if the location of the pre-empted resources imposes an undue restriction on the WTRU processing time, then the WTRU may decide not to provide an early HARQ feedback message (e.g., in the case where the pre-emption affects symbols / symbol groups at the end of the scheduling time slot).

[0216] In another embodiment, the WTRU may be semi-statically pre-configured with a set of PUCCH resources dedicated to providing early HARQ feedback. This set of PUCCH resources may include resources common to the set of resources pre-configured for normal (slot-based) HARQ feedback. As an alternative or in addition, these resources may be separated from other sets of PUCCH resources for normal HARQ feedback according to the normal slot-based HARQ timing.

[0217] If the selected PUCCH format can include medium UCI (HARQ) payloads and is transmitted over multiple / some symbols / micro-slots / sub-slots (e.g., a PUCCH with a long duration on a single resource block pair (PUCCH format 4)), thereby effectively using the PUCCH resource set, then multiple WTRUs can share the same resource block pair. Devices sharing the same resource block pair within a symbol / micro-slot can be separated by different orthogonal phase rotations of the frequency domain sequence (e.g., cyclic shifts in the time domain). As an alternative or addition, for larger UCI payload formats (e.g., greater than 2 bits) that use multiple resource block pairs (e.g., PUCCH format 2 or 3), the symbol / micro-slot / non-slot multiplexing capacity can be increased by having multiple WTRUs share the same resource block pair (where each WTRU uses a different orthogonal cover sequence), thereby reducing the number of PUCCH resources required for early HARQ feedback.

[0218] Since the number of high-performance WTRUs capable of performing active HARQ processing is likely to be a small fraction of the total served WTRUs, these resources are likely to be very limited and can be shared among WTRUs or groups of high-performance WTRUs. The BS (e.g., gNB) can use the HARQ feedback data received from the WTRUs to determine the percentage of high-performance WTRUs among the WTRUs. The BS can also determine which portion of these WTRUs actually transmits early HARQ-NACK feedback. Then, the BS (e.g., gNB) can use this data to semi-statically reconfigure the PUCCH resource set in order to optimize resource usage.

[0219] Since early HARQ feedback can be single-bit or multi-bit HARD feedback (as described above), a WTRU can be semi-statically pre-configured with more than one PUCCH resource set / format in order to provide early HARQ feedback to the BS (e.g., gNB). These PUCCH resources can be differentiated based on payload size (e.g., based on the HARQ payload size of a normal time slot).

[0220] In another embodiment, the WTRU can use the same PUCCH resources (resource blocks) that have been defined for time-slot-based HARQ feedback.

[0221] In any of the above embodiments, the WTRU may need to consider the fact that the resources required to provide early HARQ feedback resources may conflict with the resources used to provide slot-based HARQ feedback in the time domain / frequency domain. For example, if early HARQ uses resources (resource blocks) on a set of symbols / micro-slots within a time slot, then these transmissions may overlap and thus affect the slot-based HARQ feedback transmission window. As an alternative or addition, the need to accommodate high-performance WTRUs (i.e., those capable of performing early HARQ feedback) and baseline-capability WTRUs (i.e., those that can only perform normal HARQ feedback) may require sharing PUCCH resources among different WTRUs in order to limit the use of PUCCH. However, doing so may increase the likelihood of conflicts between WTRUs.

[0222] A simple way to avoid the possibility of conflicts is to immediately stop normal HARQ transmissions when early HARQ feedback has been transmitted. As described above, doing so can reduce the limitations on early HARQ feedback and there is no loss in the reliability of overall retransmissions, nor is there any loss in the likelihood of conflicts between PUCCH retransmissions of different WTRUs.

[0223] The WTRU may need to transmit early HARQ feedback and normal HARQ feedback related to high-reliability applications. To ensure that early HARQ (based on micro-slot timing) feedback does not affect normal HARQ feedback, the WTRU can limit early HARQ feedback to PUCCH transmissions of very short duration, thereby ensuring that the early HARQ feedback transmission ends before the slot-based HARQ feedback transmission window. Since it can be assumed that at any given time, only a small number of WTRUs in the system have limited power and limited coverage, and most WTRUs do not require transmissions of long PUCCH durations, using PUCCH transmissions of very short duration will not have a negative impact on the reliability of HARQ feedback and thus can be acceptable.

[0224] In another embodiment, the WTRU may be limited in the number of available early HARQ feedback transmission opportunities within a time slot. For example, in Figure 10In this case, the WTRU may be restricted to a single early HARQ feedback occasion (i.e., early HARQ 11040), rather than two early HARQ feedback transmission occasions (early HARQ 1 1040 and early HARQ 2 1045). This restriction may be based on whether short or long PUCCH transmissions are configured / used for HARQ feedback. For example, if the WTRU needs to use a very long-duration PUCCH transmission for HARQ feedback, then it may determine that early HARQ 1 1040 provides the only occasion for early HARQ feedback. On the other hand, if the WTRU needs to use a very short-duration PUCCH transmission, then providing both HARQ feedback opportunities (i.e., early HARQ 1 1040 and early HARQ 2 1045) would be satisfactory, since neither of them would interfere with normal (slot-based) HARQ transmission 1050.

[0225] In another embodiment, the WTRU may use transmit diversity similar to space-orthogonal resource transmit diversity (e.g., in LTE) by using different resources on different antennas (code domain may also be used in addition to time and frequency resources). Doing so may allow PUCCH transmissions from different antennas to appear primarily as two PUCCH transmissions from two different WTRUs (at the cost of twice the PUCCH resources). This means that the WTRU may use the code domain (e.g., different codes on each antenna) to separate two HARQ feedback transmissions, rather than using the same PUCCH resources for early and normal HARQ feedback. Doing so may effectively provide early HARQ feedback and normal HARQ feedback transmissions.

[0226] In another embodiment, if low-latency traffic (e.g., URLLC) pre-empts eMBB WTRU resources, then in addition to sending an explicit indication about the pre-empted resources, the BS (e.g., gNB) may even automatically decide to retransmit the affected CB / CBG (or perform a subsequent transmission for it) before it receives HARQ feedback from the WTRU. The existence of the subsequent transmission may be indicated to the WTRU or the set of affected WTRUs by means of a 1-bit flag, and may be sent to the WTRU together with the explicit indication signal.

[0227] Then, the WTRU may use the flag by not providing any HARQ feedback, since the WTRU knows that if the initial transmission fails, then the WTRU may use the subsequent transmission to decode the affected CB. This mechanism may have the dual benefit of improving latency while reducing signaling overhead, at the cost of using additional transmission resources.

[0228] In another embodiment, the WTRU may not have information as to whether it has preempted the resources of an initial scheduling. This may happen when: (i) there is no semi-static configuration information related to a predefined preemptable region; (ii) the dynamic indication of the preempted resources received via downlink control information (DCI) fails to arrive before the ACK / NACK feedback; or (iii) there is no explicit indication of the preempted resources to start with. In such a case, the WTRU may monitor subsequent scheduling assignments (e.g., subsequent time slots) to see if any CB / CBGs for the TBs that were initially scheduled for transmission in a previous time slot / micro-slot are now being scheduled as subsequent transmissions.

[0229] The BS (e.g., gNB) may inform the WTRU of the resources affected by the low-latency traffic that has performed the preemption by transmitting a preemption indication, and thereby inform it of the affected CB / CBGs. This preemption indication and the resulting retransmission may assist the WTRU when it determines how to handle the affected CBG and decode the TB.

[0230] In one embodiment, the WTRU may decide to flush the soft buffer content associated with all of the affected CBGs or a subset of the affected CBGs, and perform decoding using the retransmission process for these affected CBGs. This method of flushing all relevant content of the CBGs would be very beneficial if a large number of CBs in the affected CBGs have been corrupted due to preemption. In such a case, as opposed to the highly unreliable initial transmission, the best approach is to use the HARQ combining process on subsequent retransmissions.

[0231] In another embodiment, the WTRU may decide to flush the soft buffer content related to a subset of the CBs within the set of affected CBGs rather than the entire CBG. In this scenario, if different redundancy versions (RVs) are used to retransmit the CBs in the soft buffer that were not flushed as a means of increasing the decoding success rate, then the WTRU may use an incremental combining process if the retransmission is based on the same incremental redundancy (IR) or incremental redundancy HARQ as the initial transmission. The WTRU may utilize CB-level CRC checks as a method for deciding which CBs in the CBG need to be flushed. This method is particularly useful if a small number of CBs in the CBG have been corrupted due to preemption.

[0232] Timing of CBG-based transmissions may affect HARQ feedback of the WTRU. The BS (e.g., gNB) may schedule CBG-based retransmissions for TBs affected by pre-empted low-latency traffic. The BS (e.g., gNB) may initiate the retransmission either proactively (i.e., before receiving HARQ feedback from the WTRU) or based on the final HARQ ACK-NACK feedback provided by the WTRU.

[0233] In one embodiment, the BS (e.g., gNB) may decide to proactively retransmit the CBG affected by pre-emption (e.g., without waiting for the final HARQ response from the WTRU). This process may be performed based on an estimated decoding failure probability based on the number of affected resources and thus based on the number of affected CBGs, etc. For the proactive or subsequent transmissions, the BS (e.g., gNB) may indicate to the WTRU the timing and resources of the HARQ feedback that the WTRU needs to use.

[0234] In this scenario, the WTRU may decide to respond with two separate HARQ feedback messages. The first HARQ message may be based on the initial PDSCH (TB) transmission timing, and the second HARQ message may be based on the new / updated resource / timing information provided with the subsequent transmission. The WTRU may use HARQ combining for the initial transmission and the subsequent transmission for the second HARQ message. As an alternative or in addition, the two HARQ messages may differ in terms of the granularity of the feedback format (e.g., multi-bit vs. single-bit), etc. In one example, if the result of the pre-empted initial transmission causes several CBGs to be decoded incorrectly, then the WTRU may provide CBG-based multi-bit HARQ feedback to inform the BS (e.g., gNB) which CBGs need to be retransmitted. If the HARQ combining of the initial transmission and the subsequent transmission still results in several CBGs being in error or the entire TB being successfully decoded, then the WTRU may decide to provide a single-bit HARQ feedback message for either case. This process may be regarded as an implicit indication to the BS (e.g., gNB) that the entire TB should be retransmitted in the next retransmission.

[0235] As an alternative or in addition, if both the initial transmission and the subsequent transmission result in a small number of CBGs being in error, then from the perspective of spectral efficiency, providing CBG-based HARQ feedback to the BS (e.g., gNB) may be more efficient as opposed to single-bit feedback that results in retransmission of the entire TB, whereby the BS (e.g., gNB) may retransmit those CBGs requested by the WTRU.

[0236] The flexibility of the WTRU to select the best feedback option for each message helps reduce UCI overhead while providing the best performance in terms of spectral efficiency. As a replacement or supplement, the robustness of the ACK-NACK message can also be improved by using two HARQ feedback messages.

[0237] The switching between HARQ feedback options can be facilitated by configuring different PUCCH formats for the WTRU. Then, the BS (e.g., gNB) can determine the feedback message granularity by blindly decoding the PUCCH. In one embodiment, when the subsequent transmission performed by the BS (e.g., gNB) is based on the result of HARQ combining that combines two transmissions, the WTRU can be configured to respond with a single HARQ feedback response. This process can be configured in an explicit or implicit manner. For example, an indication of the subsequent transmission regarding the BS (e.g., gNB) can be regarded as a signal to send a single HARQ response. Then, the WTRU can send a single HARQ response based on the result of HARQ combining that combines two transmissions. The timing of this response can be based on the newly indicated timing / resources to provide the WTRU with sufficient processing time. As a replacement or supplement, the WTRU can autonomously determine the format (e.g., single-bit vs. multi-bit) for this single HARQ feedback response. For example, if only a small number of CBGs are in error, it is best to respond with a CBG-based multi-bit HARQ feedback. However, if a large number of CBGs are continuously in error, the WTRU can respond with a single-bit NACK, thereby indicating to the BS (e.g., gNB) that the entire TB needs to be retransmitted. By using a single HARQ feedback message to respond, the feedback overhead can also be saved. For example, if one or more subsequent transmissions result in the successful reception of one or more previously damaged CBGs, the WTRU waiting to send a single HARQ message can transmit a single-bit ACK representing that the entire TB has now been received. In contrast, if relying on HARQ-based retransmissions or subsequent transmissions with two HARQ feedback messages, this will result in at least one multi-bit HARQ message followed by another multi-bit or single-bit HARQ message. The above process can be extended to the case where the BS (e.g., gNB) schedules one or more subsequent transmissions after a preemption. As a replacement or supplement, if the BS (e.g., gNB) schedules CBG retransmissions based on the HARQ feedback provided by the WTRU, the WTRU can simply follow the timing associated with the initial TB transmission.

[0238] As an alternative or in addition, the HARQ processing capabilities of the WTRU may affect HARQ processing and feedback response times. In one example, if a high-performance WTRU receives an original transmission followed by a subsequent transmission, the WTRU may use early HARQ feedback (based on mini-slot timing) and / or normal HARQ feedback (based on slots) for the initial transmission. The WTRU may then perform the same operation for the subsequent transmission (after HARQ combining with the initial transmission). This processing may be used as a method to improve HARQ reliability.

[0239] In another embodiment, the WTRU may respond to the initial transmission using only slot-based HARQ responses, followed by a combination of early HARQ feedback (based on mini-slots) and / or normal HARQ feedback (based on slots) for the subsequent transmission after HARQ combining with the original transmission.

[0240] In another embodiment, the WTRU may stop sending HARQ responses for the initial transmission and wait for the subsequent transmission before sending a HARQ feedback response. The resulting HARQ feedback response may be based on HARQ combining of the initial transmission and the subsequent transmission and may include early HARQ feedback and / or normal HARQ feedback.

[0241] In the above example, the early HARQ feedback generated during the transmission of the subsequent transmission may be based on the HARQ combining result of the initial transmission (already received) and the CBG received in the initial symbol / mini-slot of the subsequent transmission. In Figure 10 it is envisioned that there are two consecutive (TB / slot 1001) transmissions (the second transmission of the TB / slot is not shown in Figure 10 ), and the early HARQ mini-slot timing opportunity occurs within the symbols / mini-slots / non-slots of the second slot (subsequent transmission). For this scenario, the WTRU may use a preemption indication (via group-shared PDCCH) and CBG clearing indication (CBGFI) information in the process of determining whether the subsequent transmission can be scheduled by the BS (e.g., gNB). This can justify skipping the HARQ feedback response based on the initial transmission rather than waiting to receive the subsequent transmission before responding with a HARQ response.

[0242] The granularity (e.g., single-bit vs. multi-bit) and format of the early and / or normal HARQ feedback responses for the initial and / or subsequent transmissions may follow the above process.

[0243] Although specific combinations of features and elements have been described above, those of ordinary skill in the art will recognize that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in a computer program, software, or firmware that is introduced into a computer-readable medium for operation by a computer or processor. Examples of computer-readable media include electrical signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memories, semiconductor storage devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM discs and digital versatile discs (DVDs)). A processor associated with the software can be used to implement the radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any computer host.

Claims

1. A method implemented by a wireless transmit / receive unit (WTRU), the method comprising: Receiving configuration information that indicates a configuration for the WTRU to utilize multi-bit hybrid automatic repeat request (HARQ) feedback, wherein the multi-bit HARQ feedback is configured for the WTRU to provide feedback for each codeblock group (CBG) of a given transport block (TB), and the configuration information indicates a maximum number of CBGs for HARQ feedback based on CBGs; Receiving information indicating a downlink shared channel transmission for the WTRU, the downlink shared channel transmission including a first TB, the first TB including a first plurality of CBGs; And Receiving a dynamic preemption indication, wherein the dynamic preemption indication indicates that one or more sets of time-frequency resources corresponding to the downlink shared channel transmission are preempted by another transmission, the one or more sets of time-frequency resources corresponding to at least one CBG of the first plurality of CBGs in the first TB.

2. The method according to claim 1 further comprises: Attempting to decode each CBG of the CBGs included in the first plurality of CBGs, and transmitting first HARQ feedback for the TB, wherein the first HARQ feedback for the TB includes respective HARQ feedback bits for each CBG of the first plurality of CBGs in the first TB.

3. The method according to claim 2, wherein a negative acknowledgment is indicated in each bit corresponding to the at least one CBG, the at least one CBG being associated with the time-frequency resources indicated as preempted by the dynamic preemption indication.

4. The method according to claim 1, wherein the plurality of bits to be included in the multi-bit HARQ feedback transmission corresponds to the maximum number of CBGs for HARQ feedback based on CBGs.

5. The method according to claim 4, wherein each bit of the plurality of bits is associated with a plurality of codeblocks.

6. The method according to claim 1, wherein the configuration information is received in a radio resource control (RRC) message.

7. The method according to claim 1, further comprising receiving a semi-static configuration indicating a plurality of time-frequency regions that can be preempted, wherein the dynamic preemption indication explicitly indicates which time-frequency region of the plurality of time-frequency regions has been preempted.

8. The method according to claim 1, wherein the indicated preemption is transmitted to a plurality of WTRUs.

9. The method according to claim 1, further comprising receiving a retransmission, the retransmission including at least one CBG of the first plurality of CBGs associated with the one or more sets of time-frequency resources indicated as preempted by the preemption indication.

10. A wireless transmit / receive unit (WTRU) comprising: A transceiver; And A processor configured to: Receive configuration information that indicates a configuration for the WTRU to utilize multi-bit hybrid automatic repeat request (HARQ) feedback, where the multi-bit HARQ feedback is configured for the WTRU to provide feedback for each codeblock group (CBG) of a given transport block (TB), and the configuration information indicates a maximum number of CBGs for CBG-based HARQ feedback; Receive information indicating a downlink shared channel transmission for the WTRU, the downlink shared channel transmission including a first TB that includes a first plurality of CBGs; And Receive a dynamic preemption indication, where the dynamic preemption indication indicates that one or more sets of time-frequency resources corresponding to the downlink shared channel transmission are preempted by another transmission, the one or more sets of time-frequency resources corresponding to at least one CBG of the first plurality of CBGs in the first TB.

11. The WTRU according to claim 10, wherein the processor is further configured to attempt to decode each CBG included in the first plurality of CBGs, and the transceiver is further configured to transmit a first HARQ feedback for the TB, wherein, The first HARQ feedback for the TB includes respective HARQ feedback bits for each CBG of the first plurality of CBGs in the first TB.

12. The WTRU according to claim 11, wherein a negative acknowledgment is indicated in each bit corresponding to the at least one CBG, the at least one CBG associated with the time-frequency resources indicated as preempted by the dynamic preemption indication.

13. The WTRU according to claim 10, wherein the plurality of bits to be included in a multi-bit HARQ feedback transmission corresponds to the maximum number of CBGs for CBG-based HARQ feedback.

14. The WTRU according to claim 13, wherein each bit of the plurality of bits is associated with a plurality of codeblocks.

15. The WTRU according to claim 10 or the method according to claim 1, wherein the dynamic preemption indication is received in downlink control information (DCI).

16. The WTRU according to claim 10, wherein the configuration information is received in a radio resource control (RRC) message.

17. The WTRU according to claim 10, wherein the processor is further configured to receive a semi-static configuration indicating a plurality of time-frequency regions that can be preempted, where the dynamic preemption indication explicitly indicates which of the plurality of time-frequency regions has been preempted.

18. The WTRU according to claim 10, wherein the indicated preemption is transmitted to a plurality of WTRUs.

19. The WTRU according to claim 10, wherein the processor is further configured to receive a retransmission that includes at least one CBG of the first plurality of CBGs associated with the one or more sets of time-frequency resources indicated as preempted by the preemption indication.

Images