阅读说明：本技术 Harq-ack码本自适应 (HARQ-ACK codebook adaptation ) 是由 阿塔·埃尔哈姆斯 N·S·纳伊卜 于 2020-02-12 设计创作，主要内容包括：本发明公开了可与HARQ-ACK码本自适应相关联的系统、方法和手段。WTRU可被配置为在时隙中具有多个物理上行链路信道,例如物理上行链路控制信道(PUCCH)。每个物理上行链路信道可具有相应的HARQ-ACK码本。在示例中,该WTRU可以确定第一物理上行链路信道和第二物理上行链路信道在时隙中重叠。在这种情况下,该WTRU可以确定与该第一物理上行链路信道相关联的第一HARQ-ACK码本具有比与该第二物理上行链路信道相关联的第二HARQ-ACK码本更高的优先级。该WTRU可以在该时隙中的该第一物理上行链路信道上传输该第一HARQ-ACK码本。该WTRU可以在该时隙中传输该第二HARQ-ACK码本的一部分,并且在后续时隙(例如,下一个时隙、未来时隙等)中传输该第二HARQ-ACK码本的一部分。(Systems, methods, and instrumentalities are disclosed that may be associated with HARQ-ACK codebook adaptation. A WTRU may be configured with multiple physical uplink channels, such as a Physical Uplink Control Channel (PUCCH), in a slot. Each physical uplink channel may have a corresponding HARQ-ACK codebook. In an example, the WTRU may determine that the first physical uplink channel and the second physical uplink channel overlap in a time slot. In this case, the WTRU may determine that a first HARQ-ACK codebook associated with the first physical uplink channel has a higher priority than a second HARQ-ACK codebook associated with the second physical uplink channel. The WTRU may transmit the first HARQ-ACK codebook on the first physical uplink channel in the slot. The WTRU may transmit a portion of the second HARQ-ACK codebook in the slot and transmit a portion of the second HARQ-ACK codebook in a subsequent slot (e.g., a next slot, a future slot, etc.).)

1. An apparatus, the apparatus comprising:

a processor configured to:

determining that a first physical uplink channel and a second physical uplink channel overlap in a first time slot, wherein the first physical uplink channel and the second physical uplink channel are associated with a first hybrid automatic repeat request-acknowledgement (HARQ-ACK) codebook and a second HARQ-ACK codebook, respectively;

determining that the first HARQ-ACK codebook has a higher priority than the second HARQ-ACK codebook;

transmitting the first HARQ-ACK codebook on the first physical uplink channel in the first slot;

determining a first sub-codebook of the second HARQ-ACK codebook and a second sub-codebook of the second HARQ-ACK codebook; and

transmitting the first sub-codebook of the second HARQ-ACK codebook on the second physical uplink channel in the first slot, wherein the first sub-codebook of the second HARQ-ACK codebook is transmitted using a non-overlapping portion of the second physical uplink channel.

2. The apparatus of claim 1, wherein the processor is further configured to transmit the second sub-codebook of the second HARQ-ACK codebook in a second slot.

3. The apparatus of claim 1, wherein determining that the first HARQ-ACK codebook has a higher priority than the second HARQ-ACK codebook is based on a type of service associated with the first HARQ-ACK codebook and a type of service associated with the second HARQ-ACK codebook.

4. The apparatus of claim 1, wherein the determination of the first sub-codebook of the second HARQ-ACK codebook and the second sub-codebook of the second HARQ-ACK codebook is based on a plurality of symbols of the second physical uplink channel in the first slot that do not overlap the first physical uplink channel in the first slot.

5. The apparatus of claim 4, wherein the determination of the first sub-codebook of the second HARQ-ACK codebook and the second sub-codebook of the second HARQ-ACK codebook is based on reliability requirements of the second HARQ-ACK codebook.

6. The apparatus of claim 5, wherein the reliability requirement of the second HARQ-ACK codebook comprises a block error rate target.

7. The apparatus of claim 1, wherein the first physical uplink channel is a physical uplink control channel.

8. The apparatus of claim 1, wherein the first physical uplink channel is a physical uplink shared channel.

9. A method, the method comprising:

determining that a first physical uplink channel and a second physical uplink channel overlap in a first time slot, wherein the first physical uplink channel and the second physical uplink channel are associated with a first hybrid automatic repeat request-acknowledgement (HARQ-ACK) codebook and a second HARQ-ACK codebook, respectively;

determining that the first HARQ-ACK codebook has a higher priority than the second HARQ-ACK codebook;

transmitting the first HARQ-ACK codebook on the first physical uplink channel in the first slot;

determining a first sub-codebook of the second HARQ-ACK codebook and a second sub-codebook of the second HARQ-ACK codebook; and

transmitting the first sub-codebook of the second HARQ-ACK codebook on the second physical uplink channel in the first slot, wherein the first sub-codebook of the second HARQ-ACK codebook is transmitted using a non-overlapping portion of the second physical uplink channel.

10. The method of claim 9, further comprising transmitting the second sub-codebook of the second HARQ-ACK codebook in a second slot.

11. The method of claim 9, wherein determining that the first HARQ-ACK codebook has a higher priority than the second HARQ-ACK codebook is based on a type of service associated with the first HARQ-ACK codebook and a type of service associated with the second HARQ-ACK codebook.

12. The method of claim 9 wherein the determination of the first sub-codebook of the second HARQ-ACK codebook and the second sub-codebook of the second HARQ-ACK codebook is based on a plurality of symbols of the second physical uplink channel in the first slot that do not overlap the first physical uplink channel in the first slot.

13. The method of claim 12 wherein the determination of the first sub-codebook of the second HARQ-ACK codebook and the second sub-codebook of the second HARQ-ACK codebook is based on reliability requirements of the second HARQ-ACK codebook.

14. The method of claim 13, wherein the reliability requirement of the second HARQ-ACK codebook comprises a block error rate target.

15. The method of claim 9, wherein the first physical uplink channel is a physical uplink control channel.

