Support of code block group (CBG)-based transmissions

Abstract

A wireless transmit / receive unit (WTRU) may receive configuration information. The WTRU may transmit a plurality of code block groups (CBGs) corresponding to one or more protocol data units (PDUs) in a first set of PDUs. The WTRU may receive feedback indicating that at least one CBG of the plurality of CBGs of the first PDU set is not successfully received. The WTRU may determine that the dynamic PUSCH resource grant is later in time than the second PUSCH transmission occasion. The WTRU may determine whether to re-transmit the at least one CBG of the plurality of CBGs of the first set of PDUs using the dynamic PUSCH resource grant or using the second PUSCH transmission occasion. The determination may be based on an amount of time remaining in a delay budget for the first set of PDUs. The WTRU may retransmit the at least one CBG of the plurality of CBGs of the first PDU set.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 410,916, filed on September 28, 2022, and U.S. Provisional Application No. 63 / 526,579, filed on July 13, 2023, each of which is incorporated herein by reference in its entirety. Background Art

[0003] Code Block Group (CBG) based transmission is beneficial for services with large transport block sizes, since in case of erroneous reception, only a small portion (CBG) of the total transport block needs to be retransmitted. Extended Reality (XR) services are examples of services characterized by large payload sizes, occasional bursty packets (thus resulting in large transport blocks (TBs)), as well as frequent arrival rates and quasi-periodicity. Therefore, XR services and other services may require high capacity as well as stringent low latency requirements. Summary of the invention

[0004] Wireless communications between one or more user equipments (UEs) and a network are contemplated herein. A UE may also be referred to as a wireless transmit / receive unit (WTRU). The terms "UE" and "WTRU" are used interchangeably herein.

[0005] A WTRU may receive configuration information. The configuration information may include, for example, a delay budget value and / or an indication of a configured resource grant for one or more physical uplink shared channels (PUSCH resources). The WTRU may use a first PUSCH transmission opportunity corresponding to the configured resource grant to send a plurality of code block groups (CBGs) corresponding to one or more PDUs in a first protocol data unit (PDU) set. If at least one of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set is not successfully received, the WTRU may receive feedback. For example, the feedback may indicate a dynamic PUSCH resource grant for retransmitting at least one of the plurality of CBGs. The at least one CBG of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set to be retransmitted may be negatively acknowledged (NACKed). In one example, the feedback may be received in downlink control information (DCI). The WTRU may determine whether the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. If the dynamic PUSCH resource grant is not later in time than (e.g., earlier in time than) the second PUSCH transmit opportunity, the WTRU may retransmit the at least one CBG corresponding to the one or more PDUs in the first PDU set via the dynamic PUSCH resource grant. If the dynamic PUSCH resource grant is later in time than the second PUSCH transmit opportunity, the WTRU may determine whether to retransmit the at least one CBG in the plurality of CBGs corresponding to the one or more PDUs in the first PDU set using the dynamic PUSCH resource grant or using the second PUSCH transmit opportunity corresponding to the configured resource grant. For example, the determination may be based on a threshold and an amount of time remaining in the delay budget for the first PDU set.

[0006] For example, if the remaining delay budget is less than a threshold, the at least one CBG may be retransmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant. The one or more CBGs corresponding to the one or more PDUs in the second PDU set may be transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant. For example, if each CBG corresponding to the one or more PDUs in the second PDU set is transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, the WTRU may transmit an indication for canceling the dynamic PUSCH resource grant.

[0007] For another example, if the remaining delay budget is greater than the threshold, the at least one CBG may be retransmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant. The at least one CBG corresponding to one or more PDUs in the second set may be transmitted in the dynamic PUSCH resource grant allocated for retransmitting the at least one CBG corresponding to one or more PDUs in the first PDU set.

[0008] The WTRU may also transmit an indication of a retransmission of the at least one CBG corresponding to one or more PDUs in the first PDU set for the second PUSCH transmission opportunity corresponding to the configured resource grant. The indication may be a hybrid automatic repeat request (HARQ) process ID. For example, the configuration information may also include a threshold associated with one or more HARQ transmissions. The WTRU may retransmit the at least one CBG corresponding to one or more PDUs in the first PDU set. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are examples. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and intended.

[0010] Figure 1A is an example system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0011] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A An example system diagram of an example wireless transmit / receive unit (WTRU) for use within an example communication system.

[0012] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A An example system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0013] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A An example system diagram of another example RAN and another example CN used within the illustrated communication system.

[0014] FIG. 2A to FIG. 2CThree example retransmissions of at least one code block group (CBG) corresponding to a first set of packet data units (PDUs) after the at least one CBG is unsuccessfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity are illustrated.

[0015] Figure 3 is a flowchart illustrating a method performed by a wireless transmit / receive unit (WTRU) to resend at least one CBG corresponding to a first PDU set after the at least one CBG corresponding to the first PDU set is not successfully sent during a first PUSCH transmission opportunity. DETAILED DESCRIPTION

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

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

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

[0019] The base station 114a may be part of the RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, 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 for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

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

[0022] 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

[0023] 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 New Radio (NR).

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

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

[0026] Figure 1AThe base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

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

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

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0030] Figure 1B is a system diagram illustrating an exemplary WTRU 102. Figure 1B As shown, 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 appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In one embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

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

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

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

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

[0037] The processor 118 may also be coupled to the 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 in lieu of the 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 received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

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

[0039] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via signal processing performed by hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0040] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

[0043] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

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

[0050] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Services originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Services originating from the STA and destined for the target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Services between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit services to the AP, and the AP may deliver services to the target STA. Services between STAs within the BSS may be considered and / or referred to as point-to-point services. Point-to-point services may be transmitted between the source STA and the destination STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.

[0051] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send 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 width dynamically set via signaling. The primary channel may be a working channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0052] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0053] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0054] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

[0057] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0058] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In one embodiment, the gNBs 180a, 180b, 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, while the remaining component carriers may be on a licensed spectrum. In one embodiment, the gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, the WTRU 102a may receive coordinated transmissions from the gNB 180a and gNB 180b (and / or gNB 180c).

[0059] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, 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 transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

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

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

[0062] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 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 mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0065] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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 UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

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

[0067] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0069] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0070] The description provided herein is for exemplary purposes and is not intended to limit in any way the applicability of the methods further described herein to other wireless technologies and / or wireless technologies using different principles where applicable.

[0071] The term "extended reality" (XR) can be used as an umbrella term for different types of immersive experiences, including virtual reality (VR), augmented reality (AR), mixed reality (MR), and / or realities inserted between them. VR can be a rendered version of the visual and audio scene delivered. The rendering can be designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimulation of the real world to the observer or user as naturally as possible as they move within the limits defined by the application. AR may include situations when additional information or artificially generated objects and / or content are provided to the user superimposed on the user's current environment. MR may be an advanced form of AR in which some virtual elements are inserted into the physical scene with the intention of providing the illusion that these elements are part of the real scene. XR may include a combined real and virtual environment, as well as human-computer interactions generated by computer technology and / or wearable devices.

[0072] The concept of immersion in the context of XR services can refer to the feeling of being surrounded by a virtual environment, as well as providing a sense of being physically and spatially located in the virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in a virtual reality that is virtually indistinguishable from actual reality.

[0073] XR devices may be associated with the ability to provide various degrees of spatial tracking. XR devices may be equipped with various sensors for implementing spatial tracking, such as monocular / stereo / depth cameras, radio beacons, GPS and / or inertial sensors, etc. Such spatial tracking may be performed at different levels, such as 3 degrees of freedom (DoF) (e.g., rotational motion along the X, Y, and Z axes), 6DoF (e.g., rotational and / or translational motion along the X, Y, and Z axes). Such spatial tracking may result in interaction to experience some form of virtual content. Users may perform actions in and / or interact with components within the extended reality. For example, actions and / or interactions may involve movement, gestures, eye tracking, etc. Spatial tracking may be a driving factor for an immersive XR experience. For example, some form of head and / or motion tracking may ensure that the visual and / or audio components of the simulation from the user's perspective are updated to be consistent with the user's movements. Inaccurate and / or delayed spatial tracking may cause the user to feel uncomfortable and / or motion sickness.

[0074] This document describes a network that may refer to one or more base stations (e.g., gNBs), which in turn may be associated with one or more transmit / receive points (TRPs) or any other nodes in a radio access network.

