Receiver Feedback in a Wireless System

Abstract

Systems, methods, and means for receiver feedback in a wireless system are disclosed. Receiver feedback format, content, type, and / or timing can be determined based on, for example, at least one of the following: the type of soft combination processing to be applied in a HARQ process, the HARQ operating point for the HARQ process, one or more reference transmissions for the type of HARQ feedback that controls the HARQ process, and the feedback suppression parameter for one or more transmissions in a sequence associated with the HARQ process or transport block (TB). Uniform and non-uniform CB to CBG mapping can be provided (e.g., by a WTRU) based on, for example, one or more parameters, interference and channel conditions, and / or the probability of an actual pre-empted transmission. A CB to CBG mapping indication can be provided, for example, to support selection of a CB to CBG mapping from multiple CB to CBG mappings. An in-WTRU and inter-WTRU interference / pre-emption indication can be provided.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 201880005828.2, titled "Receiver Feedback in a Wireless System", filed on January 3, 2018, which is hereby incorporated by reference in its entirety.

[0002] Cross - reference to related applications

[0003] This application claims the priority and benefit of U.S. Provisional Application Serial No. 62 / 442,093, filed on January 4, 2017; U.S. Provisional Application Serial No. 62 / 453,085, filed on February 1, 2017; U.S. Provisional Application Serial No. 62 / 500,989, filed on May 3, 2017; U.S. Provisional Patent Application Serial No. 62 / 519,675, filed on June 14, 2017; and U.S. Provisional Patent Application Serial No. 62 / 542,927, filed on August 9, 2017, which are hereby incorporated by reference in their entirety. Background of the invention

[0004] Mobile communication using wireless communication continues to develop. The fifth generation can be referred to as 5G. Previous (conventional) generations of mobile communication can be, for example, the fourth generation (4G) Long - Term Evolution (LTE). Summary of the invention

[0005] Systems, methods, and means for receiver feedback in a wireless system are disclosed. Receiver feedback format, content, type, and / or timing can be determined according to, for example, a hybrid automatic repeat request (HARQ) processing state. The HARQ processing state can correspond to, for example, a transmission sequence of a HARQ process, a maximum time for which the HARQ process continues, a measured or estimated link quality, a demodulation performance, and / or a number of successfully decoded code blocks. Receiver feedback format, content, type, and / or timing can be determined according to, for example, a configuration of a wireless transmit / receive unit (WTRU). The configuration can indicate one or more of the following: a type of soft combining processing to be applied 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, a feedback suppression parameter for one or more transmissions in a sequence associated with the HARQ process or a transport block (TB). Transmissions of a subset of one or more code block groups (CBGs) (e.g., valid transmissions) can be used. Adaptive resource allocation can be used to transmit a subset of one or more CBGs. Mini-slots can be used for retransmitting a subset of one or more CBGs. A WTRU can monitor (e.g., a new downlink) a downlink control channel (e.g., when a transmission is desired). A retransmission CBG index can be indicated. A timing relationship between a downlink assignment, a transmission (retransmission), and an adaptive feedback for an adaptive slot size can be used. A uniform and non-uniform CB to CBG mapping (e.g., provided by a WTRU) can be provided based on, for example, one or more parameters, interference and channel conditions, and / or a probability of an actual pre-empted transmission. A CB to CBG mapping indication can be provided to, for example, support selection of a CB to CBG mapping from multiple CB to CBG mappings. An in-WTRU and inter-WTRU interference / pre-emption indication can be provided. A feedback bit counter downlink assignment index (DAI) can enable a WTRU to determine how many feedback bits are required for a feedback report of a lost DL assignment. Feedback report bit adaptive bundling can be used to achieve a fixed feedback report size per DL assignment. Unequal reliability can be used for the multiplexed feedback reports.

[0006] A WTRU and a wireless communication system may have one or more configured (e.g., programmed with executable instructions) computer processors. For example, the WTRU may have a processor configured to communicate with a wireless communication network (e.g., by using UR-LLC communication). The WTRU processor may be configured to receive first downlink control information (DCI) that indicates whether HARQ feedback based on a transport block (TB) should be provided for a downlink transmission or whether HARQ feedback based on a codeblock group (CBG) should be provided for the 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 codeblocks. The WTRU processor may be configured to attempt to decode the one or more codeblocks of the transport block. The WTRU processor may be configured to determine that the first DCI indicates that HARQ feedback based on a CBG should be provided. If the processor determines that the first DCI indicates that HARQ feedback based on a CBG should be provided, the WTRU processor may be configured to determine a mapping of the one or more codeblocks to one or more CBGs; determine HARQ feedback for at least one of the one or more CBGs based on whether corresponding codeblocks of at least one of the one or more CBGs are successfully decoded; and send 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 HARQ feedback based on a TB should be provided. If the WTRU processor determines that the first DCI indicates that HARQ feedback based on a TB 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.

[0007] The mapping may be a mapping of the one or more codeblocks to the codeblock groups in at least one of frequency or time. The mapping may be based on one or more of the following: the number of subcarriers or OFDM symbols assigned to the codeblock group or the transmission, the maximum codeblock length, the number of codeblock groups in the transmission, the number of codeblocks in the transmission, and the number of time symbols and / or resource blocks occupied by a potential pre-empting transmission.

[0008] If each of the corresponding code blocks is successfully decoded, the determined HARQ feedback for the one or more CBGs may be ACK, and if one or more of the one or more code blocks are not successfully decoded, the determined HARQ feedback for the one or more CBGs may be NACK. The WTRU processor may be configured to receive a retransmission in response to the transmitted NACK from a wireless communication network. The wireless communication network may have a processor configured to receive the transmitted ACK or NACK and, if a NACK is received, determine to send a retransmission.

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

[0010] The WTRU processor may be configured to monitor a first downlink control information and monitor a second downlink control information based on a preemption instruction from a wireless communication network. The wireless communication network may have a processor configured to determine to send a preemption instruction to the WTRU.

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

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

[0013] The wireless communication network may have a processor configured to determine to send a first downlink control information (DCI) and send the first downlink control information, which indicates whether HARQ feedback based on a transport block (TB) should be provided for a downlink transmission or whether HARQ feedback based on a code block group (CBG) should be provided for the downlink transmission. The wireless communication network may have a processor configured to receive the transmitted HARQ feedback, which includes HARQ feedback based on TB. Description of the Drawings

[0014] Figure 1A is a system diagram showing an exemplary communication system in which one or more of the disclosed examples may be implemented.

[0015] Figure 1B is showing an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system shown in Figure 1A according to an example.

[0016] Figure 1C is showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system shown in Figure 1A according to an example.

[0017] Figure 1D is showing another exemplary RAN and another exemplary CN that may be used within the communication system shown in Figure 1A according to an example.

[0018] Figure 2 is an example of a punctured transmission with different HARQ feedback types for each transmission.

[0019] Figure 3 is an example of a codeblock group (CBG) spanning multiple codeblocks (CBs) in the time domain.

[0020] Figure 4 is an example of a CBG spanning multiple CBs in the time domain.

[0021] Figure 5 is an example of a non-uniform CB to CBG mapping that allows minimizing the retransmitted CBs in case of preemption.

[0022] Figure 5A is an example of frequency-first and time-first CB-CBG mapping. Detailed Description

[0023] A detailed description of illustrative embodiments will now be described with reference to the accompanying drawings. Although the description provides detailed examples of possible implementations, it should be noted that these details are intended to be exemplary and in no way limit the scope of the present application.

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

[0025] As Figure 1A shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network components. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, any one of the WTRUs 102a, 102b, 102c, 102d may be referred to as a “station” and / or “STA” which may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop computer, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain environment), a consumer electronic device, and a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, 102d may be interchangeably referred to as a UE.

[0026] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112) by wirelessly interfacing with at least one of WTRUs 102a, 102b, 102c, 102d in a wireless manner. For example, base stations 114a, 114b may be base transceiver stations (BTSs), Node Bs, eNode Bs, home Node Bs, home eNode Bs, gNBs, NR Node Bs, site controllers, access points (APs), and wireless routers, etc. Although each of base stations 114a, 114b is described as a single component, it should be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network components.

[0027] Base station 114a may be part of RAN 104 / 113, and the RAN may also include other base stations and / or network components (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies in a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell may provide wireless service coverage for a relatively fixed or possibly time-varying specific geographical area. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, that is, each transceiver corresponds to a sector of the cell. In an embodiment, base station 114a may use multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, by using beamforming, signals may be transmitted and / or received in a desired spatial direction.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0058] A WLAN operating in an 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 be connected to or interfaced with a Distribution System (DS) or another type of wired / wireless network that sends traffic into and / or out of the BSS. Traffic originating outside the BSS and destined for an STA may reach the AP and be delivered to the STA. Traffic originating from an STA and destined for a destination outside the BSS may be sent to the AP for delivery to the corresponding destination. Traffic between STAs within the BSS may be sent through the AP, e.g., the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. The point-to-point traffic may be sent using a Direct Link Setup (DLS) between the source and destination STAs (e.g., directly between them). In some exemplary embodiments, the DLS may use 802.11e DLS or 802.11z Channelized DLS (TDLS). A WLAN operating in an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all STAs) may communicate directly with each other. Here, the IBSS communication mode is sometimes referred to as an "ad hoc" communication mode.

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

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

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

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

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

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

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

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

[0067] WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable digital configuration. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may be different for different transmissions, different cells, and / or different wireless transmission spectrum portions. WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) having different or scalable lengths (e.g., including a different number of OFDM symbols and / or a continuously varying absolute time length).

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

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

[0070] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and may possibly include data networks (DN) 185a, 185b. Although each of the foregoing components has been described as part of CN 115, it should be understood that any of these components may be owned and / or operated by entities other than the CN operator.

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

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

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

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

[0075] In view of Figures 1A - 1D and regarding Figures 1A - 1D the corresponding descriptions, one or more or all of the following functions can be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-b, eNode Bs 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 device(s) described herein. These emulation devices can be one or more devices configured to simulate one or more or all of the functions herein. For example, these emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

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

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

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

[0079] Mobile communications are constantly evolving. The fifth generation of evolution is known as 5G.

[0080] HARQ-related feedback may support codeblock-based HARQ operation and / or transmission puncturing. One or more of the following may be combined: per-transmission measurement-based probability feedback, per-codeblock feedback, and / or per-TB feedback. Support may be provided for switching HARQ process-specific and / or per-TB-specific reporting (e.g., reporting type and / or method) (e.g., to optimize the tradeoff between granularity and overhead assuming a given HARQ operating point).

