HARQ-ACK codebook compatible

Abstract

To provide systems, methods, and devices associated with hybrid automatic repeat request acknowledgement (HARQ-ACK) transmission.SOLUTION: A device, such as a wireless transmit / receive unit (WTRU), may be configured with multiple physical uplink channels (PUCCHs) in a slot. Each PUCCH may have a respective HARQ-ACK codebook. In examples, the WTRU may determine that a first PUCCH and a second PUCCH overlap in a slot, determine that a first HARQ-ACK codebook associated with the first PUCCH has a higher priority than a second HARQ-ACK codebook associated with the second PUCCH, transmit the first HARQ-ACK codebook on the first PUCCH in the slot, and send part of the second HARQ-ACK codebook in the slot and part of the second HARQ-ACK codebook in a subsequent slot.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] Cross-reference of related applications This application claims the interests of U.S. Provisional Application No. US62 / 805,023, filed on 13 February 2019, the contents of which are incorporated herein by reference. [Background technology]

[0002] Mobile communications are constantly evolving and are already at the beginning of the fifth generation - 5G. [Overview of the project]

[0003] Systems, methods, and means that may be related to the transmission of Hybrid Automatic Retransmission Request Delivery Confirmation (HARQ-ACK), such as HARQ-ACK codebook adaptations related to HARQ-ACK transmission, are disclosed. A device such as a Wireless Transmitter / Receiver Unit (WTRU) may consist of multiple physical uplink channels in a slot, such as a Physical Uplink Control Channel (PUCCH). Each physical uplink channel may have its own HARQ-ACK codebook. In an example, the WTRU may determine that a first physical uplink channel and a second physical uplink channel overlap in a slot. In such a 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 a first HARQ-ACK codebook on the first physical uplink channel in the slot. A WTRU may transmit a portion of the second HARQ-ACK codebook in a slot and a portion of the second HARQ-ACK codebook in a subsequent slot (e.g., the next slot, a future slot, etc.). For example, a WTRU may determine the first subcodebook of the second HARQ-ACK codebook and the second subcodebook of the second HARQ-ACK codebook. A WTRU may transmit the first subcodebook of the second HARQ-ACK codebook over the first physical uplink channel in a slot and the second subcodebook of the second HARQ-ACK codebook in a subsequent slot (e.g., over the second physical uplink channel). A WTRU may transmit the first subcodebook 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 the slot).

[0004] A WTRU may, for example, autonomously decide to use the remaining symbols of a PUCCH configured for a dropped HARQ-ACK codebook transmission based on one or more of the following: the remaining symbols available to the PUCCH, the size of the HARQ-ACK codebook, or the BLER target / service type associated with the HARQ-ACK codebook.

[0005] A WTRU may consist of a PUCCH resource set specific to a dropped HARQ-ACK codebook transmission, in which case one or more of the following may apply: the PUCCH resource representation within the resource set may depend on the PRI of the dropped HARQ-ACK codebook transmission; or, K1 timing may be associated with the transmission timing and dynamically represented in the WTRU.

[0006] WTRU may use a configured authorization / dynamic authorization push for dropped HARQ-ACK codebook transmissions. WTRU may autonomously determine which UL authorization to use based on one or more of the following: authorization arrival timing; or beta offset indication.

[0007] WTRU may combine the remaining bits of a dropped HARQ-ACK codebook into the next codebook of the same service type / requirement. This can be based on the counter DAI and / or total DAI step size. [Brief explanation of the drawing]

[0008] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] [This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment.] [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1D] [This is a system diagram showing further exemplary RAN and further exemplary CN that may be used in the communication system shown in Figure 1A according to one embodiment.] [Figure 2] This shows duplicate HARQ-ACK codebooks. [Figure 3] This example shows a WTRU related to a PUCCH resource configured for a dropped codebook. [Figure 4] This example illustrates the process of separating a dropped HARQ-ACK codebook into subcodebooks. [Figure 5] This demonstrates HARQ-ACK transmissions across multiple PUCCH resources in two TB slots with different priorities. [Figure 6] This demonstrates HARQ-ACK transmissions across multiple PUCCH resources within slots of two different services. [Figure 7] This demonstrates HARQ-ACK transmissions from multiple PUCCH resources within slots of different durations. [Figure 8] This demonstrates HARQ-ACK transmissions across multiple PUCCH resources in slots with different RB offsets. [Modes for carrying out the invention]

[0009] Figure 1A shows an exemplary communication system 100 that can implement one or more disclosed embodiments. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messaging, and broadcast to multiple radio users. The communication system 100 can enable multiple radio users to access such content through the sharing of system resources, including radio bandwidth. For example, the 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), quadrature 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 filtering OFDM, and filter bank multi-carrier (FBMC).