16. The method of claim 9, wherein the first physical uplink channel is a physical uplink shared channel.

Background

Mobile communications are continuously evolving and are already in the door of its fifth release-5G.

Disclosure of Invention

Systems, methods, and instrumentalities are disclosed that may be associated with hybrid automatic repeat request acknowledgement (HARQ-ACK) transmissions, such as HARQ-ACK codebook adaptation associated with HARQ-ACK transmissions. A device, such as a wireless transmit/receive unit (WTRU), may be configured with multiple physical uplink channels, such as a Physical Uplink Control Channel (PUCCH), in a slot. Each physical uplink channel may have a corresponding HARQ-ACK codebook. In an example, the WTRU may determine that the first physical uplink channel and the second physical uplink channel overlap in a time slot. In this case, the WTRU may determine that a first HARQ-ACK codebook associated with a first physical uplink channel has a higher priority than a second HARQ-ACK codebook associated with a second physical uplink channel. The WTRU may transmit a first HARQ-ACK codebook on a first physical uplink channel in a slot. The WTRU may transmit a portion of the second HARQ-ACK codebook in a slot and transmit a portion of the second HARQ-ACK codebook in a subsequent slot (e.g., a next slot, a future slot, etc.). For example, the WTRU may determine a first sub-codebook of a second HARQ-ACK codebook and a second sub-codebook of the second HARQ-ACK codebook. The WTRU may transmit a first sub-codebook of a second HARQ-ACK codebook on a first physical uplink channel in a slot and a second sub-codebook of the second HARQ-ACK codebook in a subsequent slot (e.g., on a second physical uplink channel). The WTRU may transmit the first sub-codebook of the second HARQ-ACK codebook using a non-overlapping portion of the second physical uplink channel (e.g., a portion/symbol of the second physical uplink channel that does not overlap with the first physical uplink channel in a slot).

For example, the WTRU may autonomously determine to use the remaining symbols of the configured PUCCH for dropped HARQ-ACK codebook transmissions based on one or more of: remaining symbols available for PUCCH; HARQ-ACK codebook size; or a BLER target value/service type associated with the HARQ-ACK codebook.

A WTRU may be configured with a set of PUCCH resources specific to dropped HARQ-ACK codebook transmissions, wherein one or more of the following may apply: the PUCCH resource indication within the resource set may depend on the PRI of the dropped HARQ-ACK codebook transmission; alternatively, the K1 timing may be associated with the timing for transmission and dynamically indicated to the WTRU.

The WTRU may use the configured grant/dynamic grant PUSCH for dropped HARQ-ACK codebook transmissions. The WTRU may autonomously determine which UL grant to use based on one or more of the following: the arrival timing of the grant; or beta offset indication.

The WTRU may combine the remaining bits of the discarded HARQ-ACK codebook in the next codebook for the same service type/requirement. This may be based on the counter DAI and/or the total DAI step size.

Drawings

FIG. 1A is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented;

figure 1B is a system diagram illustrating an exemplary wireless transmit/receive unit (WTRU) that may be used within the communication system shown in figure 1A according to one embodiment;

fig. 1C is a system diagram illustrating an exemplary Radio Access Network (RAN) and an exemplary Core Network (CN) that may be used within the communication system shown in fig. 1A according to one embodiment;

figure 1D is a system diagram illustrating another exemplary RAN and another exemplary CN that may be used within the communication system shown in figure 1A according to one embodiment;

figure 2 shows an overlapping HARQ-ACK codebook;

figure 3 shows an example associated with a WTRU configured with a PUCCH resource set of a codebook for discarding;

FIG. 4 illustrates an example associated with separating a discarded HARQ-ACK codebook into sub-codebooks;

figure 5 shows HARQ-ACK transmission on multiple PUCCH resources in a slot for two TBs with different priorities;

figure 6 shows HARQ-ACK transmissions on multiple PUCCH resources in a slot for two different services;

figure 7 shows HARQ-ACK transmissions on multiple PUCCH resources in slots having different durations; and

fig. 8 shows HARQ-ACK transmissions on multiple PUCCH resources in a slot with different RB offsets.

Detailed Description

Fig. 1A is a schematic diagram illustrating an exemplary communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcast, etc., to a plurality of wireless users. Communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication system 100 may employ one or more channel access methods such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), orthogonal FDMA (ofdma), single carrier FDMA (SC-FDMA), zero-tailed unique word DFT-spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), and so forth.

As shown in fig. 1A, the communication system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104/113, CNs 106/115, Public Switched Telephone Networks (PSTNs) 108, the internet 110, and other networks 112, although it should be understood that any number of WTRUs, base stations, networks, and/or network elements are contemplated by the disclosed embodiments. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and/or a "STA") may be configured to transmit and/or receive wireless signals and may include User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a smartphone, a laptop, 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, medical devices and applications (e.g., tele-surgery), industrial devices and applications (e.g., robots and/or other wireless devices operating in industrial and/or automated processing chain environments), consumer electronics devices and applications, Devices operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

Communication system 100 may also include base station 114a and/or base station 114 b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114B may be Base Transceiver Stations (BTSs), node bs, evolved node bs, home evolved node bs, gnbs, NR node bs, site controllers, Access Points (APs), wireless routers, and so forth. Although the base stations 114a, 114b are each depicted as a single element, it should be understood that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

The base station 114a may be part of a RAN104/113, which may also include other base stations and/or network elements (not shown), such as Base Station Controllers (BSCs), Radio Network Controllers (RNCs), relay nodes, and so forth. Base station 114a and/or base station 114b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for wireless services to a particular geographic area, which may be relatively fixed or may change over time. 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, the base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of a cell. For example, beamforming may be used to transmit and/or receive signals in a desired spatial direction.

The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, centimeter wave, micrometer wave, Infrared (IR), Ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable Radio Access Technology (RAT).