[0075] The WTRU may correspond to any XR device / node that appears in a variety of form factors. The WTRU (e.g., an XRWTRU) may include various forms, such as a head-mounted display (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearable devices, and / or the like. In addition to the above, several different types of XR WTRUs are envisioned based on XR device functions, such as displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, and / or power, etc. provided by one or more devices, wearable devices, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs may be grouped into collaborative XR groups for supporting any of the XR applications / services.

[0076] Throughout the embodiments described herein, the network may include any of a base station (e.g., gNB, TRP, RAN node, access node), a core network function (e.g., AMF), and an application function (e.g., edge server function, remote server function).

[0077] Throughout the embodiments described herein, a flow may correspond to one or more of a QoS flow and / or a data flow. For example, a data flow may consist of one or more PDUs or PDU sets. The one or more PDUs or PDU sets may be associated with one or more QoS requirements. The one or more QoS requirements may include latency, data rate, reliability, and / or RTT latency. Different flows (which may originate from a common application / experience source and / or are intended for a common destination device / WTRU or a group of associated devices / WTRUs) may be referred to as associated flows or related flows.

[0078] Throughout the embodiments described herein, the forwarding configuration may correspond to one or more of the following: a radio bearer (e.g., a data radio bearer (DRB) and / or a signaling radio bearer (SRB)), a logical channel (LCH), a logical channel group (LCG), configuration parameters in various layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, other protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), BWP, carrier, radio link / interface (Uu link, SL), and / or radio resources. For example, a radio resource may include a set of one or more frequency / time / space resources, such as a time slot, a subcarrier, or a beam. A radio resource may also be associated with a configuration grant (CG), a dynamic grant (DG), and / or any other resource grant or grant-free resource.

[0079] Throughout the embodiments described herein, a mapping configuration may correspond to one or more parameters and / or configurations associated with mapping from one or more application data (e.g., a PDU set) flows, QoS flows (e.g., associated or non-associated) to one or more radio bearers, SDAP, PDCP, LCH, carriers or component carriers (e.g., CCs in a CA configuration), BWPs, and radio links / interfaces (e.g., Uu links or side links), which may be used, for example, to deliver PDUs in the UL direction or the DL direction.

[0080] Throughout the embodiments described herein, XR / application-aware data transmission / reception or XR / application-aware QoS processing may correspond to one or more of the following: for example, a PDU set or PDU set processing, application / high-level importance / priority and / or QoS processing. A PDU set (e.g., a media unit, a video frame, etc.) may include one or more PDUs. A PDU set may be associated with PDU set-level QoS requirements (e.g., data rate, latency, error rate, reliability), which may apply to one or more PDUs (e.g., all PDUs) associated with the PDU set. Different PDUs in a PDU set may be associated with individual PDU-level QoS requirements. Such associations and interdependencies may be visible to an AS layer (e.g., with an association ID) and / or processed at an AS layer with association awareness during data transmission in the UL and data reception in the DL. Different PDUs in a PDU set or each PDU in a PDU set may be associated with different application / high-level importance / priority values. Such associations and interdependencies may be visible to the AS layer (eg, with an association ID) and / or handled at the AS layer with association awareness during data transmission in the UL and data reception in the DL.

[0081] Different PDUs in a PDU set or one or more PDUs in a PDU set (e.g., all PDUs) may be associated with different application / higher layer importance / priority values. Such importance values ​​may correspond to spatial importance (e.g., spatial positioning of video frames carrying data by a PDU / PDU set, where a PDU / PDU set carrying field of view (FoV) spatial positioning may be associated with higher spatial importance than a non-FoV spatial positioning) or temporal importance (e.g., temporal sequence of video frames carrying data by a PDU / PDU set, where a PDU / PDU set carrying a basic video frame such as an I-frame may be associated with higher temporal importance than a differential video frame such as a P-frame / B-frame). Such importance values ​​may be visible to the AS layer (e.g., with an associated ID / tag / indication) during data transmission and reception, possibly by application awareness.

[0082] The PDU / set of PDUs for an application may be encoded by the application and / or delivered by the application to the WTRU (in the UL) or the network (in the DL) via one or more QoS / data flows. In this regard, the different QoS flows carrying the PDU / set of PDUs associated with the XR application / experience may be visible to the AS layer (e.g., with an association ID) and / or processed at the AS layer with association awareness during data transmission and reception.

[0083] Throughout the embodiments described herein, one or more of the characterizations and references to PDU sets may correspond to one or more of the following characterizations. For example, a PDU set (e.g., an application data unit or a video frame) may include multiple PDUs. PDUs within the same PDU set may have the same or different payload sizes and / or priorities (e.g., importance). PDUs within a PDU set may have dependencies on each other. PDUs in a PDU set may have joint QoS requirements (e.g., PDU set delay bounds, PDU set error rates, PDU set throughput). PDUs and PDU sets may be characterized by intra-PDU set dependencies (e.g., the importance of changes between PDUs and / or the presence of redundant PDUs) and / or inter-PDU set dependencies (e.g., the next / new PDU set may be similar to or different from the previous PDU set). PDU sets may be characterized by jitter and / or non-integer periodicity values ​​(e.g., due to the PDU set generation rate, which typically follows a video frame generation rate of 60fps or 120fps). A PDU set may be characterized by a variable periodicity value (eg, due to a video encoder which may change the frame generation rate during runtime).

[0084] Throughout the embodiments described herein, WTRU actions associated with application actions and / or AS layer actions for ensuring / supporting differentiated QoS may correspond to one or more of the following actions. For example, the WTRU actions may include determining metadata for an application (e.g., an XR application), determining / generating application content, performing measurements and reporting, processing / forwarding data / PDUs / PDU sets and processing QoS associated with PDUs / PDU sets, and / or processing / forwarding information related to connectivity with the network and / or other WTRUs. The WTRU determining metadata for an application may involve determining one or more of FoV / visual perimeter, 2D / 3D dimensions, edges, spatial attributes, and / or FoV boundaries based on measurements of any spatial dimension, including but not limited to longitude, latitude, altitude, depth, roll, pitch, and / or yaw in one or more coordinate systems (e.g., Cartesian, spherical coordinate systems). The WTRU determining metadata for an application may involve determining the quality of the FoV content. For example, the WTRU may determine whether the FoV content is of high quality, which in the case of images may be quantified and evaluated by the image resolution (e.g., number of megapixel density). The WTRU determines that the metadata applied may involve determining the importance and / or priority of the FoV content. The importance may be associated with the spatial importance and / or temporal importance of the content / data. For example, the spatial / temporal importance value may indicate an absolute or relative importance associated with the FoV content. The spatial importance may be associated with one or more segments / tiles / slices / positions of the FoV in the spatial dimension. The temporal importance may be associated with one or more frames / subframes of the FoV in the temporal dimension.

[0085] The WTRU's determination / generation of application content may involve determining / capturing one or more 2D / 3D image / video frames associated with a FoV boundary / perimeter / edge, as defined by the WTRU / node for itself and / or on behalf of another WTRU / node via FoV metadata. For FoV content mapping, the WTRU may use visual sensors (e.g., 2D / 3D cameras, LiDAR), RF sensors (e.g., RF transceivers, RADAR), and / or audio sensors (e.g., sonar) to determine image / video frames. Here, mapping of the FoV may also be referred to as sensing of FoV content or capturing of FoV content. The WTRU's determination / generation of application content may include recording / capturing audio frames as part of the real environment or as part of an overlaid soundtrack / audio file, where the audio file originates from a source outside of the current real environment being mapped.

[0086] The WTRU may measure the pose (e.g., 6 degrees of difference (DoD) / 3DoD orientation, position / location) and / or rate of motion / movement of the user / WTRU and / or other objects (e.g., virtual objects or real objects) with which the user may interact. The WTRU may transmit and / or report pose measurements to the network periodically or upon detecting an event trigger (e.g., a change in pose measurement above / below a threshold). The WTRU may perform measurements of one or more of reference signals (e.g., SSB, channel state information (CSI)-SR, physical reference signal (PRS), sidelink reference signal (RS)), GNSS signals, unlicensed carriers, ultra-wideband signals, LIDAR signals, and / or visual signals. The WTRU may perform measurements of a radio link interface (e.g., Uu link, SL) associated with the WTRU. The WTRU may trigger the sending and / or measurement of reference signals in one or more other WTRUs (e.g., via Uu link and / or side link). The WTRU may transmit measurement reports to the network and / or to another WTRU.