[0010] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d (any of which may be referred to as “Station” and / or “STA”) may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

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

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

[0014] More specifically, as described above, the communication system 100 may be a multi-connection system and may adopt one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a of RAN104 / 113 and WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish air interfaces 115 / 116 / 117 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

[0015] In one embodiment, the base stations 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interface 116 using Long-Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro).

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

[0017] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by transmissions that occur between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNBs and gNBs).

[0018] In other embodiments, base station 114a and 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, 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 Rate for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0019] The base station 114b in Figure 1A could be, for example, a wireless router, home Node-B, home eNode-B, or access point, and could utilize any suitable RAT to facilitate wireless connectivity in local areas such as businesses, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), and roads. In one embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRU 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in Figure 1A, base station 114b can connect directly to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0020] RAN104 / 113 can communicate with CN106 / 115, which can be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 can provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to connecting to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing general telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) of the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

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

[0023] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any subcombinations of the aforementioned elements while maintaining consistency with the embodiment.

[0024] 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, other types of integrated circuits (ICs), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120, and the transceiver 120 may be coupled to a transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0025] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the 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 both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

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

[0027] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0029] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components within the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.), a solar cell, a fuel cell, etc.

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

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

[0032] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (e.g., associated with specific subframes of both UL (e.g., for transmission) and downlink (e.g., for reception) may occur in parallel and / or simultaneously. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing either through hardware (e.g., chokes) or through a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of a signal (e.g., associated with specific subframes of either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0033] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 employs E-UTRA wireless technology and can communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 can also communicate with CN106.

[0034] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c can implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.

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

[0036] The CN106 shown in Figure 1C may 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 aforementioned elements is shown as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0037] MME162 may be connected to each of the eNode-B162a, 162b, and 162c within RAN104 via the S1 interface and may function as a control node. For example, MME162 could be responsible for user authentication of WTRU102a, 102b, and 102c, activation / deactivation of bearers, and selecting a specific serving gateway during the initial connection of WTRU102a, 102b, and 102c. MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0038] The SGW164 can connect to each of the eNode-B160a, 160b, and 160c within RAN104 via the S1 interface. Generally, the SGW164 can route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can also perform other functions, such as fixing the user plane during handovers between eNode-B, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0039] SGW164 can connect to PGW166, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0040] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed telephone communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0041] While the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, it is assumed that such a terminal may be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0042] In a typical embodiment, the other network 112 can be a WLAN.

[0043] 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 to or interfaces with a distribution system (DS) or another type of wired / wireless network that transmits traffic into and / or out of the BSS. Traffic originating from outside the BSS to an STA may arrive via the AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP and delivered to its respective destination. Traffic between STAs within the BSS can be transmitted via the AP; for example, a 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 peer-to-peer traffic. Peer-to-peer traffic can be transmitted (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain representative embodiments, the DLS may be 802.11e DLS or 802.11z Tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode may be referred to herein as the “ad hoc” communication mode.

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

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

[0046] 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. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels or two discontinuous 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed individually on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0047] Sub-1 GHz operating modes are supported in 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited functionality, including support for specific bandwidths and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

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

[0050] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 employs NR radio technology and can communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 can also communicate with CN115.

[0051] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with the embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c can implement MIMO technology. For example, gNB180a and 180b can utilize beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit carriers of multiple components to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, and the remaining component carriers may be on the licensed spectrum. In another embodiment, gNB180a, 180b, and 180c can implement cooperative multipoint (CoMP) technology. For example, WTRU102a can receive cooperative transmissions from gNB180a and gNB180b (and / or gNB180c).

[0052] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or lasting for varying absolute times).

[0053] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, the WTRU102a, 102b, and 102c can utilize one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using unlicensed bandwidth signals. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c may also function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c may provide additional coverage and / or throughput to serve WTRU102a, 102b, and 102c.

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

[0055] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the aforementioned elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] AMF182a and 182b may be connected to one or more gNB180a, 180b, and 180c within RAN113 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the types of services utilized by WTRU102a, 102b, and 102c. For example, various network slices may be established for various use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on extended large-scale mobile broadband (eMBB) access, and services using machine-type communications (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0057] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0058] UPF184a and 184b can be connected to one or more gNB180a, 180b, and 180c within RAN113 via the N3 interface, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, handling of user plane QoS, buffering of downlink packets, and providing mobility anchors.