More specifically, as indicated above, communication system 100 may be a multiple-access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) terrestrial radio access (UTRA), which may use wideband cdma (wcdma) to establish the air interface 115/116/117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and/or evolved HSPA (HSPA +). HSPA may include high speed Downlink (DL) packet access (HSDPA) and/or High Speed UL Packet Access (HSUPA).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as evolved UMTS terrestrial radio access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and/or LTE-advanced (LTE-a) and/or LTE-advanced Pro (LTE-a Pro).

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access that may use a New Radio (NR) to establish the air interface 116.

In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, e.g., using Dual Connectivity (DC) principles. Thus, the air interface used by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., eNB and gNB).

In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA 20001X, 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), GSM EDGE (GERAN), and the like.

The base station 114B in fig. 1A may be, for example, a wireless router, a home nodeb, a home enodeb, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, campus, industrial facility, air corridor (e.g., for use by a drone), road, and so forth. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE-A, LTE-a Pro, NR, etc.) to establish the pico cell or the femto cell. As shown in fig. 1A, the base station 114b may have a direct connection to the internet 110. Thus, base station 114b may not need to access internet 110 via CN 106/115.

The RAN104/113 may communicate with a CN 106/115, which may be any type of network configured to provide voice, data, application, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102 d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and so forth. The CN 106/115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in fig. 1A, it should be understood that the RAN104/113 and/or CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN104/113 or a different RAT. For example, in addition to connecting to the RAN104/113, which may utilize NR radio technology, the CN 106/115 may communicate with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technologies.

The CN 106/115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the internet 110, and/or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides Plain Old Telephone Service (POTS). The internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or the Internet Protocol (IP) in the TCP/IP internet protocol suite. The network 112 may include wired and/or wireless communication networks owned and/or operated by other service providers. For example, the network 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN104/113 or a different RAT.

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

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

The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of Integrated Circuit (IC), a state machine, or the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functions that enable the WTRU102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, which may be coupled to a transmit/receive element 122. Although fig. 1B depicts the processor 118 and the transceiver 120 as separate components, it should be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

Transceiver 120 may be configured to modulate signals to be transmitted by transmit/receive element 122 and demodulate signals received by transmit/receive element 122. As noted above, the WTRU102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU102 to communicate via multiple RATs, such as NR and IEEE 802.11.

The processor 118 of the WTRU102 may be coupled to and may receive user input data from a speaker/microphone 124, a keypad 126, and/or a display/touch pad 128, such as a Liquid Crystal Display (LCD) display unit or an Organic Light Emitting Diode (OLED) display unit. The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. Further, the processor 118 may access information from, and store data in, any type of suitable memory, such as non-removable memory 130 and/or removable memory 132. The non-removable memory 130 may include Random Access Memory (RAM), Read Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, a memory that is not physically located on the WTRU102, such as on a server or home computer (not shown).

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

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

The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and/or hardware modules that provide additional features, functionality, and/or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and/or video), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a microphone, and/or the like,A module, a Frequency Modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and/or augmented reality (VR/AR) device, an activity tracker, and/or the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, and a time sensor; a geographic position sensor; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and/or humidity sensors.

The WTRU102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous. A full-duplex radio may include an interference management unit to reduce and/or substantially eliminate self-interference via hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and/or simultaneous.

Figure 1C is a system diagram illustrating the RAN104 and the CN 106 according to one embodiment. As described above, the RAN104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using E-UTRA radio technology. The RAN104 may also communicate with the CN 106.

RAN104 may include enodebs 160a, 160B, 160c, but it should be understood that RAN104 may include any number of enodebs while remaining consistent with an embodiment. The enodebs 160a, 160B, 160c may each include one or more transceivers to communicate with the WTRUs 102a, 102B, 102c over the air interface 116. In one embodiment, the enode bs 160a, 160B, 160c may implement MIMO technology. Thus, for example, the enode B160a may use multiple antennas to transmit wireless signals to the WTRU102a and/or receive wireless signals from the WTRU102 a.

Each of the enodebs 160a, 160B, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in fig. 1C, enode bs 160a, 160B, 160C may communicate with each other over an X2 interface.

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

MME 162 may be connected to each of enodebs 162a, 162B, 162c in RAN104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, 102c, and the like. MME 162 may provide a control plane function for switching between RAN104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

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

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

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

Although the WTRU is depicted in fig. 1A-1D as a wireless terminal, it is contemplated that in some representative embodiments, such a terminal may use a wired communication interface (e.g., temporarily or permanently) with a communication network.

In a representative embodiment, the other network 112 may be a WLAN.

A WLAN in infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access or interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic to and/or from the BSS. Traffic originating outside the BSS and directed to the STA may arrive through the AP and may be delivered to the STA. Traffic originating from the STAs and directed to destinations outside the BSS may be sent to the AP to be delivered to the respective destinations. Traffic between STAs within a BSS may be sent through the AP, e.g., where a source STA may send traffic to the AP and the AP may pass the traffic to a destination STA. Traffic between STAs within a BSS may be considered and/or referred to as point-to-point traffic. Direct Link Setup (DLS) may be utilized to transmit point-to-point traffic between (e.g., directly between) a source and destination STA. In certain representative embodiments, DLS may use 802.11e DLS or 802.11z tunnel DLS (tdls). A WLAN using Independent Bss (IBSS) mode may not have an AP, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

When using an 802.11ac infrastructure mode of operation or a similar mode of operation, the AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be a fixed width (e.g., a20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access with collision avoidance (CSMA/CA) may be implemented, for example, in 802.11 systems. For CSMA/CA, an STA (e.g., each STA), including an AP, may listen to the primary channel. A particular STA may back off if the primary channel is sensed/detected and/or determined to be busy by the particular STA. One STA (e.g., only one station) may transmit at any given time in a given BSS.

High Throughput (HT) STAs may communicate using a 40 MHz-wide channel, e.g., via a combination of a primary 20MHz channel and an adjacent or non-adjacent 20MHz channel to form a 40 MHz-wide channel.

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

802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11 ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter type control/machine type communication, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., supporting only) certain bandwidths and/or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