[0081] Sub-TB feedback configuration may be used (e.g., different sub-TB regions may be configured with different HARQ feedback types). Feedback requests may be used (e.g., for sub-TB resources), for example, regardless of whether such sub-TB resources are included in the current retransmission. For example, the feedback request may confirm a previous probabilistic HARQ feedback. The WTRU may select sub-TB resources for feedback. Sub-TB resources may be retransmitted (e.g., regarding mapping of subsets of sub-TB resources, methods for reusing unused resources, and methods for controlling soft combining).

[0082] The 5G system can, for example, at least partially correspond to a new radio (NR) access technology.

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

[0084] In an example supporting LLC, the air interface latency can be, for example, 1 ms round-trip time (RTT). The transmission time interval (TTI) can be, for example, between 100 us and 250 us.

[0085] Support for ultra-low access latency can be provided (e.g., the time from initial system access to the completion of the transmission of the first user plane data unit).

[0086] Communications (e.g., IC and / or vehicle-to-everything communication (V2X)) can have an end-to-end (e2e) latency, e.g., less than 10 ms.

[0087] In an example supporting URC, the transmission reliability can be, for example, a transmission success rate and service availability of approximately 99.999%.

[0088] Support for mobility can be provided. The mobile speed can be in the range of, for example, 0 to 500 km / h.

[0089] Support can be provided for a packet loss rate (PLR) of less than 10e -6 for communications (e.g., IC and V2X).

[0090] In an example supporting MTC operations, the air interface can support narrowband operations (e.g., using less than 200 KHz), extended battery life (e.g., up to 15 years of autonomy), and / or minimal communication overhead for small and infrequent data transmissions (e.g., low data rates in the range of 1 - 100 kbps and access latency of seconds to hours).

[0091] Orthogonal frequency division multiplexing (OFDM) can be used as a signal format for data transmission, such as for LTE and / or IEEE 802.11. OFDM can be used to divide the spectrum into multiple parallel orthogonal sub-bands. A rectangular window in the time domain can be used to shape (e.g., each) sub-carrier, which can result in a sinusoidal-shaped sub-carrier in the frequency domain. OFDMA (Orthogonal Frequency Division Multiple Access) can be implemented to manage (e.g., perfect) frequency synchronization and (e.g., strict) uplink timing alignment during the duration of the cyclic prefix, e.g., to maintain orthogonality between signals and minimize inter-carrier interference. For example, in a system where a WTRU can be connected to multiple access points simultaneously, strict synchronization can be a challenge. Additional power reduction can be applied to uplink transmissions, e.g., to comply with spectrum emission requirements in adjacent frequency bands, which can occur when there is an aggregation of fragmented spectra for WTRU transmissions.

[0092] For example, when operating with a large continuous spectrum without the need for aggregation, OFDM (e.g., cyclic prefix (CP)-OFDM) implementations can apply more stringent RF requirements. A CP-based OFDM transmission scheme can result in a downlink physical layer similar to previous generations of 5G in terms of, for example, modifications to pilot signal density and location.

[0093] For 5G systems, 5G NR access can use waveforms other than OFDM.

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

[0095] 5G systems can support data transmissions with different requirements (e.g., in terms of latency, throughput, and reliability), which may lead to different processing principles and transmission attributes. In an example, data (e.g., associated with ultra-low latency and / or ultra-reliable use cases) can be transmitted using (e.g., very) short transmission time intervals (TTIs), e.g., by using mini-slots (e.g., using x symbols and / or a first digital configuration) within slot-based framing (e.g., with a moderate payload per TTI). Data (e.g., associated with mobile broadband or massive MTC use cases) can be transmitted using longer TTIs (e.g., to reduce control channel overhead), e.g., by using slot-based transmissions (e.g., using y > x symbols and / or using a second digital configuration).

[0096] Data (e.g., data associated with ultra-low latency or ultra-reliable use cases) can be sent with a very strict latency starting from the time it is generated at the application layer. Delaying data transmission until the ongoing transmission using a larger TTI ends may be unacceptable. For example, considering that latency-sensitive traffic may be sporadic, it may be inefficient to reserve dedicated resources. Next-generation (e.g., 5G) wireless systems can support the transmission of latency-sensitive data within the resources used for ongoing transmissions while maintaining the robust performance of both transmissions.

[0097] Code-block based hybrid automatic repeat request (HARQ) processing can be supported. Data included in a transmission (e.g., which is sent as a transport block (TB)) can be encoded using block-based coding (e.g., further). A TB can contain one or more code blocks (CBs) associated with one or more MAC PDUs. Block-based coding can be used, for example, to isolate and / or limit transmission errors and / or puncturing events to specific parts of the transmission, e.g., to improve decoding efficiency and minimize retransmissions. Block-based coding can include mapping code blocks to code block groups. The mapping can be performed within frequency, time, and / or a combination of frequency and time. The mapping can be indicated in control information. For example, a wireless communication network can have a processor configured to determine the mapping and can send the mapping to a WTRU in downlink control information. The WTRU can have a processor configured to monitor DCI and receive the DCI, receive a downlink transmission with code blocks, and attempt to decode the code blocks using the mapping received in the DCI.

[0098] HARQ feedback can be generated by HARQ processing, e.g., based on the reception result of a (e.g., one) TB transmission. For example, a WTRU may have a processor configured for HARQ feedback and may determine the HARQ feedback based on attempting to decode the code blocks of a code block group using the mapping received on a 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 decoding is successful. The wireless communication network may have a processor configured to retransmit the mapping of the code blocks to the code block group if the processor determines that a NACK is received from the WTRU. In an example (e.g., when using block-based coding), HARQ feedback may be generated at a higher granularity (e.g., per CB), at the cost of higher overhead (e.g., increased number of feedback bits) to transmit such feedback.

[0099] The generation and transmission of HARQ-related feedback can be improved. For example, the improvement may be useful when using block-based coding and / or when puncturing events may occur in the system.

[0100] The feedback process is applicable to many use cases, technologies, and scenarios.

[0101] In an example, a first transmission can be initiated. At least a portion of the physical layer resources can be used to perform the first transmission. One or more resources can correspond to at least a portion of the physical layer resources associated with a second transmission.

[0102] The first transmission can be, for example, a "puncturing" transmission, an "interference" transmission, a "delay-sensitive" transmission, or a "mini-slot" transmission. The second transmission can be, for example, an "ongoing" transmission, a "best-effort" transmission, or a "slot-based" transmission.

[0103] The first and second transmissions can be sent by the same entity or different entities. The first and second transmissions can be received (or intended for) the same entity or different entities. The first and second transmissions can be downlink or uplink transmissions, which can be part of an infrastructure-based (e.g., cellular system) transmission. The first and second transmissions can be direct WTRU-to-WTRU transmissions (e.g., sidelink-type transmissions).

[0104] (E.g., each) entity can be part of, for example, a WTRU or a network infrastructure node.

[0105] The feedback process can be associated with specific aspects, processes, and / or components of radio access.

[0106] The WTRU may apply (e.g., having a processor configured with executable instructions) a feedback process based on one or more of the following: e.g., (i) digital configuration, spectral operation mode (SOM), and / or its configuration associated with transmission (e.g., a set of resources, carriers, subcarrier spacing, symbol duration, priority associated with specific data, TTI duration, framing (e.g., slot-based, mini-slot based), etc.); (ii) physical layer resources associated with transmission; (iii) control channels and / or one or more associated characteristics associated with transmission and / or physical layer resources (e.g., RNTI, position in search space, or CCE, etc.); (iv) receiving downlink control information, e.g., an explicit request for a specific method to be applied (e.g., no HARQ feedback), a first reporting method, or a second reporting method; (v) reference and / or demodulation signals associated with transmission; (vi) configuration received by the upper layer (e.g., configured feedback and / or transmission mode); (vii) configuration associated with one or more HARQ processes (e.g., including a set of processes), which may include applicable soft combining processes (e.g., incremental redundancy or chase combining).

[0107] (e.g., NR) systems may support soft combining for HARQ processes, which may include multiple processes, e.g., incremental redundancy or chase combining. In an example (e.g., for a given HARQ process using incremental redundancy (IR)), for a given TB, HARQ retransmissions may be performed using different numbers of bits (TBS) relative to a previous transmission of the same TB. For example, considering how soft combining works with IR, different numbers of bits may be used. This may be the case for turbo coding (e.g., which may be used for LTE) or (variable size) LDPC (e.g., which may be used for NR). For coding (UL) and soft combining (DL), WTRU buffering and processing may be higher. HARQ retransmissions with IR may have different values and / or combinations for one or more 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), (e.g., any) HARQ transmissions associated with the HARQ process and 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 slot transmission or a mini-slot transmission) for a given HARQ process for a given TB. The WTRU may receive signaling for this purpose and may make an appropriate determination for (e.g., each) transmission. The WTRU may handle the HARQ processing timeline in terms of authorized UL transmission and HARQ feedback timeline (e.g., accordingly).

[0108] Example processes are provided to generate receiver feedback information.

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

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

[0111] In (e.g., alternative) examples, HARQ-related parameters can be expressed over time (e.g., according to TTI(s)) in terms of, for example, the scheduling occasion of the HARQ process. For example, HARQ-related feedback can refer to feedback corresponding to a specific transmission associated with the HARQ process.

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

[0113] Feedback type control parameters can be provided (e.g., to the WTRU by a wireless communication network). One or more reference transmissions for a given HARQ process can correspond to transmission x in a sequence i_type . The WTRU can be configured (e.g., a processor programmed with the configuration) to enable and / or change the type of HARQ-related feedback, where the feedback is generated (or starts) for a downlink transmission of the associated HARQ process x i_type The WTRU can be configured (e.g., a processor programmed with the configuration) to control the switching of the type of feedback sent by the WTRU from one type to another. These feedback types can correspond to, for example, DM-based feedback, CSI-based feedback, CB-based feedback, or TB-based feedback.

[0114] The feedback suppression parameter can correspond to, for example, one or more values x threshold(e.g., from a set such as [1, 2, 3, infinity]). A value (e.g., 1, 2, or 3) can indicate, respectively (e.g., for downlink transmission), that the WTRU can refrain from generating HARQ-related feedback and / or reporting for an initial transmission (e.g., suppress until the first transmission), the first retransmission, or the second retransmission. The infinity value can indicate that the WTRU can send HARQ-related feedback only when receiving control signaling that requests such feedback (e.g., explicitly). The suppression parameter can be associated with all types of feedback that can apply to and / or be configured for the associated HARQ process or a specific type that can apply thereto. The type of feedback can correspond to, for example, DM-based feedback, CSI-based feedback, CB-based feedback, or TB-based feedback. The WTRU has a processor programmed to receive a feedback suppression parameter from a wireless communication network, read the feedback suppression parameter, and determine to act according to the received feedback suppression parameter. The wireless communication network can have one or more processors programmed to determine the feedback suppression parameter and send the parameter to the WTRU.