[0059] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a, 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, WTRU102a, 102b, 102c can connect to local data networks (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0060] With regard to Figures 1A-1D and the corresponding descriptions therein, with respect to one or more of the WTRU102a-d, base stations 114a-b, eNode-B160a-c, MME162, SGW164, PGW166, gNB180a-c, AMF182a-b, UPF184a-b, SMF183a-b, DN185a-b, and / or any other devices described herein, one or more, or all, of the functions described herein can be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0061] Emulation devices can be designed to implement one or more tests of other devices in a lab environment and / or operator network environment. For example, one or more emulation devices can perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices can perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices can be directly coupled to another device for testing purposes and / or perform tests using wireless communication over a wireless network.

[0062] One or more emulation devices can perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test lab test scenario and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may also be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0063] New radio (NR) technologies can be associated with 3GPP. NR can support variable transmit duration / start symbol and HARQ feedback timing. With variable transmit duration, a PDSCH or PUSCH transmit can occupy, for example, a consecutive set of symbols within a slot. With variable feedback timing, the DCI scheduling DL assignments can include a representation of the HARQ feedback timing to the WTRU, for example, by pointing to one of the semi-statically configured HARQ timings. NR can support dynamic HARQ-ACK codebooks, where the size of the HARQ codebook may depend on the number of scheduled transport blocks (TBs). The gNB can use a counter downlink assignment index (DAI) and total DAI within the DCI to indicate the number of previously scheduled TBs. The counter and total DAI can have a size of 2 bits, and for example, a WTRU can recover up to 4 missing TBs. In the example, NR Rel-15 can support a WTRU transmitting up to 1 HARQ-ACK codebook within a slot.

[0064] The reliability and / or delay of control signaling can affect data transmissions on both the downlink and uplink. Unreliable uplink control information (UCI) can increase the probability of decoding errors in downlink data transmissions. For example, HARQ-ACK feedback with a high BLER may increase the likelihood of NACK-to-ACK or NACK / ACK detection misses. For example, it may be supported that HARQ-ACK codebooks for different types of services be sent separately, even if transmissions are scheduled within the same slot (e.g., to mitigate problems). In this example, the WTRU could drop one of the HARQ-ACK codebooks if the transmissions overlap.

[0065] If a WTRU is configured by a gNB to send multiple HARQ-ACK codebooks with overlapping symbols (e.g., in a power-limited scenario), the WTRU may drop HARQ-ACK codebooks for types of services that do not require low latency or high reliability. For example, a WTRU may support eMBB and URLLC, and in a given slot, it may be scheduled to send two HARQ-ACK codebooks for different types of services that may overlap (e.g., partially or completely) within the slot. The WTRU may drop the eMBB HARQ-ACK codebook and prioritize the URLLC HARQ-ACK codebook. The eMBB ACK / NACK bits may not be available to the gNB. This can trigger unnecessary retransmission of eMBB packets (e.g., the transport block corresponding to the dropped HARQ-ACK codebook). The WTRU may need to address how to construct the HARQ-ACK codebook if transmission may be scheduled in subsequent slots. One or more of the features provided herein could, for example, be associated with rebuilding / adapting the HARQ-ACK codebook in the event of a drop.

[0066] The term "codebook type" can refer to HARQ-ACK codebooks for the same type of service. For example, if a WTRU groups the ACK / NACK of eMBB TB into one HARQ-ACK codebook, it can be called codebook type 1. The ACK / NACK of URLLC TB in a different codebook can be called codebook type 2.

[0067] A single WTRU may have multiple HARQ-ACK codebooks configured. Multiple HARQ-ACK codebooks can accommodate transmissions of different types of services and / or different requirements. For example, for a URLLC type service, a WTRU may be configured to maintain different HARQ-ACK codebooks depending on the BLER target of the transmission. An example could include: BLER target 10 -5 URLLC transmission is when the BLER target is 10 -6 URLLC transmissions can be confirmed for delivery using a different HARQ-ACK codebook than those with a URLLC transmission that has a 0.5ms delay requirement.

[0068] A dropped HARQ-ACK codebook can be sent in a subsequent slot (e.g., the next slot, a future slot, etc.). In the example, this could include one or more of the following related functions: sending a dropped HARQ-ACK codebook on a PUCCH resource; sending a dropped HARQ-ACK codebook using a PUSCH send; sending a dropped HARQ-ACK using a HARQ-ACK timing (e.g., a new HARQ-ACK); or adapting a HARQ-ACK codebook (e.g., combining a dropped HARQ-ACK codebook with the next HARQ-ACK codebook send of the same codebook type).

[0069] A WTRU may be configured to transmit a dropped HARQ-ACK codebook in a slot different from the slot in which it is scheduled to transmit HARQ feedback. For example, a WTRU may be configured to transmit a HARQ-ACK codebook in slot n, and based on one of the triggers described herein, the WTRU may drop the transmission of the HARQ-ACK codebook. The WTRU may hold the A / N bit in its buffer for potential transmissions in slot n+k (k>0).