[0087] The WTRU may perform processing / forwarding of data / PDU / PDU sets and process QoS associated with the PDU / PDU sets. The data may include any of media / image / video frames, sensor data, and measurement data (e.g., posture measurement results, link / channel measurement results) determined by the WTRU, which may be used to support application / service / network requests associated with the WTRU. The WTRU may transmit data to one or more destinations and / or receive data from one or more destinations, which may include RAN nodes (e.g., gNBs), CN functions / entities, and / or application functions (e.g., hosted in the WTRU or in the network). The WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more forwarding configurations during transmission / reception.

[0088] The WTRU may perform processing / forwarding of information related to connectivity with the network and / or other WTRUs. For example, the WTRU may transmit capability information to the network, which may include the capability to support one or more interfaces and / or the capability to coordinate and / or interact with other WTRUs / devices (e.g., via the SL interface), which other WTRUs / devices may be co-located or non-co-located with the WTRU. The WTRU may also or alternatively receive configurations, which include receiving RRC configurations from the gNB and / or receiving NAS layer configurations from the CN. The WTRU may also or alternatively transmit and / or receive auxiliary data to and from the network associated with services, QoS and / or scheduling, etc. to support UL / DL transmissions. The WTRU may also or alternatively transmit requests for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

[0089] If the WTRU is configured to use CBG based transmission by receiving higher layer parameters (codeBlockGroupTransmission for PDSCH or codeBlockGroupTransmission in PUSCH-ServingCellConfig), the WTRU may determine the number of CBGs to use for PUSCH transmission as shown in equation (1) below:

[0090] Equation (1) M = min (N, C)

[0091] where N is the maximum number of CBGs per transport block as configured by maxCodeBlockGroupsPerTransportBlock (for PDSCH or in PUSCH-ServingCellConfig), and C is the number of code blocks in a transport block (TB) (e.g., according to the procedures defined in 3GPP TR 38.212 - Multiplexing and Channel Coding (Release 16) (V16.2.0)).

[0092] If the WTRU is configured to send code block group based transmission by receiving higher layer parameters (codeBlockGroupTransmission in PUSCH-ServingCellConfig) for initial transmission of a TB as indicated by the 'New Data Indicator' field of a scheduling downlink control information (DCI), the WTRU may expect that the CBGTI field indicates that each of the CBGs (e.g., all CBGs) of the TB is to be transmitted, and the WTRU may include each of the code block groups (e.g., all code block groups) of the TB. If the WTRU is configured to send code block group based transmission by receiving higher layer parameters (codeBlockGroupTransmission in PUSCH-ServingCellConfig) for retransmission of a TB as indicated by the 'New Data Indicator' field of a scheduling DCI, the WTRU may include the CBGs (e.g., only the CBGs) indicated by the CBGTI field of the scheduling DCI.

[0093] A bit value of '0' in the CBGTI field may indicate that the corresponding CBG may not be sent, and '1' indicates that the corresponding CBG may be sent. The order of the CBGTI field bits may cause the CBGs to be mapped sequentially starting from CBG number 0 onward, starting from the MSB.

[0094] CBG-based transmission may be beneficial for services with large transport block sizes because in case of erroneous reception, a small portion of the CBG of the total transport block may need to be retransmitted (e.g., only a small portion of the CBG of the total transport block may need to be retransmitted). XR services are characterized by large payload sizes, occasional bursty packets (thus resulting in large TBs), and frequent arrival rates and quasi-periodicity. Therefore, XR services may require high capacity as well as strict low latency requirements. However, HARQ retransmissions with large TB sizes for XR services may cause resource utilization issues and thus affect system capacity. Therefore, CBG-based transmission for XR may significantly improve resource utilization and capacity. However, CBG-based transmission may increase the overhead of HARQ feedback (e.g., adding 1 bit per CBG on the DCI). Currently, the number of CBs and CBGs in a TB may be fixed, and no application / PDU level awareness (information) is available to the WTRU and / or gNB when it segments the TBs and determines the number of CBGs to use. Equal importance may be given to each segment and PDU (eg, all segments and PDUs), thereby limiting the application possibilities of an effective method for dynamically adapting the number of CBGs in a TB to XR traffic.

[0095] Embodiments for maintaining overhead and / or improving HARQ feedback efficiency as the number of CBGs increases are described herein. Embodiments for dynamically performing grouping of CBs in a TB based on PDU / PDU set level importance priority are also described herein.

[0096] Embodiments for supporting CBG-based transmissions for XR services are described herein. The WTRU may dynamically and / or semi-statically adapt the number of CBGs used for UL transmissions of a TB by selecting from a set of values ​​for the number of CBGs based on attributes of a PDU / PDU set received from higher layers, including the required QoS bounds. The WTRU may transmit auxiliary information about the selected number of CBGs to be used during UL transmissions to the network (e.g., a base station) and begin.

[0097] The WTRU may use explicit or implicit information / indications received from the application / higher layer / network to determine the size of the TB and the number of CBGs it can use when transmitting in the UL, and transmit an indication to the network (base station). For example, the WTRU may periodically or aperiodically / dynamically receive information in RRC signaling, MAC CE, DCI, NAS layer signaling, and / or application layer signaling.

[0098] The service information obtained by each WTRU in the collaborative group of WTRUs from the application / higher layer / network may include, but is not limited to, an identifier / ID, a service type associated with the data flow of each application, attributes of the supported services, and / or QoS requirements or expected QoS associated with the data. The identifier / ID may include an identifier / ID associated with the application (e.g., application ID, service ID, session ID, application configuration ID). The identifier / ID may include a group ID (e.g., associated with a QoS flow group, a forwarding configuration group, a device group / WTRU group). The identifier / ID may include an ID for each QoS flow, mapping configuration, and / or forwarding configuration. The identifier / ID may include a data type / message ID (e.g., a PDU set ID, a PDU ID, an ID associated with posture information, FoV information, media / video frame information). The identifier / ID may include an association ID (e.g., an ID or sequence number indicating an association between one or more UL PDU / PDU sets / streams and one or more DL PDU / PDU sets / streams).

[0099] The traffic information obtained by each WTRU in the cooperative group of WTRUs from the application / higher layers / network may include traffic types associated with data flows per application. The WTRU may receive information about different data / QoS flows associated with an application, where the data types may include video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, haptic data, pose / positioning data, and / or audio data, etc.

[0100] The service information obtained by each WTRU in the cooperative group of WTRUs from the application / higher layer / network may include the attributes of the supported services. For example, the WTRU may receive information about the service characteristics / patterns of different data / QoS flows associated with the application, including whether the data is periodic, aperiodic, semi-persistent and / or quasi-periodic, etc. The service characteristics may include one or more periodicity values ​​for the flow. The WTRU may receive information about the number of PDUs expected per PDU set in one or more flows per application. The information about the number of PDUs per PDU set may also include statistical / distribution information, such as mean, minimum, maximum and / or standard deviation values. The information related to the PDU set may include the size of the PDU set (e.g., total payload, number of PDUs in the PDU set), indication of the start / first PDU and / or end / last PDU of the PDU set and / or indication of the association / dependency of the PDUs in the PDU set (e.g., ID of the PDU set, importance / priority value).

[0101] The traffic information obtained by each WTRU in the cooperative group of WTRUs from the application / higher layers / network may include QoS requirements or expected QoS associated with the data. For example, the WTRU may receive QoS requirements or expected QoS for one or more flows associated with the application, which QoS requirements or expected QoS may include data rate, latency, reliability and / or absolute / relative priority values, etc. The information about the QoS requirements may also or alternatively include statistical / distribution information, such as average, minimum, maximum and / or standard deviation values. The WTRU may also or alternatively receive indications of the following: Such QoS requirements or expected QoS may refer to different QoS granularities, such as per PDU, per PDU subgroup (e.g., one or more PDUs) within a PDU set, per PDU set, per group of PDU sets, per flow and / or per session.

