Time and code domain coverage enhancement

Abstract

To provide a system method and device for transmitting a transport block (TB) over a plurality of slots.SOLUTION: A first grant associated with a hybrid automatic repeat request (HARQ) process in a first set of slots is received. A first subset of the first set of slots is determined to be available and a second subset of the first set of slots is determined to be unavailable for the uplink transmission. The TB is segmented into a first segment and a second segment in response to the determination. The first segment is transmitted in a first subset of the first set of slots. A second grant associated with the HARQ process is received to transmit the TB in a second set of slots. A second segment of the TB is transmitted in a second set of slots.SELECTED DRAWING: Figure 13

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 061,491, filed August 5, 2020, U.S. Provisional Patent Application No. 63 / 136,514, filed January 12, 2021, U.S. Provisional Patent Application No. 63 / 167,883, filed March 30, 2021, and U.S. Provisional Patent Application No. 63 / 185,901, filed May 7, 2021, the contents of which are incorporated herein by reference. [Background technology]

[0002] In New Radio (NR), a WTRU can transmit the same transport block (TB) over multiple consecutive slots. A grant for the same TB can be retransmitted over up to eight slots. Summary of the Invention

[0003] Some implementations provide systems, methods, and devices for transmitting a transport block (TB) over multiple slots. A first grant associated with a hybrid automatic repeat request (HARQ) process is received in a first set of slots. A first subset of the first set of slots is determined to be available for uplink transmission, and a second subset of the first set of slots is determined to be unavailable. The TB is segmented into a first segment and a second segment in response to the determination. The first segment is transmitted in the first subset of the first set of slots. A second grant associated with the HARQ process is received to transmit the TB in the second set of slots. The second segment of the TB is transmitted in the second set of slots. [Brief explanation of the drawings]

[0004] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate similar elements and in which: [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communications system shown in FIG. 1A, according to one embodiment. [Figure 1C] 1B is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system shown in FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 is a block diagram illustrating an example of a block coding method. [Figure 3] 1 is a graph reflecting cell throughput for different numbers of VoIP users per cell. [Figure 4] FIG. 1 illustrates nominal and actual slots for an exemplary multi-slot PUSCH. [Figure 5] FIG. 1 is a block diagram illustrating an example implementation including outer coding between MAC and PHY. [Figure 6] FIG. 1 is a block diagram illustrating an example implementation including outer coding after channel coding. [Figure 7] FIG. 1 is a block diagram illustrating an exemplary implementation including orthogonal coding after modulation and channel coding. [Figure 8] FIG. 1 is a block diagram illustrating an example implementation including orthogonal coding after channel coding. [Figure 9] FIG. 2 is a block diagram illustrating an exemplary outer coding between MAC and PHY. [Figure 10]FIG. 2 is a block diagram illustrating an exemplary outer coding after channel coding. [Figure 11] FIG. 2 is a block diagram illustrating an exemplary orthogonal encoding after modulation and channel coding. [Figure 12] FIG. 2 is a block diagram illustrating an exemplary orthogonal encoding after channel encoding. [Figure 13] FIG. 1 is a block diagram illustrating an exemplary transmission of TB over multiple slots in the case of time domain duplex (TDD). [Figure 14] FIG. 1 is a block diagram illustrating an exemplary transmission of TB over multiple slots in the case of frequency domain duplex (FDD). [Figure 15] 1 is a flow diagram illustrating an example method for transmitting a TB over multiple slots. DETAILED DESCRIPTION OF THE INVENTION

[0005] 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. Communication system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communication system 100 may enable multiple wireless users to access such content through sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

[0006] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 (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 mobile phone, 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, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a consumer electronic device, a device operating in a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

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

[0008] The base station 114a may be part of the RAN 104, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and / or 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 a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a particular geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

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

[0011] 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).

[0012] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using NR.

[0013] 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 jointly implement LTE radio access and NR radio access, e.g., using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0015] 1A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a location such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106.

[0016] The RAN 104 may communicate with the CN 106, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, mobility, etc. The CN 106 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 will be understood that the RAN 104 and / or CN 106 may communicate directly or indirectly with other RANs that use the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may utilize NR radio technology, the CN 106 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0017] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a public switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, which use common communication protocols such as the transmission control protocol (TCP), user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP Internet protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may use the same RAT as RAN 104 or a different RAT.

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

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

[0020] The processor 118 may be a general-purpose processor, a special-purpose 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), any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0021] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 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 IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

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

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

[0024] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, 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, etc. In other embodiments, the processor 118 may access information and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

[0026] 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 information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0027] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (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, etc. The peripherals 138 may include one or more sensors. The sensor may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, and the like.

[0028] The WTRU 102 may include a full-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on both the UL (e.g., for transmission) and DL (e.g., for reception)) simultaneously and / or together. The full-duplex radio may include an interference management unit for reducing and or substantially eliminating self-interference through hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for transmitting and receiving some or all of the signals (e.g., associated with a particular subframe on either the UL (e.g., for transmission) or DL ​​(e.g., for reception)).

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

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

[0031] 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, user scheduling, etc. in the UL and / or DL. As shown in FIG. 1C, the eNodeBs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0032] 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. Although the foregoing elements are shown as part of the CN 106, it will be understood that any of these elements may also be owned and / or operated by an entity other than the CN operator.

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

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

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

[0036] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Furthermore, 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.

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

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

[0039] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distribution system (DS) or another type of wired / wireless network that carries traffic within and / or outside the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP and transmitted to the respective destination. Traffic between STAs within the BSS may be transmitted, for example, through the AP; the source STA may transmit traffic to the AP, which 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 may be transmitted between a source STA and a destination STA (e.g., directly between them) in a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

[0040] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a dynamically configured width. The primary channel may be the operating channel of the BSS and may be used by 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 an 802.11 system. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0041] High Throughput (HT) STAs may use 40 MHz wide channels for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.

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

[0043] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah, where the channel operating bandwidths and carriers are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to representative embodiments, 802.11ah may support meter-type control / machine-type communications (MTC), such as MTC devices, in macro coverage areas. MTC devices may have specific capabilities, including, for example, support for (e.g., support only for) specific and / or limited bandwidths. MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0044] WLAN systems that may support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that may be designated as a primary channel, which 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 configured and / or limited by the STA among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah example, the primary channel may be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the state of the primary channel. For example, if the primary channel is busy, STAs (that only support the 1 MHz operating mode) transmitting to the AP may consider all of the available frequency band to be busy, even if most of the available frequency band is idle.

[0045] In the United States, the available frequency band that can be used by 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 bandwidth available for 802.11ah is 6MHz to 26MHz depending on the country code.

[0046] 1D is a system diagram illustrating the RAN 104 and the CN 106, according to one embodiment. As noted above, the RAN 104 may communicate with the WTRUs 102a, 102b, 102c over the air interface 116 using NR radio technology. The RAN 104 may also communicate with the CN 106.

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

[0048] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. 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 varying or scalable lengths (e.g., including varying numbers of OFDM symbols and / or varying lengths of absolute time).

[0049] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c without accessing another RAN (e.g., eNodeBs 160a, 160b, 160c, etc.). In a standalone configuration, the WTRUs 102a, 102b, 102c may utilize one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in unlicensed bands. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate with and connect to gNBs 180a, 180b, 180c while also communicating with and connecting to another RAN, such as eNodeBs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement 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 act as mobility anchors for the WTRUs 102a, 102b, 102c, while the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0050] 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 the UL and / or DL, support for network slicing, DC, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D , the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

[0051] 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are shown as part of the CN 106, it will be understood that any of these elements may also be owned and / or operated by an entity other than the CN operator.

[0052] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for user authentication of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of the SMF 183a, 183b for registration, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMFs 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0054] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks such as the Internet 110 to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPFs 184, 184b may perform other functions such as packet routing and forwarding, user plane policy enforcement, support for multi-homed PDU sessions, handling user plane QoS, DL packet buffering, mobility anchoring, etc.

[0055] The CN 106 may facilitate communication with other networks. For example, the CN 106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. Furthermore, 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. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to the local DNs 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

[0058] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab 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 be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0059] Some implementations provide systems, methods, and devices for transmitting a transport block (TB) over a plurality of slots, wherein a first grant associated with a hybrid automatic repeat request (HARQ) process is received in a first set of slots. A first subset of the first set of slots is determined to be available for uplink transmission, and a second subset of the first set of slots is determined to be unavailable. The TB is segmented into a first segment and a second segment in response to the determination. The first segment is transmitted in the first subset of the first set of slots. A second grant associated with the HARQ process is received to transmit the TB in the second set of slots, and a second segment of the TB is transmitted in the second set of slots.

[0060] Some implementations provide a method for transmission scheduling implemented in a wireless transmit / receive unit, in which a medium access control (MAC) protocol data unit (PDU) is divided into multiple different coded PDU segments, the coded PDU segments are mapped to multiple different transmission occasions associated with different hybrid automatic repeat request (HARQ) process identifiers (PIDs), and the coded PDU segments are transmitted on the different transmission occasions.

[0061] In some implementations, one of the different coded PDU segments is retransmitted provided that the WTRU receives a retransmission grant for a HARQ PID associated with one of a plurality of different transmission occasions. In some implementations, the plurality of different transmission occasions includes a number of different transmission occasions, where the number is received in a dynamic indication. In some implementations, the dynamic indication is received indicating whether segmentation is used, the number of slots in which the coded PDU segment is transmitted, whether the mapping includes interleaving, whether the mapping includes frequency hopping, and / or the HARQ PID of the associated HARQ process.

[0062] In some implementations, each of the multiple different transmission occasions comprises a slot. In some implementations, the modulated symbols of each coded PDU segment are mapped to a different slot. In some implementations, the multiple coded PDU segments are coded after the MAC PDU is segmented into multiple different coded PDU segments. In some implementations, the MAC PDU is coded before being segmented into multiple different coded PDU segments. In some implementations, the different MAC PDUs are transmitted using scheduled HARQ processes that are not associated with the multiple different coded PDU segments. In some implementations, the transmission occasion is a physical uplink shared channel (PUSCH) transmission occasion. In some implementations, the transmission occasion is a physical uplink control channel (PUCCH) transmission occasion. In some implementations, a timer is maintained for each different HARQ PID, and the WTRU stops and / or starts the time for each different HARQ PID simultaneously.

[0063] Some implementations provide a wireless transmit / receive unit (WTRU), a network device configured for wireless networking, a computing device, an integrated circuit, an eNodeB (eNB), a next generation NodeB (gNB), a base station (BS), or an access point (AP) configured to perform the above-described methods. Some implementations provide a non-transitory computer-readable medium including instructions that, when executed by a processing device, cause the processing device to perform the above-described methods.