WLAN systems that can support multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by STAs from all STAs operating in the BSS (which support the minimum bandwidth operating mode). In the 802.11ah example, for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1MHz mode, the primary channel may be 1MHz wide, even though the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. If the primary channel is busy, for example, because STAs (supporting only 1MHz mode of operation) are transmitting to the AP, the entire available band may be considered busy even though most of the band remains idle and may be available.

In the united states, the available frequency band for 802.11ah is 902MHz to 928 MHz. In korea, the available frequency band is 917.5MHz to 923.5 MHz. In Japan, the available frequency band is 916.5MHz to 927.5 MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As noted above, the RAN113 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. RAN113 may also communicate with CN 115.

RAN113 may include gnbs 180a, 180b, 180c, but it should be understood that RAN113 may include any number of gnbs while remaining consistent with an embodiment. The gnbs 180a, 180b, 180c may each include one or more transceivers to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gnbs 180a, 180b, 180c may implement MIMO techniques. For example, the gnbs 180a, 108b may utilize beamforming to transmit signals to the gnbs 180a, 180b, 180c and/or receive signals from the gnbs 180a, 180b, 180 c. Thus, the gNB180a may use multiple antennas to transmit wireless signals to the WTRU102a and/or receive wireless signals from the WTRU102a, for example. In one embodiment, the gnbs 180a, 180b, 180c may implement carrier aggregation techniques. For example, the gNB180a may transmit multiple component carriers to the WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, the gnbs 180a, 180b, 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive a cooperative transmission from gNB180a and gNB180 b (and/or gNB180 c).

The WTRUs 102a, 102b, 102c may communicate with the gNB180a, 180b, 180c using transmissions associated with the set of scalable parameters. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of various or extendable lengths (e.g., including different numbers of OFDM symbols and/or varying absolute lengths of time).

The gnbs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in an independent configuration and/or in a non-independent configuration. In a standalone configuration, the WTRUs 102a, 102B, 102c may communicate with the gnbs 180a, 180B, 180c while also not visiting other RANs (e.g., such as the enodebs 160a, 160B, 160 c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gnbs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gnbs 180a, 180b, 180c using signals in an unlicensed frequency band. In a non-standalone configuration, the WTRUs 102a, 102B, 102c may communicate or connect with the gnbs 180a, 180B, 180c, while also communicating or connecting with other RANs, such as the eNode-B160a, 160B, 160 c. For example, the WTRUs 102a, 102B, 102c may implement the DC principles to communicate with one or more gnbs 180a, 180B, 180c and one or more enodebs 160a, 160B, 160c substantially simultaneously. In a non-standalone configuration, the enodebs 160a, 160B, 160c may serve as mobility anchors for the WTRUs 102a, 102B, 102c, and the gnbs 180a, 180B, 180c may provide additional coverage and/or throughput for the serving WTRUs 102a, 102B, 102 c.

Each of the gnbs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards User Plane Functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, etc. As shown in fig. 1D, the gnbs 180a, 180b, 180c may communicate with each other through an Xn interface.

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

The AMFs 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c via an N2 interface in the RAN113 and may serve as control nodes. For example, the AMFs 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, and so forth. The AMFs 182a, 182b may use network slicing to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service used by the WTRUs 102a, 102b, 102 c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for Machine Type Communication (MTC) access, and so on. The AMF 162 may provide control plane functionality for switching between the RAN113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-a Pro, and/or non-3 GPP access technologies, such as WiFi).

The SMFs 183a, 183b may be connected to the AMFs 182a, 182b in the CN115 via an N11 interface. The SMFs 183a, 183b may also be connected to UPFs 184a, 184b in the CN115 via an N4 interface. The SMFs 183a, 183b may select and control the UPFs 184a, 184b and configure traffic routing through the UPFs 184a, 184 b. SMFs 183a, 183b may perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notifications, etc. The PDU session type may be IP-based, non-IP-based, ethernet-based, etc.

The UPFs 184a, 184b may be connected via an N3 interface to one or more of the gnbs 180a, 180b, 180c in the RAN113, which may provide the WTRUs 102a, 102b, 102c with access to a packet-switched network, such as the internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchors, etc.

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

In view of the corresponding descriptions of fig. 1A-1D and 1A-1D, one or more, or all, of the functions described herein with reference to one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-B, enodebs 160a-c, MME 162, SGW 164, PGW 166, gNB180 a-c, AMFs 182a-B, UPFs 184a-B, SMFs 183a-B, DNs 185a-B, and/or any other device described herein. The emulation device can be one or more devices configured to emulate one or more or all of the functionalities described herein. For example, the emulation device may be used to test other devices and/or simulate network and/or WTRU functions.

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

The one or more emulation devices can perform one or more (including all) functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the simulation device may be used in a test scenario in a test laboratory and/or in a non-deployed (e.g., testing) wired and/or wireless communication network to enable testing of one or more components. The one or more simulation devices may be test devices. Direct RF coupling and/or wireless communication via RF circuitry (which may include one or more antennas, for example) may be used by the emulation device to transmit and/or receive data.

New Radio (NR) technologies may be associated with 3 GPP. NR may support variable transmission duration/start symbol and HARQ feedback timing. With variable transmission duration, PDSCH or PUSCH transmissions may occupy a contiguous set of symbols, e.g., within a slot. With variable feedback timing, the DCI scheduling the DL assignment may include an indication of HARQ feedback timing to the WTRU, e.g., by pointing to one of the semi-statically configured HARQ timings. NR may support a dynamic HARQ-ACK codebook, where the size of the HARQ codebook may depend on the number of scheduled Transport Blocks (TBs). The gNB may use a counter Downlink Assignment Index (DAI) and a total DAI in the DCI to indicate the number of previously scheduled TBs. The counter and total DAI may have a size of 2 bits, which may allow the WTRU to recover up to 4 missing TBs, for example. In an example, the NR Rel-15 may support WTRUs transmitting at most one HARQ-ACK codebook within a slot.