[0102] The WTRU may transmit information to the network to support dynamic selection of the number of CBGs during UL transmission. For example, the WTRU may transmit information to the network that is associated with data communication (e.g., for receiving / sending data in one or more streams) and / or for enabling dynamic selection of the number of CBGs during UL transmission based on available service characteristics in one or more streams. The WTRU may transmit information to the network via AS layer signaling (e.g., RRC signaling and / or messages, MAC CE, control PDU, or UCI) or non-AS (NAS) layer signaling (e.g., PDU session related messages).

[0103] The information transmitted by the WTRU may include applications supported by the WTRU. The WTRU may transmit numbers and / or IDs associated with the supported applications. The WTRU may also or alternatively transmit information about relative priority values / absolute priority values ​​associated with the supported applications.

[0104] The information transmitted by the WTRU may include data flows associated with the application. The WTRU may transmit numbers and / or IDs associated with data flows supported per application. The WTRU may also or alternatively transmit information about relative priority values / absolute priority values ​​associated with the data flows.

[0105] The information transmitted by the WTRU may include data / traffic types associated with the data streams per application. The WTRU may transmit information about the types of data carried by the different streams associated with the applications in each WTRU. The different streams associated with the applications in each WTRU may include, for example, video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, haptic data, posture / positioning data, and / or audio data.

[0106] The information transmitted by the WTRU may include service characteristics and / or parameters of the data / service associated with each application and / or data stream per WTRU. The WTRU may transmit information about the characteristics of a single or multiple stream services associated with an application, including whether the data in each stream is periodic, aperiodic, semi-persistent and / or quasi-periodic, etc. The WTRU may transmit information about the number of PDUs expected per PDU set in one or more streams per application. The information about the number of PDUs per PDU set may also or alternatively include statistical information, such as average, minimum, maximum, standard deviation values. The WTRU may transmit QoS requirements (per PDU and / or per PDU set) for one or more streams associated with each application, including data rate, latency, reliability and / or absolute / relative priority values, etc.

[0107] The information transmitted by the WTRU may include a preferred number of CBGs per application to be used when sending TBs in the UL. For example, the WTRU may transmit to the network (e.g., a base station) the optimal number of CBGs to use when transmitting TBs in the UL.

[0108] The WTRU may transmit the above information to the network under various conditions. For example, the various conditions may include detecting one or more events. For example, the WTRU may transmit the above information to the network during connectivity / session establishment and / or (re) configuration. For example, the WTRU may transmit the above information during RRC connection, PDU session, application session establishment and / or (re) configuration. The WTRU may transmit the above information when the RRC state is changed in any WTRU in the cooperative WTRU group.

[0109] The WTRU may transmit the above information when changing / updating data flows on a per-application basis. For example, the WTRU may transmit the above information when adding a new flow associated with an application and / or when releasing an existing flow associated with an application.

[0110] The WTRU may transmit the above information when receiving higher layer / application information. For example, the WTRU may transmit the above information when receiving an indication (e.g., from an application function hosted in the WTRU or in the network) indicating a change in supported data types, service characteristics, and / or QoS requirements.

[0111] The WTRU may transmit the above information when changing / updating the number of CBGs used for UL transmission of a TB.

[0112] The WTRU may receive configuration information from the network associated with a power saving scheme applicable to a group of flows / WTRUs. For example, a WTRU (e.g., an anchor WTRU) may receive configuration information from the network, based on which the WTRU may dynamically and / or semi-statically adapt the number of CBGs used when it sends TBs in the UL. The configuration information received by the WTRU may include one or more values. The one or more values ​​may include a set of values ​​related to the number of CBGs used for UL transmission. For example, the WTRU may receive the maximum number of CBGs per TB that it is allowed to use. The WTRU may also or alternatively receive a set of possible numbers of CBGs that it may adapt per given TB per application.

[0113] The configuration information received by the WTRU may include a threshold value related to the TB size per application. For example, the WTRU may receive a threshold value related to the minimum TB size in order to use CBG-based and / or TB-based transmission.

[0114] The configuration information received by the WTRU may include thresholds related to QoS / joint QoS (e.g., PER PDB). For example, the WTRU may receive thresholds related to the required QoS per PDU / PDU set. Specific QoS related values ​​may include, for example, a PDU / PDU set level delay bound and / or a PDU / PDU set level error rate bound. The WTRU may additionally or alternatively receive joint QoS requirements on PDUs across multi-flow services, for example, a joint delay bound associated with a time difference between a reception time of a PDU in a first flow and a reception time of another PDU in a second flow.

[0115] The configuration information received by the WTRU may include a threshold value related to the number of HARQ retransmissions. For example, the WTRU may receive a threshold value related to the maximum number of HARQ retransmissions allowed.

[0116] The configuration information received by the WTRU may include a threshold value related to the number of negative acknowledgements (NACKS) received. For example, the WTRU may receive a threshold value related to the number of NACKs received during the initial transmission of a TB in order to select a different number of CBGs during UL transmission.

[0117] The configuration information received by the WTRU may include a threshold value associated with an event counter. For example, the WTRU may receive a threshold value associated with an event counter. The event counter may be related to, for example, the number of initial UL / DL transmissions.

[0118] The configuration information received by the WTRU may include a configured resource grant. For example, the WTRU may receive a configured resource grant for uplink resources. The configured resource grant may be a set of predetermined resource blocks that are pre-allocated to the WTRU at a given periodicity for uplink transmissions of one or more physical uplink shared channels (PUSCH).

[0119] The configuration information received by the WTRU may include a delay budget value. For example, the delay budget value may include a PDU / PDU aggregate level delay bound. The delay budget value may set the maximum duration that a PDU / PDU aggregate may take to be processed by lower layers in the WTRU and over the air for transmission until it arrives at a receiver (e.g., at a MAC entity of the receiver).

[0120] For example, a WTRU (eg, any WTRU in a collaborative WTRU group) may receive configuration information via AS layer signaling (eg, RRC signaling / messages, MAC CE, or DCI) or non-AS (NAS) layer signaling (eg, PDU session related messages).

[0121] The WTRU may assist the network in dynamically and / or semi-statically adapting the number of CBGs used for UL transmission of a TB to XR services (e.g., dynamically and / or semi-statically adapting the UL retransmission of a TB to XR services). The WTRU may assist the network (e.g., a base station) in adapting the number of CBGs when transmitting a TB in the UL (e.g., retransmitting a TB in the UL). The WTRU may have received a set of values related to the number of CBGs that the WTRU can adapt for a given TB size. The WTRU may determine whether a dynamic PUSCH resource grant is later in time than a second PUSCH transmission occasion corresponding to a configured resource grant. If the dynamic PUSCH resource grant is later in time than the second PUSCH transmission occasion corresponding to the configured resource grant, and at least one CBG among a plurality of CBGs corresponding to one or more PDUs in a first PDU set has not been successfully transmitted, the WTRU may determine whether to use the dynamic PUSCH resource grant or the second PUSCH transmission occasion corresponding to the configured resource grant to retransmit the at least one CBG among the plurality of CBGs corresponding to the one or more PDUs in the first PDU set based on the amount of time remaining in the delay budget for the first PDU set. In one example, for a given TB size, the WTRU may receive a first and / or default CBG number (CBG1) and a second CBG number (CBG2), where CBG1 < CBG2. The WTRU may then receive an XR data burst from an application / higher layer, the XR data burst including one or more PDUs / PDU sets and an indication of a PDU / PDU set level delay bound (e.g., in a PDU header). The WTRU may use the indicated PDU / PDU set level delay bound (e.g., in a PDU / PDU set header) to determine whether to use the first and / or default CBG number (CBG1) and the second CBG number (CBG2) when transmitting a TB in the UL. For example, if the indicated PDU / PDU set level delay bound is greater than a configured threshold related to the delay bound (e.g., the XR data burst can be transmitted over multiple time slots on multiple small-sized TBs), then when transmitting a TB in the UL, the WTRU may use the first and / or default CBG number (CBG1). The second CBG number (CBG2) may be sent in a received dynamic resource grant. If the indicated PDU / PDU set level delay bound is less than the configured threshold related to the delay bound (e.g., the XR data burst needs to be transmitted in a single time slot on a large TB), then the WTRU may convey an indication to the network (NW) to use the second CBG number for its next UL transmission, and / or the WTRU may receive a resource grant from the gNB and use the second CBG number (CBG2) in the received resource grant to transmit a TB in the UL.If each second CBG number (CBG2) is sent in the next UL transmission, the WTRU may transmit an indication to cancel the received dynamic resource grant. In addition, at least one CBG to be resent is negatively acknowledged.