[0070] A WTRU may be configured to send a dropped HARQ-ACK codebook on a resource (for example, the PUCCH resource used in the example). A WTRU may consist of a specific set of PUCCH resources for sending the dropped HARQ-ACK codebook. Such a set of PUCCH resources may be an additional set of resources or may be specified from a set of resources already configured for the WTRU. In the example, a WTRU may determine a PUCCH resource in a set of PUCCH resources based on a PUCCH resource indicator (PRI) scheduled for the dropped HARQ-ACK codebook. A WTRU may use the same PRI to determine a PUCCH resource from a set of resources. A WTRU may apply an offset to the PRI to determine a PUCCH resource from a set of resources. The offset applied may depend on one or more of the following: the PRI of a prioritized HARQ-ACK codebook transmission; or the HARQ-ACK timing of subsequent attempts to send the dropped HARQ-ACK codebook.

[0071] Using PRI for prioritized HARQ-ACK codebook submissions 、A WTRU may receive instructions to send a first HARQ-ACK codebook with PRI1 and a second HARQ-ACK codebook with PRI2. The WTRU may drop the first codebook and send the second codebook. In a subsequent slot, the WTRU may send the dropped codebook using the PUCCH resource with index PRI1+PRI2 from the PUCCH resource set configured for the dropped codebook.

[0072] Using the HARQ-ACK timing of subsequent attempts to send the dropped HARQ-ACK codebook, the WTRU may be configured to send the dropped HARQ codebook in N slots after it was dropped. The WTRU may use an index equal to PRI + F(N), where PRI is the initial PUCCH resource index shown for the dropped HARQ transmission, and F(.) is a function / mapping / table that associates the HARQ timing with the PUCCH index offset.

[0073] A WTRU may be configured to send dropped HARQ-ACK codebooks using a PUSCH transmission. For example, a WTRU may send a HARQ-ACK codebook using DCI-based authorization. For instance, a WTRU may send dropped feedback using a UL authorization received in the next slot. A WTRU may receive an explicit bit field in DCI requesting that a dropped HARQ codebook be sent over PUSCH, or it may autonomously determine whether a UL authorization should be used for HARQ-ACK transmission. A WTRU may consist of an RRC parameter, e.g., "betaOffsets", that supports a value that can be signaled by, for example, the "Beta_offset indicator" field in DCI format 0_1, indicating that the WTRU should send a dropped HARQ codebook over the corresponding PUSCH. A WTRU may determine that a UL authorization is for HARQ-ACK codebook transmission based on one or a combination of the following: the timing offset between the dropped HARQ codebook and the UL authorization is less than a threshold; or, no scheduling request was sent by the WTRU in the timing window before receiving the authorization.

[0074] In an example where the timing offset between the dropped HARQ codebook and UL authorization is below the threshold, the HARQ codebook will be dropped. symbol If a UL authorization is received afterward, the WTRU may use the uplink authorization to send a HARQ-ACK codebook. In an example where the WTRU did not send a scheduling request in the timing window before receiving authorization, the WTRU may not have sent a scheduling request for uplink scheduling, and / or the UL buffer is empty.

[0075] A WTRU can be configured to transmit dropped HARQ-ACK codebooks using UL-configured authorizations. The WTRU may receive instructions from the network on which configured authorization to use from a set of pre-configured / RRC-configured authorizations used for transmitting dropped HARQ-ACK codebooks. These instructions may be signaled semi-statically or dynamically, for example, using DCI. The WTRU may be configured using an RRC parameter, e.g., "betaOffsets," which represents one of the reserved index values ​​not mapped to beta offset values ​​for HARQ-ACK or CSI transmissions in PUSCH (e.g., Table 1: Beta Offsets not mapped to index values ​​19-31 in RRC configuration). [Table 1]

[0076] A WTRU may consist of a HARQ-ACK timing (e.g., a new HARQ-ACK timing) for sending a dropped HARQ-ACK, which may be called, for example, "HARQ timing to new HARQ timing". The granularity of "HARQ timing to new HARQ timing" may consist of slots, subslots, or symbols. In the example, the WTRU may be constructed using RRC signaling, for example, with a mapping between the timing values ​​from PDSCH to HARQ and the timing values ​​from HARQ timing to new HARQ. After dropping the codebook, based on the PDSCH to HARQ timing initially scheduled for the codebook transmission, the WTRU may use the configured mapping to determine the timing of the transmission.

[0077] In the example, the WTRU may autonomously determine the HARQ-ACK timing (e.g., the new HARQ timing) based on one or a combination of the following: control information related to a dropped transmission, or control information related to a prioritized transmission.