[0064] Various abbreviations and acronyms used herein include the following: Context-dependent grant or cell group (CG), Dynamic grant (DG), Channel access priority class (CAPC), Downlink feedback information (DFI), HARQ Process ID (HARQ PID), enhanced Licensed Assisted Access (eLAA), Further enhanced Licensed Assisted Access (FeLAA), MAC control element (MAC CE), RACH occasion (RO), random access (RA), physical random-access channel (PRACH), Acknowledgement (ACK), Block Error Rate (BLER), Bandwidth Part (BWP), Channel Access Priority (CAP), Clear Channel Assessment (CLA) Frequency Assessment (CCA), Cyclic Prefix (CP), Conventional OFDM relying on cyclic prefix (CP-OFDM), Channel Quality Indicator (CQI), Cyclic Redundancy Check (CRC), Channel State Information (CSI), Contention Window (CW), Contention Window Size (CWS), Channel OccupancyOccupancy (CO), Downlink Assignment Index (DAI), Downlink Control Information (DCI), Downlink (DL), Demodulation Reference Signal (DM-RS), Data Radio Bearer (DRB), Hybrid Automatic Repeat Request (HARQ), License Assisted Access (LAA), Listen-Before-Talk (LBT), Long Term Evolution (LTE), e.g., 3GPP LTE R8 and later, Negative ACK (NACK), Modulation and Coding Scheme (MCS), Multiple Input Multiple Output (MIMO), New Radio (NR), Orthogonal Frequency-Division Multiplexing (OFDM), Physical Layer Layer (PHY), Physical Random Access Channel (PRACH), Primary Synchronization Signal (PSS), Random Access Channel (RACH), Random Access Response (RAR), Radio access network Central Unit (RCU), Radio Front end (RF), Radio Link Failure (RLF), Radio Link Monitoring (RLM), Radio Network Identifier (RNTI), Radio Resource Control (RRC), Radio Resource Management (RadioResource Management (RRM), Reference Signal (RS), Reference Signal Received Power (RSRP), Received Signal Strength Indicator (RSSI), Service Data Unit (SDU), Sounding Reference Signal (SRS), Synchronization Signal (SS), Secondary Synchronization Signal (SSS), Self-Contained Subframe, Switching Gap (SWG), Semi-persistent scheduling (SPS), Supplemental Uplink (SUL), Transport Block (TB), Transport Block Size (TBS), Transmission / Reception Point (TRP), Time-sensitive communications (TSC), Time-sensitive networking (TSN), Uplink (UL), Ultra-Reliable and Low Latency Communications (UHRC) Wireless Local Area Networks (WLANs) and related technologies, such as in the IEEE 802.xx domain.

[0065] Some NR implementations include multi-TTI scheduling. Some NR Release 15 implementations support uplink slot aggregation, e.g., allowing a WTRU to transmit the same transport block (TB) over multiple consecutive slots, possibly using different redundancy versions (RVs) and frequency hopping. This may be supported for both dynamic and configured grants. A grant for the same TB may be retransmitted over up to eight slots using the same HARQ process. Each retransmission in a bundle of retransmissions may be treated like a retransmission with an incremented RV without waiting for feedback. For example, in some implementations, eight consecutive transmissions of the same TB with different RVs are the same as eight retransmissions with an incremented RV but without waiting for HARQ feedback.

[0066] In some NR Release 16 implementations, multi-TTI scheduling is extended, for example, for NR-U WTRUs. In some examples, a gNB may use a single DCI to allocate multiple physical uplink shared channel (PUSCH) transmission occasions to a WTRU, e.g., to reduce the number of LBTs and / or increase channel acquisition opportunities. The PUSCH occasions of a multi-TTI grant may be contiguous in the time domain. The single DCI scheduling the multi-TTI grant may indicate the HARQ process ID, the number of occasions, and / or the RV. The signaled HARQ PID may apply to the first TTI / PUSCH occasion in the bundle. For each subsequent PUSCH occasion, the WTRU may increment the signaled PID by one. The WTRU may map the generated TB to a different HARQ process if the LBT fails, and the WTRU may transmit a TB pending transmission on an HARQ process due to a failed LBT in a different HARQ process associated with a PUSCH where the LBT was successful. The TB may include or be a different and / or new TB if the same RV and TB size (TBS) as the signaled one are used.

[0067] Some implementations include code domain coverage extension in the physical uplink control channel (PUCCH). In some implementations, for example, for NR-PUCCH, multiple formats are possible for a given PRB. For example, in Format 0 (short PUCCH), one or two symbols may be used to transmit up to two bits of UCI (e.g., including HARQ-ACK or SR). The two bits may be the same in each symbol. In some implementations, a different cyclic shift may be used in the second symbol, resulting in frequency diversity. For example, in Format 2 (short PUCCH), one or two symbols may be used to transmit more than two bits of UCI (e.g., including CSI reporting, multi-bit HARQ-ACK codebook, and / or SR). For example, in Format 1 (long PUCCH), half of the symbols are for RS channel estimation, so up to two bits can be transmitted. In some implementations, frequency hopping (as in LTE) may be configured. In format 3 or format 4 (long PUCCH), more than two bits can be transmitted, possibly using frequency hopping and UE code multiplexing.

[0068] In some implementations, a PUCCH may be configured on a Primary Cell (PCell) and a Primary Secondary Cell (PSCell). A WTRU may be configured with two PUCCH groups, and each group may be used to provide UCI for several DL carriers.

[0069] In some implementations, the NR-PUCCH bits may be coded using an orthogonal code to provide better PUCCH capacity (e.g., relative to uncoded NR-PUCCH bits) while potentially maintaining good coverage (e.g., better than a short PUCCH) for longer PUCCH formats.

[0070] To generate such orthogonal codes, 12 base length sequences may be used (e.g., the same sequences used for RS generation). This may result in 12 possible cyclic shifts in the time domain (i.e., 12 phase rotations in the frequency domain), and therefore it may be possible to multiplex up to 12 WTRUs, e.g., if they each transmit one bit on the same resource and use the same MCS. In some implementations, not all cyclic shifts may be usable, e.g., in high delay spread and / or multipath environments, or among symbols occupying an RS.

[0071] For long PUCCH formats, additional spreading may be performed using orthogonal discrete Fourier transform (DFT) codes, e.g., to match the number of symbols in the long PUCCH format. In some implementations, this may additionally or alternatively increase the WTRU multiplexing capacity while improving coverage (e.g., for devices with the same cyclic shift). In some implementations, the number of devices that can multiplex on the same resource can be roughly estimated as the length of the orthogonal code plus the number of cyclic shifts used.

[0072] In some implementations, cyclic shift hopping is applied to the PUCCH transmission. In some implementations, the cyclic shift can be varied between different slots by adding an offset to each slot, whereby the offset is provided by a WTRU pseudo-random sequence. In some implementations, this randomizes interference between different WTRUs and / or different cells. In some implementations, if the number of PUCCH bits is large (e.g., greater than 2 bits), a scrambling sequence based on the C-RNTI can be used to randomize interference between the WTRU and other cells. The maximum code rate can be used to determine resource consumption.

[0073] Some implementations include a HARQ operating point. From the network's perspective, a scheduler may operate using a target HARQ operating point. The number of HARQ transmissions required to successfully receive and decode a transport block, e.g., to reach a sufficient amount of received energy per transmitted bit, may be referred to as the HARQ operating point. In some implementations, the scheduler may vary the HARQ operating point to optimize resource usage (e.g., the number of PRBs for a given TB transmission), transmit power (e.g., more transmissions with less power each, or vice versa), and / or latency (e.g., fewer transmissions that can complete transmission sooner in time). In some implementations, the scheduler may adapt the HARQ operating point, e.g., to implement different strategies for accumulating transmitted energy at the receiver, e.g., by varying the number of PRBs, the assigned MCS, and / or the transmit power.

[0074] Some implementations include block coding. Data retransmission can be considered as simple retransmission coding. In some implementations, when three or more resource sets are available, instead of duplicating the same data for every transmission, a block coding stage can be introduced. For example, data (either raw data bits or modulated bits) is first divided into K blocks, from which K+L MAC-coded blocks are generated and transmitted over the K+L resource sets. At the receiver side, if at least K transmissions are successfully received, the data can be recovered. In one example, for three resource sets, the data can be divided into two blocks, and the additional block can be generated as a sum (e.g., a binary sum) of the two blocks (e.g., as a parity code). When more resource sets are involved, codes such as Reed-Solomon codes or Fountain codes can be used to generate the additional blocks. In some implementations, each MAC-coded block can be sent to the physical layer as a separate TB or TB segment.

[0075] Figure 2 is a block diagram illustrating an example block coding scheme for four resource sets (K=3, L=1) in the time domain. In Figure 2, a PDU 200 is divided into three PDU blocks 202, 204, and 206. A block encoder 208 encodes the PDU blocks 202, 204, and 206 as coded blocks 210, 212, 214, and 216. In this example, the PDU blocks 202, 204, and 206 are coded as coded blocks 210, 212, and 214, respectively, and coded block 216 is generated as a sum (e.g., a parity code) of the coded blocks 210, 212, and 214. The coded blocks 210, 212, 214, and 216 are sent to physical layer processing for transmission during different time slots. Note that the sum refers to the binary sum of the three blocks used with respect to this figure. For example, if coded block 210 = (a1, a2, ..., aN), coded block 212 = (b1, b2, ..., bN), and coded block 214 = (c1, c2, ..., cN), then coded block 216 = (a1 + b1 + c1, a2 + b2 + c2, ..., aN + bN + cN), where + is a binary sum.

[0076] In some implementations, such block coding may be more efficient for a larger number of resource sets and under conditions with sparse fading (e.g., fast fading) and / or bursty interference, e.g., due to the very low probability of deep fades hitting an undesirable number (e.g., above a threshold number, or more than a few) of resource sets. In some implementations, for N resource sets, block coding consumes (e.g., approximately) an (N / K)-fold increase in energy per information bit for transmission, where N=K+L.

[0077] In some implementations, the channel state information (CSI) may include at least one of a channel quality index (CQI), a rank indicator (RI), a precoding matrix index (PMI), a layer 1 (L1) channel measurement (e.g., an RSRP such as L1-RSRP, or a signal to interference plus noise ratio (SINR), a CSI-RS resource indicator (CRI), an SS / PBCH block resource indicator (SSBRI), a layer indicator (LI), and / or any other measurement measured by the WTRU from a configured CSI-RS or SS / PBCH block.

[0078] In some implementations, the uplink control information (UCI) may include CSI, HARQ feedback for one or more HARQ processes, a scheduling request (SR), a link recovery request (LRR), CG-UCI, and / or other control information bits. In some implementations, the UCI may be transmitted on a PUCCH or a PUSCH. In some implementations, the channel conditions may include any condition regarding radio / channel conditions that may be determined by the WTRU based on WTRU measurements (e.g., L1 / SINR / RSRP, CQI / MCS, channel occupancy, RSSI, power headroom, exposure headroom), L3 / mobility-based measurements (e.g., RSRP, RSRQ), RLM status, and / or channel availability in the unlicensed spectrum (e.g., whether the channel is occupied based on a determination of an LBT procedure or whether the channel is deemed to have experienced consistent LBT failures).

[0079] In some implementations, the PRACH resource includes the PRACH resource (e.g., in frequency), the PRACH occasion (RO) (e.g., in time), the preamble format (e.g., in terms of total preamble duration, sequence length, guard time duration, and / or cyclic prefix length), and / or the specific preamble sequence used for transmitting the preamble in the random access procedure.

[0080] In some implementations, the properties of the scheduling information (e.g., of an uplink grant or a downlink assignment) may include at least one of the following: frequency allocation, aspect of the time allocation (e.g., duration, priority, modulation and coding scheme, transport block size, number of spatial layers, number of transport blocks to be carried, TCI state or SRI, number of retransmissions, whether the grant is a configured grant Type 1, Type 2, or dynamic grant, whether the retransmission scheme is Type A or Type B, whether the grant is a configured grant Type 1, Type 2, or dynamic grant, configured grant index or semi-persistent assignment index, configured grant or assignment periodicity, Channel Access Priority Class (CAPC), and / or any parameters provided in the DCI by the MAC-CE or by RRC signaling to schedule the grant or assignment.

[0081] In the following, properties of data contained in a transport block (TB) may refer to parameters configuring the logical channel or radio bearer in which the data may be contained in the TB. For example, properties of data contained in a TB may include at least one of logical channel priority, prioritized bit rate, logical channel group, and / or RLC mode. By extension, properties of a grant or allocation may also refer to properties of the data contained in the corresponding TB.

[0082] In some implementations, the indication by the DCI may include at least one of an explicit indication by a DCI field or by an RNTI used to mask the CRC of the PDCCH, and / or an implicit indication by properties such as a DCI format, a DCI size, a core set or search space, an aggregation level, and / or an identity of a first control channel resource (e.g., an index of a first CCE) for the DCI, and the mapping between the property and the value may be signaled by RRC signaling or MAC-CE.

[0083] In low SNR conditions, transmission based on retransmission with RV cycling may not be optimal, for example, in situations with limited power headroom, limited cell capacity, or stringent latency requirements. Coverage extension retransmission techniques may require non-narrowband frequency domain allocation to accommodate the TB size within a slot (e.g., potentially larger than one PRB).

[0084] Even if the TB size is not large, there may be certain latency requirements (e.g., for VoIP or TSC traffic) that may not be met if a large number of retransmissions are required to meet the HARQ operating point. Furthermore, from a cell load / capacity perspective, if a cell is serving many devices in cell edge conditions, retransmissions may limit the number of devices served and may result in starvation of non-GBR traffic within the cell. This is shown in Figure 3.

[0085] Figure 3 is a graph reflecting cell throughput for different numbers of VoIP users per cell for a simulation of a cell supporting VoIP and Internet traffic in a 10 MHz LTE cell. In one example, for VoIP service, packets arrive in bursts of 308 kbps every 20 ms, which corresponds to 15.4 kbps. Therefore, the maximum data rate can be 15.4 kbps, which includes header overhead and robust header compression (ROHC). ROHC, packet data convergence protocol (PDCP), radio link control (RLC), and / or medium access control (MAC) headers can be dropped if the grant size cannot accommodate them. Therefore, the guaranteed bit rate is 12.2 kbps, which accommodates data bits without headers. As shown in Figure 3, the network can serve up to 240 VoIP users at 15.4 kbps, but the Internet best-effort rate drops as more VoIP users are added. Beyond 240 VoIP users, non-GBR traffic is stopped and additional VoIP users are served at 12.2 kbps. This shows that supporting many VoIP users in a single cell can limit capacity, especially when coverage requires retransmissions.

[0086] Therefore, in some implementations, relying solely on retransmissions to meet coverage requirements for GBR traffic may incur one or more of the following costs and drawbacks: a non-narrowband frequency allocation resulting in a lower power spectral density for the TB, increased latency required to transmit the TB / reach the required HARQ operating point, and / or increased cell load, possibly at the expense of other service types / users in the cell.

[0087] In some implementations, spreading a TB over multiple slots in the time domain can improve power spectral density. In some implementations, a single TB can be scheduled over multiple slots using a narrow frequency allocation, or the TB can be divided into multiple coded segments transmitted over multiple TTIs. It may be desirable to retransmit a portion of a TB that was not successfully decoded. If the TBS is small, retransmission of the CBG may not be possible.

[0088] In some implementations, depending on the solution chosen, one TB may be associated with more than one HARQ process. In some such cases, HARQ process buffer management and / or flushing buffers upon new data indicator (NDI) toggling may be complicated. For example, timers and operations maintained at higher layers (e.g., discontinuous reception (DRX) timers, retransmission grant and timers, CG timers, etc.) are maintained per HARQ process and are based on having a one-to-one mapping between TBs and HARQ processes.

[0089] A "slot" may refer to a set of 14 time symbols, for example, as defined in the NR specifications. A "subslot" may refer to a smaller set of time symbols within a slot, or possibly across two slots. The terms "slot" and "subslot" may be used interchangeably, and solutions applicable at the slot level may also be applicable at the subslot level. A time interval in which resources are available for a WTRU to map PUSCH modulation symbols and associated DMRS of a PUSCH transmission may be referred to as a "PUSCH occasion." A time interval in which resources are available for a WTRU to map PUCCH modulation symbols and associated DMRS of a PUCCH transmission may be referred to as a "PUCCH occasion."

[0090] Some implementations combine resources of multiple slots for a single PUSCH (or PUCCH) occasion for a multi-slot transmission. In some implementations, the WTRU may generate a transmission that occupies resources across more than one slot (M slots) in the time domain. Such processing may be referred to as a "multi-slot transmission." Such processing may be applicable to PUSCH and / or PUCCH transmissions. In some implementations, such processing may be applicable to other types of transmissions.

[0091] When the WTRU performs multi-slot transmission, the modulated symbols for transmission may be mapped to the combined resources of multiple slots. For example, the modulated symbols may be mapped in the same manner as in existing systems (e.g., frequency first, time second). In some implementations, the physical resources for multi-slot transmission may include a set of M slots. In some implementations, the physical resources for multi-slot transmission may also include at least one of the following for each slot: time symbols, frequency domain allocation (set of PRBs) including frequency hopping information, spreading code, beam indication such as SRS identifier, CSI-RS identifier, or TCI state, bandwidth fraction, subcarrier spacing, DMRS configuration or mapping type, and / or resource index (e.g., for PUCCH).

[0092] In some implementations, the WTRU may determine whether to perform multi-slot transmission, the number of slots M, and / or at least one property of the grant from an explicit indication by the DCI or from a semi-static configuration. The WTRU may obtain at least one of the following: a time symbol, a frequency-domain allocation (set of PRBs) including frequency hopping information, a spreading code, a beam indication such as an SRS identifier, a CSI-RS identifier, or a TCI state, a bandwidth portion, a subcarrier spacing, a DMRS configuration or mapping type, and / or a resource index (e.g., for PUCCH), and apply it to all slots. The WTRU may obtain at least one of the following: a time symbol, a frequency-domain allocation (set of PRBs) including frequency hopping information, a spreading code, a beam indication such as an SRS identifier, a CSI-RS identifier, or a TCI state, a bandwidth portion, a subcarrier spacing, a DMRS configuration or mapping type, and / or a separate resource index per slot (e.g., for PUCCH). The multi-slot transmission may be applicable to a subset of HARQ processes configured by higher layers.

[0093] In some implementations, the WTRU may determine the set of M slots based on at least one of higher layer configuration, the timing of the DCI indicating the transmission (e.g., slot index), the delay between receiving the DCI and the start of the transmission (e.g., as indicated by a time domain resource allocation field), the number of slots configured by higher layers or indicated by the DCI, and / or the slot configuration for at least one slot configured by higher layers and / or indicated by the DCI (e.g., in the slot formation indication).

[0094] For example, the WTRU may determine the set of slots as the set of K slots starting from the slot index (n) at which the DCI is received plus the delay for the slot (k2). The set of slots may be the set of K consecutive slots {n+k2, n+k2+1, ... n+K-1}, or the set of the first K slots following and including slot n+k2 corresponding to a particular slot configuration that is semi-statically configured and / or dynamically indicated. For example, the set of slots may correspond to a slot configuration that includes only uplink symbols or a slot configuration that includes at least one uplink symbol.

[0095] Alternatively, the WTRU may determine the time domain resource as the set of N time symbols following and including symbol m+k2, where m may be the symbol index of the last (or first) symbol of the PDCCH containing a grant and k2 may correspond to the delay in number of symbols. The set of N time symbols may correspond to symbols configured as uplink, or possibly configured as uplink or flexible, according to the slot configuration.

[0096] In some implementations, the WTRU may multiply the modulated symbols (or coded bits) by a spreading sequence in the time domain before mapping to physical resources. The size of the spreading sequence may be a function of (or correspond to) the number of slots M of a multislot allocation and / or the number of resource elements available for transmission. Such a spreading operation may facilitate multiplexing of WTRUs on the same resource.

[0097] Some implementations include transmitting or retransmitting segments of a multi-slot transmission. In some implementations, the WTRU may process the TB and map modulated symbols across resources of a set of slots, e.g., as described above. In some implementations, the WTRU may determine a set of coded bits and / or modulated symbols for transmission over each slot (or sub-slot). Each such set of coded bits and / or modulated symbols mapped to resources of a slot (or sub-slot) may be referred to as a segment of the multi-slot transmission.

[0098] In some implementations, the WTRU may transmit a first segment of a transmission over a first slot or set of slots, and then retransmit the segment over a second slot or set of slots. In some implementations, the WTRU remaps the coded bits and / or modulated symbols of the segment to the resources of the second slot or set of slots for retransmission. To support this, in some implementations, the WTRU may keep the coded bits and / or modulated symbols for each applicable HARQ process in memory and may flush this information when new data is indicated for the HARQ process.

[0099] In some implementations, the WTRU may transmit or retransmit segments in a slot based on higher layer configuration and / or dynamic indication. For example, the WTRU may receive a DCI indicating a multislot transmission of M slots for the TB of an HARQ process. The DCI may also indicate a subset of segments for mapping across M'<=M slots, where M' slots may be determined using one of the methods described above for multislot or multi-PUSCH transmission. For example, in some implementations, the indication of the subset of segments may include a bitmap, and M' may indicate the number of segments to be transmitted or retransmitted according to the bitmap.

[0100] In some implementations, a WTRU may transmit a TB over multiple slots, and the slots or sets of slots may be contiguous or non-contiguous. For example, a WTRU may transmit a TB over a first set of slots and then transmit or retransmit another segment of the TB over a second set of slots. The WTRU may transmit or retransmit another segment of the TB over the second set of slots, for example, upon or after an interruption in the transmission of the first segment. The transmission of the second segment may be triggered by a condition, event, or signal. For example, the transmission of the second segment may be triggered by scheduling a grant or by the availability of a grant for the second set of slots. The second set of slots may be non-contiguous in the time domain with the first set of slots. The WTRU may determine which portion of the TB to transmit or retransmit, for example, based on the number of slots, the number of PRBs, the TBS, and / or the resource allocation of the grant for the second set of slots. For example, the WTRU may transmit a portion of a TB that was dropped (i.e., not transmitted for a specific reason). For example, the WTRU may transmit a portion of a TB that was dropped due to UL slot cancellation or due to UL slot unavailability (e.g., in a dynamic time domain duplex (TDD) environment) in a grant in the second set of slots. In some implementations, the WTRU may transmit a portion of a TB that was dropped due to UL slot cancellation or UL slot unavailability if the second grant has a grant size that matches the number of slots that were interrupted in the first set of slots or is larger than the size (e.g., in bits or RE) of the canceled or interrupted UL slot. The WTRU may send such transmissions or retransmissions of TB segments according to the conditions.For example, the WTRU may transmit or retransmit the TB if a grant is received for a second set of slots, if the grant is for the same HARQ process used to initially transmit / store the TB, if the grant is a retransmission grant (e.g., indicated by the NDI not being flipped), if the size of the grant is greater than or equal to the size of the interrupted / indicated slot (e.g., the grant is scheduled over the same number of slots and / or PRBs of the interrupted slot), and / or if the TBS of the grant is less than or equal to the size of the TB.

[0101] In some implementations, the WTRU may retransmit one or more PUSCH transmissions in a multi-slot transmission in one or more slots if the PUSCH transmission is preempted. For example, a PUSCH transmission may be preempted by another PUSCH transmission, by a PUCCH transmission, or by another reference signal. The WTRU may receive a configuration from the network to retransmit a preempted PUSCH transmission or PUSCH transmissions in one or more slots scheduled by the DCI. In some implementations, the WTRU may transmit or retransmit a PUSCH transmission (e.g., a TB or a portion of a TB) in a second retransmission grant scheduled for a second set of slots. In some implementations, the WTRU may transmit or retransmit a PUSCH transmission in a second retransmission grant scheduled for a second set of slots if the number of slots and / or PRBs in the second grant matches the number of slots and / or PRBs canceled or preempted during the initial transmission or retransmission.

[0102] Some implementations include multi-PUSCH transmissions. In some implementations, the WTRU may generate a set of processed PUSCH transmissions from the same transport block (TB) (e.g., based on multiple coded blocks therefrom) and transmit each PUSCH transmission of the set on a different PUSCH occasion. PUSCH retransmission schemes defined in existing systems are examples of multi-PUSCH transmissions, where a PUSCH occasion corresponds to a set of symbols in a slot and the sets of PUSCH transmissions are generated from different redundancy versions of the channel coding bits.

[0103] Some implementations include multi-PUCCH transmissions. In some implementations, the WTRU may generate a set of processed PUCCH transmissions from the same uplink control information (UCI) bits (e.g., based on multiple coded blocks therefrom) and transmit each PUCCH transmission of the set on a different PUCCH occasion. The PUCCH retransmission schemes defined in existing systems are examples of multi-PUCCH transmissions, where a PUCCH occasion corresponds to a set of symbols in a slot and a set of PUCCH transmissions are retransmissions.

[0104] Some implementations include combined multi-PUSCH (or multi-PUCCH) and multi-slot operation. In some implementations, the WTRU may generate a set of PUSCH (or PUCCH) transmissions and may transmit each PUSCH (or PUCCH) during either a single-slot or a multi-slot PUSCH (or PUCCH) occasion. The WTRU may determine the number of transmissions K and may determine parameters defining the multi-slot allocation according to the above for each transmission, and / or the above parameters may be configured by RRC or signaled by DCI. The WTRU may also determine a set of slots Sk associated with each transmission k and allocate the indicated resources for the set of slots Sk to the kth retransmission. Such a determination may be implicit from the number of slots M per multi-slot allocation or from the total number of slots M across all retransmissions obtained by semi-static or dynamic signaling.

[0105] Some implementations include transmitting coded TB segments across multiple PUSCH occasions. The following various examples illustrate exemplary multi-PUSCH transmission schemes. Some implementations allow TB transmission over one or more slots. For example, in some implementations, an information element is used to configure the time-domain relationship between the PDCCH (carrying the DCI scheduling UL grant) and the PUSCH, and the time-domain length of the scheduled PUSCH. In some implementations, the information element is a "PUSCH Time-Domain Resource Allocation" and / or a "PUSCH-Allocation-r16" information element. In some implementations, the information element (e.g., the "PUSCH Time-Domain Resource Allocation" information element) includes a K2 value, a mapping type, and / or a start symbol and length (SLIV). In some implementations, the K2 value indicates the time difference between the PUCCH and the PUSCH in units of slots. In some implementations, the mapping type indicates the mapping type of the DMRS within the allocated resources. In some implementations, the start symbol and length (SLIV) indicates the PUSCH start symbol and length in units of symbols.

[0106] As used herein, a "list of possible PUSCH time domain resource allocations" may include, for example, the PUSCH-TimeDomainResourceAllocationList or puschAllocationList-r16 information element, as used in the 3GPP specifications.

[0107] Some implementations dynamically allow multi-slot PUSCH transmission. In some implementations, the WTRU may be configured to interpret the length indicated by the SLIV parameter of an information element (e.g., the "PUSCH Time Domain Resource Allocation," "PUSCH-TimeDomainResourceAllocationList," and / or "PUSCH-Allocation-r16" information element) in units of slots instead of symbols. For example, the information element (e.g., the "PUSCH Time Domain Resource Allocation" or "PUSCH-TimeDomainResourceAllocationList" information element) may include a parameter (e.g., an additional parameter) indicating the unit of the PUSCH time domain resource allocation. Alternatively, in some implementations, the SLIV parameter is replaced by a starting symbol parameter and / or an additional parameter to indicate the number of slots allocated for multi-slot transmission.

[0108] In some implementations, the WTRU may be semi-statically configured (e.g., using RRC signaling) with a list of possible PUSCH time domain resource allocations. In some implementations, the list of possible PUSCH time domain resource allocations includes a subset of PUSCH time domain resource allocations across multiple slots. In some implementations, the list of possible PUSCH time domain resource allocations also, or alternatively, includes a subset of PUSCH time domain resource allocations across a single slot and / or sub-slot. In some implementations, the DCI scheduling the uplink grant may include an indication (e.g., a bit field) indicating which PUSCH time domain resource allocation to use from the configured list. In some implementations, after receiving the uplink grant, the WTRU uses the time domain resource allocation indication to determine whether the PUSCH transmission will span multiple slots or a single slot or sub-slot.

[0109] In some implementations, the WTRU may be semi-statically configured (e.g., using RRC signaling) with two separate lists of possible PUSCH time domain resource allocations. In some implementations, the first list includes only PUSCH time domain resource allocations across multiple slots. In some implementations, the second list includes only PUSCH time domain resource allocations across a single slot or sub-slot. In some implementations, the DCI scheduling the uplink grant may include an indication (e.g., a bit field) indicating which list to select from. In some implementations, the DCI scheduling the uplink grant may include an indication (e.g., a bit field) indicating which PUSCH time domain resource allocation to use from the indicated list. In some implementations, after receiving the uplink grant, the WTRU determines whether the PUSCH transmission will span multiple slots or a single slot or sub-slot based on the bit field indication indicating which list to select from.

[0110] In some implementations, the WTRU may be semi-statically configured (e.g., using RRC signaling) with a list of possible PUSCH time-domain resource allocations that only include PUSCH time-domain resource allocations over a single slot and / or sub-slot. In some implementations, the DCI scheduling the uplink grant may include an indication (e.g., a bit field) indicating the number of allocated slots in addition to the time-domain resource allocation over a single slot and / or sub-slot. In some implementations, the WTRU may determine that the scheduled grant is a transmission over multiple slots if the indicated number of allocated slots is greater than one. In some implementations, the WTRU may assume that the indicated SLIV is the same across different scheduled slots. Alternatively, in some implementations, the WTRU may assume that the SLIV is in units of slots instead of symbols if the number of allocated slots is greater than one.

[0111] Some implementations include retransmissions using a single slot. For example, in some implementations, the WTRU may be configured to retransmit using a single-slot PUSCH transmission a transport block that was initially transmitted in a multi-slot PUSCH transmission. In some implementations, the WTRU may determine the type of PUSCH transmission (e.g., single-slot PUSCH transmission or multi-slot PUSCH transmission) using, for example, methods described herein. In some implementations, if the WTRU uses a single slot for the retransmission, the WTRU may be configured to use a modulation and coding scheme (MCS) index that is higher than a pre-configured MCS value.

[0112] Some implementations include discontinuous and / or suspended multi-slot transmissions. For example, in some implementations, a WTRU may be configured to transmit a discontinuous multi-slot PUSCH transmission. In some implementations, the slots and / or symbols available for discontinuous multi-slot PUSCH transmission may be indicated using an indication (e.g., a dedicated bit field) in the DCI. In some implementations, the slots and / or symbols available for discontinuous multi-slot PUSCH transmission may be indicated by reusing existing fields in the DCI (e.g., existing bit fields such as the FDRA and / or MCS bit fields). In some implementations, a WTRU may be configured to transmit a multi-slot PUSCH transmission and receive an indication that a portion of the configured slot, slots, symbol, or symbols for transmission is not available. This indication may be referred to as a suspend indication. In some implementations, the WTRU stops transmission in the slot, slots, symbol, or symbols indicated by the suspend indication. In some implementations, the suspend indication may be transmitted in a DCI different from the scheduling DCI. For example, after receiving an UL grant and starting transmission, the WTRU may receive another DCI indicating that a set of resources (slots and / or symbols) are not available and that the WTRU should stop transmitting on the indicated resources. In some implementations, the suspend indication may be sent in a scheduling DCI.

[0113] In some implementations, the WTRU may exclude and / or not transmit resources of a configured or pre-configured uplink signal and / or channel that overlap with a scheduled multi-slot PUSCH transmission. In some implementations, the pre-configured signal and / or channel may include a PUSCH, PUCCH, or PRACH transmission, an SRS, or an SR. For example, in some implementations, the WTRU is semi-statically configured with a configured grant (CG) PUSCH transmission. The WTRU may receive a multi-slot PUSCH grant from the gNB that partially or completely overlaps with the CG PUSCH transmission. The WTRU may prioritize the transmission of the multi-slot PUSCH transmission and may drop (i.e., stop or not transmit) the CG PUSCH transmission (e.g., the entire transmission or just the overlapping resources). Alternatively, in some implementations, the WTRU may be configured to prioritize the configured transmission and stop and / or not transmit the multi-slot PUSCH transmission (e.g., the entire transmission or just the overlapping resources). In some implementations, the WTRU may decide whether to prioritize the transmission of a multi-slot PUSCH or the configured uplink transmission, and in some implementations, the WTRU can make this decision based on an explicit indication in the DCI.

[0114] Some implementations include reusing an existing bit field in the DCI to indicate a parameter or parameters of the multi-slot PUSCH. For example, in some implementations, the WTRU may be configured to receive parameters related to a multi-slot PUSCH transmission in an existing bit field or fields of the DCI. In some implementations, the WTRU may be configured to receive a parameter or parameters of the multi-slot PUSCH using one or more of the following bit fields or portions thereof: a Frequency Domain Resource Allocation (FDRA) field, a Modulation and Coding Scheme (MCS) field, and / or a Bandwidth Fraction Indicator field.

[0115] In some implementations, the parameter or parameters of the multi-slot PUSCH may indicate or include, for example, one or more of the following: a number of scheduled slots for the multi-slot PUSCH, a list of possible PUSCH time-domain resource allocations for the multi-slot PUSCH (e.g., as described herein), available slots for multi-slot PUSCH transmission (e.g., as described herein), an interrupt indication within the set of allocated slots (e.g., as described herein), and / or a parameter related to a group of coded bits (e.g., as described herein).

[0116] In some implementations, the WTRU may determine whether multi-slot PUSCH transmission parameters are carried in an existing bit field and / or whether multi-slot PUSCH transmission is enabled based on one or more (e.g., a combination) of the following: the RNTI used to schedule the uplink grant, the value of one of the existing bit fields, the search space set on which the scheduling DCI is received, the core set (CORESET) on which the scheduling DCI is received, the bandwidth portion on which the DCI is received, the bandwidth portion on which the PUSCH is scheduled, the component carrier (CC) on which the DCI is received, and / or the CC on which the PUSCH is scheduled.

[0117] For example, in some implementations, the WTRU determines whether multi-slot PUSCH transmission parameters are conveyed and / or whether multi-slot PUSCH transmission is enabled based on the RNTI used to schedule the uplink grant, where a new RNTI is introduced for multi-slot scheduling.

[0118] In another example, in some implementations, the WTRU determines whether multi-slot PUSCH transmission parameters are conveyed and / or whether multi-slot PUSCH transmission is enabled based on the value of one of the existing bit fields. For example, the value of the time-domain resource allocation field may trigger the WTRU to restrict the set of possible frequency-domain allocations and / or modulation and coding scheme fields. In some implementations, the WTRU is composed of FDRA / MCS bit fields of sizes N and M respectively. When the WTRU receives a multi-slot PUSCH grant indicated by TDRA, the WTRU may use N1 < N bits within the FDRA bit field to determine frequency allocation resources and M1 < M bits to determine the MCS. In some implementations, the remaining N - N1 bits and M - M1 bits may carry multi-slot PUSCH transmission parameters.

[0119] Some implementations involve power distribution. For example, in some implementations, the WTRU may receive implicit and / or explicit instructions to maintain power and / or phase continuity between different slots when multi-slot PUSCH transmission is used. In some implementations, the DCI that schedules multi-slot PUSCH transmission may indicate or include a power configuration for different slots. In some implementations, a transmit power control command or phase control command may include an instruction to use the same spatial filter and / or precoding scheme across different slots in multi-slot PUSCH transmission.

[0120] Some implementations involve multiplexing with other signals and / or channels. For example, in some implementations, the WTRU may determine to multiplex other signals or channels with the PUSCH in a multi-slot transmission. In some implementations, the WTRU may determine to multiplex the PUSCH in a multi-slot transmission with another reference signal or reference signals, such as SRS, DMRS, or PTRS, or PUCCH, based on one or more conditions or a combination of conditions. In some implementations, the WTRU may determine to multiplex the PUSCH in a multi-slot transmission with another reference signal or reference signals based on at least one of the following conditions: the number of resource blocks allocated to the multi-slot transmission, the number of slots allocated to the multi-slot transmission, and / or the number of symbols allocated to each slot or all slots in the multi-slot transmission. For example, if a WTRU is semi-statically configured with PUCCH resources used for HARQ ACK / NACK, and the WTRU is scheduled for a multi-slot PUSCH transmission that overlaps with a PUCCH transmission, the WTRU may determine whether to transmit multiple PUCCHs on a PUSCH (e.g., piggybacked on a multi-slot PUSCH) transmission based on the number of scheduled resource blocks / slots for the multi-slot PUSCH. Instead of transmitting multiple PUCCHs, the multi-slot PUSCH may carry multiple UCI "piggybacked" on the multi-slot PUSCH. For example, if a multi-slot PUSCH is scheduled in slots 0, 1, 2, and 3, and two PUCCHs are configured in slots 1 and 2, the WTRU may transmit a multi-slot PUSCH with piggybacked UCI in slots 1 and 2.

[0121] Some implementations include a TBS determination. For example, in some implementations, if the WTRU is configured to perform a multi-slot transmission, the WTRU may determine a TBS for the configured multi-slot transmission. In some implementations, the WTRU may receive a configuration of the number of PRBs and slots for the multi-slot transmission from a DCI or a semi-static configuration. In some implementations, the WTRU may receive a configuration on the amount of physical resource overhead (i.e., resources assumed not to be available for data transmission) to reserve per slot in a multi-slot transmission (i.e., excluding the physical resource overhead from the uplink grant) when the WTRU determines the TBS. In some implementations, the overhead parameters are signaled from the gNB to the WTRU. In some implementations, the WTRU determines the number of physical resources for data by subtracting the number of overhead resources from the number of resources allocated for the PUSCH. In some implementations, the number of resource elements allocated for the PUSCH in a PRB in a slot may be given by:

[0122]

number

[0123]

number

[0124]

number

[0125]

number

[0126] In some implementations, in a multi-slot transmission, the WTRU may

[0127]

number

[0128]

number

[0129]

number

[0130] The WTRU transmits the overhead within the preconfigured slots in a multi-slot transmission.

[0131]

number

[0132]

number

[0133]

number

[0134]

number

[0135] In another example, in some implementations where the WTRU decides to use the same overhead size in all slots in a multi-slot transmission, the WTRU may decide to use the same overhead size for all slots if the PUSCH is scheduled for the entire slot in the multi-slot transmission (i.e., 14 symbols in the PUSCH per slot).

[0136]

number

[0137] In some implementations, the WTRU may receive an indication in DCI, MAC-CE, or RRC signaling to perform at least one of the above overhead determination procedures. In some implementations, the WTRU may receive the overhead configuration per slot or per multi-slot transmission. In some implementations where the WTRU may receive the overhead configuration per slot or per multi-slot transmission, the WTRU may apply the same overhead parameters to all slots in a multi-slot transmission.

[0138] In some implementations, the WTRU may determine the overhead parameters from the aforementioned information elements for PUSCH time-domain resource allocation. In some implementations, the WTRU may determine the overhead parameters based on one or more of the following conditions: whether the slots in a multi-slot transmission are contiguous, whether or how many symbols for a reference signal such as PUCCH or SRS are scheduled in a slot in the multi-slot transmission, and / or whether DMRS bundling is enabled for the multi-slot transmission.

[0139] After the WTRU determines the overhead parameters from the information elements, the WTRU may determine the total number of resource elements in a multi-slot transmission using one or more of several methods. In some implementations, if the same overhead applies to all slots in a multi-slot transmission, the WTRU may determine the number of resource elements in a multi-slot transmission using

[0140]

number

[0141]

number

[0142]

number

[0143]

number

[0144]

number

[0145]

number

[0146] In some implementations, the WTRU may receive an indication from the network (e.g., gNB) that the number of PRBs allocated to a multi-slot transmission is always 1, e.g., to minimize resource usage in the frequency domain. Alternatively, the WTRU may determine that the number of PRBs is 1 by default after a multi-slot transmission is configured.

[0147] In some implementations, based on the determined number of total resource elements and other transmission-related information such as modulation or code rate, the WTRU may determine the TBS based on a look-up table.

[0148] Some implementations provide a nominal number of slots for transmission and / or retransmission and a maximum number of additional slots for transmission and / or retransmission. The total number of slots for transmission and / or retransmission, including the nominal number and the additional slots, is referred to as the actual number of slots. For example, in some implementations, a WTRU may be configured with a nominal number of slots for multi-slot uplink (e.g., PUSCH) transmission or retransmission. Such a nominal number of slots may be part of a SLIV configuration or a time domain resource allocation (TDRA) configuration, or may be indicated separately by DCI scheduling, by activating multi-slot PUSCH transmission or retransmission, or by an RRC configuration for a configured grant transmission. In some implementations, the nominal number of slots indicates to the WTRU the number of slots for a multi-slot PUSCH if there is no interruption in the multi-slot PUSCH transmission or retransmission. For example, if a WTRU is configured with a nominal number of slots equal to three, if the WTRU is interrupted during a multi-slot PUSCH transmission (e.g., by a DL slot due to a TDD configuration), the WTRU may use an additional slot to transmit at the end of the indicated number of slots (i.e., the WTRU may use the fifth slot to transmit in this example). In some implementations, the WTRU may determine (e.g., based on its configuration) the maximum number of additional slots that may be used for multi-slot PUSCH transmission. In some implementations, the maximum number of additional slots for multi-slot PUSCH transmission is based on one or more, or a combination thereof, of indications of rate matching, puncturing, and / or truncation of a portion of the resources allocated for multi-slot PUSCH transmission, the number of invalid slots and / or symbols for uplink transmission, and / or the number of remaining symbols configured for multi-slot PUSCH transmission beyond the remaining symbols of a slot.

[0149] In some implementations, where the maximum number of additional slots (or the actual number of slots in total) is determined based on an indication of rate-matching, puncturing, and / or truncation of a portion of the resources allocated for multi-slot PUSCH transmission, the WTRU may receive an indication indicating that a portion of the resources are to be rate-matched, punctured, or truncated. In some implementations, the indication may be semi-statically configured. For example, the WTRU may be configured using RRC with a rate-matching pattern for LTE CRS. Alternatively, the indication may be sent using dynamic signaling. For example, if the WTRU receives a group-common DCI indicating an interruption, the WTRU may transmit a multi-PUSCH transmission using the additional slots.

[0150] In some implementations where the maximum number of additional slots (or the total actual number of slots) is determined based on the number of invalid slots and / or symbols for uplink transmission, the WTRU may determine the number of valid slots and / or symbols based on a TDD configuration, including, for example, dynamic reconfiguration of the TDD structure. For example, the WTRU may receive a slot format instruction to change or "flip" a flexible slot to a downlink slot. Based on the instruction, the WTRU may determine that one slot is lost for downlink transmission and, accordingly, use the additional slot at the end of the configured number of nominal number of slots for a multi-slot uplink transmission.

[0151] In some implementations, the maximum number of additional slots (or the total actual number of slots) is determined based on the number of remaining symbols configured for multi-slot PUSCH transmission being greater than the number of remaining symbols in the slot.

[0152] FIG. 4 is a diagram illustrating nominal and actual slots for an exemplary multi-slot PUSCH 400. In the example of FIG. 4, a WTRU is configured with a multi-slot PUSCH transmission of three nominal slots 400, where nominal slots refer to the number of slots required to transmit all symbols of the PUSCH transmission. In this example, the WTRU determines that portions 402 and 404 of slot 1 and slot 2, respectively, are occupied by DL transmissions (e.g., by flipping a portion of a flexible slot). Based on this determination, the WTRU selects slot 3 to transmit the remaining symbols of the multi-slot PUSCH transmission. The WTRU determines that the available UL symbols 406 in slot 3 are insufficient to transmit the remaining symbols of the multi-slot PUSCH transmission. Here, the "remaining symbols" refer to the symbols of the multi-slot PUSCH transmission that could not be transmitted in the nominal slots (i.e., portions 402 and 404 of slot 1 and slot 2, respectively). Based on this determination, the WTRU also selects slot 4 to transmit the remaining symbols of the multi-slot PUSCH transmission, where the UL symbols 408 of slot 4 are sufficient to transmit the remaining symbols of the multi-slot PUSCH transmission, resulting in five actual slots 410 of the multi-slot PUSCH. In some implementations, the WTRU may transmit the multi-slot PUSCH transmission using the determined actual number of slots. In some implementations, the actual number of slots may be contiguous or non-contiguous, for example, depending on the TDD configuration, where the TDD configuration indicates a set of slots and / or symbols for the downlink, flexible, and uplink. For example, one configuration may be DDDUDDDU. In this example case, the uplink slots are non-contiguous or non-contiguous.

[0153] Some implementations include coded redundancy in separate HARQ processes. Some such implementations include TB partitioning and orthogonal coding. For example, for a single MAC PDU generated by the WTRU, the WTRU may partition the PDU into multiple coded segments. The WTRU may map the coded segments to different PUSCH transmission occasions associated with different HARQ PIDs. The WTRU may generate the coded TB segments using a DFT code or a similar orthogonal coding scheme. The WTRU may generate the coded TB segments using an outer code or a similar block coding scheme. The coding selection may be predefined or configured by the network. The WTRU may apply such coding to information bits received from higher layers (e.g., MAC PDUs), to bits after channel coding, and / or to modulated symbols before mapping to transmission resources. The WTRU may apply a coding sequence directly to the modulated bits. The WTRU may select the orthogonal code and / or sequence length as a function of the number of bits and / or MCS.

[0154] 5 is a block diagram illustrating an example implementation 500 including outer coding between the MAC and PHY. In this example, one MAC PDU is not contained within a single TB because the PDU is encoded into multiple PDU segments, each containing one TB in this implementation. In this example, the WTRU may segment a MAC PDU 502 into N PDU segments 504, 506, 508 by an encoder 550 (e.g., using outer coding, block coding, fountain coding, or the like). Each segment 504, 506, 508 is treated as a TB 510, 512, 514, respectively, at the physical layer and undergoes separate physical layer processing 516, 518, 520, respectively, and separate channel coding and modulation 522, 524, 526, respectively. The TBs 510, 512, 514 may then undergo separate modulation 528, 530, 532, and the WTRU may transmit each corresponding modulated TB 510, 512, 514 in a different PUSCH occasion HARQ process 534, 536, 538, respectively.

[0155] In some implementations, a receiver (e.g., a gNB) may configure, signal, or indicate the number of segments N, the number of applicable segments, the applicable PUSCH occasions, and / or the number of applicable HARQ PIDs. The receiver may decode a PDU if, for example, it successfully receives the number of PDU segments <= N. The gNB may issue a retransmission grant for a given HARQ process ID, thereby allowing the WTRU to retransmit PDU segments (i.e., TBs) associated with that HARQ process ID. For such retransmissions, the WTRU MAC may store each PDU segment / TB in an associated HARQ buffer or may store the entire PDU in a single HARQ buffer. When a retransmission is invoked, the WTRU MAC may provide the entire PDU to the PHY, and the WTRU PHY may regenerate the requested segment / TB for retransmission, or the WTRU MAC may provide only the requested PDU segment for retransmission to the PHY.

[0156] 6 is a block diagram illustrating an example implementation 600 that includes outer coding after channel coding. In this example, a MAC PDU 602 undergoes physical layer processing 604 and channel coding 606. At this stage, the MAC PDU 602 is contained within one TB 610. After channel coding 606, the WTRU segments the TB 610 into N TB segments 612, 614, 616 using a block encoder 618 (e.g., using outer coding, block coding, fountain coding, etc.). The WTRU may then subject each TB segment 612, 614, 616 to separate modulation 620, 622, 624 and transmit each modulated TB segment 612, 614, 616 on a different PUSCH occasion and a different HARQ process 626, 628, 630, respectively.

[0157] In some implementations, a receiver (e.g., a gNB) may configure, signal, or indicate the number of segments N, the number of applicable segments, the PUSCH occasion, and the HARQ PID. The receiver may decode a PDU, for example, if it successfully receives the number of TB segments <= N. The receiver (e.g., a gNB) may issue a retransmission grant for a given HARQ process ID, thereby allowing the WTRU to retransmit the TB segment associated with that HARQ process ID. When a retransmission is invoked, the WTRU PHY may play the requested TB segment for retransmission if it is not already stored in the associated HARQ buffer.

[0158] FIG. 7 is a block diagram illustrating an example implementation 700 that includes orthogonal coding after modulation and channel coding by applying a phase rotation to an orthogonal code (e.g., a DFT code) operating on a base sequence or OFDM symbol output.

[0159] In this example, the MAC PDU 702 undergoes physical layer processing 704, channel coding 706, and modulation 608. At this stage, the MAC PDU 702 is contained within one TB 710. Channel modulation 712 is applied to the MAC PDU after channel coding 706 to generate M modulated symbols 714. After modulation 712, the WTRU may apply spreading orthogonal codes to the M modulated symbols 714 using an orthogonal spreader 716 to generate J symbols 718, where J>M. The WTRU may transmit the J symbols in N different PUSCH occasions (or TTIs) and HARQ processes 720, 722, 724. The WTRU may map the J symbols 718 to the PUSCH occasions and HARQ processes 720, 722, 724 based on a symbol-to-PUSCH occasion mapping function 726.

[0160] 8 is a block diagram illustrating an example implementation 800 that includes orthogonal coding after channel coding. In this example, a MAC PDU 802 undergoes physical layer processing 804 and channel coding 806 to generate M channel coded bits 808. At this stage, the MAC PDU 802 is contained within one TB 810. After channel coding 806 but before modulation 812, the WTRU may apply a spreading orthogonal code 814 to the M channel coded bits 808 to generate R orthogonal coded bits 816, where R>M. Modulation 812 is applied to the R orthogonal coded bits 816 to generate J symbols 818. The WTRU may transmit the J symbols 818 on different PUSCH occasions (or TTIs) and different HARQ processes 820, 822, 824. The WTRU may map the J symbols 818 to the PUSCH occasions and HARQ processes 820, 822, 824 based on a symbol-to-PUSCH occasion mapping function 826.

[0161] In the examples described with respect to Figures 7 and 8, the receiver (e.g., gNB) may signal and / or configure N, the number of applicable PUSCH occasions, and the HARQ PID and / or coding rate. The receiver (e.g., gNB) may multiplex another WTRU on the same resources, e.g., using different codes from the same base sequence. In some implementations, the mapping function (726 or 826) may map the number of symbols J per PUSCH occasion N, may map the symbols to the applicable PUSCH occasions sequentially by time order, or may map the symbols first by frequency order and then by PUSCH occasion. The gNB may issue a retransmission grant for a given HARQ process ID or a given slot, thereby allowing the WTRU to retransmit the symbols associated with that slot and / or HARQ process ID. When a retransmission is invoked, the WTRU PHY may recover the requested symbols associated with the HARQ process and / or PUSCH occasion for which retransmission is requested if they are not already stored in the associated HARQ buffer.

[0162] Some implementations include mapping coded TB segments to different TTIs associated with different HARQ processes. In some implementations, the WTRU may allocate each segment to a different PUSCH occasion. For example, in the case of a multi-TTI grant (e.g., a 3GPP NR R16 multi-TTI grant), the WTRU can assign each coded TB segment to a different PUSCH occasion of a multi-TTI grant signaled by a single DCI, whereby each TTI may correspond to a different HARQ PID. Each TB segment may be mapped for transmission on a different HARQ process.

[0163] In some implementations, the WTRU may transmit TB segments discontinuously in the time domain and / or on different frequency regions / PRBs, e.g., for additional coverage enhancement (e.g., for diversity against fading, interference, and / or link jamming). The WTRU may transmit TB segments coded on CG occasions of different HARQ processes (e.g., on the same CG on different time occasions corresponding to different HARQ PIDs). For example, the WTRU may create TBs according to multiples of the TBS of the CG. The WTRU may then generate coded TB segments of the same size as the TBS of the CG, whereby each segment is transmitted consecutively on the CG occasion (e.g., on different HARQ PIDs).

[0164] Some implementations include HARQ process buffer maintenance. For example, in some implementations, the WTRU may store the total TB or PDU using the first HARQ process used to transmit the first TB segment, or any single HARQ PID associated with the TB. However, the WTRU may retransmit the TB segment according to the HARQ PID associated with the retransmission grant. In some implementations, the WTRU may store each coded PDU segment in the HARQ process in which it is transmitted.

[0165] In some implementations, the WTRU may flush the HARQ buffers of all associated HARQ processes after determining an ACK for any HARQ process associated with a TB. The WTRU may determine an ACK for the HARQ process in any suitable manner (e.g., by receiving an ACK, a toggled NDI, a timer expiry, etc.). After determining an ACK for the HARQ process ID used to store the TB in the WTRU buffer, the WTRU may flush the HARQ buffers of all associated HARQ processes. In some implementations, the WTRU may assume that the entire TB was not successfully decoded (e.g., determine a NACK) if a retransmission grant is issued for any HARQ PID associated with the TB and / or if the NDI is not toggled. Alternatively, the WTRU may maintain a HARQ-ACK for each TB segment, e.g., for each associated HARQ PID. The WTRU may retransmit (e.g., only) the TB segment associated with the HARQ process signaled for or associated with the retransmission grant.

[0166] In some implementations, if a TB segment is transmitted using different HARQ processes with different CG occasions, the WTRU may start or restart the CG timer after each transmission or retransmission on any of the HARQ processes used to transmit the PDU segment. The WTRU may restart the CG timer and / or CGRT for all HARQ processes associated with the TB if a retransmission grant is issued for any HARQ PID associated with the TB and / or if the NDI is not toggled. The WTRU may stop the CG timer and / or CGRT for all HARQ processes associated with the TB if an ACK is determined for the entire PDU (i.e., for all TB segments).

[0167] Some implementations include coded redundancy within a single HARQ process. In some implementations, the WTRU may generate at least one coded segment for a transport block, e.g., as described herein. In some implementations, the WTRU may map the modulated symbols of each coded segment to different slots using a configuration of the RS, which may be unique to each slot.

[0168] In some implementations, the WTRU may determine a single HARQ process for all coded segments. In some implementations, the WTRU may determine the applicable HARQ process from the DCI in case of dynamic grants or from a formula in case of configured grants. In case of configured grants, in some implementations, the HARQ process may be the one obtained for the first slot or first symbol when applying the formula.

[0169] 9 is a block diagram illustrating an example implementation 900 including outer coding between MAC and PHY. In this example, the WTRU may segment a MAC PDU 902 by an encoder 950 (e.g., using outer coding, block coding, fountain coding, etc.) into N segments 904, 906, 908. Each segment 904, 906, 908 is treated as a TB 910, 912, 914, respectively, at the physical layer and undergoes separate physical layer processing 916, 918, 920, respectively, and separate channel coding and modulation 922, 924, 926, respectively. The TBs 910, 912, 914 may then undergo separate modulation 928, 930, 932, and the WTRU may transmit each corresponding modulated TB 910, 912, 914 on a different PUSCH occasion but using the same HARQ process 934, 936, 938, respectively.

[0170] In some implementations, a receiver (e.g., a gNB) may signal to a WTRU the number N, the number of segments applicable to the PUSCH occasion, and the applicable HARQ PID. The receiver may decode the PDU if it successfully receives the number of PDU segments <= N. The gNB may issue a retransmission grant for a given PDU segment, thereby allowing the WTRU to retransmit the PDU segment (i.e., TB) associated with the indicated segment. For such a retransmission, the WTRU MAC may store the entire PDU in a single HARQ buffer. If a retransmission is invoked for a given segment, the WTRU MAC may provide the entire PDU to the PHY, and the WTRU PHY may regenerate the requested segment / TB for retransmission, or the WTRU MAC may provide only the requested PDU segment for retransmission to the PHY.

[0171] 10 is a block diagram illustrating an example implementation 1000 that includes outer coding after channel coding. In this example, a MAC PDU 1002 undergoes physical layer processing 1004 and channel coding 1006. At this stage, the MAC PDU 1002 is contained within one TB 1010. After channel coding 1006, the WTRU segments the TB 1010 into N TB segments 1012, 1014, 1016 using a block encoder 1018 (e.g., using outer coding, block coding, fountain coding, etc.). The WTRU may then subject each TB segment 1012, 1014, 1016 to a separate modulation 1020, 1022, 1024 and transmit each modulated TB segment 1012, 1014, 1016 on a different PUSCH occasion but using the same HARQ process 626, 628, 630, respectively.

[0172] In some implementations, a receiver (e.g., a gNB) may configure, signal, or indicate the number of segments N, the number of applicable segments, the PUSCH occasion, and the applicable HARQ PID. The receiver may decode a PDU, for example, if it successfully receives the number of TB segments <= N. The receiver (e.g., a gNB) may issue a retransmission grant for a given TB segment, thereby allowing the WTRU to retransmit the TB segment associated with the indicated TB segment. If a retransmission is invoked, the WTRU PHY may play the requested TB segment for retransmission.

[0173] FIG. 11 is a block diagram illustrating an exemplary orthogonal coding after modulation and channel coding by applying a phase rotation to a code (eg, a DFT code) operating on the base sequence or OFDM symbol output.

[0174] In this example, the MAC PDU 1102 undergoes physical layer processing 1104, channel coding 1106, and modulation 1108. At this stage, the MAC PDU 1102 is contained within one TB 1110. Channel modulation 1112 is applied to the MAC PDU after channel coding 1106 to generate M modulated symbols 1114. After modulation 1112, the WTRU may apply spreading orthogonal codes to the M modulated symbols 1114 using an orthogonal spreader 1116 to generate J symbols 1118, where J>M. The WTRU may transmit the J symbols on N different PUSCH occasions (or TTIs), but using the same HARQ processes 1120, 1122, 1124, respectively. The WTRU may map the J symbols 1118 to PUSCH occasions based on a symbol-to-PUSCH occasion mapping function 1126.

[0175] 12 is a block diagram showing exemplary orthogonal coding after channel coding. In this example, a MAC PDU 1202 undergoes physical layer processing 1204 and channel coding 1206 to generate M channel coded bits 1208. At this stage, the MAC PDU 1202 is contained within one TB 1210. After channel coding 1206 but before modulation 1212, the WTRU may apply a spreading orthogonal code 1214 to the M channel coded bits 1208 to generate R orthogonal coded bits 1216, where R>M. Modulation 1212 is applied to the R orthogonal coded bits 1216 to generate J symbols 1218. The WTRU may transmit the J symbols 1218 in different PUSCH occasions (or TTIs) but in the same HARQ processes 1220, 1222, 1224. The WTRU may map the J symbols 1218 to PUSCH occasions and HARQ processes 1220 , 1222 , 1224 based on a symbol-to-PUSCH occasion mapping function 1226 .

[0176] For the examples shown in Figures 11 and 12, the receiver (e.g., gNB) may signal and / or configure N, the number of applicable PUSCH occasions, the applicable HARQ PID, and / or the coding rate. The receiver (e.g., gNB) may multiplex another WTRU on the same resources, e.g., using different codes from the same base sequence. In some implementations, the mapping function (1126, 1226) may map the number of symbols J for each of the N PUSCH occasions or may map symbols sequentially by time order to the applicable PUSCH occasions. The gNB may issue a retransmission grant for a given slot or PUSCH occasion, allowing the WTRU to retransmit the symbols associated with that slot / PUSCH occasion. When a retransmission is invoked, the WTRU PHY may recover the requested symbols associated with the PUSCH occasion for which retransmission is requested.

[0177] Some implementations include mapping coded TB segments to different TTIs associated with the same HARQ process. In some implementations, the WTRU may assign each segment to a PUSCH occasion. For example, in the case of a multi-TTI grant with slot aggregation (e.g., a 3GPP R15 multi-TTI grant with slot aggregation), the WTRU can allocate each coded TB segment to a different PUSCH occasion of a multi-TTI grant signaled by a single DCI, whereby each TTI may correspond to the same HARQ PID.

[0178] In some implementations, the WTRU may transmit TB segments non-continuously in the time domain and / or on different frequency regions / PRBs for additional coverage enhancement (e.g., for diversity against fading, interference, and / or link jamming). The WTRU may transmit encoded TB segments on CG occasions of the same HARQ PID, possibly even on the same CG. The WTRU may assume that the same HARQ PID is used for consecutive occasions and may therefore ignore the HARQ PID determination formula for transmission of subsequent TB segments.

[0179] In some implementations, the WTRU may assume that the entire TB was not successfully decoded (e.g., determine a NACK) if a retransmission grant is issued for any TB segment. The WTRU may maintain a sub-HARQ-ACK status (i.e., ACK or NACK) for each TB segment, where the sub-HARQ-ACK refers to a different HARQ-ACK status for each TB segment. In some implementations, the WTRU may retransmit only the TB segments associated with the associated PUSCH occasion used to transmit the TB segment.

[0180] Some implementations include grouping of coded and modulated bits. For example, in some implementations, the WTRU may receive an indication (e.g., from a gNB or other network device) to group sets of coded and modulated bits of a transport block. For example, in some implementations, the WTRU may be configured to associate a group index with the grouped coded and modulated bits. In some implementations, the WTRU may group the coded and modulated bits based on the slot to which they are mapped during initial transmission, based on the set of symbols to which they are mapped during initial transmission, and / or based on the type of resource to which the coded and modulated bits are mapped.

[0181] In some implementations, for example, if the WTRU groups the coded and modulated bits based on the slot to which they are mapped during the initial transmission, the WTRU may determine the initial transmission based on a new data indicator (NDI) field.

[0182] In some implementations, for example, when the WTRU groups coded and modulated bits based on the set of symbols to which they are mapped during initial transmission, the set of symbols may be smaller than the slot duration (i.e., 14 symbols) or larger than the slot duration, and / or the size of the set of symbols may be configured to be semi-static or dynamically indicated using the scheduling DCI.

[0183] In some implementations, for example, if the WTRU groups the coded and modulated bits based on the type of resource to which they are mapped, the type may include, for example, whether they are mapped to one flexible slot, multiple slots, one symbol, or multiple symbols. For example, in some implementations, the WTRU may be configured with a TDD configuration consisting of a set of DL slots / symbols, a set of flexible slots and / or symbols, and a set of UL slots and / or symbols. Upon receiving or after receiving a multi-slot PUSCH grant, the WTRU may group the coded and modulated bits into a first group that is mapped onto the flexible resources and a second group that is mapped onto the uplink resources.

[0184] Some implementations include retransmission of groups of coded and modulated bits, for example, in some implementations, the WTRU may be configured to retransmit only one group or multiple groups of coded and modulated bits transmitted during the initial transmission. In some implementations, upon or after receiving a grant for retransmission, the WTRU may receive a bit field in the DCI that indicates the group of indices requested for retransmission. Alternatively, in some implementations, the WTRU may be configured to autonomously determine the groups needed for retransmission. In some implementations, the WTRU may determine that one or more groups should be retransmitted if the WTRU was initially unable to transmit the group. In some implementations, for example, a group of coded and modulated bits is initially mapped to a flexible slot and / or symbol. In some implementations, for example, after receiving an UL grant, the WTRU determines that UL transmissions are not allowed on the flexible resources (e.g., based on an instruction or configuration received from a gNB or other network device). In some implementations, the WTRU may decide to transmit the portions of the TB that were not transmitted in the flexible slots (e.g., due to not receiving an indication or slot format indicator (SFI) indicating the slot as an UL slot) in the second grant over the second set of slots, e.g., if the second grant matches the size and / or number of slots that were not indicated as the uplink portion of the first set of slots.

[0185] In some implementations, the WTRU may receive a UL grant for retransmission with more resources than were needed to retransmit the group of coded and modulated bits. In some implementations, the WTRU may be configured to retransmit the coded and modulated bits until the WTRU fills the scheduled resources. In some implementations, for example, the WTRU may receive a UL grant with 14 symbols for retransmission. In some implementations, the WTRU may determine that seven symbols are needed for the requested group for retransmission. In some implementations, after determining that seven symbols are needed, the WTRU transmits the group twice (i.e., transmits the group twice using 14 symbols). In other implementations, the WTRU may be configured to transmit additional redundancy version bits in the UL grant for retransmission. In some implementations, the WTRU may determine the number of RV bits to be transmitted based on the remaining resources after mapping the requested group. In some implementations, the WTRU may be configured to group sets of coded and modulated bits per slot. The WTRU may receive an instruction to retransmit one or more groups of coded and modulated bits. The indication may be signaled by a DCI and / or may accompany a retransmission grant. The indication may also indicate the number of slots (e.g., slot index). The WTRU may determine the group or groups to be retransmitted based on the set of interrupted slots. The WTRU may receive an indication to retransmit a portion of the TBs transmitted via the indicated slots.

[0186] Some implementations include various procedural aspects. For example, some implementations include dynamic indication of sequence selection and resource allocation. In some implementations, the WTRU may receive dynamic indication and / or signaling indicating the number of slots in which the TB is transmitted, whether TB segmentation is used, the retransmission type, whether interleaving is used, whether frequency hopping is used, and / or the identity of the associated HARQ process.

[0187] In some implementations, the WTRU may select an orthogonal sequence to encode the modulated PUSCH bits according to the number of scheduled slots, whether interleaving is applied (e.g., for RS transmission), the MCS, the measurement gap, and / or the number of PUSCH occasions applicable to transmitting the modulated data bits. The WTRU may be semi-statically configured to apply coded redundancy for a subset of LCHs and / or for a subset of CGs. The WTRU may be semi-statically configured with coded redundancy parameters for CGs, including the set of applicable HARQ processes, the sequence to be used, the RV pattern, the number of segments / coded retransmissions, etc.

[0188] Some implementations include reusing remaining scheduled PUSCH occasions for different PDUs. For example, in some implementations, the WTRU may use the remaining scheduled HARQ processes and PUSCH occasions associated with TBs for different MAC PDUs. For example, when some segments are successfully decoded (e.g., an ACK is received or determined by the WTRU for the entire PDU in response to the transmitted PUSCH), the WTRU may use the remaining scheduled HARQ processes and PUSCH occasions associated with the acknowledged TBs for different MAC PDUs. In some implementations, the WTRU may map a different generated TB, or a new TB, if the TB has the same RV and TBS as the one signaled.

[0189] Some implementations affect higher layers. For example, some implementations affect HARQ process ID specific timers. In some implementations, the WTRU MAC may maintain timers associated with a single HARQ process. In the case of a PDU associated with multiple HARQ PIDs (e.g., in accordance with the above description regarding coded redundancy on separate HARQ processes), the WTRU may handle the MAC timers for all HARQ PIDs associated with the PDU in the same manner. For example, the WTRU may simultaneously stop or start (or restart) the timers for all HARQ PIDs associated with the PDU.

[0190] In some implementations, the WTRU may stop or start (or restart) the DRX timers for all HARQ PIDs associated with a PDU when the PDU or PDU segment is transmitted (or retransmitted) and / or when a HARQ ACK is provided or determined for the PDU. This may include, for example, the drx-HARQ RTT Timer and / or drx-RetransmissionTimer parameters, among others.

[0191] The WTRU may stop or start (or restart) timers associated with configured grants for all HARQ PIDs associated with a PDU when the PDU or PDU segment is transmitted or retransmitted and / or when a HARQ ACK is provided for the PDU. This may include, among others, the configured grant (CG) timer or the configured grant retransmission (CGRT) timer.

[0192] Some implementations provide uplink control information (UCI) multiplexing with a multi-slot PUSCH transmission. For example, in some implementations, a WTRU may be configured with a PUCCH transmission that overlaps with a multi-slot PUSCH transmission. In such a case, the WTRU may be configured to transmit UCI of the PUCCH transmission over the multi-slot PUSCH transmission.

[0193] Some implementations provide slot selection for UCI multiplexing. For example, in some implementations, a WTRU may be configured to select a slot into which to multiplex UCI from multiple slots configured for PUSCH transmission. In some implementations, a WTRU may be configured to select a slot based on the timing of a PUCCH transmission. In some implementations, a WTRU may be configured to select the first slot of a multi-slot PUSCH transmission that starts after a duration T of a configured PUCCH transmission. In some implementations, the duration T may be semi-statically configured for the WTRU, e.g., using RRC signaling or a fixed value in a specification. In some implementations, a WTRU may be configured to select a slot based on the number of uplink symbols allocated in the slot. In some implementations, a WTRU may be configured to select a slot with a larger number of uplink symbols. In some implementations, a WTRU may be configured to select a slot with a minimum number of suspended symbols. In some implementations, suspended symbols can be symbols configured for downlink transmissions or for higher priority uplink transmissions, including other WTRU transmissions.

[0194] Some implementations provide UCI that is spread over multiple slots. For example, in some implementations, the WTRU may be configured to transmit UCI over multiple slots of a multi-slot PUSCH transmission. In some implementations, the WTRU may transmit a portion of the UCI bits on each slot. In some implementations, the WTRU may be configured to select the first slot in which the WTRU starts UCI transmission based on the timing of the PUCCH transmission. In some implementations, the WTRU may select the first slot of the multi-slot PUSCH transmission that starts after a duration T of the configured PUCCH transmission. In some implementations, the duration T may be semi-statically configured for the WTRU using RRC signaling or a fixed value in a specification. In some implementations, the WTRU may be configured to select the amount of resources reserved for UCI in a slot as a percentage of the available uplink symbols on the slot. In some implementations, for each slot of the multiple slots selected for UCI transmission, the WTRU uses the same percentage of the available uplink symbols.

[0195] In some implementations, the WTRU may be configured to enable or disable UCIs that spread over multiple slots based on the latency requirements of the UCI, e.g., in some implementations, for low latency UCI requirements, the WTRU is not allowed to use UCIs that spread over multiple slots.

[0196] Some implementations provide UCI retransmission over multiple slots. For example, in some implementations, the WTRU may be configured to retransmit UCI over multiple slots of a multi-slot PUSCH transmission. In some implementations, a gNB configuration of a PUCCH that overlaps with a multi-slot PUSCH transmission is or may include an implicit indication of UCI retransmission. In some implementations, the WTRU may be configured to select the first slot in which the WTRU starts UCI transmission based on the timing of the PUCCH transmission. In some implementations, the WTRU may select the first slot of a multi-slot PUSCH transmission that starts after a duration T of a configured PUCCH transmission. In some implementations, the duration T may be semi-statically configured for the WTRU, e.g., using RRC signaling or a fixed value in a specification. In some implementations, the WTRU may be configured to retransmit UCI over a number of slots that is less than the number of slots available for the multi-slot PUSCH transmission. For example, in some implementations, the WTRU is configured with four slots for a multi-slot PUSCH transmission and an overlapping PUCCH transmission on the first slot. In some implementations, the WTRU determines that the second slot of the multi-slot PUSCH transmission should be used for the first UCI transmission. In some implementations, the WTRU retransmits the UCI twice and uses only the second and third slots of the multi-slot PUSCH transmission. In some implementations, the number of slots for UCI retransmissions in a multi-slot PUSCH transmission may be semi-statically configured. Additionally or alternatively, in some implementations, the number of slots for UCI retransmissions in a multi-slot PUSCH transmission may be dynamically indicated to the WTRU. For example, in some implementations, the DCI scheduling the multi-slot PUSCH transmission may indicate the number of slots for UCI retransmissions.In some implementations, a new field (e.g., a new bit field) in the DCI may be implemented or an existing field (e.g., an existing bit field) in the DCI may be reused to indicate, for example, the number of slots for UCI retransmissions. For example, in some implementations, the Downlink Assignment Indication (DAI) field may be reused to indicate the number of slots for UCI retransmissions.

[0197] Some implementations provide rate matching adaptation. For example, in some implementations, the WTRU may divide the generated coded bits of a transport block into subgroups and map the subgroups to a set of symbols and / or a set of transmission occasions (e.g., where a transmission occasion is or includes a set of symbols and / or a set of one or more slots). In some implementations, the WTRU may be configured to perform rate matching of the subgroups of coded bits for each occasion. In some implementations, at the start of each occasion, the WTRU excludes resource elements for UCI transmission and rate matches on the available resources. Alternatively or additionally, in some implementations, the WTRU may puncture resources allocated to the transmission occasion to reserve resources for UCI transmission. In some implementations, the WTRU may be configured to initially assume a set of resource elements (REs) for each occasion and perform a first pass of rate matching. In some implementations, at the start of each slot, if UCI is to be transmitted in the slot / transmission occasion, the WTRU may perform a second round of rate matching.

[0198] 13 and 14 show examples of scheduling a TB over multiple slots. For a TB transmitted by a WTRU over multiple slots, the WTRU decides to transmit or retransmit the TB segment dropped in the later grant using the same HARQ process if the later grant indicates a retransmission (e.g., NDI is not toggled), the grant is for the same number of slots as the dropped one, and the grant size is large enough.

[0199] 13 is a block diagram illustrating an example transmission 1300 for time domain duplexing (TDD). In the figure, slots marked with D are downlink, and slots marked with U are uplink. In slot 1302, a WTRU receives a DCI containing an uplink grant to transmit a TB over three slots 1302, 1304, and 1306. The SFIs for slots 1302 and 1304 indicate that these are uplink slots, while the SFI for slot 1306 indicates that it is not an uplink slot (e.g., because it is a flexible slot flipped to downlink). Therefore, the WTRU segments the TB into two segments. The WTRU transmits the first segment of the TB in the first slot 1304 and the second slot 1306 of the uplink grant. The second segment of the TB is dropped because the SFI does not indicate that the next slot 1308 of the uplink grant is an uplink slot. In slot 1310, the WTRU receives a DCI (indicated in this example by the NDI not being toggled) containing a retransmission uplink grant for the same HARQ process as the grant received in slot 1302. The retransmission grant is also for the same number of slots that were dropped for the grant received in slot 1302. Based on this information, the WTRU decides to retransmit the second segment of the TB in slot 1312.

[0200] 14 is a block diagram illustrating an example transmission 1400 for the case of frequency domain duplexing (FDD). In the figure, all slots are marked as uplink (U) slots. Prior to slot 1402, the WTRU receives a DCI in the downlink symbol, which includes an uplink grant to transmit a TB over five slots 1402, 1404, 1406, 1408, and 1410. Prior to transmission of the TB (or the entire TB), the WTRU receives a UL cancellation indication for slots 1406, 1408, and 1410. Therefore, the WTRU segments the TB into two segments. The WTRU transmits the first segment of the uplink grant in TB slots 1404 and 1406, and the second segment of the TB is dropped. After the second segment is dropped, the WTRU receives a DCI in the downlink symbol, which includes a retransmission uplink grant for the same HARQ process as the grant received before slot 1402 (indicated in this example by the NDI not being toggled). The retransmission grant is also for the same number of slots that were dropped for the grant received before slot 1402. Based on this information, the WTRU decides to retransmit the second segment of the TB in slots 1412, 1414, and 1416.

[0201] 15 is a flow diagram illustrating an example method for transmitting a TB over multiple slots. In step 1502, a WTRU receives a first grant to transmit a TB in a first set of slots. With the condition 1504 that all slots are available for the uplink, the WTRU transmits the entire TB in the first set of slots in step 1506. With the condition 1504 that a subset of the first set of slots is unavailable for the uplink, the WTRU segments the TB into a first segment and a second segment in step 1508. In some implementations, the first segment is sized to fit within a first subset of the first set of slots that are available for the uplink. In some implementations, the first segment is sized equal to the amount of data that can be transmitted in the first subset.

[0202] The WTRU transmits a first segment of the TB in a first subset of the first set of slots in step 1510. On the condition that a second grant to transmit the TB in the second set of slots is received 1512, the WTRU transmits a second segment in the second set of slots in step 1514. In some implementations, the WTRU determines that the second grant is for transmitting the TB in the second set of slots if the second grant is for the same HARQ process as the first grant (e.g., NDI is not toggled), the second grant provides an amount of uplink resources equal to or greater than the second segment of the TB, and / or the second grant is for a number of uplink slots equal to or greater than a subset of the first set of slots that are unavailable for the uplink.

[0203] Although features and elements are described above in particular combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with the other features and elements. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium 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, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. 1. A method implemented in a wireless transmit / receive unit (WTRU) for transmitting a transport block (TB) over a plurality of slots, the method comprising: receiving a first grant to transmit a TB in a first set of slots, the first grant being associated with a hybrid automatic repeat request (HARQ) process; determining that a first subset of the first set of slots is available for uplink transmission and that a second subset of the first set of slots is unavailable for uplink transmission; segmenting the TB into a first segment and a second segment in response to determining that the first subset of the first set of slots is available for uplink transmission and that the second subset of the first set of slots is unavailable for uplink transmission; transmitting the first segment in the first subset of the first set of slots; receiving a second grant to transmit the TB in a second set of slots, the second grant being associated with the HARQ process, the second set of slots being equal to or greater in number than the second subset, and the second set of slots being available for uplink transmission; transmitting the second segment of the TB in the second set of slots in response to the second grant being for a number of slots equal to or greater than the second subset, the second grant being for the same HARQ process, and the second grant number of slots being available for uplink.

2. 2. The method of claim 1, wherein the second grant includes a new data indicator (NDI) equal in value to the NDI of the first grant.

3. 2. The method of claim 1, further comprising determining a set of coded bits of the TB for transmission over each slot of the first set of slots.

4. 4. The method of claim 3, further comprising remapping a subset of the set of coded bits of the TB corresponding to the second segment to a second set of resources of the slot.

5. The method of claim 1 , further comprising determining a set of modulated symbols of the TB for transmission over each slot of the first set of slots.

6. 6. The method of claim 5, further comprising remapping a subset of the set of modulated symbols of the TB corresponding to the second segment to a second set of resources of the slot.

7. 2. The method of claim 1, wherein the first grant is received in a first downlink control information (DCI).

8. The method of claim 7 , wherein the second grant is received in a second DCI that is different from the first DCI.

9. The method of claim 1 , wherein the second set of slots is non-contiguous in time with the first set of slots.

10. 2. The method of claim 1, wherein the second subset of the first set of slots is unavailable for uplink transmission due to uplink slot cancellation, due to uplink slot unavailability, or due to flexible slots being changed from uplink to downlink.

11. 1. A wireless transmit / receive unit (WTRU) configured to transmit a transport block (TB) over a plurality of slots, the wireless transmit / receive unit comprising: a circuit configured to receive a first grant to transmit a TB in a first set of slots, the first grant being associated with a hybrid automatic repeat request (HARQ) process; a circuit configured to determine that a first subset of the first set of slots is available for uplink transmission and that a second subset of the first set of slots is unavailable for uplink transmission; a circuit configured to segment the TB into a first segment and a second segment in response to determining that the first subset of the first set of slots is available for uplink transmission and that the second subset of the first set of slots is unavailable for uplink transmission; circuitry configured to transmit the first segment in the first subset of the first set of slots; a circuit configured to receive a second grant to transmit the TB in a second set of slots, the second grant being associated with the HARQ process, the second set of slots being equal to or greater in number than the second subset, and the second set of slots being available for uplink transmission; and and circuitry configured to transmit the second segment of the TB in the second set of slots in response to the second grant being for a number of slots equal to or greater than the second subset, the second grant being for the same HARQ process, and the second grant's number of slots being available for uplink.

12. The WTRU of claim 11 , wherein the second grant includes a new data indicator (NDI) equal in value to an NDI of the first grant.

13. The WTRU of claim 11 , further comprising: circuitry configured to determine a set of coded bits of the TB for transmission over each slot of the first set of slots.

14. 14. The WTRU of claim 13, further comprising: circuitry configured to remap a subset of the set of coded bits of the TB corresponding to the second segment to a second set of resources of the slot.

15. The WTRU of claim 11 , further comprising: circuitry configured to determine a set of modulated symbols of the TB for transmission over each slot of the first set of slots.

16. 16. The WTRU of claim 15, further comprising: circuitry configured to remap a subset of the set of modulated symbols of the TB corresponding to the second segment to a second set of resources of the slot.

17. The WTRU of claim 11 , further comprising: a circuit configured to receive the first grant in a first downlink control information (DCI).

18. The WTRU of claim 17, further comprising: circuitry configured to receive the second grant in a second DCI that is different from the first DCI.

19. The WTRU of claim 11 , wherein the second set of slots are non-contiguous in time with the first set of slots.

20. 12. The WTRU of claim 11, wherein the second subset of the first set of slots is unavailable for uplink transmission due to uplink slot cancellation, due to uplink slot unavailability, or due to a flexible slot being changed from uplink to downlink.

Images