[0122] The WTRU may transmit an indication of a retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set for a second PUSCH transmission opportunity corresponding to a configured resource grant. The indication may be a hybrid automatic repeat request (HARQ) process ID. In one example, each PUSCH transmission may have an associated HARQ process running in the MAC layer. Since multiple HARQ processes may run in parallel, a HARQ process ID / number may be assigned to each HARQ process. In conventional procedures, a given PUSCH transmission may maintain its assigned HARQ process ID during initial transmission and HARQ retransmissions. The HARQ process ID may be released and may be assigned to subsequent PUSCH transmissions only after the MAC layer receives an ACK indicating that the PUSCH to which the HARQ process ID belongs is successfully received.

[0123] If the dynamic PUSCH resource grant is not later in time than (e.g., earlier in time than) the second PUSCH transmission opportunity corresponding to the configured resource grant, the WTRU may resend the at least one CBG corresponding to one or more PDUs in the first PDU set via the dynamic PUSCH resource grant.

[0124] The WTRU may incrementally or decrementally adapt the number of CBGs to be used when it transmits in the UL from a set of available numbers of CBGs (e.g., {CBG0>CBG1>CBG2}). The set of numbers of CBGs to which the WTRU is set to adapt (e.g., {CBG0>CBG1>CBG2}) may be received directly from the network as configuration information, or the set may be determined by the WTRU based on past and / or current behavior of the UL service. In one example, the WTRU may transmit auxiliary information about the UL service to the network by providing statistical information such as average, minimum, maximum, standard deviation values, and the auxiliary information includes the number of PDUs expected per PDU set in one or more flows per application. Based on the provided statistical values, the network may determine the set of numbers of CBGs to which the WTRU may adapt and / or transmit an indication to the WTRU. Alternatively, the WTRU may determine the set of numbers of CBGs based on the application / higher layer information available to it. The WTRU may transmit auxiliary information to the network indicating the set of numbers of CBGs it prefers to use.

[0125] The WTRU may receive feedback indicating whether one or more CBGs corresponding to one or more PDUs are successfully received or unsuccessfully received. The feedback may indicate a dynamic PUSCH resource grant for retransmitting one or more CBGs corresponding to one or more PDUs that were not successfully received. For example, the WTRU may then start sending the first set of TBs in the UL using an initial number of CBGs (e.g., CBG0), and / or may start a counter to determine the number of initial UL transmissions performed before receiving a given number of NACKs. If the number of initial UL transmissions (e.g., determined by a counter) exceeds a threshold T1 and at least X% of the CBGs relative to the total number of CBGs in the TB do not receive a NACK, the WTRU may perform a series of actions. For example, the WTRU may transmit to the network an indication that CBG1 (number of CBGs) is to be used for UL transmissions starting from the next TB, and / or receive from the network a confirmation of the use of CBG1 (number of CBGs). In addition, the feedback may be received in downlink control information (DCI).

[0126] After receiving confirmation of the use of CBG1, the WTRU may start using CBG1 (number of CBGs) to send TBs, thereby achieving a reduction in HARQ-DCI overhead (CBG0-CBG1). The WTRU may also restart the counter and / or start counting the number of initial UL transmissions performed before receiving a given number of NACKs. If the number of initial UL transmissions (e.g., determined by the counter) exceeds the threshold T2 and at least Y% of the CBGs receive NACKs relative to the total number of CBGs in the TB, the WTRU may perform a similar set of actions. For example, the WTRU may transmit an indication to the network to use CBG2 (number of CBGs) for UL transmissions starting from the next TB, and / or receive confirmation from the network of the use of CBG2 (number of CBGs).

[0127] After receiving confirmation of using CBG2, the WTRU may start using CBG1 (number of CBGs) to send TBs, thereby achieving overhead reduction (CBG1-CBG2). On the other hand, if the WTRU receives NACKs for at least X% or Y% of the CBGs before the counter exceeds the threshold T1 or T2, the WTRU may maintain the number of CBGs it is currently using and / or reset the counter.

[0128] The WTRU may adapt a TB-specific number of CBGs in a multi-slot transmission of multiple TBs using a single DCI. In multiple PUSCH (multi-slot) scheduling, the WTRU may be configured to map a set of PDUs to a TB so that the TB may be scheduled for UL transmission across multiple slots arranged in descending order of priority (e.g., QoS). The WTRU may then determine the number of CBGs to be used for each TB slot based on the priority. The determination of the number of CBGs may result in different numbers of CBGs being used across TBs in multi-PUSCH scheduling. In one example, the WTRU may receive configuration information from the network, which may include a maximum number of CBGs that may be used across each TB (e.g., all TBs) scheduled for UL transmission in multiple slots. The configuration information from the network may also or alternatively include a set of intervals that may or may not overlap and may be related to QoS requirements (e.g., delay bounds) and the number of CBGs to be used corresponding to each interval of the QoS requirements. The configuration information from the network may also or alternatively include a set of rules for mapping PDUs / PDU sets to scheduled TBs according to descending PDU / PDU set level QoS requirements (e.g., delay bounds per PDU / PDU set). For example, a PDU / PDU set with a lower delay bound may be mapped in the first TB, and so on.

[0129] The WTRU may begin receiving a higher layer data burst consisting of one or more PDU sets and / or an indication of a delay bound per PDU set and a delay bound per data burst (e.g., in a PDU header). The WTRU may determine the total number of TBs required to send each PDU set (e.g., all PDU sets) based on the delay bound per PDU set and the delay bound per data burst. The WTRU may map the PDUs / PDU sets to corresponding TBs according to the ascending order of the delay bound per PDU set and the delay bound per data burst. For each TB in a multi-slot scheduling, the WTRU may determine the number of CBGs it can use, the indicated PDU / PDU set level delay bound, the total number of TBs to be used, and / or the maximum number of CBGs across each TB (e.g., all TBs) to be scheduled in multiple slots. The WTRU may transmit auxiliary information to the network, which includes the number of CBGs per TB that can be used during UL transmission of multiple PUSCHs. When sending multi-slot traffic, the WTRU may receive a scheduling grant that includes a confirmation to use the determined number of CBGs per TB.

[0130] In an example implementation, as further described herein, a WTRU may determine the number of CBGs per TB to use when transmitting XR data in the UL based on the QoS of the XR data (e.g., the latency bound for transmitting a set of PDUs). The WTRU may be configured to receive configuration information from a gNB, the configuration information including a first / default number of CBGs per TB (CBG1) and a second number of CBGs per TB (CBG2) and a latency threshold, where CBG1 < CBG2. The WTRU may receive an XR data burst from a higher layer, the XR data burst including one or more sets of PDUs and / or an indication of the data burst level latency bound (e.g., in the PDU header). If the latency bound is greater than the latency threshold (e.g., the XR data burst may be transmitted over multiple time slots on multiple small-sized TBs), then when transmitting data in the UL, the WTRU may use the default number of CBGs per TB (CBG1). If the latency bound is less than the latency threshold (e.g., the XR data burst needs to be transmitted in a large TB on a single time slot), then the WTRU may send an indication to the NW to use the second number of CBGs for the next UL transmission, receive a resource grant from the gNB, and / or transmit a TB (carrying the XR data) composed of the second number of CBGs (CBG2) using the received resource grant.

[0131] In another example embodiment, as further described herein, the WTRU may adjust the number of CBGs it uses when transmitting in the UL based on the percentage of CBGs for which NACKs are received during a specified period. The WTRU may receive configuration information including the number of CBGs to be used when transmitting in the UL (e.g., {N0>N1>N2}) and / or a counter threshold (e.g., C1, C2) for the number of initial UL transmissions before receiving NACKs for at least X% of the total number of CBGs used. The WTRU may transmit the first TB in the UL using the initial number of CBGs (e.g., N0) and / or start a counter to determine the number of initial UL transmissions before receiving a NACK. If the number of initial UL transmissions (e.g., determined by a counter) exceeds a threshold C1 before receiving NACKs for at least X% of the CBGs, the WTRU may transmit an indication to the network to use N1 (the number of CBGs) in the next UL transmission, and / or the WTRU may stop the counter and start using N1 (the number of CBGs) after receiving an acknowledgement from the NW. The HARQ feedback overhead may be reduced by N0-N1. If the number of initial UL transmissions exceeds a threshold C2 before receiving NACKs for at least X% of the CBGs while sending TBs using N1 (number of CBGs), the WTRU may transmit an indication to the network to use N2 (number of CBGs) in the next UL transmission and / or stop the counter and start using N2 (number of CBGs) after receiving an acknowledgement from the NW. The HARQ feedback overhead may be reduced by N0-N2. If the WTRU receives NACKs for at least X% of the CBGs before the counter exceeds thresholds C1 or C2, the WTRU may maintain the number of CBGs it is currently using and / or reset the counter.