[0078] For control information related to a dropped transmit, the following may apply: a search space configuration for which a DCI was received (e.g., a DCI scheduling at least one TB associated with the dropped HARQ-ACK codebook) may be used. The search space configuration may include one or more of the following: monitoring periodicity and duration; monitoring pattern within slots; or search space index. A CORESET configuration for which a DCI was received (e.g., a DCI scheduling at least one TB associated with the dropped HARQ-ACK codebook) may be used. The CORESET configuration may include one or more of the following: CORESET index; CORESET duration; or BWP associated with CORESET. HARQ timing for the dropped transmit may be included.

[0079] For control information related to prioritized transmissions, one or more of the following may apply: The search space configuration for which the DCI was received (e.g., a DCI scheduling at least one TB associated with a prioritized HARQ-ACK codebook) may be used. The search space configuration may include one or more of the following: monitoring periodicity and / or duration; monitoring pattern within slots; or search space index. The CORESET configuration for which the DCI was received (e.g., a DCI scheduling at least one TB associated with a prioritized HARQ-ACK codebook) may be used. The CORESET configuration may include one or more of the following: CORESET index; CORESET duration; or BWP associated with CORESET. HARQ timing for prioritized transmissions may be included.

[0080] A WTRU can adapt HARQ-ACK codebooks. A WTRU can be configured to combine a dropped HARQ-ACK codebook with the next HARQ-ACK codebook transmission of the same codebook type. In the example, a WTRU can be configured to identify codebook types (e.g., dynamically). A WTRU can use the PUCCH resource instruction and HARQ feedback timing instruction to identify transmissions (e.g., new transmissions) and / or dropped HARQ-ACK codebooks (e.g., if it receives a downlink assignment of the same type). For example, a WTRU can be configured to determine the codebook type based on the codebook identifier. In slot n, the WTRU dropped a HARQ-ACK codebook with a codebook identifier equal to k. In slot n+1, the WTRU may receive a downlink assignment in slot n+4 that indicates a PUCCH resource and HARQ timing using the codebook identifier equal to k. WTRU can accommodate the dropped HARQ-ACK codebook in slot n by adapting to the size of the HARQ-ACK codebook (e.g., the new HARQ-ACK codebook size).

[0081] In the example, the WTRU may be configured to identify, for example, whether a dropped HARQ-ACK codebook can be combined with the next HARQ-ACK codebook, based on the DAI and / or counter DAI. The WTRU may be configured to interpret an increased step above a configured threshold in the counter DAI and / or total DAI as an indicator for combining an ACK / NACK transmission (e.g., a new ACK / NACK transmission) with the dropped HARQ-ACK. For example, the last counter DAI received by the WTRU showed a value of 1 before the HARQ-ACK drop. In the next assignment after the drop, the WTRU may receive a counter DAI and / or total DAI of value 4. The WTRU may then determine that the next HARQ-ACK codebook may contain the dropped HARQ codebook.

[0082] A trigger can be used to drop a HARQ-ACK codebook. A WTRU can be configured to drop a HARQ-ACK codebook scheduled to be transmitted on a given slot. A WTRU can be configured to drop a HARQ-ACK codebook on a given slot based on one or a combination of the following: the HARQ-ACK codebook overlaps with another uplink transmission (e.g., one with a higher priority than the HARQ-ACK codebook); or there is a power-limited scenario.

[0083] If a HARQ-ACK codebook overlaps with another uplink transmission that has a higher priority (for example, another HARQ-ACK codebook), that uplink transmission may include the other higher-priority HARQ-ACK codebook and may be scheduled to be transmitted via PUCCH or PUSCH. In the example of a PUSCH transmission, a WTRU may be configured to transmit URLLC type transmissions via PUSCH that overlap with a HARQ-ACK codebook.

[0084] In an example related to a power limiting scenario, the WTRU may consist of multiple overlapping transmits and / or maximum transmit power (Pmax). The WTRU may determine that one of the scheduled transmits cannot meet the BLER target due to the current path loss from the gNB.

[0085] A WTRU may be configured to determine the priority of a HARQ-ACK codebook based on the type of service associated with the HARQ-ACK codebook and / or whether a HARQ-ACK codebook was dropped in the previous slot. For example, a WTRU may be configured to associate priority with a HARQ-ACK codebook depending, for example, on the service type of at least one transport block associated with the HARQ codebook. A WTRU may continue to adjust priorities based on the status of the transmission. For example, after dropping a HARQ-ACK codebook, a WTRU may increase the priority of the dropped HARQ codebook transmission.