[0115] The configuration can have different granularities. The configuration can be different for uplink HARQ processing and downlink HARQ processing. The HARQ processing can be specific to a given TrCH. The HARQ processing can support transmissions according to different transmission durations (e.g., different numerical configurations), which can generally be referred to as TTIs. The configuration can be supplementary to other (e.g., legacy) parameters (e.g., the maximum number of HARQ transmissions).

[0116] The WTRU can be configured (e.g., for downlink transmission) (e.g., a processor programmed with the configuration) to generate and / or send uplink control information according to the HARQ process state. The state can correspond to an aspect, such as the sequence in transmission for the HARQ process. The state can also correspond to a timing aspect, such as the maximum time for which the HARQ process continues, etc. The state can correspond to, for example, measured or estimated link quality, demodulation performance, or the number of successfully decoded code blocks.

[0117] A feedback method for a subset of resources within a TB (e.g., and / or all resources) described herein can be used to configure a WTRU (e.g., a processor programmed with such configuration). For example, the WTRU can be configured with a set of suppression parameters. For example, one or more (e.g., each) individual suppression parameters can be defined for each sub-TB resource (e.g., each code block, or each group of code blocks) and / or for 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 can be configured with DM-based feedback, while another set of sub-TB resources can be configured with CB-based feedback. The WTRU can be configured (e.g., explicitly) (e.g., a processor programmed with such configuration) to report feedback for a specific subset of sub-TB resources. The WTRU report can correspond to feedback (e.g., DM-based feedback, CSI-based feedback, and / or CB-based feedback as further described below).

[0118] For example, if feedback is expected, the WTRU can expect (e.g., for an uplink transmission) to receive HARQ-related feedback using similar logic. For example, the WTRU can determine (e.g., the processor can determine) the format, content, and / or type of the feedback based on a logic similar to the logic used to generate feedback for a downlink transmission.

[0119] The WTRU processor can receive configuration in downlink control signaling, which can allow for dynamic control of HARQ processing related to feedback.

[0120] The feedback can be based on demodulation (DM) performance. For example, the WTRU processor can generate HARQ-related feedback based on metrics related to demodulation performance

[0121] The WTRU can be configured (e.g., a processor programmed with such configuration) to generate HARQ-related feedback for physical transmission resources.

[0122] A set of physical resources associated with a transmission can be segmented, for example, according to resource regions. The resource regions can correspond to a subset of resources in time, frequency, and / or space of the resources allocated to the transmission. In an example, the resource regions can correspond to a subset of one or more PRBs on a particular symbol (or one or more parts thereof). For example, the resource regions can correspond to a symbol (or a part thereof). The regions can be (e.g., further) associated with one or more demodulation reference signals (DM-RS).

[0123] Different parts of a transmission (e.g., one or more code blocks or transport blocks) can be mapped to multiple resource regions. (E.g., each) part can correspond to a specific region.

[0124] The WTRU may utilize a processor to determine that a downlink transmission is scheduled by using a specific resource allocation. The WTRU may utilize the processor to perform one or more actions upon receipt of the transmission.

[0125] For example (e.g., upon receipt), the WTRU processor may determine that the region(s) for which it has received a transmission may be above a certain reception quality, which may be reported as positive feedback or a measurement. The WTRU processor may determine which regions may otherwise be reported as negative feedback or a measurement. This may be based on, for example, SINR measurements, decoding of individual CBs, or other metrics. The WTRU processor may make a determination based on, for example, relative DM-RS, signal strength, an estimate of how close the WTRU is to successfully decoding a portion of the transmission, based on individual (e.g., failed or successfully decoded) code blocks, etc.

[0126] For example (e.g., upon receipt), the WTRU processor may determine that it has failed to decode one or more (e.g., all) code blocks that may be mapped on a resource region, which may be reported as negative feedback. The WTRU processor may determine that it has successfully decoded one or more (e.g., all) code blocks that are mapped on a resource region, which may be reported as positive feedback.

[0127] For example (e.g., upon receipt), the WTRU processor may determine that the region(s) for which it has received a transmission is above a specific reception quality. The region may correspond to a symbol. The symbol may be reported as good or poor quality, which may be calculated as a function of SINR. For example, poor quality may be reported as negative feedback or as a measurement. For example, good quality may be reported as positive feedback or as a measurement.

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

[0129] In one example, the WTRU processor may (e.g., further) determine that the quality of more than x regions is insufficient. The WTRU processor may report feedback (e.g., to the wireless communication network), i.e., a single report for all regions. The WTRU may use different reporting procedures (e.g., a TB-based procedure or a channel state indicator value). The WTRU processor may (e.g., alternatively) report more granularity (e.g., report to the wireless communication network). The network scheduler may determine a resource allocation with a higher successful decoding probability (e.g., based on the increased granularity).

[0130] For example, assume that demodulation-based measurements can be generated earlier than codeblock-based feedback or TB-based feedback. Reporting may be useful for ultra-low latency services. The SINR measurement may (e.g., further) provide probability information back to the transmitter (e.g., the scheduler). The transmitter may perform a more efficient retransmission, e.g., when operating at an expected operating point (e.g., early in the transmission period of a transport block).

[0131] Feedback reporting based on demodulation performance may provide an indication to the scheduler of the confidence of the WTRU in decoding a TB or a portion of a TB (e.g., sub-TB resources). The confidence (or likelihood or probability) of decoding (e.g., correctly decoding) may be fed back as a quantized value. For example, the WTRU processor may use x bits to report feedback based on demodulation performance. Each code point may correspond to a predefined confidence level.

[0132] Despite having a high confidence in correct decoding, the WTRU may be unable to decode the TB and / or sub-TB resources associated with the reported feedback. For example, after an indication of a high decoding likelihood has been received, the scheduler may not include the TB and / or sub-TB resources in future retransmissions. The WTRU processor may determine to maintain the feedback state (e.g., it may now be an absolute NACK) and / or any stored received soft data. Although no other transmissions (retransmissions) have been received since the previous feedback report, the network may indicate that the WTRU feedback the HARQ value for the TB and / or sub-TB resources. For example, the WTRU processor may receive a first transmission and may 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. This indication that one region has a higher likelihood of correct decoding and the second region has a lower likelihood of correct decoding may trigger the scheduler to retransmit the data for the second region in the first retransmission, and the data for the second region may not be included in the first retransmission. Then, the WTRU processor may determine that the WTRU cannot correctly decode the first region. The wireless communication network may indicate that the WTRU feedback a HARQ report for the first region (e.g., an absolute ACK / NACK type report) after the first retransmission, even though the first region itself may not be included in the first retransmission.

[0133] Feedback based on demodulation performance can be determined according to measurements obtained from demodulation reference signals (DMRS), channel state information reference signals (CSI-RS), other RS, and / or measurements obtained from actual data transmissions. The WTRU processor may be configured with an association between reference measurement (or data measurement) resources and / or HARQ feedback.

[0134] Feedback can 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 its code block group).

[0135] The WTRU processor may determine that feedback may not be generated for one or more code blocks (or resource regions). For example, the determination may be based on signaling and / or determination that the corresponding resources may be subject to interference (e.g., puncturing). For example, this may be useful when the transmitter (e.g., scheduler) may (e.g.) know of preemption (e.g., due to a first transmission of some resources allocated to a second resource). In (e.g., another) example, a transmitter aware of the event may determine that feedback for the preempted CB may be ignored (e.g., applicable to puncturing) or enriched (e.g., applicable to superposition). The WTRU processor may make the determination, for example, based on whether a CRC for (e.g., each) code block is included. This may (e.g., implicitly) indicate a change to the receiver by, for example, discarding or masking the per-CB CRC when the transmitter inserts a CRC at the start of (e.g., each) CB.

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

[0137] The enriched feedback may provide ACK / NACK indications that may be generated for a single CB or for a CB group (CBG). Grouping of CBs may be configured or indicated by control signaling. For example, when TB multiplexing or multiplexing of CBs from different TBs may be supported, the grouping may be based, for example, on CBs mapped to different TBs in the same transmission. The switch between enriched feedback and single-bit feedback may be configured for each HARQ transmission (retransmission) number of a particular HARQ process. The enriched / multi-bit feedback may be determined based on, for example, an explicit index (e.g., CBG index and CBG index plus offset therebetween, or index for each CBG) and / or implicitly (e.g., based on feedback of an index regarding PRB, slot, mini-slot, or symbol) for the CBs that are NACKed. There may be a 1A / N-bit bitmap per CBG. For example, the bundling size may be indicated by a prefix (e.g., a 2-bit prefix mapped to four possible bundling sizes).

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

[0139] The WTRU processor may be configured to generate HARQ-related feedback, e.g., by combining two or more of the foregoing examples (and / or other examples) according to, e.g., HARQ process state and / or DCI request(s) to generate HARQ-related feedback. For example, the WTRU processor may generate different types of feedback: (i) for different HARQ entities (e.g., by configuration); (ii) for different HARQ processes (e.g., via dynamic control signaling, via applicable framing (e.g., time slots or mini-slots)); (iii) for different uplink control channels (e.g., whether the feedback is on a common shared uplink control channel or on a dedicated transmission (with or without other data)); (iv) for different transmissions in a transmission (retransmission) sequence for a given HARQ process; and / or (v) as a function of an applicable soft combining process for the HARQ process.

[0140] The process may provide transmission of receiver feedback. The WTRU processor may be configured to report HARQ-related feedback in one of a plurality of payload arrangements. The feedback reporting process may be applied in conjunction with any of the feedback types described herein, e.g., for link quality-related feedback (DM-based feedback) and / or resource region or code block-related feedback (CB-based feedback).

[0141] Additional information bits may be introduced, e.g., using channel selection. Selecting one resource out of a set of 2 y possible uplink resources for feedback transmission may provide y additional bits of feedback information. In one example, this may be used to indicate the applicable reporting type.

[0142] Pattern-based signaling (e.g., compression process) may be supported and may be based on, e.g., CB, RE, and / or PRB mapping. The WTRU processor may be configured with one or more sets of elements. The elements may be resources (e.g., which form one or more resource regions) and / or code blocks (e.g., which form one or more subsets, e.g., there may be one subset per TB when TB multiplexing is supported for a given transmission). The resource regions and code block groups may or may not map to each other.

