Receiver feedback in wireless systems

Abstract

To provide systems and methods for receiver feedback in wireless systems.SOLUTION: Receiver feedback formats, contents, types and / or timing may be determined as a function of at least one of a type of soft-combining processing to apply in a HARQ process, a HARQ operating point for the HARQ process, one or more reference transmissions for controlling a type of HARQ feedback for the HARQ process, and a feedback suppression parameter for one or more transmissions in a sequence associated with the HARQ process or a transport block (TB). Uniform and non-uniform CB-to-CBG mappings may be provided based on one or more parameters, interference and channel conditions and / or a probability of pre-empting transmissions or actual pre-empting transmissions.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Application No. 62 / 442,093, filed January 4, 2017, U.S. Provisional Application No. 62 / 453,085, filed February 1, 2017, U.S. Provisional Application No. 62 / 500,989, filed May 3, 2017, U.S. Provisional Application No. 62 / 519,675, filed June 14, 2017, and U.S. Provisional Application No. 62 / 542,927, filed August 9, 2017, all of which are incorporated herein by reference. [Background technology]

[0002] Mobile communications using radio communication continues to evolve. The fifth generation is sometimes referred to as 5G. Previous (legacy) generations of mobile communications can be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention [Problem to be solved by the invention]

[0003] SUMMARY OF THE DISCLOSURE Systems, methods and means are provided for receiver feedback in wireless systems. [Means for solving the problem]

[0004] Systems, methods, and means for receiver feedback in wireless systems are disclosed. The receiver feedback format, content, type, and / or timing can be determined, for example, as a function of a hybrid automatic repeat request (HARQ) processing state. The HARQ processing state can correspond, for example, to a sequence of transmissions for a HARQ process, a maximum time for a HARQ process to be successful, a measured or estimated link quality, demodulation performance, and / or a number of successfully decoded code blocks. The receiver feedback format, content, type, and / or timing can be determined, for example, as a function of a configuration of a wireless transmit / receive unit (WTRU). The configuration can indicate one or more of a type of soft combining process applied in the HARQ process, a HARQ operating point for the HARQ process, one or more reference transmissions for controlling a type of HARQ feedback for the HARQ process, a feedback suppression parameter for one or more transmissions in a sequence associated with a HARQ process or a transport block (TB). A (e.g., efficient) transmission of a subset of one or more code block groups (CBGs) can be used. Adaptive resource allocation can be used to transmit a subset of one or more CBGs. Minislots can be used for retransmission of a subset of one or more CBGs. The WTRU can monitor a downlink control channel (e.g., of a new downlink) (e.g., when anticipating a transmission). Retransmission of a CBG index can be indicated. A timing relationship between downlink allocation, transmission (retransmission), and adaptive feedback for adaptive slot size can be used. For example, uniform and non-uniform mapping from CBs to CBGs can be provided (e.g., by the WTRU) based on one or more parameters, interference and channel conditions, and / or probability or actual preempting transmission.For example, an indication of a CB to CBG mapping may be provided, supporting selection of a CB to CBG mapping from multiple CB to CBG mappings. Intra-WTRU and inter-WTRU interference / preemption indications may be provided. A feedback bit counter downlink allocation index (DAI) may enable the WTRU to determine how many feedback bits were needed for feedback reporting of missed DL allocations. Adaptive bundling of feedback report bits may be used to achieve a constant feedback report size per DL allocation. Unequal reliability may be used for multiplexed feedback reports.

[0005] The WTRU and wireless communication system may have one or more computer processors configured (e.g., programmed with executable instructions). For example, the WTRU may have a processor configured to communicate with a wireless communication network (e.g., using UR-LLC communication). The WTRU processor may be configured to receive a first downlink control information (DCI) indicating whether a transport block (TB)-based hybrid automatic repeat request (HARQ) feedback should be provided for a downlink transmission or whether a code block group (CBG)-based HARQ feedback should be provided for a downlink transmission. The WTRU processor may be configured to receive a downlink transmission associated with the first DCI, the downlink transmission including a transport block having one or more code blocks. The WTRU processor may be configured to attempt to decode one or more code blocks of the transport block. The WTRU processor may be configured to determine that the first DCI indicates that a CBG-based HARQ feedback should be provided. If the processor determines that the first DCI indicates that CBG-based HARQ feedback should be provided, the WTRU processor may be configured to determine a mapping of the one or more code blocks to one or more CBGs, determine HARQ feedback for at least one of the one or more CBGs based on whether decoding of a corresponding code block for the at least one CBG is successful, and transmit the HARQ feedback for the one or more CBGs to the wireless communication network. The WTRU processor may be configured to determine that the first DCI indicates that TB-based HARQ feedback should be provided.If the WTRU processor determines that the first DCI indicates that TB-based HARQ feedback should be provided, the WTRU processor may be configured to determine HARQ feedback for the transport block and send the HARQ feedback for the transport block to the wireless communication network.

[0006] The mapping can be a mapping of one or more code blocks to code block groups in at least one of frequency or time, and can be based on one or more of the number of subcarriers or OFDM symbols assigned to a code block group or transmission, the maximum code block length, the number of code block groups in a transmission, the number of code blocks in a transmission, and the number of time symbols and / or resource blocks occupied by a potential preempting transmission.

[0007] The determined HARQ feedback for the one or more CBGs can be an ACK if the decoding of each of the corresponding code blocks is successful, or a NACK if the decoding of one or more of the one or more code blocks is not successful. The WTRU processor can be configured to receive a retransmission from the wireless communication network in response to the transmitted NACK. The wireless communication network can have a processor configured to receive the transmitted ACK or NACK and determine to transmit a retransmission if a NACK is received.

[0008] The WTRU processor can be configured to receive a second DCI for the retransmission. The second DCI can indicate which CBGs are to be retransmitted. The second DCI can indicate which CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding. The second DCI can include a bitmap that can be used to indicate which CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding. The wireless communication network can have a processor configured to determine to transmit the second DCI and content of the second DCI.

[0009] The WTRU processor can be configured to monitor for the first downlink control information and, based on a preemption command from the wireless communication network, to monitor for the second downlink control information. The wireless communication network can have a processor configured to determine to send a preemption command to the WTRU.

[0010] The WTRU may include a HARQ buffer. A WTRU processor may be configured to manage the HARQ buffer and to discard data in the HARQ buffer if one or more code blocks are not successfully decoded.

[0011] The WTRU processor may be configured to determine a preemption indication to send in uplink control information to the wireless communication network if one or more code blocks are not successfully decoded.

[0012] The wireless communication network may have a processor configured to determine to transmit first downlink control information (DCI) indicating whether transport block (TB)-based hybrid automatic repeat request (HARQ) feedback should be provided for a downlink transmission or whether code block group (CBG)-based HARQ feedback should be provided for a downlink transmission, and to transmit the first downlink control information. The wireless communication network may have a processor configured to receive the transmitted HARQ feedback, including the TB-based HARQ feedback. Effect of the Invention

[0013] A system, method and means are provided for receiver feedback in a novel wireless system. [Brief description of the drawings]

[0014] [Figure 1A] FIG. 1 illustrates an example communication system for implementing one or more disclosed examples. [Figure 1B] 1A is a system diagram illustrating an exemplary wireless transmit / receive unit that may be used within the communications system illustrated in FIG. 1A, in accordance with an example. [Figure 1C] 1A is a system diagram illustrating an example radio access network and an example core network that can be used within the communications system illustrated in FIG. 1A, according to an example. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communications system illustrated in FIG. 1A, in accordance with an example. [Diagram 2] FIG. 1 illustrates an example of a punctured transmission using different HARQ feedback types for each transmission. [Diagram 3] FIG. 1 is a diagram showing an example of a CBG spanning multiple CBs in the time domain. [Figure 4] FIG. 1 is a diagram showing an example of a CBG spanning multiple CBs in the time domain. [Diagram 5] FIG. 13 shows an example of a non-uniform mapping from CBs to CBGs that allows minimizing retransmitted CBs in the preemption case. [Figure 5A] FIG. 1 illustrates an example of frequency-first and time-first CB-CBG mapping. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] A detailed description of illustrative embodiments will now be given with reference to various figures. While this description provides detailed examples of possible implementations, it should be noted that the details are intended to be illustrative and in no way limit the scope of the present application.

[0016] 1A illustrates an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable the multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may utilize 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-tailed Unique Word DFT Spread OFDM (ZT UW DFT-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, and Filter Bank Multi-Carrier (FBMC).

[0017] 1A, the communications 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, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and / or “STA,” 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 phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain situations), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be referred to interchangeably as UEs.

[0018] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

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

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

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

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

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a wireless technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Global 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).

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

[0027] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error resilience requirements, reliability requirements, data throughput requirements, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs that utilize the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) that utilizes GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

[0030] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombination of the above elements while remaining consistent with an embodiment.

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

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

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

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

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

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

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

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

[0039] The WTRU 102 may include a full-duplex radio where the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception).

[0040] 1C is a system diagram illustrating the RAN 104 and the CN 106, according to an embodiment. As mentioned above, the RAN 104 can communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 can also communicate with the CN 106.

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

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

[0043] 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the above elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity different from the CN operator.

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

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

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

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

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

[0049] In an exemplary embodiment, the other network 112 may be a WLAN.

[0050] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP for delivery to the respective destination. Traffic between STAs in the BSS may be sent through the AP, e.g., a source STA may send traffic to the AP, which may deliver the traffic to the destination STA. Traffic between STAs in the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent (e.g., directly) between a source STA and a destination STA using a direct link setup (DLS). In one representative embodiment, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs (e.g., all of the STAs) in or using an IBSS may communicate directly with each other. IBSS mode communication is sometimes referred to herein as an "ad-hoc" mode of communication.

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

[0052] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0053] A Very High Throughput (VHT) STA can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. The 160 MHz channel can be formed by combining eight contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time domain processing can be performed separately for each stream. The streams can be mapped onto two 80 MHz channels and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed and the combined data can be transmitted to the Medium Access Control (MAC).

[0054] Sub-1 GHz mode operation can be supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices can have limited functionality, including, for example, support of (e.g., only) a certain bandwidth and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0055] A WLAN system, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, that may support multiple channels and channel bandwidths, includes a channel that may be designated as a primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA that supports a minimum bandwidth operating mode among all STAs operating in the BSS. In an 802.11ah example, for a STA (e.g., an MTC type device) that supports (e.g., only supports) the 1 MHz mode, the primary channel may be 1 MHz wide, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) setting may depend on the status of the primary channel. For example, if the primary channel is busy because a STA (that only supports a 1 MHz mode of operation) is transmitting to the AP, the entire available frequency band may be considered busy even though a large portion of the frequency band may remain idle and available.

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

[0057] 1D is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As mentioned above, the RAN 113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 utilizing NR radio technology. The RAN 113 may also communicate with the CN 115.

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

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

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

[0061] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, and routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c can communicate with each other over the Xn interface.

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

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

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

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

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

[0067] In view of Figures 1A-1D and the corresponding description thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0069] The emulation device or devices may perform one or more functions, inclusive, without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation device may be utilized in a test lab and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to perform testing of one or more components. The emulation device or devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, for example, one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0070] A network may refer to one or more gNBs, which may be associated with one or more transmission / reception points (TRPs) or other nodes in a radio access network.

[0071] Mobile communications is continually evolving. The fifth generation of this evolution is called 5G.

[0072] The HARQ-related feedback may support code-block-based HARQ operation and / or puncturing of transmissions. One or more of measurement-based probabilistic feedback per transmission, feedback per code block, and / or feedback per TB may be combined. Support for exchange of reports (e.g., reporting type and / or method) on HARQ processes and / or on TBs may be provided (e.g., to optimize the trade-off between granularity and overhead, given a given HARQ operating point).

[0073] A sub-TB feedback configuration can be used (e.g., different sub-TB regions can be configured to use different HARQ feedback types). A feedback request (e.g., for sub-TB resources) can be used, e.g., regardless of whether such sub-TB resources are included in the current retransmission. For example, the feedback request can confirm a previous probabilistic HARQ feedback. The WTRU can select the sub-TB resources to feedback. The sub-TB resources can be retransmitted (e.g., mapping of a subset of sub-TB resources, how to reuse unused resources, and how to control soft-combining).

[0074] 5G systems may, for example, at least in part, support New Radio (NR) access technology.

[0075] The 5G air interface may support ultra-low latency (LLC) transmission, ultra-reliable transmission (URC), and / or machine type communication (MTC) operations, which may include narrowband operations. These communications may be referred to as UR-LLC communications.