[0132] In another example embodiment, as described herein, the WTRU may be configured to map PDU sets to TBs such that the TBs are scheduled in the UL in descending order of priority (e.g., QoS) in scheduling of multiple PUSCHs (multiple time slots). The WTRU may determine the number of CBGs to be used for each TB based on the priority, and may result in different numbers of CBGs being used across TBs in multi-PUSCH scheduling. The WTRU may be configured to receive configuration information that may include a maximum number of CBGs in each TB (e.g., all TBs). The WTRU may receive a data burst from a higher layer that consists of one or more PDU sets and / or an indication of a delay bound per PDU set and a delay bound per data burst (e.g., in a PDU header). The WTRU may determine the number of TBs / time slots to use for sending each PDU set (e.g., all PDU sets) based on the delay bound per PDU set and the delay bound per data burst. The WTRU may determine the number of CBGs per TB (carrying each PDU set) for each TB (e.g., all TBs) based on the maximum number of CBGs, the delay bound, and / or the determined number of TBs / timeslots. The WTRU may transmit an indication of the determined number of CBGs per TB to the gNB. The WTRU may receive a resource grant for multiple TBs (e.g., multi-slot scheduling). The WTRU may use the received resource grant to send a TB (e.g., carrying a PDU set) that includes the determined number of CBGs per TB.

[0133] FIG. 2A to FIG. 2C Three example retransmissions of at least one CBG corresponding to a first PDU set after at least one CBG is not successfully transmitted during a first PUSCH transmission opportunity are illustrated. The PDU set 204 may include multiple PDUs 202a to 202e. Each PDU 202a to 202e may include multiple CBGs (e.g., 4 CBGs). The CBGs may be acknowledged (ACK) and / or not acknowledged (NACK). For example, CBG 3 in PDU 202b and CBG 2 in PDU 202d are NACKed, while CBG 1 to CBG 4 in PDU 202c are ACKed. Similarly, the PDU set 212 may include multiple PDUs (e.g., 5 PDUs), and each PDU may include multiple CBGs. Each PUSCH transmission opportunity (e.g., a first PUSCH transmission opportunity, a second PUSCH transmission opportunity, etc.) may occur within an uplink time slot (UL time slot). There may be one or more downlink time slots (DL time slots) between the first PUSCH transmission opportunity and the second PUSCH transmission opportunity.

[0134] During the first PUSCH transmission opportunity, the WTRU may have successfully transmitted one or more CBGs (e.g., all CBGs) corresponding to the first PDU set 204. During the first transmission opportunity, the WTRU may fail to transmit at least one CBG corresponding to the first PDU set 204. For example, the WTRU may fail to transmit NACKed CBG 3 in PDU 202b and NACKed CBG 2 in PDU 202d. When at least one CBG corresponding to the first PDU set 204 is not successfully transmitted, the WTRU may receive feedback. For example, the at least one CBG corresponding to the first PDU set 204 that is not successfully transmitted may include a bundle 210 of one or more CBGs. The bundle 210 may include each NACKed CBG in the first PDU set 204, for example, CBG 3 in PDU 202b and CBG 2 in PDU 202d. The feedback may be received in downlink control information (DCI) 206. The feedback received in the DCI 206 may be received in a DL time slot between one or more DL time slots.

[0135] The WTRU may determine whether the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. Figure 2A , the WTRU may determine that the dynamic PUSCH resource grant is later in time than (e.g., earlier in time than) the second PUSCH transmission opportunity. Therefore, the WTRU may resend at least one CBG that was not successfully transmitted corresponding to the first PDU set 204 via the dynamic PUSCH resource grant at 208 before the second PUSCH transmission opportunity. The PDU set 212 may be transmitted at the second PUSCH transmission opportunity.

[0136] exist Figure 2BIn the DCI 206, a bundle 210 including each NACKed CBG in the first PDU set 204 (e.g., CBG 3 in PDU 202b and CBG 2 in PDU 202d) may not have been successfully transmitted at the first PUSCH transmission opportunity. After receiving the feedback in the DCI 206, the WTRU may determine that the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. The WTRU may retransmit at least one CBG (e.g., bundle 210) that was not successfully transmitted corresponding to the first PDU set 204 via the second PUSCH transmission opportunity corresponding to the configured resource grant. In addition, the WTRU may compare the amount of time remaining in the delay budget for the first PDU set 204 with a threshold. In one example, the threshold may refer to an absolute time given in T milliseconds (ms). The WTRU may determine that the amount of time remaining in the delay budget for the first PDU set 204 is greater than the threshold. At the second PUSCH transmission opportunity, the bundle 210 including each NACKed CBG in the first PDU set 204 (e.g., CBG 3 in PDU 202b and CBG 2 in PDU 202d) may be retransmitted along with one or more CBGs in the PDU set 212 (e.g., PDU 1 to PDU 4 in PDU set 212). The one or more additional CBGs of the PDU set 212 may not be transmitted at the second PUSCH transmission opportunity. At 216a, the WTRU may transmit the one or more additional CBGs of the PDU set 212 (e.g., PDU 214) in a dynamic PUSCH resource grant allocated for retransmitting at least one CBG corresponding to one or more PDUs in the first PDU set 204.

[0137] exist Figure 2CIn the DCI 206, the bundle 210 including each NACKed CBG in the first PDU set 204 (e.g., CBG 3 in PDU 202b and CBG 2 in PDU 202d) may not be successfully transmitted at the first PUSCH transmission opportunity. After receiving the feedback in the DCI 206, the WTRU may determine that the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. The WTRU may retransmit at least one CBG (e.g., bundle 210) that was not successfully transmitted corresponding to the first PDU set 204 via the second PUSCH transmission opportunity corresponding to the configured resource grant. In addition, the WTRU may compare the amount of time remaining in the delay budget for the first PDU set 204 with a threshold. The WTRU may determine that the amount of time remaining in the delay budget for the first PDU set 204 is less than the threshold. At the second PUSCH transmission opportunity, the bundle 210 including each NACKed CBG in the first PDU set 204 (e.g., CBG 3 in PDU 202b and CBG 2 in PDU 202d) may be retransmitted along with each CBG of each PDU in the PDU set 212. If each CBG corresponding to one or more PDUs in the second PDU set 212 is transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, then at 216b, the WTRU may transmit an indication for canceling the dynamic PUSCH resource grant. The above method may retransmit the CBG using the available configured resource grant before the PDU set delay budget of the first PDU set 204 expires. This may enable the WTRU to achieve the stringent high reliability and low latency requirements for XR applications.

[0138] Figure 3 1 is a flow chart illustrating a method performed by a WTRU to retransmit at least one CBG corresponding to a first PDU set after unsuccessfully transmitting at least one CBG corresponding to a first PDU set during a first PUSCH transmission opportunity. The method may include, for example, the method described above in FIG. 2A to FIG. 2C. The method may include receiving configuration information at 302. The configuration information may include, for example, a delay budget value and / or an indication of a configured resource grant for one or more physical uplink shared channels (PUSCH resources). At 304, the WTRU may use a first PUSCH transmission opportunity corresponding to the configured resource grant to send a plurality of code block groups (CBGs) corresponding to one or more PDUs in a first protocol data unit (PDU) set. If at least one of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set is not successfully received, the WTRU may receive feedback at 306. For example, the feedback may indicate a dynamic PUSCH resource grant for retransmitting the at least one CBG in the plurality of CBGs. The at least one CBG in the plurality of CBGs corresponding to the one or more PDUs in the first PDU set to be retransmitted may be negatively acknowledged (NACKed). In one example, the feedback may be received in downlink control information (DCI). At 308, the WTRU may determine whether the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. If the dynamic PUSCH resource grant is not later in time than (e.g., earlier in time than) the second PUSCH transmission opportunity, then at 310, the WTRU may retransmit the at least one CBG corresponding to one or more PDUs in the first PDU set via the dynamic PUSCH resource grant, such as Figure 2A If the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity, then at 312, the WTRU may determine whether to retransmit the at least one CBG in the plurality of CBGs corresponding to the one or more PDUs in the first PDU set using the dynamic PUSCH resource grant or using the second PUSCH transmission opportunity corresponding to the configured resource grant. For example, the determination may be based on a threshold and an amount of time remaining in the delay budget for the first PDU set.