[0143] The WTRU processor may (e.g., further) be configured with one or more modes. The modes may correspond to a group including one or more sets of elements. The elements may be represented in one or more modes. (E.g., each) mode may be associated with a code point or identifier.

[0144] For example, a WTRU processor may be configured with modes. In an example, mode 00 may indicate elements 1, 3, 5, and 7 of a transmission (e.g., an element may be an index CB of a transmission or an index resource region of a resource allocation for that transmission). Mode 10 may indicate elements 0, 2, 4, and 6 of a transmission. Mode 01 may indicate elements 0 - 3 of a transmission. Mode 11 may indicate elements 4 - 7 of a transmission.

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

[0146] The size, content, and number of modes may (e.g., further) be a function of dynamic scheduling information (e.g., DCI). For example, the number of possible reporting modes may be a function of the resource allocation size, or the number of code blocks, etc. The determination may be based on a predetermined function.

[0147] A WTRU processor may generate HARQ - related feedback. (E.g., each) mode may indicate what is being reported, or may (e.g., further implicitly) indicate an acknowledgement (positive or negative) of the elements related to the report. In an example, for instance, by selecting a mode (e.g., such a mode that may include all the negatively - acknowledged elements and the fewest possible positively - acknowledged elements) that may minimize the number of unnecessary re - transmissions, the WTRU processor may determine the mode to report in the feedback.

[0148] For example, this may be effective when the network configuration of a WTRU with multiple modes reports may be based on a resource allocation strategy for puncturing events that may be coherent with these modes. For example, coherent modes may include at least one mode corresponding to resources that may (e.g., only) be used for puncturing, and the scheduler may use those resources to schedule puncturing events (e.g., when necessary).

[0149] High - rate channel state information may be provided (e.g., also).

[0150] In (e.g., another) example, a WTRU may receive downlink control signaling that may request feedback, for example, based on the indicated mode (e.g., elements for a related mode).

[0151] In (e.g., another) example, the WTRU may receive downlink control signaling that may request a retransmission, the retransmission including (e.g., including only) elements of the indicated mode, e.g., (e.g., only) code blocks of the relevant mode for the applicable TB. For example, when the transport block size indicated in the control signaling permits, the WTRU processor may determine (e.g., when multiplexing of CBs associated with different TBs is supported) to include these elements. 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.

[0152] In (e.g., another) example, the CBs for retransmission may be derived (e.g., implicitly) based on, for example, the receiver indicating one or more of the following: (i) frequency domain parameters (e.g., index of PRBs, a set of PRBs for each one or more enriched FB processes) and / or (ii) time domain parameters (e.g., index of time slot, mini-slot, symbol). For example, a mini-slot indication may be used to inform the transmitter to retransmit all CBs mapped to the scheduling resources used on that mini-slot.

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

[0154] The WTRU processor may be configured to feedback an HARQ report for a mode (e.g., whole TB, sub-TB, CB group, single CB, etc.), and the report and / or mode may be independent of their presence in the relevant transmission (retransmission). The WTRU processor may be configured to feedback an HARQ report for the CBs (e.g., all CBs) of the original TB after the x-th retransmission (e.g., when only a subset of CBs is included in that x-th retransmission).

[0155] The signaling may be based on the reception status (e.g., suppression process). At least N blocks may be decoded, e.g., to enable combining.

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

[0157] For example, combining of the process may be provided based on the HARQ process state and / or DCI request.

[0158] The WTRU processor may indicate the resources associated with the feedback report.

[0159] The WTRU processor can be signaled to provide feedback for a set of sub-TB resources (e.g., a pattern, a CB group, etc.). The WTRU processor can determine a set of sub-TB resources for which to provide feedback resources (e.g., those sub-TB resources for which the WTRU needs to provide feedback resources). For example, the WTRU processor may have provided confidence-based feedback on some sub-TB resources in the past, and such feedback may still be valid or may no longer be valid. The WTRU processor can determine whether to update the feedback report (e.g., depending on feedback validity). The WTRU processor can 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 can send a confidence-based report for a CB (e.g., each CB) after transmission. The report can indicate the likelihood of correct decoding (e.g., a strong likelihood). The WTRU can be signaled to report feedback for some or all of the CBs for which it previously provided a confidence-based report. In the case where the WTRU processor successfully decodes a CB that the WTRU previously indicated it could successfully decode, the WTRU can determine not to provide updated feedback. If the WTRU processor cannot decode a CB that the WTRU previously indicated it could successfully decode, the WTRU processor can provide the CB identifier and a NACK value. The WTRU can be signaled to provide feedback for all correctly decoded sub-TB resources (e.g., regardless of whether the WTRU has indicated an ACK). The absence of an identifier for a sub-TB resource can be used as an indication of a NACK for that sub-TB resource. The WTRU can be signaled to provide feedback for sub-TB resources whose HARQ ACK / NACK status has changed since its previous feedback report.

[0160] The WTRU processor can be configured to report, for example, according to a first reporting procedure for some transmissions and according to one or more other reporting procedures for other transmissions (which may be for the same HARQ process and / or the same TB). This can be indicated, for example, in the downlink control information and / or dynamically based on the configuration of the WTRU.

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

[0162] For example, when HARQ ACK is applicable, the WTRU processor may (e.g., alternatively) determine that (e.g., a single) bit can be sent for TB-based reporting.

[0163] Figure 2 is an example of a transmission 200 that is punctured 201 due to a URLLC transmission and expects different HARQ feedback types at each retransmission. Figure 2 Different CBs 202, 204, 206, 208, 210, 212 are shown. During the first transmission 200, the second CB 204 and the third 206 CB are punctured to enable the transmission of URLLC (e.g., the transmission of URLLC to another WTRU). The WTRU processor may be configured to report feedback per region. This feedback may be confidence-based (e.g., DM-based) and / or absolute ACK / NACK-based feedback. For example, the WTRU processor may feedback a NACK for the first region and an ACK for the second region. In the first retransmission 214, the WTRU processor receives the CB (e.g., only that CB) for which it has feedback a NACK. The WTRU processor may be configured to perform feedback per CB. The second CB 204 and the third 206 CB may not have a combined gain (e.g., because they were punctured during the first transmission), and thus decoding may fail. In the third retransmission 218, the second and third CBs are transmitted (e.g., only the second and third CBs are transmitted). The WTRU processor may be configured to provide HARQ feedback per TB (e.g., because per-CB feedback may use more resources and the gain associated with granular feedback may be limited due to the number of CBs left to be retransmitted (e.g., few)). The WTRU may have a second retransmission 216. After the third retransmission 218, the WTRU processor may provide a feedback ACK for the TB (e.g., the entire TB), and this may complete the process. In this example, the first feedback may utilize confidence-based feedback. The decoding confidence for the second region may be considered to be very high, but the decoding may have failed, and the TB-based feedback for the second retransmission (216) may be configured for the entire TB or for those sub-TB regions that still have active retransmissions (e.g., not configured for regions without active retransmissions). The WTRU processor may be configured to provide a feedback report for the previous confidence-based reports for different sub-TB regions (e.g., only sub-TB regions with active retransmissions).

[0164] The WTRU processor can be configured to report feedback for a set of DL transmissions. The set of DL transmissions can include transport blocks sent on any combination of the following: multiple component carriers (CCs), multiple bandwidth parts (BWPs), multiple time slots, multiple spatial layers, and / or multiple codewords. A WTRU (e.g., configured with multiple CCs) can have a large and varying amount of feedback to report at any given 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.

[0165] When determining the feedback, the WTRU processor can determine whether the order in which Ack / Nack (A / N) values are assigned in the feedback payload matches the order expected by the network. DCI scheduling data can provide the WTRU with information about the order of the feedback bits within the feedback report. The DCI can include a feedback bit counter DAI (e.g., which can replace the counter Downlink Assignment Index (DAI) or be in addition to that DAI), which can enable the WTRU to determine the order of the DL assignments within the total number of DL assignments that the WTRU might receive). The DAI can indicate to the WTRU one or more of the following: (i) the number of bits required to provide feedback for a DL assignment; (ii) the bit position where the HARQ A / N bits for the DL assignment should be in the feedback report; and / or (iii) the total number of feedback bits included in the feedback report.

[0166] The number of bits required to provide feedback for a DL assignment can be indicated. For example, the feedback can be for CBG-based feedback, and the WTRU processor can be configured with one or more feedback bits per CBG. The number of bits can be fixed on retransmissions of the TB (e.g., regardless of how many CBGs there are in a particular retransmission); can depend on the number of CBGs present in the retransmission; and / or can indicate the number of feedback bits used per CBG feedback report.

[0167] The bit position of the HARQ A / N bits for a DL assignment in the feedback report can be indicated. For example, a network entity can signal this bit position information to the WTRU. For example, a first DL assignment can indicate to the WTRU that the position of the feedback report can start at bit '0'. A second DL assignment can indicate to the WTRU that the position of its feedback report can start at bit '5'. Such an indication can enable the WTRU to know how many bits are required for a NACK in the event that the first DL assignment DCI is lost.

[0168] The total number of feedback bits to be included in the feedback report (e.g., the size of the feedback payload) can be indicated. The WTRU processor can determine the size of the feedback for the missing assignments and can adjust its payload to match the expected order at the network.

[0169] An example of a feedback bit counter is that the WTRU receives a first assignment with a feedback bit counter = 0 and the feedback report within the grant can be 4-bit information. The WTRU can expect that if it receives a second DL assignment, it should have a feedback bit counter = 4. If the WTRU instead receives a DL assignment with a feedback bit counter greater than 4 (e.g., x), the WTRU processor can determine that it has missed an assignment and determine that the WTRU needs x - 4 bits of feedback as NACK to maintain an appropriate feedback report size.

[0170] The feedback bit DAI can be indicated (e.g., explicitly). The feedback bit DAI can be an index pointing to a value table that can be provided to the WTRU semi-statically.

[0171] The feedback bit DAI can be used as a supplement or alternative to the counter DAI in the DL assignment DCI.

[0172] The WTRU processor can determine from the counter DAI that it has missed one or more assignments. The WTRU processor can send a set of bits to the radio communication network that indicate NACK for the maximum feedback size (or a configurable default size) required for the one or more potentially missed assignments. This can result in a mismatch with the expected feedback size at the network. The WTRU processor can indicate to the network that it has missed one or more DL assignments and that padding must be used. The WTRU can indicate padding by using a bit flag. For example, the WTRU can send a single bit to indicate whether the feedback size of the assignment was obtained (explicitly or implicitly) from the DCI, or whether the feedback size is a default value (due to not receiving a DL assignment).