The reliability and/or delay of the control signaling may have an impact on data transmission in the downlink and uplink. Uplink Control Information (UCI) with low reliability may increase the decoding error probability of downlink data transmission. For example, HARQ-ACK feedback with high BLER may result in a high probability of NACK-to-ACK or NACK/ACK loss detection. It may be supported, for example, that HARQ-ACK codebooks for different types of services may be transmitted separately (e.g., to mitigate problems) even where transmissions are scheduled within the same time slot. In an example, the WTRU may discard one of the HARQ-ACK codebooks in case of overlapping transmissions.

In the case where the WTRU is configured by the gNB to transmit multiple HARQ-ACK codebooks in overlapping symbols (e.g., in a limited power scenario), the WTRU may discard HARQ-ACK codebooks for service types that do not require low latency and/or high reliability. For example, a WTRU may support eMBB and URLLC, and at a given time slot, the WTRU may be scheduled to transmit two HARQ-ACK codebooks of different types of services, which may overlap (e.g., partially or fully) within the time slot. The WTRU may discard the eMBB HARQ-ACK codebook and prioritize the URLLC HARQ-ACK codebook. The eMBB ACK/NACK bit may not be available at the gbb. This may trigger unnecessary retransmissions of the eMBB packet (e.g., the transport block corresponding to the discarded HARQ-ACK codebook). On the WTRU side, the following problems may need to be solved: how the HARQ-ACK codebook will be constructed, taking into account that it may be necessary to schedule transmissions in subsequent slots. One or more features provided herein may be associated with re-establishing/adjusting the HARQ-ACK codebook, e.g., in the event of a drop.

The term "codebook type" may refer to a HARQ-ACK codebook for the same type of service. For example, in case the WTRU groups ACK/NACK for eMBB TBs in one HARQ-ACK codebook, it may be referred to as codebook type 1. The ACK/NACK for URLLC TBs in another codebook may be referred to as codebook type 2.

There may be cases where multiple HARQ-ACK codebooks are configured for a WTRU. The multiple HARQ-ACK codebooks may correspond to different types of services and/or transmissions having different requirements. For example, for URLLC type services, the WTRU may be configured to maintain different HARQ-ACK codebooks depending on the BLER target value for the transmission. Examples may include the following: can be adjusted to a BLER target value of 10^-6The acknowledgement BLER target value in the HARQ-ACK codebooks of the different URLLC transmissions is 10^-5URLLC. The URLLC transmission with the delay requirement of 0.5ms can be confirmed by a HARQ codebook which is different from the URLLC transmission with the delay requirement of 1 ms; and the like.

The discarded HARQ-ACK codebook may be transmitted in a subsequent slot (e.g., a next slot, a future slot, etc.). In an example, this may include features associated with one or more of: transmitting the discarded HARQ-ACK codebook on the PUCCH resources; transmitting the dropped HARQ-ACK codebook using a PUSCH transmission; using HARQ-ACK (e.g., new HARQ-ACK) timing to transmit discarded HARQ-ACK; alternatively, the HARQ-ACK codebook is adjusted (e.g., the discarded HARQ-ACK codebook is combined with the next HARQ-ACK codebook transmission of the same codebook type).

The WTRU may be configured to transmit the discarded HARQ-ACK codebook in a different slot than the slot on which the HARQ feedback is scheduled to be transmitted. For example, the WTRU may be configured to transmit the HARQ-ACK codebook in slot n, and based on one of the triggers described herein, the WTRU may discard the transmission of the HARQ-ACK codebook. The WTRU may keep the a/N bits in its buffer for potential transmission in time slot N + k, where k > 0.

The WTRU may be configured to transmit the discarded HARQ-ACK codebook on a resource (e.g., PUCCH resource for example). The WTRU may be configured with a specific set of PUCCH resources for transmitting the discarded HARQ-ACK codebook. Such PUCCH resource sets may be additional resource sets or specified from a resource set already configured for the WTRU. In an example, the WTRU may determine PUCCH resources within a PUCCH resource set based on a PUCCH resource indication identity (PRI) scheduled for the dropped HARQ-ACK codebook. The WTRU may use the same PRI to determine PUCCH resources from the set of resources. The WTRU may apply an offset to the PRI to determine PUCCH resources from the set of resources. The offset applied may depend on one or more of the following: PRI of prioritized HARQ-ACK codebook transmission; or, HARQ-ACK timing for subsequent attempts to transmit the discarded HARQ-ACK codebook.

Using PRI for prioritized HARQ-ACK codebook transmission, the WTRU may have received a transmission with PRI₁And a first HARQ-ACK codebook having a PRI₂Of the second HARQ-ACK codebook. The WTRU may discard the first codebook and transmit the second codebook. In subsequent slots, the WTRU may use the index PRI from the PUCCH resource set of the codebook configured for discarding₁+PRI₂The discarded codebook is transmitted.

Using the HARQ-ACK timing for subsequent attempts to transmit the discarded HARQ-ACK codebook, the WTRU may be configured to transmit the discarded HARQ codebook in N slots after the discard. The WTRU may use an index equal to PRI + F (n), where PRI is the index initial PUCCH resource indicating discarded HARQ transmission and F (.) is a function/mapping/table that associates HARQ timing with PUCCH index offset.

The WTRU may be configured to transmit the dropped HARQ-ACK codebook using a PUSCH transmission. In an example, the WTRU may use DCI-based grants to transmit the HARQ-ACK codebook. For example, the WTRU may transmit the discarded feedback using the UL grant received in the next slot. The WTRU may receive an explicit bit field in DCI (which requests transmission of a discarded HARQ codebook on PUSCH) or autonomously determine that a UL grant should be used for HARQ-ACK transmission. The WTRU may be configured with an RRC parameter, e.g., "betaOffsets," that supports a value that may be signaled, e.g., by a "Beta _ offset indicator" field in DCI format 0_1, which may indicate that the WTRU needs to transmit a dropped HARQ codebook on the corresponding PUSCH. The WTRU may determine the UL grant for the HARQ-ACK codebook transmission based on one or a combination of: a timing offset between the discarded HARQ codebook and the UL grant is less than a threshold; alternatively, the scheduling request is not sent by the WTRU in a timing window prior to receiving the grant.