[0086] Figure 2 shows overlapping HARQ-ACK codebooks within a slot. For example, as shown in Figure 2, PUCCH1 transmitting HARQ-ACK codebook 1 may overlap (e.g., at least partially) with PUCCH2 transmitting HARQ-ACK codebook 2. As shown in Figure 2, a WTRU may consist of two overlapping HARQ-ACK codebooks within slot n-3. The WTRU may, for example, prioritize codebook 1 over codebook 2, dropping some transmissions of PUCCH2 that overlap with PUCCH1, and prioritizing HARQ-ACK codebook 1, as shown in Figure 2 and / or Figure 4. As shown in Figure 2, the WTRU may transmit the undropped portion of PUCCH2 that does not overlap with PUCCH1. The WTRU may determine that the number of remaining symbols in PUCCH2 (e.g., the number of remaining symbols in the non-overlapping portion of PUCCH2, as shown in Figure 2) is above a threshold (e.g., a configured threshold). The WTRU may, (e.g., if the WTRU determines that the number of remaining symbols in PUCCH2 exceeds the threshold), split HARQ-ACK codebook 2 into two subcodebooks, as shown in Figure 2 and / or Figure 4. The WTRU may, for example, use the remaining symbols of PUCCH2 in a slot (e.g., slot n-3 in the example in Figure 2) to send the first subcodebook in the non-overlapping portion of PUCCH2. The WTRU may determine whether or not the PUCCH resources configured for the dropped HARQ-ACK codebook (e.g., a second subcodebook or a HARQ-ACK subcodebook such as a complete HARQ-ACK codebook) are configured (e.g., for subsequent slots such as the next slot, future slots, etc.). The WTRU may decide whether to use a UL authorization assignment for a dropped HARQ-ACK codebook transmission, for example, as shown in Figures 2, 3, and / or 4. In slot n-2, the WTRU may, for example, from the end of PUCCH2 to T symbolA UL authorization may be received that begins after this. The WTRU may decide to transmit the second subcodebook of HARQ-ACK codebook 2 in accordance with the uplink authorization.

[0087] Figure 3 shows an example related to a WTRU configured with a PUCCH resource set up for a dropped codebook. As shown in Figure 3, a WTRU may consist of a dropped HARQ-ACK codebook that was not transmitted in the previous slot (e.g., a HARQ-ACK subcodebook such as the second subcodebook or the complete HARQ-ACK codebook in Figure 2). As shown in Figure 3, a WTRU may determine whether it is configured with a PUCCH resource set up for a dropped HARQ-ACK codebook. If a WTRU is configured with a PUCCH resource set up for a dropped HARQ-ACK codebook, the WTRU may use a PUCCH resource from the resource set, which is configured by applying an offset to the PRI of the dropped HARQ-ACK codebook. The WTRU may determine the HARQ-ACK timing based on the timing instructions of the dropped transmission. If a WTRU is not configured with a PUCCH resource set up for a dropped HARQ-ACK codebook, the WTRU may transmit the dropped HARQ-ACK codebook using UL authorization.

[0088] Figure 4 illustrates an example related to separating a dropped HARQ-ACK codebook into subcodebooks. As shown in Figure 4, a WTRU may consist of duplicate PUCCHs for each HARQ-ACK transmission (e.g., each HARQ-ACK codebook). A WTRU may prefer a HARQ-ACK codebook over another HARQ-ACK codebook (see, for example, Figure 2). A WTRU may determine whether the remaining amount of PUCCH symbols (e.g., the non-overlapping portion of the PUCCH that was not preferred, as shown in Figure 2) exceeds a threshold (e.g., a configured threshold). If it exceeds the threshold, a WTRU may separate the dropped HARQ-ACK codebook into two subcodebooks (e.g., Figure 2). A WTRU may transmit a first subcodebook with the remaining symbols of the configured PUCCH (e.g., the portion of the configured PUCCH that does not overlap with the preferred PUCCH, as shown in Figure 2). The WTRU may transmit a second subcodebook (e.g., the remaining bits of the dropped HARQ-ACK codebook) in a subsequent slot (e.g., the next slot, a future slot, etc.). If the WTRU determines that the number of PUCCH symbols is below a threshold, the WTRU may transmit bits of the dropped HARQ-ACK codebook (e.g., the complete subcodebook) in a subsequent slot (e.g., the next slot, a future slot, etc.).

[0089] A WTRU may be configured to send a dropped HARQ-ACK codebook in the slot initially scheduled to send the HARQ codebook. For example, a WTRU may be configured to send a HARQ-ACK codebook in slot n, and based on one of the triggers enumerated herein, the WTRU may drop the transmission of the HARQ-ACK codebook. The WTRU may, for example, send the A / N bits in the same slot n using the remaining non-repeating symbols.