[0173] The WTRU may have missed the last DL assignment (or a set of last assignments). There may be no starting position for the next set of feedback bits. The WTRU processor may not know the number of bits to NACK. The WTRU processor can use the maximum feedback size (or a configurable size). The WTRU processor can indicate (e.g., by using a flag) to the network that padding has been used. The WTRU processor can use multiple bits to indicate the amount of padding.

[0174] When using a mix of slots and mini-slots to schedule data, the WTRU processor can use the DAI counter. The WTRU processor can be scheduled for data transmission on regular slots, mini-slots (e.g., which have different sizes), and aggregated slots. The transmission duration can be configured semi-statically for each component carrier (or for each BWP of a component carrier). The transmission duration can be changed dynamically (e.g., for transmission within a component carrier or within a BWP of a component carrier).

[0175] The counter DAI or the feedback bit DAI can be incremented in any order of BWP, CC, time, and / or codeword. For example, the counter DAI or the feedback bit DAI can be incremented in the manner that BWP is first, CC is second, and time is third. The BWP and CC can be sorted by using an index. The DAI can be incremented with the assignment in the BWP of the first CC, the assignment in the BWP of the second CC, and so on, and move to the next time slot and repeat in the BWP / CC.

[0176] For the case of using different time slot lengths or digital configurations for different BWPs and / or CCs, the incrementing can follow the same rules. For some time instances, some BWPs and / or CCs may have scheduling opportunities. The DAI incrementing can be carried out with the BWP of the CC and with the time scheduling opportunities of the subframe (e.g., time slot, mini-slot, symbol). The DAI incrementing can be carried out with the BWP of the second CC and with the time scheduling opportunities of the subframe (e.g., time slot, mini-slot, symbol), and so on.

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

[0178] Bundling rules can be configured (e.g., to ensure that the feedback bit string assigned for DL can be maintained at a default and / or configurable value). Maintaining a fixed value for the feedback of DL assignments can ensure that there is no ambiguity between what the WTRU intends to send and what the network believes it has received as a feedback report even if some DL assignments are lost. The fixed feedback value for each DL assignment can be less than the maximum value, in which case bundling can be used. The WTRU processor can be configured with a bundling method as described herein to achieve an appropriate feedback value. The feedback bits required for some DL assignments may be less than the fixed value. The WTRU can use repetition of the feedback or can use padding to achieve a fixed feedback bit string value.

[0179] The fixed feedback string value per DL assignment can depend on one or more of the following: (i) the PUCCH resource used for sending the feedback (e.g., PUCCH format, e.g., feedback using a short PUCCH can use a first value while feedback using a long PUCCH can use a second value); (ii) the parameters of the data being transmitted (e.g., URLLC data can have a first feedback bit string value while eMBB can have a second value and / or the numerical configuration configured for a CC or BWP can determine the feedback bit string value); (iii) the number of configured and / or active CCs or BWPs and / or the number of BWPs per CC; and / or (iv) the number of time slots, mini - slots or sub - frames for which the feedback reported in a single report is targeted.

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

[0181] Unequal error protection for the feedback report can be used. For example, the feedback bits of the feedback report can be divided into groups with similar reliability requirements. The feedback bits can be mapped to a specific set of resources of the feedback report - where a set of resources can achieve different reliabilities (e.g., depending on the reliability requirements of the feedback group). For example, the PUCCH can occupy multiple OFDM symbols, and some symbols can be transmitted with a higher power than others. The feedback bits that require a higher reliability can be mapped to the resources in the symbols with a higher transmission power. The feedback that requires a higher reliability can be repeated on multiple resources within the PUCCH resource (e.g., in multiple hops of the PUCCH resource). The feedback that requires a lower reliability can not be repeated on multiple resources within the PUCCH resource.

[0182] Feedback resource selection can be used. For different DL assignments with different requirements, there may be conflicts in the feedback report. The feedback for URLLC can use the first set of PUCCH parameters, while the feedback for eMBB can use the second set of PUCCH parameters. Multiple feedback reports can be multiplexed into a single feedback report. The WTRU can be configured with rules to determine the appropriate PUCCH resources for providing the multiplexed feedback report. For example, the WTRU can use the PUCCH resources associated with any DL assignment multiplexed in the feedback report, and / or the WTRU can use different PUCCH resources to transmit the multiplexed feedback report.

[0183] All or a subset of the feedback report can be multiplexed into a single feedback report. For example, in a case where the resources for reliably transmitting the feedback report of URLLC traffic may be too large such that there are not enough resources available for multiplexing the feedback report of eMBB traffic, a subset of the feedback report can be multiplexed. The WTRU processor can be configured with priority rules to determine what feedback can be included in the feedback report.

[0184] The WTRU processor can use the PUCCH resources indicated in the DL assignment (e.g., the last received DL assignment). For example, if the WTRU is time-division multiplexing the feedback reports for multiple DL assignments, the WTRU can use the PUCCH resources indicated in the DL assignment.

[0185] The WTRU processor can determine the number of information bits (e.g., for setting the transmission power of the report).

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

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

[0188] It may be indicated in the downlink control information (DCI) whether the WTRU reports at the CBG level and / or the 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 bit sequence of the same value (e.g., 0 or 1), where the length of the sequence may correspond to the number of CBGs of the transport block or the maximum number of CBGs, which may be configured by a higher layer. The WTRU processor and the network may determine to use a consistent codebook size. For example, when the WTRU (e.g., by using a counter DAI or other techniques) detects a DL assignment loss, the WTRU processor may include the same number of bits, regardless of whether CBG-level or TB-level feedback is expected. To count the number of HARQ-ACK information bits, the WTRU processor may: (i) count a single (1) HARQ-ACK information bit for the TB of the received PDSCH, where HARQ-ACK at the TB level should be provided based on an indication from the DCI or a higher layer configuration; (ii) count a single (1) HARQ-ACK information bit for the TB of the PDSCH detected as lost (e.g., by using a counter DAI or other techniques), where HARQ-ACK at the TB level should be provided for it based on a higher layer configuration (e.g., regardless of the indication from the DCI); (iii) determine the number of TBs of the PDSCH based on a configuration (e.g., based on whether spatial multiplexing is configured for this PDSCH); (iv) count the NCBG HARQ-ACK information bits for the TB of the received PDSCH (e.g., where NCBG may be the number of CBGs configured for this PDSCH), where HARQ-ACK at the CBG level should be provided for it based on an indication from the DCI or a higher layer configuration; (v) count the NCBG HARQ-ACK information bits for the TB of the PDSCH detected as lost (e.g., by using a counter DAI or other techniques), where the CBG level should be provided for it based on a higher layer configuration; and / or (vi) count the NCBG HARQ-ACK information bits for the TB of the PDSCH detected as lost (e.g., by using a counter DAI or other methods), where the WTRU is configured to determine whether to use the CBG level or the TB level based on an indication in the DCI. Even when using the same codebook size, the WTRU may use sufficient but not excessive transmission power (or resource elements) for the transmission of HARQ-ACKs for multiple PDSCHs including those for the TB level or the CBG level.

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

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

[0191] The remaining CBs can be concatenated and transmitted in adjacent resources of the assigned resource block. For example, in the case of retransmitting CB2 and CB4 of a TB, they can be mapped to adjacent resources (e.g., to the first OFDM symbol of the assigned resources). The mapping of each CB or the concatenated remaining CBs can be explicitly indicated in the assignment for retransmission.

[0192] The WTRU processor can determine the modulation and coding scheme (MCS) for retransmission (e.g., a new MCS compared to the previous transmission and / or previous retransmission). For example, the WTRU processor can obtain the MCS for transmission in order to use a larger number of resources for each retransmitted CBG. The WTRU processor can obtain the MCS from the downlink assignment for CBG retransmission. The WTRU can be configured with a mapping function for the MCS based on one or more of the following: the number of retransmitted CBGs, the original (or previous) number of transmitted CBGs, and / or the original MCS.

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

[0194] The CBGs of a TB can be indexed. In retransmission, the retransmitted CBGs can be sorted by increasing or decreasing the index and can be placed adjacent to each other. This can enable non - punctured data retransmission. If the resource allocation for retransmission is the same as the previous transmission or retransmission (which may have a larger number of CBGs), there may be a mismatch between the required number of resource elements and the resource elements available in the resource allocation. The resource allocation can be adjusted based on the number of CBGs being retransmitted. For example, the WTRU can be configured with a different (possibly smaller) set of PRBs for retransmission, e.g., which can be a subset of the originally transmitted CBGs of the CBGs being retransmitted.

[0195] Code blocks (CBs) or CB groups (CBGs) may be defined by symbols or sets of symbols. For example, CBG mapping may be performed first in the frequency domain and then in the time domain (e.g., frequency-first mapping). For example, resource allocation may span 7 symbols (e.g., in time), and each of the 7 CBs or CBGs may span each subcarrier 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, and so on). Transmission may be configured such that no code block / CBG may span multiple symbols, and each symbol may include one or more code blocks / CBGs (e.g., each symbol may have an integer number of code blocks / CBGs). This may attempt to ensure that interference events occurring over an integer number of symbols have no negative impact on the code blocks transmitted in adjacent symbols. The size of a code block may depend on the frequency span of the resource allocation. In a retransmission using reduced resource allocation, a code block or CBG of the first transmission may be allowed to span multiple symbols. A WTRU may be configured to expect the transmitted CBG (and / or CB) to be re-segmented into a set of (e.g., new) CBGs (and / or CBs). For example, in a first transmission, a first code block may occupy the entire transmission bandwidth in a first symbol. In a retransmission over a reduced number of PRBs, the code block may now span two symbols. The code block may be segmented into two smaller code blocks, each spanning the frequency allocation of a single symbol. When the WTRU feeds back HARQ A / N for the retransmission, the code block segmentation may be taken into account. For example, the HARQ A / N may be a common feedback for the two new code blocks, and / or separate HARQ A / N feedback may be sent for each new code block.