In an example, in the case that the timing offset between the discarded HARQ codebook and the UL grant is less than a threshold, if T of the HARQ codebook is discarded_(symbol)After receiving the UL grant, the WTRU may transmit the HARQ-ACK codebook using an uplink grant. In examples where a scheduling request is not sent by the WTRU in the timing window prior to receiving the grant, the WTRU may not have sent a scheduling request for uplink scheduling and/or its UL buffer is empty.

The WTRU may be configured to transmit the discarded HARQ-ACK codebook using the UL configured grant. The WTRU may receive an indication from the network that a configured grant to use is from a set of pre-configured/RRC-configured grants to be used for the discarded HARQ-ACK codebook transmission. The indication may be signaled semi-statically or dynamically using, for example, DCI. The WTRU may be configured with an RRC parameter, such as "betaOffsets," that indicates one of the reserved index values that is not mapped to the beta offset value for HARQ-ACK or CSI transmission on PUSCH (e.g., index values 19-31 in the RRC configuration that are not mapped to the beta offset in table 1).

Table 1: RRC configuration of beta offset

The WTRU may be configured with HARQ-ACK timing (e.g., new HARQ-ACK timing) to transmit discarded HARQ-ACKs, which may be referred to as "HARQ timing to new HARQ timing," for example. The granularity of "HARQ timing to new HARQ timing" may be configured in units of slots, sub-slots, or symbols. In an example, using RRC signaling, a WTRU may be configured with a mapping between, for example, a PDSCH to HARQ timing value and a HARQ timing to a new HARQ timing value. Based on the PDSCH-to-HARQ timing initially scheduled for codebook transmission, and after dropping the codebook, the WTRU may use the configured mapping to determine the timing of the transmission.

In an example, the WTRU may autonomously determine HARQ-ACK timing (e.g., new HARQ timing) based on one or a combination of: control information related to the dropped transmission; or control information associated with prioritized transmissions.

For control information related to the dropped transmission, one or more of the following may be applied. A search space configuration on which DCI (e.g., DCI scheduling at least one of TBs related to a discarded HARQ-ACK codebook) is received may be used. The search space configuration may include one or more of the following: monitoring periodicity and duration; monitoring a pattern within a time slot; or search the spatial index. A CORESET configuration may be used on which DCI is received (e.g., DCI scheduling at least one of the TBs associated with the discarded HARQ-ACK codebook). The CORESET configuration may include one or more of the following: CORESET indexing; a CORESET duration; or BWP associated with CORESET. HARQ timing for the dropped transmission may be included.

For control information related to prioritized transmission, one or more of the following may be applied. A search space configuration may be used on which DCI (e.g., DCI scheduling at least one of the TBs associated with the prioritized HARQ-ACK codebook) is received. The search space configuration may include one or more of the following: monitoring periodicity and/or duration; monitoring a pattern within a time slot; or search the spatial index. A CORESET configuration may be used on which DCI is received (e.g., DCI scheduling at least one of the TBs associated with the prioritized HARQ-ACK codebook). The CORESET configuration may include one or more of the following: CORESET indexing; a CORESET duration; or BWP associated with CORESET. HARQ timing for prioritized transmissions may be included.

The WTRU may adjust the HARQ-ACK codebook. The WTRU may be configured to combine the discarded HARQ-ACK codebook with the next HARQ-ACK codebook transmission of the same codebook type. In an example, the WTRU may be configured to (e.g., dynamically) identify the codebook type. The WTRU may use the PUCCH resource indication and the HARQ feedback timing indication (e.g., if it receives the same type of downlink allocation) to acknowledge the transmission (e.g., a new transmission) and/or the discarded HARQ-ACK codebook. For example, the WTRU may be configured to determine the codebook type based on the codebook identifier. In slot n, the WTRU discards the HARQ-ACK codebook with a codebook identifier equal to k. In slot n +1, the WTRU may receive a downlink allocation indicating the PUCCH resource and HARQ timing in slot n +4 and using a codebook identifier equal to k. The WTRU may adjust the HARQ-ACK codebook size (e.g., the new HARQ-ACK codebook size) to include the discarded HARQ-ACK codebook in slot n.

In an example, the WTRU may be configured to identify whether the discarded HARQ-ACK codebook may be combined with the next HARQ-ACK codebook, e.g., based on the DAI and/or the counter DAI. The WTRU may be configured to interpret an increase step size above a threshold configured in the counter DAI and/or the total DAI as an indication to combine the transmission of the ACK/NACK (e.g., a new transmission of the ACK/NACK) with the discarded HARQ-ACK. For example, the counter DAI indicator value from the WTRU is received last before HARQ-ACK discard is 1. In the next allocation after the discard, the WTRU may receive a counter DAI and/or a total DAI of 4. The WTRU may then determine that the next HARQ-ACK codebook may contain a discarded HARQ codebook.

A trigger may be used to discard the HARQ-ACK codebook. The WTRU may be configured to discard the HARQ-ACK codebook scheduled for transmission at a given time slot. The WTRU may be configured to discard the HARQ-ACK codebook at a given slot based on one or a combination of: the HARQ-ACK codebook is overlapping another uplink transmission (e.g., it has a higher priority than the HARQ-ACK codebook); alternatively, there are power limited scenarios.

In the case where the HARQ-ACK codebook is overlapping another uplink transmission having a higher priority than the HARQ-ACK codebook (e.g., another HARQ-ACK codebook as an example), the uplink transmission may include another HARQ-ACK codebook having a higher priority that may be scheduled for transmission on the PUCCH or PUSCH. In the example of PUSCH transmission, a WTRU may be configured to transmit a URLLC type of transmission over a PUSCH overlapping with a HARQ-ACK codebook.