[0076] In the example of LLC support, the air interface latency can be, for example, 1 ms round trip time (RTT), and the transmission time interval (TTI) can be, for example, between 100 μs and 250 μs.

[0077] It can provide support for very low access latency (eg, the time from initial system access to the completion of transmission of the first user plane data unit).

[0078] Communications (e.g., IC and / or vehicle-to-everything (V2X)) may have end-to-end (e2e) latency, for example, less than 10 ms.

[0079] In the example of support for URC, transmission reliability may be, for example, approximately 99.999% transmission success and service availability.

[0080] Mobility support can be provided, where the mobility speed can range, for example, from 0 to 500 km / h.

[0081] For communications (e.g. IC and V2X), 10e -6 It can provide support for a packet loss rate (PLR) lower than

[0082] In examples of supporting MTC operation, the air interface may support narrowband operation (e.g., using less than 200 KHz), extended battery life (e.g., up to 15 years of autonomy), and / or minimal communication overhead for low volume and infrequent data transmissions (e.g., low data rates in the range of 1-100 kbps with access latency of a few seconds to a few hours).

[0083] For example, for LTE and / or IEEE 802.11, orthogonal frequency division multiplexing (OFDM) can be used as a signal format for data transmission. Using OFDM, the spectrum can be divided into multiple parallel orthogonal sub-bands. The (e.g., each) sub-carrier can be shaped using a rectangular window in the time domain, which can result in a sinc-shaped sub-carrier in the frequency domain. For example, to maintain orthogonality between signals and to minimize inter-carrier interference, OFDM access (OFDMA) can be implemented with (e.g., perfect) frequency synchronization and (e.g., strict) management of uplink timing alignment within the duration of the cyclic prefix. For example, in a system where a WTRU can connect to multiple access points simultaneously, strict synchronization can be a challenge. For example, additional power reduction can be applied to uplink transmissions to comply with spectral emission requirements in adjacent bands, which can occur when there is aggregation of fragmented spectrum for WTRU transmissions.

[0084] OFDM (e.g., Cyclic Prefix (CP)-OFDM) implementations may impose more stringent RF requirements, such as when operating with a large contiguous spectrum without requiring aggregation. CP-based OFDM transmission schemes can result in a downlink physical layer for 5G similar to previous generations, such as changes in pilot signal density and location.

[0085] 5G NR access may use waveforms different from OFDM for 5G systems.

[0086] A reference signal (RS) may refer to any reference signal, preamble, or system signature that may be received and / or transmitted by a WTRU, for example, for one or more purposes described herein. Different RSs may be defined for downlink (DL) and uplink (UL) transmissions. For example, a reference (e.g., in DL) may correspond to a channel state information reference signal (CSI-RS), a demodulation reference signal (DMRS), a synchronization signal, a beam reference signal (BRS), etc. For example, a reference signal (e.g., in UL) may correspond to a sounding reference signal (SRS), a demodulation reference signal (DMRS), a preamble, or a beam reference signal (BRS), etc.

[0087] 5G systems can support the transmission of data with different requirements, e.g., regarding latency, throughput, and reliability, which can result in different processing principles and transmission characteristics. In an example, data (e.g., associated with ultra-low latency and / or ultra-high reliability use cases) can be transmitted using (e.g., very) short transmission time intervals (TTIs), such as minislots (e.g., using x symbols and / or a first numerology) within a slot-based framing (e.g., with a moderate payload per TTI). Data (e.g., associated with mobile broadband or large-scale MTC use cases) can be transmitted using longer TTIs (e.g., to reduce control channel overhead), for example, by using slot-based transmission (e.g., using y symbols, where y>x, and / or using a second numerology).

[0088] Data (e.g., associated with ultra-low latency or ultra-high reliability use cases) can be transmitted with very little delay from the time it was generated by the application layer. Delaying transmission of data until an ongoing transmission using a larger TTI is finished may not be acceptable. For example, given that delay-sensitive traffic may be sporadic, reserving resources for exclusive use may be inefficient. Next generation (e.g., 5G) wireless systems may support transmission of delay-sensitive data on resources used for ongoing transmissions while maintaining robust performance for both transmissions.

[0089] A code block-based hybrid automatic repeat request (HARQ) process may be supported. Data (e.g., MAC PDUs) included within a transmission (e.g., transmitted as a transport block (TB)) may be (e.g., further) encoded using block-based coding. A TB may include one or more code blocks (CBs) associated with one or more MAC PDUs. Block-based encoding may help, for example, to isolate and / or confine transmission errors and / or puncturing events to a particular portion of a transmission, for example, to increase decoding efficiency and minimize retransmissions. Block-based coding may include mapping code blocks to code block groups. The mapping may be in frequency, time, and / or a combination of frequency and time. The mapping may be indicated in control information. For example, the wireless communication network may have a processor configured to determine the mapping and may transmit the mapping to the WTRU in downlink control information. The WTRU may have a processor configured to monitor for DCI, receive downlink transmissions having the DCI, the code blocks, and attempt to decode the code blocks using the mapping received in the DCI.

[0090] The HARQ feedback may be generated by the HARQ process, for example, based on the outcome of the reception of a transmission for (e.g., one) TB. For example, the WTRU may have a processor configured for HARQ feedback and may determine the HARQ feedback based on attempting to decode the code blocks of the code block group using the mapping received on the DCI. The WTRU processor may be configured to send a NACK to the wireless communication network if the decoding is unsuccessful and an ACK if the encoding is successful. The wireless communication network may have a processor configured to resend the mapping of code blocks to code block groups if the processor determines that a NACK was received from the WTRU. In an example (e.g., when block-based coding is used), the HARQ feedback may be generated with higher granularity (e.g., per CB) at the expense of higher overhead (e.g., increased number of feedback bits) for the transmission of such feedback.

[0091] The generation and transmission of HARQ-related feedback may be improved, which may be useful, for example, when block-based encoding is used and / or when puncturing events may occur in the system.

[0092] The feedback procedure is applicable to many use cases, technologies and scenarios.

[0093] In an example, a first transmission can be initiated. The first transmission can be performed using at least a portion of the physical layer resources. The one or more resources can correspond to at least a portion of the physical layer resources associated with the second transmission.

[0094] The first transmission can be, for example, a "puncturing" transmission, an "interfering" transmission, a "delay-sensitive" transmission, or a "minislot" transmission. The second transmission can be, for example, an "on-going" transmission, a "best effort" transmission, or a "slot-based" transmission.

[0095] The first and second transmissions may be transmitted by the same entity or different entities. The first and second transmissions may be received by (or destined for) the same entity or different entities. The first and second transmissions may be downlink or uplink transmissions that may be part of an infrastructure-based (e.g., cellular system) transmission. The first and second transmissions may be direct WTRU-to-WTRU transmissions (e.g., sidelink type transmissions).

[0096] The (eg, each) entity may be, for example, part of a WTRU or a network infrastructure node.

[0097] The feedback procedures may be associated with particular aspects, procedures, and / or components of wireless access.