[0196] The number of CBGs and / or the number of CBs per CBG, as well as the resource mapping of CB / CBG, can depend on the allocation (e.g., the size of the frequency allocation, the slot size, etc.) and possibly some rules. These rules can be fixed or configurable by the network (and / or a combination of fixed and configurable). The number of CBGs can be obtained according to a one-to-one mapping with the number of symbols in the allocation. For example, a WTRU scheduled with data on a slot size of x symbols can assume y CBGs, where y = fct(x). For example, y = x, and each symbol is used for a single CBG. The number of CBGs can depend on the total number of subcarriers z. For example, if the number of subcarriers z is greater than a threshold, a CBG can consist of resource elements of some or all of the symbols. If z is less than the threshold, a CBG can span multiple symbols. For example, when the interference is bursty in the time domain rather than in the frequency domain, it may be beneficial for a CBG to span as few symbols as possible. For example, the number of symbols (defined as s) spanned by a CBG can be obtained as s = floor(minimum_CBG_length / z), where minimum_CBG_length (the minimum CBG length) can be fixed or configurable. In some cases, the frequency allocation z can be greater than a second threshold (e.g., t2), and in this case, multiple CBGs can be mapped to a single symbol. The total number of subcarriers z can be evenly divided among multiple CBGs. In an example, the CBG mapping on a symbol can 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 can be determined by y_s = ceiling(z / t2).

[0197] For example, in the case where a CBG consists of a single CB, the CB mapping can be similar to the CBG mapping. The CB-to-CBG mapping can be obtained according to the number of subcarriers and / or OFDM symbols assigned to each CBG. For example, the number of CBs in a CBG can be obtained according to the number of resource elements assigned to the CBG (e.g., if the assignment is continuous in time and frequency, the total number of subcarriers multiplied by the number of OFDM symbols). The resource elements assigned to a CBG can be evenly divided among a fixed number of CBs, or can be calculated in such a way that allows the maximum number of CBs to have the maximum length. For example, the number of CBs n in a CBG can be determined according to the maximum CB length (max_CB_length) and the total number of resource elements w in the CBG, such that n = ceiling(w / max_CB_length).

[0198] In one example, the TB can be partitioned into CBs in such a way that most of the CBs can have the maximum CB length. The set of CBs can then be grouped into CBGs. This grouping can be done in a way that reduces the number of symbols spanned by the CBG. For example, the CB-to-RE mapping and the CB-to-CBG mapping can be done first in frequency and then in time (e.g., first across the subcarriers of the first symbol, then across the subcarriers of the second symbol, and so on). If the CBG does not already include another CB mapped to multiple symbols, the CB mapped to multiple symbols can be grouped within that CBG.

[0199] In one example, a CBG can span several symbols in the time domain while occupying a more limited bandwidth in the frequency domain. This scenario can occur, for example, in the following cases: (i) when interference may (e.g., is expected to) span a bandwidth that may be smaller than the bandwidth that can be allocated for transmission and / or (ii) when multiple pre-emptive transmissions (e.g., which have a limited bandwidth and one or more finite durations) may occur or are occurring. The scheduler can (e.g., in the latter case) make a choice to allocate multiple pre-emptive transmissions within the resources that can be occupied by (e.g., a single) CBG, which can minimize the number of CBGs (e.g., the number required) to be retransmitted. Exemplary mappings are shown in Figure 3 and 4 are shown.

[0200] Figure 3 is an example of a CBG that spans multiple CBs in the time domain. In the example (e.g., as shown in Figure 3 ), the number of CBs spanned by the CBG in the frequency domain can be F = 1.

[0201] Figure 4 is an example of a CBG that spans multiple CBs in the time domain. In the example (e.g., as shown in Figure 3 ), the number of CBs spanned by the CBG in the frequency domain can be F = 2.

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

[0203] The optimal process for mapping CBs to CBGs may vary according to, for example, interference and channel conditions, the probability of pre-emptive transmissions occurring, etc. The mapping may be determined using, for example, one or more of the aforementioned parameters and / or other parameters. 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. One or more parameters may (e.g., also may) be indicated in a field of the DCI that may be associated with the transmission, for example, to allow the mapping to be more dynamically adapted to the channel and traffic conditions.

[0204] A non-uniform CB-to-CBG mapping may be provided. In an example, the CB-to-CBG mapping may be configured such that the number of CBs per CBG for one or more CBGs may be significantly less than that of other CBGs. Such CBGs may be referred to as, for example, "underloaded" CBGs. In one example (e.g., when it may be necessary to schedule pre-emptive transmissions), the scheduler may preferentially pre-empt resources that may be occupied by code blocks of underloaded CBGs and may preferentially avoid pre-empting resources that may be occupied by code blocks of other CBGs. In the case of a pre-emption occurring, the method may minimize the number of CBs that may need to be retransmitted. Underloaded CBGs and / or the CBs that may be mapped to underloaded CBGs may occupy resources that may be extended in the time domain, for example, to maximize the chance that the scheduler may find resources that may be occupied by underloaded CBGs (e.g., independent of the time of the pre-emptive transmission). Figure 5 An example is shown in.

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

[0206] Figure 5 is an example of a non - uniform CB to CBG mapping that allows minimizing the re - transmitted CBs in case of pre - emption. In the example, (e.g., each) rectangle can represent a CB. CBG #4, #5, and #6 may be under - loaded. In the example, it may be necessary to schedule high - priority traffic on a micro - slot with 2 symbols. For example, depending on the timing of the high - priority transmission, the scheduler can choose to schedule the transmission on the resources of CBG #4, #5, or #6. In one example, only 2 CBs may need to (e.g., subsequently) be re - transmitted for the TB.

[0207] For example, the WTRU processor can be configured with one or more of the following parameters (e.g., to determine an appropriate mapping): (i) the target number of CBs for an under - loaded CBG; (ii) the target number of CBs for a normal (not under - loaded) CBG; and / or (iii) an indication regarding the CBs that are to be mapped to an under - loaded CBG. For example, the indication can include a set of resources that can be assigned to the CB (e.g., in the frequency domain and / or time domain). For example, the indication can include an explicit list of the CBs. For example, the indication can include at least one parameter that can be used in a formula (from which the CB to CBG mapping for normal CBGs and under - loaded CBGs can be derived).

[0208] A CB to CBG mapping indication can be provided. The WTRU processor can be configured with multiple CB to CBG mappings (e.g., uniform and non - uniform). For example, upon receiving an indication from the network, the WTRU processor can determine which mapping can (e.g., should) be used.

[0209] An explicit indication can be provided to the WTRU by a wireless communication network. In an example, the WTRU processor can receive an explicit indication that can point to (e.g., one) a configured mapping. For example, DCI signaling can be used to send the indication. For example, the indication can be sent at the start of a time slot / micro-slot. The DCI can be common (e.g., group common PDCCH or within a group common search space) or WTRU-specific.

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

[0211] In an example of the preemption indication, the WTRU can receive information about the frequency / time resources being preempted. The WTRU can group the CBs according to the indication. In an example of a WTRU that may be configured with 2 CBGs, for example, when the WTRU may not receive a preemption indication, the WTRU can map the CBs evenly to the CBGs. The WTRU can receive a preemption indication. The WTRU can map the CBs within the frequency / time resources that may be preempted (e.g., according to the preemption indication) to the first CBG and the remaining CBs to the second CBG.

[0212] In an example of the indication about potential preemption resources, the WTRU processor can be configured (e.g., by the indication) with the resources (e.g., potential) that will be used for preemption. The WTRU can map the CBs within the indicated resources to separate CBG(s). In an example, the WTRU processor can be configured with K potential resources for preemption and N CBGs, where K can be less than N (e.g., K < N). For example, the first K CBGs can be formed by the CBs that can respectively correspond to the K potential resources. The remaining (e.g., N - K) CBGs can be formed, for example, evenly from the other CBs.

[0213] In an example of the time pattern indication, the WTRU processor can apply a (e.g., one) configured mapping according to the time pattern. In an example of "bad" channels that can be time-related, the CBs with bad channel conditions can be grouped into (e.g., one) CBG, while the remaining CBs can be grouped (e.g., evenly) into other CBGs.

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

[0215] The WTRU processor can be configured with DL control channel occasions to monitor scheduling assignments (e.g., DCI). For example, the WTRU can be configured with DL control channel occasions that occur periodically, which may be associated with a fixed slot size (e.g., a regular slot size). To efficiently use mini-slots for retransmission, it may be beneficial to schedule sub-TB retransmissions of multiple WTRUs in adjacent mini-slots. The WTRU processor can be indicated by the radio communication network in the DCI for retransmission the offset in terms of symbols (or mini-slots) between the DCI and the data. For example, the WTRU processor can be scheduled for a transmission that may have a shorter duration at its regular DL control channel occasion (e.g., at the start of a regular slot). Another WTRU processor can also be scheduled at its regular DL control channel occasion, however, this WTRU can be indicated the symbol offset for the start of its DL assignment for sub-TB retransmission.

[0216] The WTRU processor can be configured with a first set of DL control channel occasions for scheduling a first transmission and / or full-TB retransmission, and a second set of DL control channel occasions for scheduling sub-TB retransmissions. The second set of DL control channel occasions can enable mini-slot scheduling with a greater number of possible starting symbols.

[0217] To save power, the WTRU processor may monitor (e.g., only) the first set of DL control channel opportunities until it is instructed to monitor the second set of DL control channel opportunities or autonomously determines to monitor the second set of DL control channel opportunities. For example, the WTRU processor may be notified by the wireless communication network in the DCI in the first DL control channel opportunity to start monitoring the second set of DL control channel opportunities. In an example, the WTRU may start monitoring the second set of DL control channel opportunities when it receives a preemption indication from the gNB. The preemption indication may be received by the WTRU in the first set of DL control channel opportunities (possibly in the next DL control channel opportunity that occurs immediately after the preemption). The first DL channel opportunity of the second set that the WTRU processor may monitor may be the first DL channel opportunity after receiving the preemption indication, or may occur at a (e.g., configurable) time offset after receiving the preemption indication. In an example where the WTRU autonomously determines, once the sub-TB HARQ that would have a mix of ACK and NACK in the feedback, the WTRU may start monitoring the second set of DL control channel opportunities. For example, if the WTRU feeds back an ACK for a CBG subset (e.g., some CBGs are NACK), the WTRU processor may start monitoring the second set of DL control channel opportunities (e.g., to enable mini-slot scheduling for CBG retransmissions). The WTRU may monitor the second set of DL control channel opportunities until it is instructed by the gNB to stop. The WTRU may monitor the second set of DL control channel opportunities until the retransmission of one or more HARQ processes that triggered the monitoring is complete.

[0218] The second set of DL control channel opportunities may be differentiated from the first set of DL control channel opportunities by one or more of the following: (i) different opportunities in time (e.g., different symbol positions within a timeline, or different positions within a subframe); (ii) different positions in frequency; (iii) different control resource sets (CORESETs); (iv) different subsets of search spaces within a CORESET; and / or (v) different beams. For example, the 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).