[0090] A trigger may exist to send a dropped HARQ-ACK codebook within the same slot. The WTRU may be configured to (e.g., autonomously) determine whether a portion of the codebook can be sent with the remaining non-overlapping symbols of the PUCCH. The WTRU may isolate the HARQ-ACK codebook and send subcodebooks based on one or more of the following: the number of remaining symbols in the slot; the size of the dropped HARQ-ACK; the type of service associated with the HARQ-ACK codebook; or the BLER requirements of the HARQ-ACK codebook.

[0091] A WTRU may consist of several symbols, and if the remaining symbols exceed the number configured, the WTRU may transmit a portion of the HARQ-ACK codebook in the slot (e.g., a subcodebook).

[0092] PUCCH resources can be adapted for transmission. Assuming that a WTRU consists of two PUCCH resources for transmitting HARQ-ACK information in a slot, if the WTRU detects first and second DCIs, respectively, indicating first and second resources for PUCCH transmission with corresponding HARQ-ACK information in the slot, the WTRU may transmit the HARQ-ACK information according to one of the following:

[0093] A WTRU may transmit higher-priority HARQ-ACK information for PUCCH resources with an earlier starting symbol in the slot (e.g., the 10th symbol) and lower-priority HARQ-ACK information for PUCCH resources with a later starting symbol in the slot (e.g., the 12th symbol). Figure 5 shows HARQ-ACK transmissions across multiple PUCCH resources in slots of two TBs with different priorities.

[0094] A WTRU may send HARQ-ACK information related to a URLLC service in a PUCCH resource with an earlier start symbol in the slot (e.g., the nth symbol) and HARQ-ACK information related to an eMBB service in a PUCCH resource with a later start symbol in the slot (e.g., the n+2th symbol). Figure 6 shows HARQ-ACK transmissions in multiple PUCCH resources in slots for two different services.

[0095] The WTRU may transmit HARQ-ACK information related to low-latency transmissions in PUCCH resources corresponding to short-duration (e.g., 1-2 symbols) PUCCH formats, and HARQ-ACK information related to high-latency-tolerant transmissions in PUCCH resources corresponding to long-duration (e.g., 10 or 14 symbols) PUCCH formats. Figure 7 shows HARQ-ACK transmissions in multiple PUCCH resources within slots with different durations.

[0096] If two PUCCH resources have the same PRB offset, start symbol, and length, the WTRU may determine that the two PUCCH resources have different cyclic shift indices. 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 one PUCCH resource has the smallest cyclic shift index used to send HARQ-ACK information for a previously received DCI, and another PUCCH resource has the largest cyclic shift index used to send HARQ-ACK information for a later received DCI.

[0097] If the PUCCH resources have the same starting symbol, cyclic shift index, and length, the WTRU may determine that the two PUCCH resources have different PRB offsets. In this case, the WTRU may apply a rule (e.g., an implicit rule) to establish an association between each received DCI and the corresponding PUCCH resource. The WTRU may assume a PUCCH resource having the minimum PRB offset used for transmission of HARQ-ACK information corresponding to a previously received DCI, and a PUCCH resource having the maximum PRB offset used for transmission of HARQ-ACK information corresponding to a later received DCI or PDSCH. FIG. 8 shows HARQ-ACK transmission on multiple PUCCH resources within a slot having different RB offsets.

[0098] The A / N bit may be dropped from the HARQ-ACK codebook. The WTRU may adjust the size of the HARQ-ACK codebook so that it can transmit a part 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., this may be the first sub-codebook). The WTRU may select the number of bits to be configured from the most significant bits or the least significant bits within the HARQ-ACK codebook. For example, the WTRU may select a1, a2,... a n The WTRU may have a HARQ-ACK codebook with ACK / NACK bits. Even if the transmission is dropped, the WTRU may still have k non-overlapping symbols for PUCCH transmission. The WTRU may transmit a part of the HARQ-ACK codebook (e.g., this may be the first sub-codebook) where M ≤ N, e.g., a 1、 a 2、... a M or a N-M+1、 a N-M+2、...、 a NIt may be transmitted with M bits such as: The WTRU may be configured to determine the number M based on one or more of the following: the number of remaining symbols of PUCCH that overlap with another uplink transmission; or the reliability requirements of the HARQ-ACK codebook transmission.

[0099] The WTRU may be configured to transmit the remaining bits of the HARQ-ACK codebook in subsequent slots (e.g., the next slot, future slots, etc.) as described herein.

[0100] If a PUSCH indicated by a DCI overlaps with one of several PUCCH resources for HARQ-ACK transmission in a slot, one or more of the following may apply: The WTRU may transmit the HARQ-ACK on a PUCCH resource that does not overlap with the PUSCH and ignore other PUCCH resources or the scheduling DCI corresponding to that PUCCH resource that overlaps with the PUSCH. The WTRU may multiplex the HARQ-ACK with a transport block and transmit it on the PUSCH indicated by the DCI and ignore the PUCCH resource or the scheduling DCI corresponding to that PUCCH resource. The WTRU may transmit the HARQ-ACK on a PUCCH resource in response to the WTRU's DCI format detection and ignore other PUCCH resources and the PUSCH. If the WTRU is using a UL authorization configured for PUSCH transmission, the WTRU may ignore the PUSCH and transmit the HARQ-ACK on one of the PUCCH resources in response to the WTRU's DCI format detection.