[0098] The WTRU may, for example, request information regarding one or more of the following: (i) a numerology, spectrum operating mode (SOM) associated with the transmission, and / or its configuration (e.g., a set of resources, carrier, subcarrier spacing, symbol duration, priority associated with a particular data, TTI duration, or framing (e.g., slot-based, minislot-based), etc.); (ii) physical layer resources associated with the transmission; (iii) a control channel and / or one or more associated characteristics (e.g., RNTI, location with respect to the search space, or CCE, etc.) associated with the transmission and / or the physical layer resources; (iv) an explicit request for a particular methodology to be applied (e.g., The feedback procedure may be applied (e.g., may have a processor configured with executable instructions for the feedback procedure) as a function of one or more of: (a) received downlink control information, such as a first reporting method, a second reporting method, or a third reporting method; (b) a reference signal and / or a demodulation signal associated with the transmission; (c) a configuration received by a higher layer (e.g., a configured feedback and / or transmission mode); (d) a configuration associated with one or more HARQ processes (e.g., comprising a set of processes), which may include an applicable soft combining procedure (e.g., incremental redundancy or chase combining).

[0099] A (e.g., NR) system may support soft combining for HARQ processes, which may include multiple procedures, such as incremental redundancy or chase combining. In an example (e.g., for a given HARQ process using incremental redundancy (IR)), a HARQ retransmission may be performed for a given TB using a different number of bits (TBS) compared to a previous transmission for the same TB. For example, assuming a scheme in which soft combining operates with IR, a different number of bits may be used. This may be true for turbo coding (e.g., as may be used for LTE) or (variable size) LDPC (e.g., as may be used for NR). WTRU buffering and processing may be higher order for coding (UL) and soft combining (DL). HARQ retransmissions with IR may have different values ​​and / or one or more combinations of TTI duration, PRB allocation, MCS, etc., which may result in the same or different TBS. In an example (e.g., for a given HARQ process using Chase combining), the HARQ process and (e.g., any) HARQ transmission associated with the same TB may use the same number of bits (TBS). The scheduler may determine whether IR or Chase combining may be used, and may determine the TTI (or whether the transmission is a slotted or minislot transmission) for a given HARQ process for a given TB. The WTRU may receive signaling to this effect and may make an appropriate decision for the (e.g., each) transmission. The WTRU may process the HARQ processing timeline (e.g., as appropriate) with respect to grants for UL transmissions and with respect to the HARQ feedback timeline.

[0100] An exemplary procedure can be provided for generating receiver feedback information.

[0101] Different types of feedback can be generated at different times.

[0102] In an example, a WTRU may be configured to generate and / or transmit uplink control information as a function of the WTRU's configuration (e.g., for a downlink transmission). The configuration may include a processor that is programmed with HARQ-related parameters, such as a type of soft-combining process to be applied, an HARQ operating point for a given HARQ process, feedback suppression parameters, such as one or more reference transmissions (e.g., to control a type of HARQ-related feedback of a transmission for a HARQ process), and / or one or more specific transmissions in a sequence associated with a given HARQ process or transport block (TB).

[0103] In (e.g., alternative) examples, the HARQ-related parameters may be expressed in time (e.g., in TTIs), with respect to scheduling opportunities for the HARQ process, etc. HARQ-related feedback may refer to, for example, feedback corresponding to a particular transmission associated with an HARQ process.

[0104] The target operating point may be, for example, the target number of transmissions for a given HARQ process x target The WTRU may be configured (e.g., the processor is programmed with the configuration) to report a particular HARQ-related feedback, e.g., starting with a transmission corresponding to the configured value. This type of feedback may correspond to, e.g., DM-based feedback, CSI-based feedback, CB-based feedback, or TB-based feedback.

[0105] The feedback type control parameter may be provided (e.g., by a wireless communication network to a WTRU). The one or more reference transmissions for a given HARQ process may be transmission X in a sequence. i_type The WTRU may respond to downlink transmission X for the associated HARQ process. i_type The WTRU may be configured (e.g., a processor is programmed with the configuration) to enable and / or change the type of HARQ-related feedback generated for (or originating from). The WTRU may be configured (e.g., a processor is programmed with the configuration) to control switching the type of feedback transmitted by the WTRU from one type to another. Such a type of feedback may correspond to, for example, DM-based feedback, CSI-based feedback, CB-based feedback, or TB-based feedback.

[0106] The feedback suppression parameter may be, for example, one or more values ​​X thresholdA value (e.g., 1, 2, or 3) may indicate that the WTRU (e.g., for a downlink transmission) may refrain from generating HARQ-related feedback and / or refrain from reporting on the initial transmission (e.g., refraining for up to the first transmission), the first retransmission, or the second retransmission, respectively. A value of infinity may indicate that the WTRU may transmit HARQ-related feedback when (e.g., only if) it receives (e.g., explicit) control signaling requesting such feedback. The suppression parameters may be associated with (e.g., all) types of feedback that may be applicable to and / or configured for the concerned HARQ process or may be applicable to a particular type thereof. The type of feedback may correspond, for example, to DM-based feedback, CSI-based feedback, CB-based feedback, or TB-based feedback. The WTRU has a processor programmed to receive feedback suppression parameters from the wireless communication network, read the feedback suppression parameters, and determine to operate according to the received feedback suppression parameters. The wireless communication network can have one or more processors programmed to determine a feedback suppression parameter and transmit the parameter to the WTRU.

[0107] The configuration can have different granularity. The configuration can be different for uplink and downlink HARQ processes. The HARQ process can be specific to a given TrCH. The HARQ process can support transmissions according to different transmission durations (e.g., different numerologies), which may be commonly referred to as TTIs. The configuration can be in addition to other (e.g., legacy) parameters (e.g., maximum number of HARQ transmissions).

[0108] The WTRU may be configured (e.g., a processor is programmed with the configuration) to generate and / or transmit uplink control information as a function of the HARQ process state (e.g., for a downlink transmission). The state may correspond to an aspect, such as a sequence of transmissions for an HARQ process. The state may correspond (e.g., may also correspond to) a timing aspect, such as a maximum number of times an HARQ process succeeds. The state may correspond, for example, to a measured or estimated link quality, demodulation performance, or the number of times a code block is successfully decoded.

[0109] The WTRU may be configured (e.g., the processor is programmed with the configuration) to use the feedback methods described herein for a subset of resources (e.g., and / or all resources) in a TB. For example, the WTRU may be configured to use a set of throttling parameters. For example, one or more (e.g., each) individual throttling parameters may be defined per sub-TB resource (e.g., per code block or set of code blocks) and / or to use different types of feedback for different sub-TB resources (e.g., for the same downlink transmission (retransmission)). For example, a first set of sub-TB resources may be configured to use DM-based feedback and another set of sub-TB resources may be configured to use CB-based feedback. The WTRU may be configured (e.g., explicitly) to report feedback for a particular subset of sub-TB resources (e.g., the processor is programmed with the configuration). The WTRU report may correspond to feedback (e.g., DM-based feedback, CSI-based feedback, and / or CB-based feedback, as described further below).

[0110] The WTRU may anticipate receipt of HARQ-related feedback, e.g., using logic similar to when feedback is expected (e.g., for an uplink transmission). For example, the WTRU may determine (e.g., a processor may determine) the format, content, and / or type of feedback as a function of logic similar to the logic used to generate feedback for a downlink transmission.

[0111] The configuration may be received by the WTRU processor in downlink control signaling, which may enable dynamic control of HARQ processing related to the feedback.

[0112] The feedback may be based on demodulation (DM) performance. For example, the WTRU processor may generate HARQ-related feedback based on a metric related to the demodulation performance.

[0113] The WTRU may be configured (eg, the processor is programmed with the configuration) to generate HARQ-related feedback for physical transmission resources.

[0114] The set of physical resources associated with a transmission can be subdivided, for example, with respect to a resource region. A resource region can correspond to a subset of resources in time, frequency, and / or space of the resources allocated to the transmission. For example, a resource region can correspond to a subset of one or more PRBs on a particular symbol (or one or more portions thereof). For example, a resource region can correspond to a symbol (or a portion thereof). A region can be (e.g., further) associated with one or more demodulation reference signals (DM-RS).

[0115] Different portions of a transmission (e.g., one or more code blocks or transport blocks) may be mapped to resource regions. (Eg, each) portion may correspond to a particular region.

[0116] The WTRU may determine, using a processor, that a downlink transmission is scheduled using a particular resource allocation. The WTRU may perform, using a processor, one or more actions upon receipt of the transmission.

[0117] For example, the WTRU processor (e.g., upon reception) may determine areas where the transmission was able to exceed some reception quality and may report that as positive feedback or as a measurement. The WTRU processor may determine which areas were not and may report that as negative feedback or as a measurement. This may be based, for example, on SINR measurements, decoding of individual CBs, or other metrics. The WTRU processor may make the decision based, for example, on relative DM-RS, signal strength, estimates based on individual (e.g., failed or successful) code blocks of how close the WTRU was to successfully decoding some of the transmission, etc.

[0118] For example, the WTRU processor may determine (e.g., upon receipt) that it failed to decode one or more (e.g., all) code blocks that may be mapped onto the resource region and may report that as negative feedback. The WTRU processor may determine that it succeeded in decoding one or more (e.g., all) code blocks that are mapped onto the resource region and may report that as positive feedback.

[0119] For example, the WTRU processor (e.g., upon reception) may determine an area where the transmission exceeded a certain reception quality. The area may correspond to a symbol. The symbol may be reported as bad or good quality, which may be calculated as a function of the SINR. The bad quality may be reported, for example, as negative feedback or as a measurement. The good quality may be reported, for example, as positive feedback or as a measurement.

[0120] The WTRU processor may report (e.g., to a wireless communication network) corresponding feedback for one or more regions. The WTRU processor may report measurements for one or more regions (e.g., regions with insufficient quality, or all regions). The WTRU processor may report (e.g., to a wireless communication network) ACK / NACK bits per region, etc. The reports may be prepared by one or more procedures, for example, as described herein.

[0121] In an example, the WTRU processor may determine that (e.g., more) than x regions are of insufficient quality. The WTRU processor may report feedback (e.g., to a wireless communication network) as a single report for all regions. The WTRU may use a different reporting procedure (e.g., a TB-based procedure, or channel condition indicator values). The WTRU processor may (e.g., alternatively) report (e.g., to a wireless communication network) with greater granularity. The network scheduler may determine a resource allocation with a higher probability of successful decoding (e.g., based on the increased granularity).

[0122] For example, assuming demodulation-based measurements can be generated earlier than code-block-based or TB-based feedback, reporting can be useful for ultra-low latency services. SINR measurements can (e.g., further) provide probabilistic information back to the transmitter (e.g., scheduler). The transmitter can perform more efficient retransmissions, for example, when operating below the intended operating point (e.g., earlier in the transport block transmission cycle).

[0123] The demodulation performance-based feedback report may provide an indication of the WTRU's confidence in decoding a TB or a portion of a TB (e.g., a sub-TB resource) to the scheduler. The confidence (or likelihood or probability) for the decoding (e.g., correct decoding) may be fed back as a quantized value. For example, the WTRU processor may report the demodulation performance-based feedback using x bits. Each code point may correspond to a predefined confidence level.

[0124] Despite the high confidence of correct decoding, the WTRU may not be able to decode the TB and / or sub-TB resources associated with the reported feedback. For example, the scheduler may not include the TB and / or sub-TB resources in future retransmissions after receiving an indication of high decoding likelihood. The WTRU processor may decide to maintain the feedback state (e.g., which may now be an absolute NACK) and / or any stored soft data received. The WTRU may be indicated by the network to feedback HARQ values ​​for the TB and / or sub-TB resources even though it has not received any other transmissions (retransmissions) since the previous feedback report. For example, the WTRU processor may receive a first transmission and provide decoding confidence feedback for two sub-regions of the TB. The WTRU processor may determine that the first region has a high likelihood of correct decoding and the second region has a low likelihood of correct decoding. An indication that one region has a higher likelihood of being correctly decoded and a second region has a lower likelihood of being correctly decoded may trigger the scheduler to retransmit the data of the second region in a first retransmission, which may not be included in the first retransmission. The WTRU processor may then determine that the WTRU is unable to correctly decode the first region. The WTRU may be indicated by the wireless communication network to feed back a HARQ report (e.g., an absolute ACK / NACK type report) for the first region after the first retransmission, even though the first region itself may not be included in the first retransmission.

[0125] The demodulation performance based feedback may be determined from measurements obtained from a demodulation reference signal (DMRS), a channel state information reference signal (CSI-RS), other RSs, and / or from measurements obtained from actual data transmissions. The WTRU processor may be configured to use an association between reference measurement (or data measurement) resources and / or HARQ feedback.

[0126] The feedback may be based on code block (CB) decoding. For example, the WTRU processor may be configured to generate HARQ-related feedback for (e.g., each) code block (or a group thereof).

[0127] The WTRU processor may determine that feedback for one or more code blocks (or resource regions) may not be generated, for example, based on signaling and / or a determination that the corresponding resources may experience interference (e.g., puncturing). This may be useful, for example, when a transmitter (e.g., scheduler) may be aware of (e.g., is aware of) a preemption, for example, due to a first transmission of some resources assigned to a second resource. In (e.g., another) example, a transmitter aware of the event may determine that feedback on the preempted CB may be ignored (e.g., applicable for puncturing) or enhanced (e.g., applicable for superposition). For example, the decision may be made by the WTRU processor as a function of whether a CRC may be included for (e.g., each) code block. This may (e.g., implicitly) indicate the change to the receiver, for example, by dropping or masking the CRC for each CB when the transmitter inserts a CRC at the beginning of (e.g., each) CB.

[0128] The WTRU processor may (e.g., in such a case) perform one or more of the following: (i) ignore feedback on the punctured CB and provide single bit feedback for all remaining CBs, and (ii) provide enhanced feedback per CB (or group of CBs) for the indicated CB and provide single bit feedback for all remaining CBs (superposition).

[0129] The enhanced feedback can provide ACK / NACK indications that can be generated for a single CB or for a CB group (CBG). The grouping of CBs can be configured or indicated by control signaling. For example, the grouping can be based on mapping of CBs to different TBs within the same transmission, for example, when TB multiplexing or multiplexing of CBs from different TBs can be supported. The switch between enhanced feedback and single-bit feedback can be configured per number of HARQ transmissions (retransmissions) for a particular HARQ process. The enhanced / multi-bit feedback can determine the NACKed CBs, for example, based on an explicit index (e.g., CBG index and meanwhile, CBG index and offset, or index of each CBG) and / or implicitly (e.g., based on feedback of PRB, slot, minislot, or symbol index). There can be one A / N bit bitmap per CBG. For example, the bundle size can be indicated by a prefix (e.g., a 2-bit prefix is ​​mapped to four possible bundle sizes).

[0130] The feedback may be based on transport block (TB) decoding. The WTRU processor may be configured to generate HARQ-related feedback for (eg, each) TB.

[0131] The WTRU processor may be configured to generate HARQ-related feedback, e.g., by combining two or more of the above examples (and / or other examples), e.g., according to HARQ process states and / or DCI requests. For example, the WTRU processor may generate different types of feedback, i.e., (i) feedback for different HARQ entities (e.g., by configuration), (ii) feedback for different HARQ processes (e.g., by applicable framing (e.g., slot or minislot) by dynamic control signaling), (iii) feedback for different uplink control channels (e.g., whether the feedback can be on a common shared uplink control channel or on a dedicated transmission (with or without other data)), (iv) feedback for different transmissions in a sequence of transmissions (retransmissions) for a given HARQ process, and / or (v) feedback as a function of an applicable soft-combining procedure for the HARQ processes.

[0132] Procedures may be provided for transmission of receiver feedback. The WTRU processor may be configured to report HARQ-related feedback in one of a number of payload placements. Feedback reporting procedures may be applied that are related to any of the feedback types described herein, e.g., link quality (DM-based feedback) and / or feedback related to resource regions or code blocks (CB-based feedback).

[0133] Additional information bits can be introduced, for example, using channel selection. y Selecting one out of a set of possible uplink resources can provide y additional bits of feedback information, which in an example can be used to indicate the type of reporting that is applicable.

[0134] Pattern-based signaling (e.g., compression procedures) may be supported, which may be based on, for example, CB, RE, and / or PRB mapping. The WTRU processor may be configured to use one or more sets of elements. The elements may be resources (e.g., forming one or more resource regions) and / or code blocks (e.g., forming one or more subsets, such as one per TB, when TB multiplexing may be supported for a given transmission). Resource regions and sets of code blocks may or may not be mapped to each other.

[0135] The WTRU processor may (e.g., further) be configured to use one or more patterns. A pattern may correspond to a group of one or more sets of elements. An element may be represented by one or more patterns. A pattern (e.g., each) may be associated with a code point or an identity.

[0136] For example, the WTRU processor may be configured to use patterns. In an example, pattern 00 may represent elements 1, 3, 5, 7 of a transmission (e.g., an element may be an indexed CB of a transmission, or an indexed resource area of ​​a resource allocation for a transmission). Pattern 10 may represent elements 0, 2, 4, 6 of a transmission. Pattern 01 may represent elements 0 through 3 of a transmission, inclusive. Pattern 11 may represent elements 4 through 7 of a transmission, inclusive.

[0137] For example, when a variable number of bits can be reported, Huffman-based coding can (e.g., can also) be used. A one-bit root indicator can indicate reporting on all elements of a report type (e.g., the entire TB in the case of a single TB per transmission). For example, a variable number of feedback bits can be supported when multiple formats can be defined for a given uplink control channel and / or when channel selection can be configured for transmission of uplink feedback.

[0138] The size, content, and number of patterns can (e.g., further) be a function of dynamic scheduling information (e.g., DCI). For example, the number of possible reporting patterns can be a function of resource allocation size, or number of code blocks, etc. The decision can be based on a pre-determined function.

[0139] The WTRU processor can generate HARQ-related feedback. The (e.g., each) pattern can indicate what is being reported or can (e.g., even implicitly) indicate positive or negative acknowledgment for the associated elements of the report. In an example, the WTRU processor can determine a pattern to report in the feedback, for example, by selecting a pattern that can minimize the number of unnecessary retransmissions (e.g., a pattern that can include all negatively acknowledged elements and the fewest possible acknowledging elements).

[0140] This can be efficient, for example, when a network configured report of a WTRU having a pattern can be based on a resource allocation strategy for puncturing events that can be consistent with such pattern. For example, the consistent pattern can include at least one pattern that corresponds to (e.g., only) resources that can be used (e.g., used) for puncturing, while the scheduler can schedule the puncturing event using (e.g., when necessary) those resources. High rate channel state information may be provided (eg, may also be provided).

[0141] In (e.g., another) example, the WTRU may receive downlink control signaling that may, for example, request feedback based on an indicated pattern (e.g., for elements of the pattern concerned).

[0142] In a (e.g., another) example, the WTRU may receive downlink control signaling that may request a retransmission including elements (e.g., only) of the indicated pattern, such as code blocks (e.g., only) of the relevant pattern for the applicable TB. The WTRU processor may determine to include the elements when, for example, the transport block size indicated in the control signaling allows it (e.g., when multiplexing of CBs associated with different TBs is supported). The same HARQ process may be used. The CBs may (e.g., alternatively) belong to different HARQ processes, which may be indicated in the received control signaling.

[0143] In (e.g., another) example, the CB for a retransmission can be derived (e.g., implicitly) based on the receiver indicating one or more of, for example, (i) frequency domain parameters (e.g., PRB index, group of PRBs per one or more enhanced FB procedures) and / or (ii) time domain parameters (e.g., slot, minislot, symbol index). For example, a minislot indication can be used to inform the transmitter to retransmit all CBs that are mapped to scheduled resources used on the minislot.

[0144] The receiver may determine the index based on, for example, demodulation performance, RS measurements, and / or (eg, explicit) decoding of the CRC per CB.

[0145] The WTRU processor may be configured to feed back HARQ reports for a pattern (e.g., an entire TB, a sub-TB, a group of CBs, a single CB, etc.), and the reports and / or patterns may be independent of their presence in the associated transmission (retransmission). The WTRU processor may be configured to feed back HARQ reports for the CBs (e.g., all CBs) of the original TB after the xth retransmission (e.g., when only a subset of CBs were included in the xth retransmission).

[0146] The signaling may be based on reception conditions (e.g., suppression procedures). For example, at least N blocks may be decoded to allow combining.

[0147] For example, the WTRU processor can be configured or instructed to report that "at least N code blocks have been decoded." This can be useful, for example, to determine whether a code block that is known to be unpunctured can (e.g., should or must) be retransmitted due to a puncturing event. The scheduler may already know that a punctured code block should be retransmitted. N can be a function of the total number of code blocks C (e.g., C-1).

[0148] For example, a combination of procedures may be provided based on HARQ process state and / or DCI requests.

[0149] The WTRU processor may indicate a resource associated with the feedback report.

[0150] The WTRU processor may be told to provide feedback for a group of sub-TB resources (e.g., a pattern, a group of CBs, etc.). The WTRU processor may determine a set of sub-TB resources for which to provide feedback resources (e.g., those for which the WTRU needs to provide feedback resources). For example, the WTRU processor may have provided confidence-based feedback in the past on some sub-TB resources, and such feedback may or may not still be valid. The WTRU processor may determine whether to update the feedback report (e.g., depending on the feedback validity). The WTRU processor may include a resource identifier in the feedback report to indicate to the scheduler the purpose of the feedback report (e.g., each feedback report). For example, the WTRU may have sent a confidence-based report for a CB (e.g., each CB) after transmission. The report may indicate a likelihood (e.g., a strong likelihood) for correct decoding. The WTRU may be told to report feedback for some or all of the CBs for which it previously provided confidence-based reports. If the WTRU processor succeeds in decoding a CB that the WTRU previously indicated it was able to successfully decode, the WTRU may decide not to provide updated feedback. If the WTRU processor is unable to decode a CB that the WTRU previously indicated it was able to successfully decode, the WTRU processor may provide a CB identifier and a NACK value. The WTRU may be told to provide feedback for all correctly decoded sub-TB resources (e.g., regardless of whether the WTRU has already indicated an ACK). The absence of an identifier for a sub-TB resource may be used as an indication of a NACK for that sub-TB resource.The WTRU may be signaled to provide feedback for sub-TB resources whose HARQ ACK / NACK status has changed since the previous feedback report.

[0151] The WTRU processor may be configured to report, e.g., according to a first reporting procedure for one transmission and according to one or more other reporting procedures for other transmissions, which may be for the same HARQ process and / or for the same TB, which may be indicated, e.g., in downlink control information and / or dynamically based on the WTRU configuration.

[0152] For example, the WTRU processor may be configured to report DM-based HARQ-related feedback for one or more initial transmissions of a HARQ process. This may be useful, for example, to provide additional channel state information. The WTRU processor may (e.g., further) be configured to report CB-based feedback, for example, when it determines that less than a threshold x of CBs were successfully decoded. The WTRU processor may be configured to report (e.g., a single) HARQ ACK / NACK bit, for example, starting from another threshold (e.g., above a configured operating point).

[0153] The WTRU processor may (eg, as an alternative) determine that it may transmit a (eg, single) bit for TB-based reporting when, for example, a HARQ ACK may be applicable.

[0154] FIG. 2 is an example of a transmission 200 that is punctured 201 due to URLLC transmission and different HARQ feedback types are expected in each retransmission. Different CBs 202, 204, 206, 208, 210, 212 are shown in FIG. 2. During the first transmission 200, the second CB 204 and the third CB 206 are punctured to allow for the transmission of URLLC (e.g., to another WTRU). The WTRU processor can be configured to report per-region feedback. The feedback can be credit-based (e.g., DM-based) and / or absolute ACK / NACK-based feedback. For example, the WTRU processor can feed back a NACK for the first region and an ACK for the second region. In the first retransmission 214, the WTRU processor receives the CBs (e.g., only the CBs) for which it feeds back a NACK. The WTRU processor can be configured to perform per-CB based feedback. The second CB 204 and the third CB 206 may not have a combined gain (e.g., because they were punctured in the first transmission), and therefore decoding may fail. In the third retransmission 218, the second CB and the third CB (e.g., only the second CB and the third CB) are transmitted. The WTRU processor may be configured to provide HARQ feedback per TB (e.g., because feedback per CB may use more resources and the gain associated with granular feedback may be limited given the number (e.g., small number) of CBs left to be retransmitted). The WTRU may have a second retransmission 216. After the third retransmission 218, the WTRU processor may provide feedback ACK for the TB (e.g., the entire TB), which may terminate the process. In this example, the first feedback may utilize a credit-based feedback.The decoding confidence of the second region may be considered high, but its decoding may fail, and TB-based feedback for the second retransmission (216) may be configured for the entire TB or for sub-TB regions where there are still active retransmissions (e.g., not for regions where there are no active retransmissions). The WTRU processor may be configured to provide a feedback report on a previous confidence-based report of a different sub-TB region (e.g., when only the sub-TB region still has active retransmissions).

[0155] The WTRU processor can be configured to report feedback for a set of DL transmissions. The set of DL transmissions can include transport blocks transmitted on any combination of multiple component carriers (CCs), multiple bandwidth portions (BWPs), multiple slots, multiple spatial layers, and / or multiple codewords. A WTRU (e.g., configured with multiple CCs) can have many variable amounts of feedback to report at any one time. Using a dynamic feedback codebook can reduce the overhead of semi-static configuration. If the transmission uses CBG segmentation and CBG feedback is utilized, the amount of feedback can be very large.

[0156] When determining the feedback, the WTRU processor may determine whether the order in which Ack / Nack (A / N) values ​​are assigned in the feedback payload matches that expected by the network. The DCI scheduling data may provide information to the WTRU on the order of feedback bits in the feedback report. The DCI may include a feedback bit counter DAI (e.g., instead of or in addition to a counter downlink allocation index (DAI), which may enable the WTRU to determine the order of DL assignments among the total number of DL assignments that the WTRU may receive). The DAI may indicate to the WTRU one or more of: (i) the number of bits required to provide feedback on DL assignments, (ii) the bit placement in the feedback report in which the HARQ A / N bits for the DL assignments should be placed, and / or (iii) the total number of feedback bits included in the feedback report.

[0157] The number of bits needed to provide feedback on the DL allocation may be indicated. For example, the feedback may be for CBG-based feedback and the WTRU processor may be configured to use one or more feedback bits per CBG. The number of bits may be fixed across retransmissions of the TB (e.g., regardless of how many CBGs are present in a particular retransmission), may be dependent on the number of CBGs present in the retransmission, and / or may indicate the number of feedback bits used per CBG feedback report.

[0158] The bit placement within the feedback report where the HARQ A / N bits for the DL allocation should be placed may be indicated, e.g., the network entity may convey the bit placement information to the WTRU. For example, a first DL allocation may indicate to the WTRU that the placement of the feedback report may start at bit "0". A second DL allocation may indicate to the WTRU that its placement of the feedback report may start at bit "5". Such an indication may enable the WTRU to know how many bits it needs to NACK if it misses the first DL allocation DCI.

[0159] The total number of feedback bits (e.g., the size of the feedback payload) included in the feedback report may be indicated. The WTRU processor may determine the size of the feedback for the missed allocations and may adjust its payload to match the expected order in the network.

[0160] An example of a feedback bit counter is a WTRU receiving a first allocation with a feedback bit counter = 0 and information in the grant that the feedback report can be 4 bits. The WTRU can anticipate whether it will receive a second DL allocation that should have a feedback bit counter = 4. If the WTRU instead receives a DL allocation with a feedback bit counter greater than 4 (e.g., of x), the WTRU processor can determine that it has missed the allocation and that the WTRU needs x-4 bit feedback that is a NACK to maintain a proper feedback report size.

[0161] The feedback bit DAI may be indicated (eg, explicitly) and may be an index into a table of values ​​that may be semi-statically provided to the WTRU.

[0162] A feedback bit DAI may be used in addition to or instead of the counter DAI in the DL allocation DCI.

[0163] The WTRU processor can determine from the counter DAI that it has missed one or more allocations. The WTRU processor can send to the wireless communication network a set of bits indicating a NACK for the maximum feedback size (or a configurable default size) that may be needed for the missed allocation or allocations. This may result in a mismatch with the expected feedback size in the network. The WTRU processor can indicate to the network that it has missed one or more DL allocations and had to use padding. The WTRU can indicate the padding by use of a bit flag. For example, the WTRU can send a single bit indicating whether the feedback size of the allocation is obtained from the DCI (explicitly or implicitly) or whether the feedback size is a default value due to not receiving a DL allocation.

[0164] The WTRU may miss the last DL allocation (or the last set of allocations). The starting position of the next set of feedback bits may not exist. The WTRU processor may not know the number of bits to NACK. The WTRU processor may use a maximum feedback size (or a configurable size). The WTRU processor may indicate the use of padding to the network (e.g., using a flag). The WTRU processor may use multiple bits to indicate the amount of padding.

[0165] The WTRU processor may use the DAI counter when scheduled with data using a mix of slots and minislots. The WTRU processor may be scheduled with data transmissions on regular slots, minislots (e.g., of variable size), and aggregated slots. The transmission duration may be semi-statically configured per component carrier (or per BWP of a component carrier). The transmission duration may vary dynamically (e.g., for transmissions on one component carrier or within one BWP of a component carrier).

[0166] The counter DAI or feedback bit DAI can be incremented in any order of the BWP, CC, time, and / or codeword. For example, the counter DAI or feedback bit DAI can be incremented first in the BWP, second in the CC, and third in time. The BWPs and CCs can be ordered by use of an index. The DAI can be incremented on the allocation in the BWP of the first CC, then on the allocation in the BWP of the second CC, and so on, moving to the next slot and repeating in the BWP / CC.

[0167] For cases where different BWPs and / or CCs use different slot lengths or numerologies, the increments can follow the same rules. For some time instances, several BWPs and / or CCs can have scheduling opportunities. DAI increments can be made on the BWP of a CC and on the time scheduling opportunities (e.g., slots, minislots, symbols) of a subframe. DAI increments can be made on the BWP of a second CC and on the time scheduling opportunities (e.g., slots, minislots, symbols) of a subframe, etc.

[0168] Bundling of HARQ feedback can be used to reduce or fix the size of the feedback for one or more DL allocations. Bundling can be combining (e.g., adding) feedback bits together to reduce the total amount of feedback bits. Examples of bundling can include one or more of the following: (i) CBG feedback bits can be bundled together (e.g., feedback bits of a set of CBGs in one or more TBs can be combined together), (ii) feedback bits for multiple BWPs of a CC can be bundled together, (iii) feedback bits for multiple CCs can be bundled together (e.g., DL allocations scheduled in the same slot of different CCs can have bundled feedback), (iv) feedback bits for multiple slots or minislots can be bundled together (e.g., feedback bits of allocations in slots / minislots in a subframe can be bundled together), (v) feedback bits for multiple spatial layers can be bundled together (e.g., feedback bits of assignments in slots / minislots in a subframe can be bundled together), (vi) feedback bits for multiple spatial layers can be bundled together (e.g., feedback bits of assignments in slots / minislots in a subframe can be bundled together), (vii ... feedback bits for multiple DL allocations on the same beam may be bundled together (e.g., spatial bundling) (e.g., the spatial layers may use CBG-based feedback, e.g., with a fixed number of CBGs per layer, and spatial bundling is achieved by bundling feedback of a first CBG of a first layer with feedback of a first CBG of a second layer or later, and bundling feedback of a second CBG of a first layer with feedback of a second CBG of a second layer or later, which may continue across CBGs of TBs in the same slot / minislot); (vi) feedback bits for multiple DL allocations on the same beam may be bundled together; and / or (vii) feedback bits for DL ​​allocations of the same service (e.g., eMBB, URLLC, mMTC) may be bundled together.

[0169] Bundling rules can be configured (e.g., to ensure that feedback bit strings for DL ​​assignments can be kept at default and / or configurable values). Maintaining fixed values ​​for feedback of DL assignments can ensure that there is no ambiguity between what the WTRU intended to send and what the network thinks it received as a feedback report, even if some DL assignments are missed. The fixed feedback value per DL assignment may be smaller than the maximum value, in which case bundling can be used. The WTRU processor can be configured to use bundling methods as described herein to achieve an appropriate feedback value. The feedback bits required for some DL assignments may be smaller than the fixed value. The WTRU can use feedback repetition or can use padding to achieve the fixed feedback bit string value.

[0170] The fixed feedback string value per DL allocation may depend on one or more of: (i) the PUCCH resource used to transmit the feedback (e.g., the PUCCH format, e.g., feedback using a short PUCCH may use a first value and feedback using a long PUCCH may use a second value); (ii) a parameter of the data to be transmitted (e.g., the URLLC data may have a first feedback bit string value, the eMBB may have a second value, and / or the configured numerology for the CC or BWP may determine the feedback bit string value); (iii) the number of configured and / or activated CCs or BWPs, and / or BWPs per CC); and / or (iv) the number of slots, minislots, or subframes for which feedback is reported within a single report.

[0171] The feedback may have unequal reliability. The WTRU processor may report feedback for two types of services to the wireless communication network in one feedback reporting instance. For example, the WTRU may be configured to use URLLC data on a first CC and eMBB data on a second CC. The WTRU processor may use a single UL channel for the feedback report. The required reliability of the components of the feedback report may vary. The WTRU processor may transmit the feedback report in a manner that can achieve the most stringent reliability needs of the multiple services. For example, the power settings, multiplexing, and / or parameters of the PUCCH resources (e.g., diversity function) may be selected to ensure that the overall feedback report achieves the requirements of the most sensitive feedback.

[0172] Unequal error protection for the feedback reports can be used. For example, feedback bits of a feedback report can be separated into groups of similar reliability requirements. Feedback bits can be mapped to a specific set of resources of the feedback report, and the set of resources can achieve different reliability (e.g., depending on the reliability requirements of the feedback group). For example, a PUCCH can occupy multiple OFDM symbols, and some symbols can be transmitted with more power than others. Feedback bits that require more reliability can be mapped to resources in symbols with more transmission power. Feedback that requires more reliability can be repeated across multiple resources in the PUCCH resources (e.g., in multiple hops of the PUCCH resources). Feedback that requires less reliability may not be repeated across multiple resources in the PUCCH resources.

[0173] Feedback resource selection may be used. There may be a collision of feedback reports for different DL allocations with different requirements. Feedback for URLLC may use a first set of PUCCH parameters, and feedback for eMBB may use a second set of PUCCH parameters. Multiple feedback reports may be multiplexed into a single feedback report. The WTRU may be configured to use a rule to determine an appropriate PUCCH resource to use to provide the multiplexed feedback report. For example, the WTRU may use a PUCCH resource tied to any of the DL allocations multiplexed in the feedback report, and / or the WTRU may use different PUCCH resources to transmit the multiplexed feedback report.

[0174] All or a subset of the feedback reports may be multiplexed into a single feedback report. For example, a subset of the feedback reports may be multiplexed in situations where there may be too many resources utilized to reliably transmit URLLC traffic feedback reports and not enough resources available to allow multiplexing of eMBB traffic feedback reports. The WTRU processor may be configured to use priority rules to determine which feedback may be included in the feedback report.

[0175] The WTRU processor may use the PUCCH resources indicated in the DL assignment (e.g., the last received DL assignment). For example, if the WTRU multiplexes in time feedback reports for multiple DL assignments, the WTRU may use the PUCCH resources indicated in the DL assignment.

[0176] The WTRU processor may determine the number of information bits (eg, for purposes of setting the transmit power of the report).

[0177] The WTRU processor may determine the number of HARQ-ACK information bits (e.g., for purposes of setting the transmit power of the PUCCH transmission carrying the report and / or determining the number of modulation symbols carrying the HARQ-ACK information that may possibly be multiplexed with data in a PUSCH transmission). The number of bits may be used as an input to a formula for power control for the PUCCH or for multiplexing in the PUSCH.

[0178] A transmission (PUCCH or PUSCH) may be configured to include HARQ-ACK information at the CBG level and / or TB level for at least one PDSCH transmission. The at least one PDSCH transmission may be mapped onto at least one resource defined at least in part by a carrier, a serving cell, a bandwidth portion, a slot, and / or a minislot. For example, a WTRU may be configured to report HARQ-ACKs associated with two PDSCHs in two carriers (or serving cells) or in two slots. A PDSCH may be configured to include data from at least one TB.

[0179] The WTRU may be indicated in the downlink control information (DCI) whether to report CBG level and / or TB level HARQ (e.g., for the TB of a given PDSCH transmission). The WTRU processor or the network may encode this information by a sequence of bits of the same value (e.g., 0 or 1), where the length of the sequence may correspond to the number of CBGs or the maximum number of CBGs for a transport block, which may be configurable by higher layers. The WTRU processor and the network may decide to use a consistent codebook size. For example, when the WTRU detects that a DL allocation is missing (e.g., using counter DAI or other techniques), the WTRU processor may include the same number of bits regardless of whether CBG level or TB level feedback is expected.For purposes of counting the number of HARQ-ACK information bits, the WTRU processor may (i) count a single HARQ-ACK information bit for a received PDSCH TB for which a TB-level HARQ-ACK should be provided based on an indication from the DCI or higher layer configuration, (ii) count a single HARQ-ACK information bit for a PDSCH TB that is detected to be missing (e.g., using counter DAI or other techniques) and for which a TB-level HARQ-ACK should be provided based on higher layer configuration (e.g., regardless of an indication from the DCI), (iii) determine the number of TBs for the PDSCH based on configuration (e.g., based on whether spatial multiplexing is configured for this PDSCH), or (iv) determine the number of TBs for the PDSCH based on an indication from the DCI or higher layer configuration. (v) may count NCBG HARQ-ACK information bits for PDSCH TBs that are detected to be missing (e.g., using counter DAI or other techniques) and for which a CBG-level HARQ-ACK should be provided based on higher layer configuration, and / or (vi) may count NCBG HARQ-ACK information bits for PDSCH TBs that are detected to be missing (e.g., using counter DAI or other techniques) and for which the WTRU is configured to determine whether a CBG level or TB level is used based on an indication in the DCI. The WTRU may utilize sufficient, but not excessive, transmit power (or resource elements) for transmissions including HARQ-ACK for multiple PDSCHs, which may be at TB or CBG levels even if the same codebook size is utilized.

[0180] The WTRU processor may be configured to report sub-TB HARQ feedback. Such reporting may enable the scheduler to not repeat transmissions of correctly decoded sub-TB resources (e.g., CBs). This may limit system interference and / or increase spectral efficiency.

[0181] The retransmission may include a subset of the sub-TB resources (e.g., a subset of the original CB). The remaining CB may be mapped to the assigned resources in a manner similar to the first transmission. For example, in FIG. 2, in the retransmission, the CB may be mapped to the same set of resource elements. The remaining resources may remain unused (e.g., free).

[0182] The remaining CBs may be concatenated and transmitted on adjacent resources of the assigned resource block. For example, if TBs CB2 and CB4 are retransmitted, they may be mapped to adjacent resources (e.g., to the first OFDM symbol of the assigned resource). The mapping of each CB or the concatenated remaining CBs may be explicitly indicated in the assignment for retransmission.

[0183] The WTRU processor may determine a modulation and coding scheme (MCS) for the retransmission (e.g., a new MCS compared to a previous transmission and / or a previous retransmission). For example, the WTRU processor may derive an MCS for the transmission to use a larger number of resources per retransmitted CBG. The WTRU processor may derive an MCS for the CBG retransmission from the downlink assignment. The WTRU may be configured to use a mapping function for the MCS based on one or more of the number of retransmitted CBGs, the original (or previous) number of transmitted CBGs, and / or the original MCS.

[0184] The transmit power used for the retransmission of the CBG may be different from the previous transmission. For example, a change in transmit power may be useful for system interference and applicable to cases where the MCS has changed. The WTRU processor may determine that there has been a change in transmit power for the retransmission, for example, based on an indication explicitly included in the downlink assignment and / or implicitly based on the downlink assignment. For example, the WTRU processor may receive an indication from the gNB of a change in the relationship between the power of the demodulation reference signal and the data.

[0185] The CBGs of the TB may be indexed. In a retransmission, the retransmitted CBGs may be ordered by ascending or descending index and may be placed adjacent to each other. This may allow for unpunctured retransmission of data. If the resource allocation for the retransmission is the same as the previous transmission or retransmission (which may have had a larger number of CBGs), there may be a mismatch between the required number of resource elements and what is available in the resource allocation. The resource allocation may be adjusted based on the number of CBGs to be retransmitted. For example, the WTRU may be configured to use a different (possibly smaller) set of PRBs for the retransmission, e.g., a subset of the initially transmitted CBGs is retransmitted.

[0186] A code block (CB) or CBG can be defined for each symbol or for each set thereof. For example, CBG mapping can be performed first in the frequency domain and second in the time domain (e.g., frequency-first mapping). For example, a resource allocation can span seven symbols (e.g., in time), and each of the seven CBs or CBGs can span each of the subcarriers utilized for a unique symbol (e.g., the first CB / CBG is transmitted in the first symbol, the second CB / CBG is transmitted in the second symbol, etc.). The transmission can be configured such that none of the code blocks / CBGs can span multiple symbols, and each symbol can include one or more code blocks / CBGs (e.g., each symbol can have an integer number of code blocks / CBGs). This can attempt to ensure that interference events occurring on an integer number of symbols do not have a negative impact on code blocks transmitted in adjacent symbols. The size of the code blocks can depend on the frequency span of the resource allocation. In a retransmission using a reduced resource allocation, the code block or CBG of the first transmission may be allowed to span multiple symbols. The WTRU may be configured to anticipate a repartition of the transmitted CBG (and / or CB) into a (e.g., new) set of CBGs (and / or CBs). For example, in a first transmission, the first code block may occupy the entire transmission bandwidth in the first symbol. In a retransmission on a reduced number of PRBs, the code block may now span two symbols. The code block may be split into two smaller code blocks, each spanning the frequency allocation of a single symbol. Code block splitting may be considered when the WTRU feeds back the HARQ A / N for the retransmission. For example, the HARQ A / N may be a common feedback for both new code blocks and / or a separate HARQ A / N feedback may be sent for each of the new code blocks.

[0187] The number of CBGs and / or the number of CBs per CBG may depend on the allocation (e.g., size of frequency allocation, slot size, etc.) and possibly some rules along with the CB / CBG resource mapping. The rules may be fixed or configurable by the network (and / or a combination of fixed and configurable). The number of CBGs may be obtained as a one-to-one mapping with the number of symbols in the allocation. For example, a WTRU scheduled with data over a slot size of x symbols may assume y CBGs, where y=fct(x). For example, y=x and each symbol is used for a single CBG. The number of CBGs may depend on the total number of subcarriers z. For example, if the number of subcarriers z is greater than a threshold, the CBG may consist of less than or all of the resource elements of a symbol. If z is less than a threshold, the CBG may span multiple symbols. It may be useful for a CBG to span as few symbols as possible, for example, when interference may be bursty in the time domain but not in the frequency domain. For example, the number of symbols spanned by a CBG, defined as s, may be obtained as s=floor(minimum_CBG_length / z), where minimum_CBG_length may be fixed or configurable. In some cases, the frequency allocation z may be greater than a second threshold (e.g., t2), and in such cases, multiple CBGs may be mapped to a single symbol. The total number of subcarriers z may be evenly divided over a number of CBGs. In an example, the CBG mapping over a symbol may be done in such a way that as many CBGs as possible use the maximum CBG length (e.g., t2). The number of CBGs per symbol y_s may be determined by y_s=ceiling(z / t2).

[0188] The CB mapping can be similar to the CBG mapping, for example, in the case where the CBG consists of a single CB. The CB-to-CBG mapping can be obtained as a function of the number of subcarriers and / or OFDM symbols allocated to each CBG. For example, the number of CBs in a CBG can be obtained as a function of the number of resource elements allocated to the CBG (e.g., the total number of subcarriers multiplied by the number of OFDM symbols, if the allocation is continuous in time and frequency). The resource elements allocated to a CBG can be evenly divided over a certain number of CBs or can be calculated in a manner that allows the maximum number of CBs to have a maximum length. For example, the number of CBs in a CBG, n, can be determined from the maximum CB length (max_CB_length) and the total number of resource elements in the CBG, w, as n=ceiling(w / max_CB_length).

[0189] In an example, the TB can be divided into CBs in such a manner that most CBs can be of maximum CB length. The set of CBs can then be grouped into CBGs. The grouping can be done in a manner that reduces the number of symbols spanned by the CBG. For example, the mapping from CBs to REs and from CBs to CBGs can be done first in frequency and then in time (e.g., first across subcarriers of a first symbol, then across subcarriers of a second symbol, etc.). A CB that is mapped to multiple symbols can be grouped within a CBG if the CBG does not already contain another CB that is mapped to multiple symbols.

[0190] In an example, a CBG may span several symbols in the time domain, while occupying a more limited bandwidth in the frequency domain. This scenario may occur, for example, when (i) interference may span (e.g., is expected to span) a bandwidth that may be smaller than the bandwidth that can be allocated for the transmission, and / or (ii) when multiple preempting transmissions (e.g., of limited bandwidth and limited duration) may occur or have occurred. The scheduler may have the option (e.g., in the latter case) to allocate multiple preempting transmissions within the resources that can be occupied by a (e.g., single) CBG, which may minimize the number of (e.g., required) retransmitted CBGs. Exemplary mappings are shown in Figures 3 and 4.

[0191] 3 is an example of a CBG that spans multiple CBs in the time domain. In the example (eg, as shown in FIG. 3), the number of CBs that the CBG spans in the frequency domain may be F=1.

[0192] 4 is an example of a CBG that spans multiple CBs in the time domain. In the example (eg, as shown in FIG. 4), the number of CBs that the CBG spans in the frequency domain can be F=2.

[0193] The WTRU processor may derive the CB to CBG mapping based on, for example, one or more of the following parameters: (i) the number of CBs (F) that the CBG can span in the frequency domain, (ii) the number of CBs that the CBG can span in the time domain, (iii) the number of CBGs for a transmission, (iv) the number of CBs in a transmission, (v) the number of time symbols and / or resource blocks that can be occupied by a transmission, (vi) the number of time symbols and / or resource blocks that can be occupied by a CB, (vii) the number of time symbols and / or resource blocks that can be occupied by a potential preempting transmission or interference, such as a minislot duration, and / or (viii) one or more sets of time symbols and / or resource blocks that can correspond to a time and / or frequency allocation of a potential preempting transmission or interference (e.g., a set of symbol indices that can correspond to a potential start of a preempting transmission).

[0194] The optimal procedure for mapping the CB to the CBG may vary depending on, for example, interference and channel conditions, as well as the probability of a preempting transmission occurring. For example, one or more of the above parameters and / or other parameters may be used to determine the mapping. For example, the parameters may be configured by a higher layer. The parameters may be specific to a transmission profile that may be associated with the transmission. For example, one or more parameters may be indicated (e.g., may be indicated) in a field of a DCI that may be associated with the transmission to enable more dynamic adaptation of the mapping to channel and traffic conditions.

[0195] A non-uniform mapping from CBs to CBGs can be provided. In an example, the mapping from CBs to CBGs can be configured such that the number of CBs per CBG can be significantly smaller for one or more CBGs than for others. Such CBGs can be referred to as, for example, “under-loaded” CBGs. In an example (e.g., when a preempting transmission may need to be scheduled), the scheduler can prefer to preempt resources that can be occupied by code blocks of the under-loaded CBGs and prefer to avoid preempting resources that can be occupied by code blocks of other CBGs. This approach can minimize the number of CBs that may need to be retransmitted in the case where a preemption occurs. The under-loaded CBGs and / or CBs that can be mapped to the under-loaded CBGs can occupy resources that can be spread in the time domain, for example, to maximize the chance that the scheduler can find resources that can be occupied by the under-loaded CBGs (e.g., regardless of the timing of the preempting transmission). An example is shown in FIG. 5.

[0196] FIG. 5A is an example of time and frequency mapping of code blocks to code block groups. FIG. 5A shows an example of time-first and frequency-first mapping of code blocks to code block groups. The mapping of code blocks to code block groups can be determined based on expected interference or puncturing of a transmission. For example, if interference or puncturing is expected to span a limited region in the frequency domain, the code blocks of a transmission can be mapped to code block groups in a frequency-first manner. An example of frequency-first mapping is shown in FIG. 5A and labeled "frequency-first." In the frequency-first example, interference is expected for frequencies associated with the shaded code blocks (502), and the code blocks are mapped to code block groups based on frequency. In another example, if interference or puncturing is expected to span a limited region in the time domain, the code blocks of a transmission can be mapped to code block groups in a time-first manner. An example of time-first mapping is shown in FIG. 5A and labeled "time-first." In the time-first example, interference is expected for the shaded code blocks (504), and the code blocks are mapped to code block groups based on time. The type of code block to code block group mapping can be indicated in a downlink control indication (DCI). The type of code block to code block group mapping can be changed to adapt to changing interference conditions and types of expected interference.

[0197] FIG. 5 is an example of a non-uniform mapping from CBs to CBGs that allows minimization of retransmitted CBs in the case of preemption. In the example, each (e.g., each) rectangle may represent a CB. CBGs #4, #5, #6 may be less packed. In the example, high priority traffic may need to be scheduled on a minislot of two symbols. The scheduler may choose to schedule transmissions on resources of CBGs #4, #5, #6, for example, depending on the timing of the high priority transmissions. In the example, only two CBs may need to be retransmitted (e.g., later) for a TB.

[0198] The WTRU processor may, for example, be configured to use one or more of the following parameters (e.g., to determine the appropriate mapping): (i) a target number of CBs for the less-packed CBG, (ii) a target number of CBs for the normal CBG (not the less-packed CBG), and / or (iii) an indication of the CBs that are mapped to the less-packed CBG. The indication may, for example, consist of a set of resources (e.g., in the frequency and / or time domain) that can be assigned to the CBs. The indication may, for example, consist of an explicit list of CBs. The indication may, for example, consist of at least one parameter that can be used in a formula from which the mapping of CBs to normal CBGs and less-packed CBGs can be derived.

[0199] An indication of a CB to CBG mapping may be provided. The WTRU processor may be configured to use multiple CB to CBG mappings (e.g., uniform and non-uniform). The WTRU processor may determine which mapping can (e.g., should) be used, for example, upon receiving an indication from the network.

[0200] An explicit indication may be provided to the WTRU by the wireless communication network. In an example, a WTRU processor may receive an explicit indication that may indicate a (e.g., one) configured mapping. The indication may be transmitted, for example, using DCI signaling. The indication may be transmitted, for example, at the beginning of a slot / minislot. The DCI may be common (e.g., in a group-common PDCCH, or a group-common search space) or WTRU-specific.

[0201] An implicit indication may be provided. In an example, the gNB may, for example, implicitly indicate a mapping from a CB to a CBG. The gNB may, for example, provide a preemption indication, an indication of potential preemption resources, and / or a time pattern indication.

[0202] In an example of a preemption indication, the WTRU may receive information about frequency / time resources that are to be preempted. The WTRU may group the CBs according to the indication. In an example of a WTRU that may be configured to use two CBGs, the WTRU may map the CBs uniformly to the CBGs, e.g., when the WTRU may not receive a preemption indication. The WTRU may receive a preemption indication. The WTRU may map the CBs in the frequency / time resources that may be preempted (e.g., according to the preemption indication) to a first CBG and the remaining CBs to a second CBG.

[0203] In an example of an indication of a potential preemption resource, the WTRU processor can be configured (e.g., by an indication) to use a (e.g., potential) resource for preemption. The WTRU can map the CBs within the indicated resource to separate CBGs. In the example, the WTRU processor can be configured to use K potential resources for preemption and N CBGs, where K can be smaller than N (e.g., K < N). The first K CBGs can be formed from CBs that can each correspond to one of the K potential resources, for example. The remaining (e.g., N - K) CBGs can be formed, for example, uniformly from other CBs.

[0204] In an example of a time pattern indication, the WTRU processor can apply a configured mapping (e.g., one) according to the time pattern. In an example of a "poor" channel that can be correlated in time, the CBs in a bad channel state can be grouped into one CBG, while the remaining CBs can be grouped (e.g., uniformly) into other CBGs.

[0205] A mini-slot for sub-TB retransmission may be used. The size of the slot may be adjusted based on the number of CBGs to be retransmitted. The WTRU processor may receive a DCI for retransmission from the wireless communication network indicating the slot size for the retransmission. The WTRU processor may implicitly determine the slot size (or transmission time interval) when it receives a DCI indicating the CBG for retransmission (UL or DL) (e.g., if the WTRU is configured such that the CB or CBG are each mapped to a single, possibly consecutive, symbol). The WTRU may expect the PDSCH and RS mapping to follow a rule configured for the mini-slot (e.g., rather than that of the slot size used for the previous transmission (retransmission)). For example, the manner in which the PDSCH and / or RS are mapped to resource elements may depend on whether the WTRU uses mini-slots and / or the length of the mini-slot.

[0206] The WTRU processor may be configured to use DL control channel opportunities to monitor for scheduling assignments (e.g., DCI). For example, the WTRU may be configured to use periodically occurring DL control channel opportunities, possibly tied to a certain slot size (e.g., normal slot size). For efficient use of minislots for retransmission, it may be useful to have multiple WTRUs scheduled to use sub-TB retransmissions in adjacent minislots. The wireless communication network may indicate to the WTRU processor an offset in symbols (or minislots) between the DCI and the data in the DCI for retransmission. For example, a WTRU processor may be scheduled in its periodic DL control channel opportunities (e.g., at the beginning of a regular slot) for a transmission that may be of shorter duration. Another WTRU processor may also be scheduled in its periodic DL control channel opportunities, however, the WTRU may be indicated a symbol offset for the beginning of its DL assignment for sub-TB retransmission.

[0207] The WTRU processor may be configured to use a first set of DL control channel opportunities for scheduling the first transmission and / or full TB retransmissions and a second set of DL control channel opportunities for scheduling the sub-TB retransmissions. The second set of DL control channel opportunities may enable minislot scheduling with more possible starting symbols.

[0208] For power conservation, the WTRU processor may monitor the first set of DL control channel opportunities (e.g., only) until it is indicated to monitor the second set or autonomously decides to monitor the second set. For example, the WTRU processor may be notified by the wireless communication network in a DCI at the first DL control channel opportunity to begin monitoring the second set of DL control channel opportunities. In an example, the WTRU may begin monitoring the second set of DL control channel opportunities upon receipt of a preemption indication from the gNB. The preemption indication may be received by the WTRU at the first set of DL control channel opportunities, possibly at the next DL control channel opportunity that occurs immediately after the preemption occurs. The first DL channel opportunity of the second set that the WTRU processor may monitor may be the first one that occurs after receipt of the preemption indication, or may occur at a (e.g., configurable) time offset from receipt of the preemption indication. In an example of WTRU autonomous decision, the WTRU may start monitoring the second set of DL control channel opportunities when it has fed back sub-TB HARQ with a mix of ACKs and NACKs. For example, if the WTRU has fed back ACKs for a subset of CBGs (e.g., some CBGs have been NACKed), the WTRU processor may start monitoring the second set of DL control channel opportunities (e.g., to allow minislot scheduling of CBG retransmissions). The WTRU may monitor the second set of DL control channel opportunities until indicated to stop by the gNB. The WTRU may monitor the second set of DL control channel opportunities until retransmissions of one or many HARQ processes that triggered the monitoring are completed.

[0209] The second set of DL control channel opportunities may be distinguished from the first set by one or more of: (i) different opportunities in time (e.g., different symbol locations in a timeline or different locations in a subframe), (ii) different locations in frequency, (iii) different control resource sets (CORESETs), (iv) different subsets of the search space within the CORESET, and / or (v) different beams. For example, a WTRU may receive a first transmission on a first beam and any retransmissions on a second beam (e.g., a beam with a narrower beamwidth).

[0210] When indicated to switch to a second set of DL control channel opportunities or when autonomously deciding to do so, the WTRU can anticipate any downlink assignments (for first transmission or retransmission) to be transmitted within that set. For example, the second set of DL control channel opportunities can be a superset that includes the first set of DL control channel opportunities. The WTRU processor can be configured to maintain a fixed total number of blind decoding attempts per time period. When increasing the DL control channel opportunities in time, the WTRU can decrease them in frequency, CORESET, and / or search space.

[0211] After concatenating the CBs and mapping them to a smaller set of symbols, the scheduler can leave the remaining resources unused (e.g., free). The scheduler can adapt the slot size to the number of CBs to be retransmitted. The scheduler can limit the number of unused resources, which can increase spectral efficiency.

[0212] The scheduler may include a new TB (or a set of sub-TB resources of the new TB) in the remaining unused resources. The new sub-TB resources may belong to a new TB or to the same TB of an ongoing HARQ process. As an example of new sub-TB resources belonging to a new TB, a DL transmission may include a CB of a first TB that is retransmitted together with a CB of a second TB (e.g., transmitted for the first time or a retransmission, but with a different retransmission number (e.g., RV number)). As an example of new sub-TB resources belonging to the same TB of an ongoing HARQ process, a first transmission may include a subset of the CBs of the TB (e.g., all CBs), and a retransmission may include a combination of the retransmitted CBs from the first transmission and a set of CBs transmitted for the first time that also belong to the same TB. A TB may be mapped to multiple slots, and the retransmission number of each CB may be independent for each slot.

[0213] The WTRU processor may be configured to provide HARQ feedback for any of the following (e.g., if a slot is used to transmit different portions of different TBs): HARQ feedback for portions of each TB (e.g., sub-TB feedback such as CB group level feedback), HARQ feedback for each TB (e.g., per-TB feedback for each TB), and / or HARQ feedback for bundled TBs (e.g., multiplexed feedback for some or all TBs contained within a slot). The HARQ feedback method for a single TB per slot can be reused for multiple TBs per slot. For example, the WTRU may provide WTRU selection feedback by sending feedback only for TBs in the slot that have an ACK.

[0214] An indication of the index of the retransmitted CBG may be used. There may be a mismatch between the CBG for which the WTRU fed back a NACK and the retransmitted CBG. The mismatch may be due to incorrect decoding of the HARQ feedback by the gNB or a mismatch in available resources for retransmission that may not allow the WTRU to receive all retransmitted CBGs in a single retransmission. Therefore, the retransmitted CBG may be indicated in the downlink allocation (e.g., DCI) for retransmission.

[0215] A bitmap covering the original CBGs included in the TB may be included in the retransmission scheduling allocation. Each bit in the bitmap may indicate whether a particular CBG is included in the retransmission. This may become prohibitive for large transmission bandwidths that require a large number of CBGs. When repartitioning CBGs for retransmission, the bitmap may need to be more adaptive. For example, the total number of CBGs to be transmitted (retransmitted) may be indicated to the WTRU, allowing the WTRU to interpret the CBG bitmap appropriately.

[0216] An implicit numbering of the CBG index in the first transmission (e.g., based on a frequency-first, time-second transmission order) combined with an explicit indication of the CBG index for retransmission can be used. Compression methods such as those described for CBG-based feedback (e.g., pattern-based) can be reused for the indication of the retransmitted CBG.

[0217] The WTRU may receive an indication for a retransmission of a CBG. Such an indication may include a CBG index and possibly an offset value. The offset value may indicate to the WTRU processor a starting point (e.g., resource element or CB) within the CBG for which the retransmission is performed. The WTRU may not expect a retransmission of any RE of the CBG that is located before the point indicated by the offset value.

[0218] The timing between the transmission, the retransmission, and the HARQ feedback may be used. The timing relationship between the transmission and the HARQ feedback for that transmission may be indicated in the scheduling assignment. The timing may be in units of the slot size used for scheduling the transmission. However, in cases where the size of the slot used for the retransmission is different from that used for the previous transmission (retransmission) of the same HARQ process, there may be discrepancies in the interpretation of the timing offset. The timing offset between a transmission (retransmission) and its HARQ feedback indicated to the WTRU may always be in units of the slot size used for the original transmission of the HARQ process or the slot size of the respective transmission (retransmission) associated with the HARQ feedback. The timing offset between the feedback for a transmission (retransmission) and the first DL control channel opportunity at which the WTRU may receive scheduling for another retransmission of the HARQ process from the wireless communication network may also be in units of the slot size used for the original transmission or the latest transmission (retransmission).

[0219] Soft combining of transmitted (retransmitted) soft data can be helpful and / or can improve decoding performance. A wireless communication network can indicate to the WTRU whether a retransmitted CB (or sub-TB resource) can be combined with one or more previous transmissions (retransmissions) of the CB (or sub-TB resource). A subset of the retransmitted CBs can be adapted to combine with the same CBs transmitted in a first subset of previous transmissions (retransmissions) (e.g., all previous transmissions (retransmissions)). Another subset can be combined with a second subset of previous transmissions (retransmissions). For example, the WTRU can receive from the wireless communication network an original transmission and a first retransmission of a set of CBs. Upon receiving a second retransmission of the same set of CBs, the wireless communication network can instruct the WTRU that the subset of CBs can be combined with (e.g., can only be combined with) those received in the original transmission (e.g., cannot be combined with those received in the first retransmission). This may be useful if puncturing of a subset of the CB occurs in the first retransmission: in combination with punctured resources may degrade BER performance and may result in an unnecessarily large number of retransmissions (or even completely failed transmissions).

[0220] The ability to combine data for TB (or sub-TB resources) on different transmissions (retransmissions) may be indicated dynamically. For example, an assignment for a DL transmission (retransmission) may include an indication of a list of previous transmissions with which the TB or sub-TB resources may be combined. The indication may be implicit. An example of an implicit indication may be whether feedback on previous transmissions from the WTRU has been requested. For example, requesting feedback on TB or sub-TB resources may indicate to the WTRU that it can use it to perform combining. In another example, if no indication of a puncturing event is provided to the WTRU, the WTRU processor may determine that the data can be combined with other transmissions (retransmissions).

[0221] The WTRU processor may determine (e.g., autonomously determine) a set of transmissions (retransmissions) on which the WTRU may perform soft combining (e.g., for each sub-TB (e.g., CB) resource). For example, the WTRU processor may use a subset of the transmissions (retransmissions) based on expected demodulation performance. The WTRU processor may determine that the demodulation performance of one or more retransmissions is below a certain threshold and may discard the soft data of one or more transmissions (retransmissions) associated with the resources on which the WTRU performed measurements.

[0222] UL retransmission of the CBG may be performed by the WTRU processor.

[0223] The WTRU processor may retransmit (e.g., be requested to retransmit) a subset of CBGs belonging to those transmitted in a previous transmission to the wireless communication network. The methods described herein for DL ​​retransmission of CBGs may also be applicable to UL retransmission of CBGs. Thus, the methods described herein with respect to DL may be equally applicable to UL, and it is not intended that these examples be limited to a transmission direction.

[0224] When a WTRU vacates resources of a CBG that is not retransmitted, the WTRU processor can reallocate power to another ongoing transmission. For example, a WTRU can have multiple UL transmissions due to carrier aggregation or dual connectivity. The UL power control can depend on the number of active transmissions. The WTRU processor can consider all active transmissions within a symbol to determine the appropriate power sharing among different UL transmissions. Due to zero power transmissions of some CBGs on a carrier, different parts of the transmissions on other carriers are allocated varying transmit power. For example, if a zero power transmission of a CBG is performed on a first carrier, the WTRU processor can allocate power that is typically used for the first carrier to the transmission of the second carrier.

[0225] An uplink interference preemption indication may be provided. The indication may include intra-WTRU interference / preemption.

[0226] In an example, high priority / low latency data may arrive at a WTRU buffer. The WTRU processor may, for example, interrupt an ongoing uplink transmission for lower priority data even after the network has been able to receive some of the lower priority data, for example, within a certain timeslot. This type of event may be referred to as intra-WTRU "uplink preemption," where multiple transmissions originate from the same WTRU.

[0227] The WTRU processor may inform the network about the uplink preemption, e.g., so that the network knows that some of the data transmitted in the (e.g., current) slot may be for a different transmission of higher priority data. The network (e.g., informed by the WTRU about the uplink preemption) may discard lower priority data that may be transmitted on the interfered resource. This may be referred to as a preemption indication. The preemption indication may be used by the receiver, e.g., to manage its HARQ soft buffer. In an example, the receiver may choose to flush or discard data that may be received on the indicated portion for the lower priority transmission. The receiver may (e.g., may also) use the indication, e.g., when it is able to receive a (e.g., subsequent) transmission for the interfered portion of data.

[0228] The WTRU may indicate an uplink preemption event to the wireless communication network, e.g., explicitly or implicitly. The explicit indication may take the form of a resource indication. For example, the indication may indicate resources in the time domain, the frequency domain, or the time-frequency domain. The indication may indicate one or more code blocks (CBs) or code block groups (CBGs) from a lower priority transmission that may have (e.g., have) been preempted (e.g., additionally or alternatively, e.g., in the context of code block-based HARQ).

[0229] For example, a new UCI field in the PUSCH channel may be used to transmit the preemption indication. For example, the UCI may be transmitted before the preemption occurs or after the preemption. In (e.g., additional or alternative) examples, a (e.g., special) control channel (e.g., specific to the high priority transmission) may carry an indication, for example, before or after the preemption event. In an example, an advanced PUCCH may accompany the high priority transmission, which may include the indication.

[0230] The preemption can (e.g., can be) an encoded part of the CB or CBG, for example, by masking an appended CRC or by adding a (e.g., extra) bit to tell the receiver that the CB or CBG may (e.g., is) preempted.

[0231] The WTRU may be tied to a type of uplink resource that can be used to transmit high priority (e.g., semi-persistent, grant-free, or scheduled) data and may (e.g., may) indicate a preemption event using, e.g., an in-band indication.

[0232] The indication may include inter-WTRU interference / preemption.

[0233] In an example, a WTRU may not have enough resources to transmit higher priority data. The WTRU may occupy and preempt resources that can be used by other WTRUs, which may be transmitting ongoing lower priority data. Interference may be indicated to other WTRUs occupying the medium, e.g., so that they can temporarily abort ongoing transmissions of lower priority data. This may be referred to, e.g., as "WTRU-to-WTRU uplink preemption indication."

[0234] For example, inter-WTRU uplink preemption indication may be implemented by allowing a block of resources to be used by multiple WTRUs for low and high priority data. Preemption indication may be useful, for example, in high cell load scenarios where resources may be occupied by lower priority data.

[0235] An inter-WTRU uplink preemption indication can, for example, be attached to (e.g., each) resource. In an example, an RS can be transmitted on a portion of a PRB to occupy it, for example, when (e.g., only when) it is used to transmit higher priority data. A WTRU that may use a shared resource can check (e.g., by sensing or decoding an RS, which can be unique for each resource), for example, before occupying the medium, whether the resource may be used by a WTRU with a higher priority. A network node can (e.g., additionally or alternatively) communicate the resource usage to other (e.g., hidden) WTRUs that cannot detect the resource usage, for example, by transmitting an RS from the serving cell (e.g., masked by its cell ID) or by conveying information on a downlink control channel.

[0236] For example, an inter-WTRU uplink preemption indication may be indicated in a different procedure without blocking some of the shared resources to indicate preemption (e.g., only for that purpose). In an example, an inter-WTRU uplink preemption indication may be transmitted on or together with uplink control information (e.g., on the UCI portion of the PUSCH, or on the PUCCH). The network may instruct other WTRUs that may (e.g., subsequently) occupy (e.g., seek to occupy) the medium to avoid or suspend their transmissions. This may be conveyed, for example, on a downlink control channel. A WTRU with a suspended transmission may resume transmission of lower priority data, for example, when the medium is no longer occupied (e.g., for a higher priority transmission), when a configured suspension timer expires, and / or when conveyed by the network.

[0237] Each of the computing systems described herein may have one or more computer processors having memory configured to use executable instructions or hardware to accomplish the functions described herein, including determining parameters described herein and sending and receiving messages between entities (e.g., the WTRU and the network) to accomplish the functions described herein. The processes described above may be implemented in computer programs, software, and / or firmware contained in a computer-readable medium that is executed by the computer and / or processor.

[0238] A system, method, and means for receiver feedback in a wireless system have been disclosed. The receiver feedback format, content, type, and / or timing can be determined as a function of, for example, a hybrid automatic repeat request (HARQ) processing state, which corresponds to, for example, a sequence of transmissions for a HARQ process, a maximum time for a HARQ process to be successful, a measured or estimated link quality, demodulation performance, and / or a number of successfully decoded code blocks. The receiver feedback format, content, type, and / or timing can be determined as a function of, for example, a configuration of a wireless transmit / receive unit (WTRU), which indicates at least one of a type of soft combining process applied in the HARQ process, a HARQ operating point for the HARQ process, one or more reference transmissions for controlling a type of HARQ feedback for the HARQ process, and a feedback suppression parameter for one or more transmissions in a sequence associated with a HARQ process or a transport block (TB). Uniform and non-uniform mappings from CB to CBG may be provided (e.g., by the WTRU) based on, for example, one or more parameters, interference and channel conditions, and / or the probability or actual preempting transmission. An indication of a CB to CBG mapping may be provided, e.g., supporting selection of a CB to CBG mapping from multiple CB to CBG mappings. Intra-WTRU and inter-WTRU interference / preemption indications may be provided.

[0239] The processes and methodologies described herein may be applied in any combination and may be applied to other wireless technologies and for other services.

[0240] The WTRU can be a physical device identity or a subscription-related identity, e.g., a user's identity, such as MSISDN, SIP URI, etc. The WTRU can be an application-based identity, e.g., a username that can be used per application.

[0241] The functions described herein may be implemented between the WTRU and the wireless communication system, e.g., on a UR-LLC communication channel. The WTRU and the wireless communication system may have one or more computer processors configured (e.g., programmed with executable instructions) to accomplish the functions described herein. For example, the WTRU may have a processor configured to communicate with a wireless communication network (e.g., using UR-LLC communication). The WTRU processor may be configured to receive a first downlink control information (DCI) indicating whether a transport block (TB)-based hybrid automatic repeat request (HARQ) feedback should be provided for a downlink transmission or whether a code block group (CBG)-based HARQ feedback should be provided for a downlink transmission. The WTRU processor may be configured to receive a downlink transmission associated with the first DCI, including a transport block having one or more code blocks. The WTRU processor may be configured to attempt to decode one or more code blocks of the transport block. The WTRU processor may be configured to determine that the first DCI indicates that a CBG-based HARQ feedback should be provided. If the processor determines that the first DCI indicates that CBG-based HARQ feedback should be provided, the WTRU processor may be configured to determine a mapping of the one or more code blocks to one or more CBGs, determine HARQ feedback for at least one of the one or more CBGs based on whether decoding of a corresponding code block for the at least one CBG is successful, and transmit the HARQ feedback for the one or more CBGs to the wireless communication network. The WTRU processor may be configured to determine that the first DCI indicates that TB-based HARQ feedback should be provided.If the WTRU processor determines that the first DCI indicates that TB-based HARQ feedback should be provided, the WTRU processor may be configured to determine HARQ feedback for the transport block and send the HARQ feedback for the transport block to the wireless communication network.

[0242] The mapping can be a mapping of one or more code blocks to code block groups in at least one of frequency or time, and can be based on one or more of the number of subcarriers or OFDM symbols assigned to a code block group or transmission, the maximum code block length, the number of code block groups in a transmission, the number of code blocks in a transmission, and the number of time symbols and / or resource blocks occupied by a potential preempting transmission.

[0243] The determined HARQ feedback for the one or more CBGs can be an ACK if the decoding of each of the corresponding code blocks is successful, or a NACK if the decoding of one or more of the one or more code blocks is not successful. The WTRU processor can be configured to receive a retransmission from the wireless communication network in response to the transmitted NACK. The wireless communication network can have a processor configured to receive the transmitted ACK or NACK and determine to transmit a retransmission if a NACK is received.

[0244] The WTRU processor can be configured to receive a second DCI for the retransmission. The second DCI can indicate which CBGs are to be retransmitted. The second DCI can indicate which CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding. The second DCI can include a bitmap that can be used to indicate which CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding. The wireless communication network can have a processor configured to determine to transmit the second DCI and content of the second DCI.

[0245] The WTRU processor can be configured to monitor for the first downlink control information and, based on a preemption command from the wireless communication network, to monitor for the second downlink control information. The wireless communication network can have a processor configured to determine to send a preemption command to the WTRU.

[0246] The WTRU may include a HARQ buffer. A WTRU processor may be configured to manage the HARQ buffer and to discard data in the HARQ buffer if one or more code blocks are not successfully decoded.

[0247] The WTRU processor may be configured to determine a preemption indication to send in uplink control information to the wireless communication network if one or more code blocks are not successfully decoded.

[0248] The wireless communication network may have a processor configured to determine to transmit first downlink control information (DCI) indicating whether transport block (TB)-based hybrid automatic repeat request (HARQ) feedback should be provided for a downlink transmission or whether code block group (CBG)-based HARQ feedback should be provided for a downlink transmission, and to transmit the first downlink control information. The wireless communication network may have a processor configured to receive the transmitted HARQ feedback, including the TB-based HARQ feedback.

[0249] Each of the computing systems described herein may have one or more computer processors having memory configured to use executable instructions or hardware to accomplish the functions described herein, including determining parameters described herein and sending and receiving messages between entities (e.g., the WTRU and the network) to accomplish the functions described herein. The processes described above may be implemented in computer programs, software, and / or firmware contained in a computer-readable medium that is executed by the computer and / or processor.

[0250] The processes described above may be implemented in computer programs, software, and / or firmware contained in a computer-readable medium executed by a computer and / or processor. Examples of computer-readable media include, without limitation, electronic signals (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, without limitation, magnetic media, magneto-optical media, such as, but not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks and removable disks, and / or optical media, such as CD-ROM disks and / or digital versatile disks (DVDs). Processors in association with software may be used to implement radio frequency transceivers used in the WTRU, terminals, base stations, RNCs, and / or any host computer. [Industrial Applicability]

[0251] The present invention can be used in communications.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: receiving configuration information including information indicating that code block group-based type (CBG-based type) hybrid automatic repeat request (HARQ) feedback is to be provided by the WTRU; receiving first downlink control information (first DCI) associated with a first downlink transmission; receiving the first downlink transmission including at least one transport block (TB), the at least one TB including a plurality of CBGs, each of the CBGs including one or more code blocks (CBs); transmit a first TB-based HARQ feedback associated with the first downlink transmission based on the first DCI indicating that a TB-based type HARQ feedback will be provided for the first downlink transmission, the first TB-based HARQ feedback including a number of HARQ-ACK information bits associated with a first TB of the first downlink transmission equal to a number of the CBGs of the first downlink transmission, each of the HARQ-ACK information bits having an identical value. A processor and a transceiver configured to A WTRU equipped with

2. The WTRU of claim 1, wherein the value of the HARQ-ACK information bit indicates whether the first TB of the first downlink transmission was successfully decoded.

3. The processor and the transceiver receiving a second DCI associated with a second downlink transmission; receiving the second downlink transmission including at least one TB, the at least one TB including a second plurality of CBGs, each of the CBGs of the second plurality of CBGs including one or more second CBs; transmit second CBG-based HARQ feedback associated with the second downlink transmission based on the second DCI indicating that the CBG-based type HARQ feedback will be provided for the second downlink transmission, the second CBG-based HARQ feedback including a number of HARQ-ACK information bits associated with a first TB of the second downlink transmission equal to a number of CBGs of the second downlink transmission. The WTRU of claim 1 configured to:

4. The WTRU of claim 3, wherein the HARQ-ACK information bit of the second CBG-based HARQ feedback associated with the second downlink transmission has a value indicating whether a corresponding CBG of the CBG of the second downlink transmission was successfully decoded.

5. The processor, 2. The WTRU of claim 1, further configured to determine a mapping of the CBs to the multiple CBGs of the first downlink transmission in at least one of a frequency domain or a time domain, the first downlink transmission being received using the mapping.

6. The mapping may include: The WTRU of claim 5, wherein the preemption determination is based on one or more of: a number of subcarriers or orthogonal frequency division multiplexing (OFDM) symbols assigned to the multiple CBGs; a maximum code block length; the number of CBGs of the first downlink transmission; a number of CBs in the first downlink transmission; and / or a number of time symbols or resource blocks occupied by a potential preempting transmission.

7. The WTRU of claim 1 , wherein the first downlink transmission is associated with a HARQ process.

8. 2. The WTRU of claim 1, wherein the first DCI includes a bitmap indicating which CBGs of the first downlink transmission may be combined with previously received CBGs.

9. The processor and the transceiver The WTRU of claim 1, further configured to receive configuration information including information indicating a maximum number of CBGs per TB, and the first TB-based HARQ feedback includes the number of HARQ-ACK information bits equal to the maximum number of CBGs per TB.

10. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: receiving configuration information including information indicating that code block group-based type (CBG-based type) hybrid automatic repeat request (HARQ) feedback should be provided by the WTRU; receiving a first downlink control information (first DCI) associated with a first downlink transmission; receiving the first downlink transmission comprising at least one transport block (TB), the at least one TB comprising a plurality of CBGs, each of the CBGs comprising one or more code blocks (CBs); transmitting a first TB-based HARQ feedback associated with the first downlink transmission based on the first DCI indicating that a TB-based type HARQ feedback will be provided for the first downlink transmission, the first TB-based HARQ feedback including a number of HARQ-ACK information bits associated with a first TB of the first downlink transmission equal to a number of the CBGs of the first downlink transmission, each of the HARQ-ACK information bits having an identical value; A method for providing the above.

11. The method of claim 10, wherein the value of the HARQ-ACK information bit indicates whether the first TB of the first downlink transmission was successfully decoded.

12. receiving a second DCI associated with a second downlink transmission; receiving the second downlink transmission including at least one TB, the at least one TB including a second plurality of CBGs, each of the CBGs of the second plurality of CBGs including one or more second CBs; transmitting second CBG-based HARQ feedback associated with the second downlink transmission based on the second DCI indicating that the CBG-based type of HARQ feedback will be provided for the second downlink transmission, the second CBG-based HARQ feedback including a number of HARQ-ACK information bits associated with a first TB of the second downlink transmission equal to a number of CBGs of the second downlink transmission; The method of claim 10 further comprising:

13. 13. The method of claim 12, wherein the HARQ-ACK information bit of the second CBG-based HARQ feedback associated with the second downlink transmission has a value indicating whether a corresponding CBG of the CBG of the second downlink transmission has been successfully decoded.

14. 11. The method of claim 10, further comprising determining a mapping of the CBs to the multiple CBGs of the first downlink transmission in at least one of a frequency domain or a time domain, the first downlink transmission being received using the mapping.

15. The mapping may include:

15. The method of claim 14, wherein the method is based on one or more of: a number of subcarriers or orthogonal frequency division multiplexing (OFDM) symbols assigned to the multiple CBGs; a maximum code block length; the number of CBGs of the first downlink transmission; a number of CBs in the first downlink transmission; and / or a number of time symbols or resource blocks occupied by a potential preempting transmission.

16. The method of claim 10 , wherein the first downlink transmission is associated with a HARQ process.

17. 12. The method of claim 11, wherein the first DCI includes a bitmap, the bitmap indicating which CBGs of the first downlink transmission may be combined with previously received CBGs.

18. receiving configuration information including information indicating a maximum number of CBGs per TB, wherein the first TB-based HARQ feedback includes the number of HARQ-ACK information bits equal to the maximum number of CBGs per TB; The method of claim 10 further comprising:

Images