[0219] After being instructed or autonomously determining to switch to the second set of DL control channel opportunities, the WTRU may expect any downlink assignments (for first transmissions or retransmissions) sent within that set of DL control channel opportunities. For example, the second set of DL control channel opportunities may be a superset that includes the first set of DL control channel opportunities. The WTRU processor may be configured to keep the total number of blind decoding attempts fixed for each time period. Once the opportunities for the DL control channels are increased in time, the WTRU may reduce them in frequency, CORESET, and / or search space.

[0220] After cascading and mapping the CBs to a smaller symbol set, the scheduler can leave the remaining resources unused (e.g., blank). The scheduler can adjust the slot size to the number of CBs to be retransmitted. The scheduler can limit the amount of unused resources, and this can improve spectral efficiency.

[0221] The scheduler can include a new TB (or a set of sub-TB resources of a new TB) in the remaining unused resources. The new sub-TB resources can belong to the same TB of the new TB or an ongoing HARQ process. As an example of new sub-TB resources belonging to a new TB, a DL transmission can include CBs of a first TB that are retransmitted together with CBs of a second TB (e.g., which are being sent for the first time, or are being retransmitted but have a different retransmission number TB (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 can include a subset of CBs of a TB (e.g., all CBs), and a retransmission can include a combination of retransmitted CBs from the first transmission and a set of CBs that are being transmitted for the first time and also belong to the same TB. A TB can be mapped to multiple slots, and the retransmission number of each CB per slot can be independent.

[0222] A WTRU processor (e.g., where slots are used to send different parts of different TBs) can be configured to provide HARQ feedback for any of the following: parts of each TB (e.g., sub-TB feedback similar to CB group-level feedback), each TB (e.g., per-TB feedback for each TB), and / or bundled TBs (e.g., multiplexed feedback for some or all of the TBs included in a slot). The HARQ feedback method for a single TB per slot can be repeated for multiple TBs per slot. For example, the WTRU can provide WTRU-selected feedback by sending feedback only for the TBs with ACKs within the slot.

[0223] An indication of the CBG index for retransmission can be used. There may be a mismatch between the CBG for which the WTRU is feeding back a NACK and the CBG being retransmitted. This mismatch may be due to incorrect decoding of the HARQ feedback by the gNB or a mismatch of the available resources available for retransmission (which may prevent the WTRU from receiving all retransmitted CBGs in a single retransmission). Thus, the CBG being retransmitted can be indicated in the downlink assignment (e.g., DCI) for retransmission.

[0224] The bitmap covering the original CBGs included in the TB can be included in the retransmission scheduling assignment. Each bit in the bitmap can indicate whether a particular CBG is included in the retransmission. For large transmission bandwidths that require a large number of CBGs, this may be prohibited. When re-segmenting CBGs for retransmission, the bitmap may need to be more adaptive. For example, the total number of CBGs sent (retransmitted) can be indicated to the WTRU, and the WTRU can be enabled to correctly interpret the CBG bitmap.

[0225] Implicit numbering of CBG indices in the first transmission (e.g., based on a frequency-first and time-second transmission order) and explicit indication of CBG indices for retransmission can be used. Compression methods such as those discussed for CBG-based feedback (e.g., pattern-based) can be reused for indicating the CBGs for retransmission.

[0226] The WTRU can receive an indication for retransmitting a CBG. Such an indication can include the CBG index and may include an offset value. The offset value can indicate to the WTRU processor the starting point within the CBG where the retransmission is being performed (e.g., a resource element or a CB). The WTRU may not expect retransmission of any REs of the CBG before the point indicated by the offset value.

[0227] The timing between transmission, retransmission, and HARQ feedback can be used. The timing relationship between transmission and HARQ feedback for that transmission can be indicated in the scheduling assignment. The timing can be in units of the slot size used for scheduling the transmission. However, in cases where the size of the slot for retransmission is different from the slot for the previous transmission (retransmission) of the same HARQ process, there may be an inconsistency in the interpretation of the timing offset. The timing offset between the transmission (retransmission) indicated to the WTRU and its HARQ feedback can always be in units of the slot size of the original transmission for the HARQ process or in units of the slot size of the corresponding transmission (retransmission) associated with the HARQ feedback. The timing offset between the feedback for the transmission (retransmission) and the first DL control channel occasion where the WTRU can receive scheduling from the wireless communication network for another retransmission of the HARQ process can also be in units of the slot size of the original transmission or the most recent transmission (retransmission).

[0228] Soft combining of the transmitted (retransmitted) soft data may be beneficial and / or may improve decoding performance. The WTRU may be instructed by the wireless communication network whether a retransmitted CB (or sub-TB resource) may be combined with one or more previous transmissions (retransmissions) of that CB (or sub-TB resource). A subset of the retransmitted CBs may be suitable for combining with the same CBs transmitted in a first subset of previous transmissions (retransmissions) (e.g., all previous transmissions (retransmissions)). Another subset may be combined with a second subset of previous transmissions (retransmissions). For example, the WTRU may receive from the wireless communication network the original transmission and the first retransmission of a set of CBs. Upon receiving the second retransmission of the same set of CBs, the wireless communication network may instruct the WTRU that it may combine a subset of that CB with the CBs received in the original transmission (e.g., only combine with them) (e.g., not combine with those received in the first retransmission). This may be beneficial if puncturing of a subset of the CBs occurred in the first retransmission. Combining with the punctured resources may degrade the BER performance and may result in an unnecessary large number of retransmissions (or a completely failed transmission).

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

[0230] The WTRU processor may determine (e.g., autonomously determine) a set of transmissions (retransmissions) for which the WTRU may perform soft combining (e.g., per sub-TB (e.g., CB) resource). For example, the WTRU processor may use a subset of transmissions (retransmissions) based on the 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 for which the WTRU performed measurements.

[0231] UL retransmissions of CBGs may be performed by the WTRU processor.

[0232] The WTRU processor may (e.g., be required to) retransmit a subset of the CBGs sent in a previous transmission to the wireless communication network. The methods described herein for DL retransmissions of CBGs may also apply to UL retransmissions of CBGs. Thus, the methods described herein with respect to DL may equally apply to UL, and these examples are not meant to be limited to a particular transmission direction.

[0233] When the WTRU leaves blank the resources of a CBG that has not been retransmitted, the WTRU processor may reallocate power to another ongoing transmission. For example, due to carrier aggregation or dual connectivity, the WTRU may have multiple UL transmissions. UL power control may depend on the number of active transmissions. The WTRU processor may consider all active transmissions in a symbol to determine the appropriate power sharing between different UL transmissions. Due to the zero-power transmission of some CBGs on a carrier, different parts of the transmission on other carriers are allocated different transmission powers. For example, if zero-power transmission of a CBG on a first carrier is being performed, the WTRU processor may allocate the power that is normally used for the first carrier to the transmission on a second carrier.

[0234] An uplink interference preemption indication may be provided. The indication may include interference / preemption within the WTRU.

[0235] In an example, high-priority / low-latency data may arrive at the WTRU buffer. For example, even after the network may have received part of the low-priority data in a certain time slot, the WTRU processor may interrupt the ongoing uplink transmission for the lower-priority data. This type of event may be referred to as "uplink preemption" within the WTRU, where multiple transmissions originate from the same WTRU.

[0236] For example, the WTRU processor may notify the network of the uplink preemption, so that the network can be aware that a part of the data sent in (e.g., the current) time slot can be used for a different transmission of higher-priority data. The network (e.g., which has been notified of the uplink preemption by the WTRU) may discard the lower-priority data that may have been sent on the interfered resources. This may be referred to as a preemption indication. The receiver may use the preemption indication, for example, to manage its HARQ soft buffer. In an example, the receiver may choose to flush or discard the data that may have been received on the indicated part for the low-priority transmission. For example, when a (e.g., subsequent) transmission can be received for the interfered data part, the receiver may (e.g., also) use the indication.

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

[0238] A preemption indication may be sent, for example, using a new UCI field within the PUSCH channel. For example, the UCI may be sent before or after preemption occurs. In (e.g., additional or alternative) examples, a (e.g., special) control channel (e.g., specific to high-priority transmissions) may carry an indication, for example, before or after a preemption event. In an example, a preloaded PUCCH may accompany a high-priority transmission, which may include an indication.

[0239] For example, by masking an additional CRC or by adding (e.g., special) bits, preemption may (e.g., also) be an encoded part of a CB or CBG, e.g., to convey to a receiver that a CB or CBG may be (e.g., is being) preempted.

[0240] A WTRU may (e.g., also) use, for example, an in-band indication to indicate a preemption event, which may be linked to the type of uplink resource (e.g., semi-persistent, grant-free, or scheduled) that may be used to send high-priority data.

[0241] The indication may include WTRU-to-WTRU interference / preemption.

[0242] In an example, a WTRU may not have sufficient resources to send higher-priority data. The WTRU may occupy and preempt resources used by other WTRUs that may be sending ongoing lower-priority data. For example, interference may be indicated to other WTRUs that are occupying the medium so that they may temporarily abort their ongoing lower-priority data transmissions. This may be referred to as, for example, "WTRU-to-WTRU uplink preemption indication".

[0243] For example, WTRU-to-WTRU uplink preemption indication may be implemented by allowing multiple WTRUs to use resource blocks for both low-priority and high-priority data. For example, in a high cell load scenario where resources may be occupied by lower-priority data, preemption indication may be useful.

[0244] WTRU-to-WTRU uplink preemption indication may be attached to, for example, (e.g., each) resource. In an example, for example, (e.g., only when) used to send higher-priority data, an RS may be sent on a portion of a PRB to occupy it. A WTRU that may be using a shared resource may, for example, check whether the resource may be used by a higher-priority WTRU (e.g., by sensing or decoding an RS that may be unique to each resource) before occupying the medium. For example, a network node may (e.g., additionally or alternatively) mark the use of a resource to other (e.g., hidden) WTRUs that may not detect the use of the resource by sending an RS (e.g., masked by its cell ID) from the serving cell or by transmitting information on a downlink control channel.

[0245] Inter-WTRU uplink preemption indication may be indicated in different procedures. For example, preemption may be indicated without blocking a portion of the shared resources (e.g., individually). In an example, the inter-WTRU uplink preemption indication may occur on or be sent with the uplink control information (e.g., on the UCI portion of the PUSCH or on the PUCCH). The network may then (e.g.) indicate other WTRUs that may (e.g., seek to) occupy the medium to avoid or suspend their transmission(s). This may be conveyed, for example, on the downlink control channel. For example, when the medium may no longer be occupied (e.g., for one or more high-priority transmissions), when the configured suspension timer expires, and / or when signaled by the network, a WTRU with an interrupted transmission may resume the transmission of its lower-priority data.

[0246] Each computing system described herein may have one or more computer processors (with a memory configured with executable instructions) or hardware to implement the functions described herein, which functions include determining the parameters described herein and sending and receiving messages between entities (e.g., WTRUs and networks) to accomplish the described functions. The above processes may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor.

[0247] Systems, methods, and means for receiver feedback in a wireless system have been disclosed. Receiver feedback format, content, type, and / or timing may be determined according to, for example, a hybrid automatic repeat request (HARQ) processing state corresponding to, for example, the following: the transmission sequence of the HARQ process, the maximum time for which the HARQ process continues, the measured or estimated link quality, the demodulation performance, and / or the number of successfully decoded code blocks. Receiver feedback format, content, type, and / or timing may be determined according to, for example, the configuration of a wireless transmit / receive unit (WTRU) that indicates at least one of the following: the type of soft combination processing to be applied in the HARQ process, the HARQ operating point for the HARQ process, one or more reference transmissions for the type of HARQ feedback to control the HARQ process, and the feedback suppression parameter for one or more transmissions in the sequence associated with the HARQ process or transmission block (TB). Uniform and non-uniform CB to CBG mapping may be provided (e.g., by the WTRU) based on, for example, one or more parameters, interference and channel conditions, and / or the probability of an actual preemption transmission. A CB to CBG mapping indication may be provided, for example, to support the selection of a CB to CBG mapping from multiple CB to CBG mappings. Interference / preemption indication within and between WTRUs may be provided.

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

[0249] A WTRU can refer to an identifier of a physical device or an identifier of a user, such as a subscription-related identifier, such as an MSISDN, a SIP URI, etc. A WTRU can refer to an application-based identifier, e.g., a user name that can be used for each application.

[0250] The functions described herein can be implemented on, for example, a UR-LLC communication channel between a WTRU and a wireless communication system. The WTRU and the wireless communication system can have one or more computer processors that are configured (e.g., programmed with executable instructions) to perform the functions as described herein. For example, the WTRU can have a processor configured to communicate with a wireless communication network (e.g., by using UR-LLC communication). The WTRU processor can be configured to receive first downlink control information (DCI) that indicates whether HARQ feedback based on a transport block (TB) should be provided for a downlink transmission, or whether HARQ feedback based on a codeblock group (CBG) should be provided for the downlink transmission. The WTRU processor can be configured to receive a downlink transmission associated with the first DCI, the downlink transmission including a transport block having one or more codeblocks. The WTRU processor can be configured to attempt to decode one or more codeblocks of the transport block. The WTRU processor can be configured to determine that the first DCI indicates that HARQ feedback based on a CBG should be provided. If the processor determines that the first DCI indicates that HARQ feedback based on a CBG should be provided, the WTRU processor can be configured to determine a mapping of the one or more codeblocks to one or more CBGs; determine HARQ feedback for at least one of the one or more CBGs based on whether the corresponding codeblocks of at least one of the one or more CBGs are successfully decoded, and send the HARQ feedback for the one or more CBGs to the wireless communication network. The WTRU processor can be configured to determine that the first DCI indicates that HARQ feedback based on a TB should be provided. If the WTRU processor determines that the first DCI indicates that HARQ feedback based on a TB should be provided, the WTRU processor can be configured to determine HARQ feedback for the transport block and send the HARQ feedback for the transport block to the wireless communication network.

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

[0252] If each of the corresponding code blocks is successfully decoded, the determined HARQ feedback for the one or more CBGs may be ACK, and if one or more of the one or more code blocks are not successfully decoded, the determined HARQ feedback for the one or more CBGs may be NACK. The WTRU processor may be configured to receive a retransmission from the wireless communication network in response to the sent NACK. The wireless communication network may have a processor configured to receive the sent ACK or NACK and, if a NACK is received, determine to send a retransmission.

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

[0254] The WTRU processor may be configured to monitor a first downlink control information and monitor a second downlink control information based on a pre-emption instruction from the wireless communication network. The wireless communication network may have a processor configured to determine to send a pre-emption instruction to the WTRU.

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

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

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

[0258] Each computing system described herein may have one or more computer processors (having a memory configured with executable instructions) or hardware to implement the functions described herein, the functions including determining the parameters described herein and sending and receiving messages between entities (e.g., WTRUs and networks) to complete the described functions. The processes described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor.

[0259] The processing described above may be implemented in a computer program, software, and / or firmware embodied in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, buffer memories, semiconductor memory devices, magnetic media (e.g., internal hard disks and removable disks), magneto-optical media, and / or optical media (e.g., CD-ROM disks and / or digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit / receive unit, comprising, a processor and a transceiver, which are configured to: receive first downlink control information (DCI) associated with a first downlink transmission comprising at least one transport block (TB); receive the first downlink transmission comprising the at least one TB, the at least one TB comprising one or more codeblock groups (CBGs), wherein each CBG comprises one or more codeblocks (CBs); transmit first CB-based hybrid automatic repeat request (HARQ) feedback associated with the first downlink transmission in a case where the first DCI indicates that CB-based type HARQ feedback is to be provided for the first downlink transmission; receive second DCI associated with a second downlink transmission, wherein the second DCI indicates that the second downlink transmission comprises a retransmission of at least a portion of the first downlink transmission, and the second DCI comprises a bitmap indicating which of the CBGs in the first downlink transmission are included in the retransmission; receive the second downlink transmission, which comprises at least the portion of the first downlink transmission; and transmit second CB-based HARQ feedback associated with the second downlink transmission in a case where the second DCI indicates that the CB-based type HARQ feedback is to be provided for the second downlink transmission.

2. The wireless transmit / receive unit according to claim 1, wherein the first downlink transmission or the second downlink transmission is associated with a first HARQ process.

3. The wireless transmit / receive unit according to claim 1, wherein the processor is further configured to determine a mapping of the one or more codeblocks to the one or more CBGs in at least one of frequency or time, and wherein the first downlink transmission and / or the second downlink transmission is received by using the mapping.

4. The wireless transmit / receive unit according to claim 1, wherein the first CB-based HARQ feedback comprises an acknowledgement (ACK) for each of the CBGs in the first downlink transmission that is successfully decoded, and comprises a negative acknowledgement (NACK) for each of the CBGs in the first downlink transmission that is not successfully decoded.

5. The wireless transmit / receive unit according to claim 1, wherein the second CB-based HARQ feedback comprises an acknowledgement (ACK) for each of the CBGs in the second downlink transmission that is successfully decoded, and comprises a negative acknowledgement (NACK) for each of the CBGs in the second downlink transmission that is not successfully decoded.

6. The wireless transmit / receive unit according to claim 1, wherein the second DCI indicates which of the CBGs included in the retransmission can be combined with previously received CBGs when performing soft decoding.

7. The wireless transmit / receive unit according to claim 1, wherein the second DCI includes information indicating that when soft decoding is performed, the CBG included in the retransmission can be combined with a previously received CBG.

8. The wireless transmit / receive unit according to claim 3, wherein the mapping is based on one or more of the following: the number of subcarriers or OFDM symbols assigned to the one or more CBGs, the maximum codeblock length, the number of codeblock groups in the first downlink transmission, the number of codeblocks in the first downlink transmission, and the number of time symbols occupied by a potential pre-emptive transmission, and / or the number of resource blocks occupied by the potential pre-emptive transmission.

9. The wireless transmit / receive unit according to claim 1, wherein the processor and the transceiver are further configured to monitor the first DCI and the second DCI based on a pre-emption instruction from a wireless communication network.

10. The wireless transmit / receive unit according to claim 1, further comprising a HARQ buffer, and wherein the processor is further configured to manage the HARQ buffer and discard data in the HARQ buffer based on the second DCI.

11. The wireless transmit / receive unit according to claim 1, wherein the processor is further configured to determine a pre-emption indication to be sent to the wireless communication network in uplink control information if the one or more codeblocks are not successfully decoded.

12. A method of sending feedback, the method comprising: receiving first downlink control information (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 one or more codeblock groups (CBGs), wherein each CBG includes one or more codeblocks (CBs); sending first CB-based HARQ feedback associated with the first downlink transmission in a case where the first DCI indicates that CB-based hybrid automatic repeat request (HARQ) feedback is to be provided for the first downlink transmission; receiving second DCI associated with a second downlink transmission, wherein the second DCI indicates that the second downlink transmission includes a retransmission of at least a portion of the first downlink transmission, and the second DCI includes a bitmap indicating which of the CBGs of the first downlink transmission are included in the retransmission; receiving the second downlink transmission, the second downlink transmission including at least the portion of the first downlink transmission; and sending second CB-based HARQ feedback for the second downlink transmission in a case where the second DCI indicates that the CB-based type of HARQ feedback is to be provided for the second downlink transmission.

13. The method according to claim 12, wherein the first downlink transmission or the second downlink transmission is associated with a first HARQ process.

14. The method according to claim 12, further comprising: Determine the mapping of the one or more code blocks to one or more CBGs in at least one of frequency or time, and wherein the first downlink transmission and / or the second downlink transmission is received by using the mapping.

15. The method according to claim 12, wherein the first CB-based HARQ feedback comprises an acknowledgment (ACK) for each of the CBGs in the first downlink transmission that is successfully decoded, and comprises a negative acknowledgment (NACK) for each of the CBGs in the first downlink transmission that is not successfully decoded.

16. The method according to claim 12, wherein the second CB-based HARQ feedback comprises an acknowledgment (ACK) for each of the CBGs in the second downlink transmission that is successfully decoded, and comprises a negative acknowledgment (NACK) for each of the CBGs in the second downlink transmission that is not successfully decoded.

17. The method according to claim 12, wherein the second DCI indicates which of the CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding.

18. The method according to claim 12, wherein the second DCI comprises information indicating that the CBGs included in the retransmission can be combined with a previously received CBG when performing soft decoding.

19. The method according to claim 14, wherein the mapping is based on one or more of the following: the number of subcarriers or OFDM symbols assigned to the one or more CBGs, the maximum code block length, the number of code block groups in the first downlink transmission, the number of code blocks in the first downlink transmission, and the number of time symbols occupied by a potential pre-emptive transmission, and / or the number of resource blocks occupied by the potential pre-emptive transmission.

20. The method according to claim 12, further comprising: monitoring the first DCI and the second DCI based on a pre-emption instruction from a wireless communication network.

21. The method according to claim 12, further comprising: managing the data of the first downlink transmission in a HARQ buffer; and discarding the data in the HARQ buffer based on the second DCI.

22. The method according to claim 12, further comprising: determining a pre-emption indication to be sent to the wireless communication network in uplink control information if the one or more code blocks are not successfully decoded.

Images