In examples associated with power limited scenarios, the WTRU may be configured with multiple overlapping transmissions and/or with a maximum transmission power (Pmax). The WTRU may determine that it cannot meet the BLER target value for one of the scheduled transmissions given the current path loss from the gNB.

The WTRU may be configured to determine a priority of the HARQ-ACK codebook based on a type of service associated with the HARQ-ACK codebook and/or whether the HARQ-ACK codebook was discarded in a previous slot. In an example, the WTRU may be configured to associate a priority with the HARQ-ACK codebook depending at least on a service type of one transport block associated with the HARQ codebook. The WTRU may keep adjusting the priority based on the status of the transmission. For example, after dropping the HARQ-ACK codebook, the WTRU may increase the priority of the dropped HARQ codebook transmission.

Fig. 2 shows overlapping HARQ-ACK codebooks in a slot. For example, as shown in fig. 2, PUCCH1 carrying HARQ-ACK codebook 1 may overlap (e.g., at least partially overlap) PUCCH2 carrying HARQ-ACK codebook 2. As shown in fig. 2, a WTRU may be configured with two overlapping HARQ-ACK codebooks in slot n-3. For example, as shown in fig. 2 and/or fig. 4, the WTRU may prioritize HARQ-ACK codebook 1, e.g., consider codebook 1 over codebook 2, and discard transmissions of the portion of PUCCH2 that overlaps PUCCH 1. As shown in fig. 2, the WTRU may transmit the non-discarded part of PUCCH2 that does not overlap PUCCH 1. The WTRU may determine that the number of remaining symbols of PUCCH2 (e.g., the number of remaining symbols in a portion of PUCCH2 that does not overlap PUCCH1 (e.g., a non-overlapping portion of PUCCH 2) as shown in fig. 2) is above a threshold (e.g., a configured threshold). For example, as shown in FIG. 2 and/or as shown in fig. 4, the WTRU may split HARQ-ACK codebook 2 into two sub-codebooks (e.g., if the WTRU determines that the number of remaining symbols of PUCCH2 is above a threshold). The WTRU may transmit the first sub-codebook in a non-overlapping portion of the PUCCH2, e.g., using the remaining symbols of PUCCH2 in the slot (e.g., in slot n-3 in the example of fig. 2). The WTRU may determine whether a PUCCH resource set for a discarded HARQ-ACK codebook (e.g., a HARQ-ACK sub-codebook, such as the second sub-codebook or a full HARQ-ACK codebook) is configured (e.g., configured for a subsequent slot, such as a next slot, a future slot, etc.). For example, as shown in fig. 2, 3, and/or 4, the WTRU may decide whether to use the UL grant allocation for the discarded HARQ-ACK codebook transmission. In slot n-2, T is from the end of PUCCH2, for example_(symbol)Thereafter, the WTRU may receive an UL grant. The WTRU may determine a second sub-codebook of transmission HARQ-ACK codebook 2 based on the uplink grant.

Fig. 3 shows an example associated with a WTRU configured with a PUCCH resource set of a codebook for discarding. As shown in fig. 3, the WTRU may be configured with a discarded HARQ-ACK codebook (e.g., a HARQ-ACK sub-codebook, such as the second sub-codebook or the full HARQ-ACK codebook of fig. 2) that was not transmitted in a previous slot. As shown in fig. 3, the WTRU may determine whether the WTRU is configured with a PUCCH resource set of the HARQ-ACK codebook for discarding. If the WTRU is configured with a PUCCH resource set for a discarded HARQ-ACK codebook, the WTRU transmission may use PUCCH resources from the resource set by applying an offset to the PRI of the discarded HARQ-ACK codebook. The WTRU may determine the HARQ-ACK timing based on the timing indication of the dropped transmission. The WTRU may use a UL grant to carry the discarded HARQ-ACK codebook if the WTRU is not configured with a PUCCH resource set for the discarded HARQ-ACK codebook.

Fig. 4 illustrates an example associated with separating a discarded HARQ-ACK codebook into sub-codebooks. As shown in fig. 4, a WTRU may be configured with overlapping PUCCHs for corresponding HARQ-ACK transmissions (e.g., corresponding HARQ-ACK codebooks). The WTRU may consider the HARQ-ACK codebook in preference to another HARQ-ACK codebook (see, e.g., fig. 2). The WTRU may determine whether the remaining PUCCH symbols (e.g., non-overlapping portions of the PUCCH that are not prioritized, e.g., as shown in fig. 2) are above a threshold (e.g., a configured threshold). If above the threshold, the WTRU may separate the discarded HARQ-ACK codebook into two sub-codebooks (e.g., figure 2). The WTRU may transmit the first sub-codebook in remaining symbols of the configured PUCCH (e.g., a portion of the configured PUCCH that does not overlap with the prioritized PUCCH, e.g., as shown in fig. 2). The WTRU may transmit a second sub-codebook (e.g., the remaining bits of the discarded HARQ-ACK codebook) in a subsequent time slot (e.g., the next slot, a future slot, etc.). For example, if the WTRU determines that the number of PUCCH symbols is below a threshold, the WTRU may transmit the discarded bits of the HARQ-ACK codebook (full sub-codebook) in a subsequent slot (e.g., next slot, future slot, etc.).

The WTRU may be configured to transmit the discarded HARQ-ACK codebook in the slot on which the initial transmission HARQ codebook is scheduled. For example, the WTRU may be configured to transmit the HARQ-ACK codebook in slot n, and based on one of the triggers listed herein, the WTRU may discard the transmission of the HARQ-ACK codebook. The WTRU may transmit a/N bits in the same slot N, for example, using the remaining non-overlapping symbols.