[0139] For example, if at 314 the remaining delay budget is less than a threshold, then at 318 the at least one CBG may be retransmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant. The one or more CBGs corresponding to the one or more PDUs in the second PDU set may be transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant. For example, if each CBG corresponding to the one or more PDUs in the second PDU set is transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, then at 320 the WTRU may transmit an indication for canceling the dynamic PUSCH resource grant, such as Figure 2C shown.

[0140] For another example, if at 316 the remaining delay budget is greater than the threshold, then at 322, the at least one CBG may be retransmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant. At least one CBG corresponding to one or more PDUs in the second set may be transmitted in the dynamic PUSCH resource grant allocated for retransmitting the at least one CBG corresponding to one or more PDUs in the first PDU set, such as Figure 2B shown.

[0141] The WTRU may also transmit an indication of a retransmission of the at least one CBG corresponding to one or more PDUs in the first PDU set for the second PUSCH transmission opportunity corresponding to the configured resource grant. The indication may be a hybrid automatic repeat request (HARQ) process ID. For example, the configuration information may also include a threshold associated with one or more HARQ transmissions. The WTRU may retransmit the at least one CBG corresponding to one or more PDUs in the first PDU set.

[0142] Although features and elements are provided above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. The present disclosure is not limited to the specific embodiments described in the present application, which are intended to be illustrative of various aspects. Many modifications and variations can be made without departing from the essence and scope of the present invention, as they will be apparent to those skilled in the art. Unless explicitly provided as such, any element, action or description used in the present application specification should not be understood as being essential or necessary to the present invention. According to the foregoing description, in addition to those listed herein, within the scope of the present disclosure, functionally equivalent methods, devices and articles will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure is limited only to the terms of the appended claims and the full range of equivalents of such entitled claims. It should be understood that the present disclosure is not limited to a specific method or system.

[0143] Although the foregoing embodiments may be discussed with respect to specific terminology and structures (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.) for simplicity, the embodiments discussed are not limited thereto and may be applied to other systems using, for example, other forms of electromagnetic waves or non-electromagnetic waves such as sound waves.

[0144] It should also be understood that the terms used herein are used only for the purpose of describing specific embodiments and are not intended to be limiting. As used herein, the term "video" or the term "imagery" may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis, or any suitable combination thereof. For example, when referred to herein, the term "user equipment" and its abbreviation "UE", the term "remote" and / or the term "head-mounted display" or its abbreviation "HMD" may mean or include (i) a wireless transmit and / or receive unit (WTRU); (ii) any of a plurality of embodiments of the WTRU; (iii) a wireless and / or wired (e.g., tetherable) device configured with (in particular) some or all of the structure and functionality of the WTRU; (iii) a wireless and / or wired device configured with less than all of the structure and functionality of the WTRU; or (iv), etc. References herein Figures 1A to 1D Details of an example WTRU are provided that may represent any WTRU described herein. As another example, various disclosed embodiments herein are described above and below as utilizing a head mounted display. Those skilled in the art will recognize that devices other than head mounted displays may be utilized and that some or all of the present disclosure and various disclosed embodiments may be modified accordingly without undue experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted reality experience.

[0145] In addition, the methods provided herein may be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Unlike signals, 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 built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0146] Variations of the methods, devices, articles, and systems provided above are possible without departing from the scope of the present invention. In view of the various embodiments that may be applied, it should be understood that the illustrated embodiments are merely examples and should not be considered to limit the scope of the following claims. For example, the embodiments provided herein include handheld devices that may include or be utilized with any suitable voltage source (such as a battery, etc.) that provides any suitable voltage.

[0147] In addition, in the embodiments provided herein, processing platforms, computing systems, controllers and other devices comprising processors are indicated. These devices may include at least one central processing unit ("CPU") and memory. According to the practice of those skilled in the art of computer programming, reference to the symbolic representation of actions and operations or instructions may be performed by various CPUs and memories. Such actions and operations or instructions may be referred to as "executed", "computer executed" or "CPU executed".

[0148] Those of ordinary skill in the art will appreciate that the actions and symbolic representations of operations or instructions include manipulation of electrical signals by the CPU. The electrical system represents data bits, which may result in the ultimate transformation of electrical signals or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise changing the operation of the CPU and performing other processing of signals. The memory location that holds the data bits is a physical location that has specific electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that the embodiments are not limited to the above-mentioned platforms or CPUs, and other platforms and CPUs may also support the provided methods.

[0149] The data bits may also be maintained on a computer-readable medium, including magnetic disks, optical disks, and any other volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system readable by the CPU. The computer-readable medium may include cooperating or interconnected computer-readable media that exist solely on a processing system or distributed across multiple interconnected processing systems that may be local or remote relative to the processing system. It should be understood that the embodiments are not limited to the above-mentioned memories, and other platforms and memories may also support the provided methods.

[0150] In an exemplary embodiment, any of the operations, processes, etc. described herein may be implemented as computer-readable instructions stored on a computer-readable medium. The computer-readable instructions may be executed by a processor of a mobile unit, a network element, and / or any other computing device.