[0101] While the features and elements of this disclosure may take into account protocols specific to LTE, LTE-A, New Radio (NR), or 5G, it should be understood that the solutions described herein are not limited to these scenarios and are applicable to other radio systems as well.

[0102] While features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in computer programs, software, or firmware embedded in computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, optical media such as CD-ROM disks, and digital multi-purpose discs (DVDs). A processor associated with the software may be used to implement a radio frequency transceiver for use in the devices described herein.

Claims

1. A device equipped with a processor, The aforementioned processor, It is determined that a Hybrid Automatic Resend Request Delivery Confirmation (HARQ-ACK) codebook is scheduled to be transmitted in the first slot, and a Physical Uplink Control Channel (PUCCH) Resource Indicator (PRI) is associated with the HARQ-ACK codebook, Deciding to drop the scheduled transmission in the first slot of the HARQ-ACK codebook, Determining the PUCCH resource set associated with the HARQ-ACK codebook, Selecting a resource from the PUCCH resource set based at least on the PRI, Determining the transmission time, The transmission of the HARQ-ACK codebook at the determined transmission time is to be transmitted in a second slot on the selected resource. A device configured to perform the following actions.

2. The HARQ-ACK codebook is a first HARQ-ACK codebook, and a second HARQ-ACK codebook is scheduled to be transmitted in the first slot. The device according to claim 1, wherein the decision to drop a scheduled transmission in the first slot of the HARQ-ACK codebook is based on the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook.

3. The device according to claim 2, wherein the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook includes the determination that the second HARQ-ACK codebook has lower delay requirements than the first HARQ-ACK codebook.

4. The device according to claim 2, wherein the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook includes the determination that the second HARQ-ACK codebook has higher reliability requirements than the first HARQ-ACK codebook.

5. The device according to claim 2, wherein the processor is configured to drop scheduled transmissions in the first slot of the first HARQ-ACK codebook, and the determined transmission time is determined based on control information related to the dropped first HARQ-ACK codebook transmission.

6. The device according to claim 2, wherein the determined transmission time is determined based on control information related to scheduled transmissions of the second HARQ-ACK codebook.

7. The device according to claim 2, wherein the processor is configured to apply an offset to the PRI and determine the PUCCH resource set.

8. The device according to claim 7, wherein the offset is based on the PRI associated with the second HARQ-ACK codebook.

9. It is determined that a Hybrid Automatic Resend Request Delivery Confirmation (HARQ-ACK) codebook is scheduled to be transmitted in the first slot, and a Physical Uplink Control Channel (PUCCH) Resource Indicator (PRI) is associated with the HARQ-ACK codebook, Deciding to drop the scheduled transmission in the first slot of the HARQ-ACK codebook, Determining the PUCCH resource set associated with the HARQ-ACK codebook, Selecting a resource from the PUCCH resource set based at least on the PRI, Determining the transmission time, The transmission of the HARQ-ACK codebook at the determined transmission time is to be transmitted in a second slot on the selected resource. A method that includes this.

10. The HARQ-ACK codebook is a first HARQ-ACK codebook, and a second HARQ-ACK codebook is scheduled to be transmitted in the first slot. The method according to claim 9, wherein the decision to drop a scheduled transmission in the first slot of the HARQ-ACK codebook is based on the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook.

11. The method according to claim 10, wherein the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook includes the determination that the second HARQ-ACK codebook has lower delay requirements than the first HARQ-ACK codebook.

12. The method according to claim 10, wherein the determination that the priority associated with the second HARQ-ACK codebook is higher than the priority associated with the first HARQ-ACK codebook includes the determination that the second HARQ-ACK codebook has higher reliability requirements than the first HARQ-ACK codebook.

13. Further comprising dropping the scheduled transmission in the first slot of the first HARQ-ACK codebook, The method according to claim 10, wherein the determined transmission time is determined based on control information related to the dropped first HARQ-ACK codebook transmission.

14. The method according to claim 10, wherein the determined transmission time is determined based on control information related to the scheduled transmission of the second HARQ-ACK codebook.

15. The method according to claim 10, further comprising applying an offset to the PRI to determine the PUCCH resource set.

16. The method according to claim 15, wherein the offset is based on the PRI associated with the second HARQ-ACK codebook.

Images