There may be a trigger for transmitting the discarded HARQ-ACK codebook within the same slot. The WTRU may be configured to determine (e.g., autonomously) whether a portion of the codebook may be transmitted in the remaining non-overlapping symbols of the PUCCH. The WTRU may separate the HARQ-ACK codebook and may transmit the sub-codebook based on one or more of: a plurality of remaining symbols within the slot; size of discarded HARQ-ACK; a service type associated with the HARQ-ACK codebook; or BLER requirement of HARQ-ACK codebook.

The WTRU may be configured with multiple symbols and if the remaining symbols are higher than the configured number, the WTRU may transmit a portion of the HARQ-ACK codebook (e.g., sub-codebook) within the slot.

PUCCH resources may be adjusted for transmission. Assuming that the WTRU is configured with two PUCCH resources for HARQ-ACK information transmission in a slot, if the WTRU detects first and second DCI indicating first and second resources, respectively, for a PUCCH transmission in the slot with corresponding HARQ-ACK information, the WTRU may transmit the HARQ-ACK information according to one of the following.

The WTRU may transmit higher priority HARQ-ACK information in the PUCCH resources with an earlier starting symbol (e.g., the 10 th symbol) in the slot and lower priority HARQ-ACK information in the PUCCH resources with a later starting symbol (e.g., the 12 th symbol) in the slot. Fig. 5 shows HARQ-ACK transmission on multiple PUCCH resources in a slot for two TBs with different priorities.

The WTRU may transmit HARQ-ACK information associated with the URLLC service in the PUCCH resource with an earlier starting symbol (e.g., nth symbol) in the slot and HARQ-ACK information associated with the eMBB service in the PUCCH resource with a later starting symbol (e.g., n +2 symbols) in the slot. Figure 6 shows HARQ-ACK transmissions on multiple PUCCH resources in a slot for two different services.

The WTRU may transmit HARQ-ACK information associated with low delay transmissions in PUCCH resources corresponding to PUCCH formats with short durations (e.g., 1 to 2 symbols) and HARQ-ACK information associated with high delay tolerant transmissions in PUCCH resources corresponding to PUCCH formats with long durations (e.g., 10 or 14 symbols). Figure 7 shows HARQ-ACK transmissions on multiple PUCCH resources in a slot having different durations.

The WTRU may determine that two PUCCH resources have different cyclic shift indices if the PUCCH resources have the same PRB offset, starting symbol, and length. In this case, the WTRU may apply rules (e.g., implicit rules) to establish an association between each received DCI and the corresponding PUCCH resource. The WTRU may assume that the PUCCH resource with the lowest cyclic shift index is used for transmitting HARQ-ACK information corresponding to earlier received DCI and the PUCCH resource with the highest cyclic shift index is used for transmitting HARQ-ACK information corresponding to later received DCI.

The WTRU resource may determine that two PUCCH resources have different PRB offsets if the PUCCH resources have the same starting symbol, cyclic shift index, and length. In this case, the WTRU may apply rules (e.g., implicit rules) to establish an association between each received DCI and the corresponding PUCCH resource. The WTRU may assume that the PUCCH resource with the lowest PRB offset is used for transmitting HARQ-ACK information corresponding to an earlier received DCI or PDSCH and the PUCCH resource with the highest PRB offset is used for transmitting HARQ-ACK information corresponding to a later received DCI or PDSCH. Fig. 8 shows HARQ-ACK transmissions on multiple PUCCH resources in a slot with different RB offsets.

The a/N bits may be discarded from the HARQ-ACK codebook. The WTRU may adjust the size of the HARQ-ACK codebook to enable transmission of a portion of the HARQ-ACK codebook in the remaining symbols of the configured PUCCH. The WTRU may separate the HARQ-ACK codebook and transmit a subset of the a/N bits of the HARQ-ACK codebook (e.g., which may be the first sub-codebook). The WTRU may select a configured number of bits from the most significant bits or the least significant bits within the HARQ-ACK codebook. For example, the WTRU may have a₁、a₂、...a_NHARQ-ACK codebook of ACK/NACK bits. When the transmission is dropped, the WTRU may still have k non-overlapping symbols for the PUCCH transmission. The WTRU may transmit a portion of a HARQ-ACK codebook (e.g., which may be a first sub-codebook) having M bits such that M ≦ N, e.g., a₁、a₂、...a_MOr a_N-M+1、a_N-M+2、...、a_N. The WTRU may be configured to determine the number M based on one or more of: a number of remaining symbols of the PUCCH overlapping another uplink transmission; or the reliability requirements of the HARQ-ACK codebook transmission.

As described herein, the WTRU may be configured to transmit the remaining bits of the HARQ-ACK codebook in a subsequent slot (e.g., the next slot, a future slot, etc.).

If the PUSCH indicated by the DCI is overlapping with one of a plurality of PUCCH resources in a slot for HARQ-ACK transmission, one or more of the following may be applied. The WTRU may transmit HARQ-ACK on PUCCH resources that do not overlap with PUSCH and may ignore other PUCCH resources or scheduling DCI corresponding to PUCCH resources that overlap with PUSCH. The WTRU may multiplex the HARQ-ACK with the transport block and transmit it on the PUSCH indicated by the DCI, and may ignore the PUCCH resources or the scheduling DCI corresponding to the PUCCH resources. The WTRU may transmit a HARQ-ACK on the PUCCH resource in response to the DCI format detection by the WTRU, and may ignore other PUCCH resources as well as the PUSCH. If the WTRU is using the configured UL grant for PUSCH transmission, the WTRU may ignore the PUSCH and may transmit a HARQ-ACK on one of the PUCCH resources in response to DCI format detection by the WTRU.

Although the features and elements of the present disclosure may consider LTE, LTE-a, New Radio (NR), or 5G specific protocols, it should be understood that the solution described herein is not limited to this scenario and is also applicable to other wireless systems.

Although features and elements are described above in particular combinations, one of ordinary skill in the art will understand that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer readable media include electronic signals (transmitted over a wired or wireless connection) and computer readable storage media. Examples of computer readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs). A processor associated with software may be used to implement a radio frequency transceiver for the devices described herein.