[0151] The above specific embodiments have been listed various embodiments of devices and / or processes by using block diagrams, flow charts and / or examples. In the case where such block diagrams, flow charts and / or examples contain one or more functions and / or operations, it should be understood by those skilled in the art that each function and / or operation within such block diagrams, flow charts or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware or almost any combination thereof. In example embodiments, several parts of the subject matter described herein can be implemented via application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), digital signal processors (DSPs) and / or other integrated formats. Those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented in integrated circuits as a whole or in part as one or more computer programs running on one or more computers (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware or almost any combination thereof, and according to the present disclosure, designing circuits and / or writing software and / or firmware codes will be completely within the technical scope of those skilled in the art. Those skilled in the art will appreciate that the mechanisms of the subject matter described herein may be distributed as a program product in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable type media (such as floppy disks, hard drives, CDs, DVDs, digital tapes, computer memory, etc.); and transmission type media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0152] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner set forth herein, and thereafter use engineering practices to integrate such described devices and / or processes into a data processing system. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system via a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally may include one or more of the following: a system unit housing; a video display device; a memory, such as a volatile memory and a non-volatile memory; a processor, such as a microprocessor and a digital signal processor; a computing entity, such as an operating system, a driver, a graphical user interface, and an application; one or more interactive devices, such as a touch pad or a screen; and / or a control system, including a feedback loop and a control motor (e.g., a feedback for sensing position and / or velocity, a control motor for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented using any suitable commercially available components, such as those typically found in data computing / communication and / or network computing / communication systems.

[0153] The subject matter described herein sometimes illustrates different components contained in or connected to different other components. It should be understood that such depicted architectures are merely examples, and in fact many other architectures that achieve the same functionality can be implemented. In a conceptual sense, any arrangement of components that achieve the same functionality is effectively "associated" so that the desired functionality can be achieved. Therefore, any two components that are combined to achieve a specific functionality in this article can be considered to be "associated" with each other so that the desired functionality is achieved, regardless of the architecture or intermediate components. Similarly, any two components so associated can also be considered to be "operably connected" or "operably coupled" to each other to achieve the desired functionality, and any two components that can be so associated can also be considered to be "operably coupled" to each other to achieve the desired functionality. Specific examples of operable coupling include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or wirelessly interact and / or components that can logically interact and / or components that can logically interact.

[0154] With respect to substantially any plural and / or singular terms used herein, those skilled in the art may convert from the plural to the singular and / or from the singular to the plural as appropriate, depending on the context and / or application. For clarity, various singular / plural arrangements may be explicitly listed herein.

[0155] It will be understood by those skilled in the art that, in general, the terms used herein, and particularly in the appended claims (e.g., the bodies of the appended claims), are generally intended to be "open" terms (e.g., the term "including" should be interpreted as "including but not limited to", the term "having" should be interpreted as "having at least", the term "comprising" should be interpreted as "including but not limited to", etc.). It will also be understood by those skilled in the art that if a specific number of an introduced claim recitation is intended, such intent will be explicitly stated in the claim, and in the absence of such a recitation, there is no such intent. For example, where only one item is intended, the term "single" or similar language may be used. To aid understanding, the following appended claims and / or the description herein may contain the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim recitations is limited to an embodiment containing only one such recitation by the indefinite article "a" or "an" to introduce the claim recitation. This is true even when the same claim includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "a kind" (e.g., "a" and / or "a kind" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one skilled in the art will recognize that such recitation should be interpreted as meaning at least the stated number (e.g., a bare recitation of "two recitations" without other modifiers means at least two recitations, or two or more recitations). In addition, in those instances where a convention similar to "at least one of A, B, and C, etc." is used, generally speaking, the meaning of such construction is that one skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, a system having A alone, B alone, C alone, A and B simultaneously, A and C simultaneously, B and C simultaneously, and / or A, B, and C simultaneously, etc.). In those instances where a convention similar to "at least one of A, B, or C, etc." is used, generally speaking, the meaning of such construction is that one skilled in the art will understand the convention (e.g., "a system having at least one of A, B, or C" will include, but is not limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). One skilled in the art will also understand that, in fact, any discrete words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, any of the terms, or both of the terms.For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." In addition, as used herein, the term "any of" followed by a listing of multiple items and / or multiple categories of items is intended to include "any of," "any combination," "any multiples," and / or "any combination of multiples" of the items and / or categories of items, either alone or in combination with other items and / or other categories of items. Furthermore, as used herein, the term "set" is intended to include any number of items, including zero. Additionally, as used herein, the term "quantity" is intended to include any number, including zero. And, as used herein, the term "plurality" is intended to be synonymous with "multiple."

[0156] In addition, where features or aspects of the disclosure are described in terms of Markush groups, those skilled in the art will recognize that the disclosure is also described in terms of any individual member or subgroup of members of the Markush group.

[0157] As will be understood by those skilled in the art, for any and all purposes (such as in terms of providing a written description), all ranges disclosed herein also encompass any and all possible subranges and combinations of their subranges. Any listed range can be easily identified as fully describing and enabling the same range to be divided into at least equal halves, one-third, one-quarter, one-fifth, one-tenth, etc. As a non-limiting example, each range discussed herein can be easily divided into a lower third, a middle third, and an upper third, etc. As will be understood by those skilled in the art, all languages ​​such as "up to", "at least", "greater than", and "less than", etc. include the cited numbers and refer to the ranges that can be subsequently divided into subranges as described above. Finally, as will be understood by those skilled in the art, the range includes each individual number. Therefore, for example, a group with 1 to 3 units refers to a group with 1, 2, or 3 units. Similarly, a group with 1 to 5 units refers to a group with 1, 2, 3, 4, or 5 units, etc.

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising a processor, the processor configured to: receiving configuration information including a delay budget value and an indication of a resource grant for configuration of one or more physical uplink shared channel (PUSCH) resources; transmitting a plurality of code block groups (CBGs) corresponding to one or more protocol data units (PDUs) in a first set of PDUs using a first PUSCH transmission opportunity corresponding to the configured resource grant; receiving feedback indicating that at least one of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set was not successfully received, wherein the feedback indicates a dynamic PUSCH resource grant for resending the at least one of the plurality of CBGs; determining that the dynamic PUSCH resource grant is later in time than a second PUSCH transmission opportunity corresponding to the configured resource grant; determining whether to retransmit the at least one CBG of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set using the dynamic PUSCH resource grant or using the second PUSCH transmission opportunity corresponding to the configured resource grant based on an amount of time remaining in a delay budget for the first PDU set, wherein if the remaining delay budget is less than a threshold, the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant, and if the remaining delay budget is greater than the threshold, the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant; as well as Resend the at least one CBG corresponding to one or more PDUs in the first PDU set.

2. The WTRU of claim 1, wherein the feedback indicating that at least one of the multiple CBGs corresponding to the one or more PDUs in the first PDU set was not successfully received is received in downlink control information (DCI).

3. The WTRU of claim 1, wherein at least one of the multiple CBGs corresponding to the one or more PDUs in the first PDU set to be retransmitted is negatively acknowledged.

4. A WTRU according to claim 1, wherein the dynamic PUSCH resource grant is earlier in time than a second PUSCH transmission opportunity corresponding to the configured resource grant, and the processor is also configured to resend the at least one CBG corresponding to one or more PDUs in the first PDU set via the dynamic PUSCH resource grant.

5. The WTRU of claim 1, wherein one or more CBGs corresponding to one or more PDUs in a second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant.

6. A WTRU according to claim 5, wherein the processor is further configured to transmit an indication for canceling the dynamic PUSCH resource grant if each CBG corresponding to the one or more PDUs in the second PDU set is sent in the second PUSCH sending opportunity corresponding to the configured resource grant.

7. A WTRU according to claim 1, wherein at least one CBG corresponding to one or more PDUs in the second set is sent in the dynamic PUSCH resource grant allocated for retransmitting the at least one CBG corresponding to one or more PDUs in the first PDU set.

8. A WTRU according to claim 1, wherein the processor is also configured to transmit an indication of retransmission of the at least one CBG corresponding to one or more PDUs in the first PDU set including the second PUSCH transmission opportunity corresponding to the configured resource grant.

9. The WTRU of claim 8, wherein the indication is a hybrid automatic repeat request (HARQ) process ID.

10. The WTRU of claim 9, wherein the configuration information further comprises a threshold associated with one or more HARQ transmissions.

11. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information including a delay budget value and an indication of a resource grant for configuration of one or more physical uplink shared channel (PUSCH) resources; transmitting a plurality of code block groups (CBGs) corresponding to one or more protocol data units (PDUs) in a first set of PDUs using a first PUSCH transmission opportunity corresponding to the configured resource grant; receiving feedback indicating that at least one of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set was not successfully received, wherein the feedback indicates a dynamic PUSCH resource grant for resending the at least one of the plurality of CBGs; determining that the dynamic PUSCH resource grant is later in time than a second PUSCH transmission opportunity corresponding to the configured resource grant; determining whether to retransmit the at least one CBG of the plurality of CBGs corresponding to the one or more PDUs in the first PDU set using the dynamic PUSCH resource grant or using the second PUSCH transmission opportunity corresponding to the configured resource grant based on an amount of time remaining in a delay budget for the first PDU set, wherein if the remaining delay budget is less than a threshold, the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant, and if the remaining delay budget is greater than the threshold, the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource grant; as well as Resend the at least one CBG corresponding to one or more PDUs in the first PDU set.

12. The method of claim 11, wherein the feedback indicating that at least one of the multiple CBGs corresponding to the one or more PDUs in the first PDU set was not successfully received is received in downlink control information (DCI).

13. The method of claim 11, wherein the at least one CBG in the plurality of CBGs corresponding to the one or more PDUs in the first set of PDUs to be retransmitted is negatively acknowledged.

14. The method of claim 11, wherein the dynamic PUSCH resource grant is earlier in time than a second PUSCH transmission opportunity corresponding to the configured resource grant, the method further comprising: The at least one CBG corresponding to one or more PDUs in the first PDU set is retransmitted via the dynamic PUSCH resource grant.

15. The method of claim 11, wherein one or more CBGs corresponding to one or more PDUs in a second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant.

16. The method according to claim 15, further comprising: If each CBG corresponding to the one or more PDUs in the second PDU set is sent in the second PUSCH transmission opportunity corresponding to the configured resource grant, an indication for canceling the dynamic PUSCH resource grant is transmitted.

17. The method of claim 11, wherein at least one CBG corresponding to one or more PDUs in the second set is sent in the dynamic PUSCH resource grant allocated for resending the at least one CBG corresponding to one or more PDUs in the first PDU set.

18. The method according to claim 11, further comprising: Transmitting an indication of retransmission of the at least one CBG corresponding to one or more PDUs in the first PDU set for the second PUSCH transmission opportunity corresponding to the configured resource grant.

19. The method of claim 18, wherein the indication is a hybrid automatic repeat request (HARQ) process ID.

20. The method of claim 19, wherein the configuration information further comprises a threshold associated with one or more HARQ transmissions.

Images