Support for Code Block Group (CBG) based transmission

Abstract

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

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 410,916, filed September 28, 2022, and U.S. Provisional Patent Application No. 63 / 526,579, filed July 13, 2023, the entire contents of each of which are incorporated herein by reference. [Background technology]

[0002] Code Block Group (CBG)-based transmission is beneficial for traffic with large transport block sizes, since in the event of an erroneous reception, only a portion of the total transport block (CBG) needs to be retransmitted. Extended Reality (XR) traffic is an example of traffic characterized by large payload sizes and sometimes bursty packets (hence large Transport Blocks (TB)), in addition to frequent arrival rates and quasi-periodicity. As a result, XR services and other traffic may demand high capacity with strict low latency requirements. Summary of the Invention

[0003] Wireless communication between one or more user equipment (UE) and a network is considered herein. A UE may also be referred to as a wireless transmit / receive unit (WTRU). The terms UE and WTRU are used interchangeably herein.

[0004] The 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 transmit multiple code block groups (CBGs) corresponding to one or more PDUs of a first protocol data unit (PDU) set using a first PUSCH transmission opportunity corresponding to the configured resource grant. If at least one of the multiple CBGs corresponding to one or more PDUs of 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 retransmission of at least one of the multiple CBGs. At least one of the multiple CBGs corresponding to one or more PDUs of the first PDU set that is to be retransmitted may be negatively acknowledged (NACK-ed). 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 (e.g., earlier in time) than the second PUSCH transmission opportunity, the WTRU may retransmit at least one CBG corresponding to one or more PDUs of the first PDU set via the dynamic PUSCH resource grant. If the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity, the WTRU may determine whether to retransmit at least one of multiple CBGs corresponding to one or more PDUs of 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.

[0005] In one example, if the remaining delay budget is less than a threshold, at least one CBG may be retransmitted using a second PUSCH transmission opportunity corresponding to the configured resource grant. One or more CBGs corresponding to one or more PDUs of the second PDU set may be transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant. For example, if all CBGs corresponding to one or more PDUs of the second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, the WTRU may send an indication to cancel the dynamic PUSCH resource grant.

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

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

[0008] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the accompanying drawings, in which: Figures of such drawings, like the detailed description, are examples; therefore, the figures and detailed description should not be considered limiting, as other equally effective embodiments are and likely are possible. [Figure 1A] FIG. 1 is an example system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is an exemplary system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C] 1A is an exemplary system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is an exemplary system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2A] 1 illustrates three exemplary 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 not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 2B] 1 illustrates three exemplary 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 not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 2C] 1 illustrates three exemplary 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 not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 3]10 is a flowchart illustrating a method performed by a wireless transmit / receive unit (WTRU) for retransmitting 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 transmitted during a first PUSCH transmission opportunity. DETAILED DESCRIPTION OF THE INVENTION

[0009] Exemplary Network for Implementation of the Invention 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. Communications system 100 may be a multiple-access system that provides content, such as voice, data, video, messaging, broadcasts, etc., to multiple wireless users. Communications 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 multicarrier (FBMC), etc.

[0010] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. As examples, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a "station" and / or "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0011] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications 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 eNodeB, a Home Node B, a Home eNodeB, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0012] 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), relay nodes, etc. The base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

[0013] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the 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).

[0014] More specifically, as noted above, the communications 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 114 a and the WTRUs 102 a, 102 b, 102 c in the RAN 104 / 113 may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA may include communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

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

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

[0019] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0020] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing 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 communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0024] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0026] 1B as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. As such, 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.

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

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

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

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

[0031] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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.

[0032] The WTRU 102 may include a full-duplex radio where transmission and reception of some or all of the signals associated with a particular subframe (e.g., for both the UL (e.g., for transmission) and the downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and or substantially eliminate self-interference via hardware (e.g., a choke) or via signal processing via a processor (e.g., a separate processor (not shown) or the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

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

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

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

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

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

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

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

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

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

[0043] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and STAs in or using the IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically set via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., any 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.

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

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

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

[0048] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only) the 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) configuration can depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

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

[0050] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one 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 communicate with the CN 115.

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

[0052] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerology. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes (e.g., including varying numbers of OFDM symbols and / or lasting varying lengths of absolute time) or transmission time intervals (TTIs) of various or scalable lengths.

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

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

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

[0056] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for 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.

[0057] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and assigning IP addresses for UEs, 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.

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

[0059] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 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 through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

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

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

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

[0063] The descriptions provided herein are for illustrative purposes and are in no way intended to limit the applicability of the methods further described herein to other wireless technologies and / or to wireless technologies using different principles, when applicable.

[0064] The term extended reality (XR) may 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 interpolated between them. VR may include rendered versions of delivered visual and auditory scenes. The rendering may be designed to mimic real-world visual (e.g., stereoscopic 3D) and / or auditory stimuli as naturally as possible to the observer or user as the observer or user moves within limits defined by the application. AR may involve users being provided with additional information or artificially generated objects and / or content overlaid on their current environment. MR may be an advanced form of AR in which some virtual elements are inserted into a physical scene with the intention of providing the illusion that these elements are part of the real scene. XR may include combined real and virtual environments and human-machine interactions generated by computer technology and / or wearables.

[0065] The concept of immersion in the context of XR services may refer to providing a sense of being surrounded by, and physically and spatially located within, a virtual environment. The level of virtualization may range from partial sensory input to fully immersive multi-sensory input, leading to a virtual reality that is virtually indistinguishable from actual reality.

[0066] XR devices may be associated with the ability to provide varying degrees of spatial tracking. XR devices may be equipped with various sensors to enable spatial tracking, such as monocular / stereo / depth cameras, radio beacons, GPS, inertial sensors, and / or the like. Such spatial tracking may be performed at different levels, such as 3 Degrees of Freedom (DoF) (e.g., rotational movement along the X, Y, and Z axes), 6 DoF (e.g., rotational and / or translational movement along the X, Y, and Z axes), etc. Such spatial tracking may result in some form of interaction to experience virtual content. A user may act within and / or interact with elements within the extended reality. For example, actions and / or interactions may include movement, gestures, gaze tracking, etc. Spatial tracking may be an enabler of an immersive XR experience. For example, some form of head and / or motion tracking may ensure that simulated visual and / or auditory components from the user's perspective can be updated to match the user's movements. Inaccurate and / or delayed spatial tracking can result in discomfort and / or a feeling of motion sickness for the user.

[0067] Described herein is a network that may refer to one or more base stations (e.g., gNBs), which may further be associated with one or more Transmission / Reception Points (TRPs) or any other nodes in a radio access network.

[0068] A WTRU may correspond to any XR device / node, which comes in various form factors. A WTRU (e.g., an XR WTRU) may include various forms, such as a head-mounted display (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, a mobile device with position tracking and a camera, a wearable, and / or the like. In addition to the above, several different types of XR WTRUs may be envisioned based on XR device capabilities, such as display, camera, sensor, sensor processing, wireless connectivity, XR / media processing, power, and / or the like, provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more devices / nodes / WTRUs may be grouped into a collaborative XR group to support any of the XR applications / services.

[0069] Throughout the embodiments described herein, a network may include, for example, 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).

[0070] Throughout the embodiments herein, a flow may correspond to one or more of a QoS flow and / or a data flow. For example, a flow of data 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, possibly originating from a common application / experience source and / or intended for a common destination device / WTRU or group of associated devices / WTRUs, may be referred to as associated or correlated flows.

[0071] Throughout the embodiments herein, a transport 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 at individual layers in 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 resource. For example, a radio resource may include a set of one or more frequency / time / space resources, such as time slots, subcarriers, or beams. A radio resource may also be associated with a configured grant (CG), a dynamic grant (DG), and / or any other resource grant or grant-free resource.

[0072] Throughout embodiments 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., PDU SET) flows, QoS flows (e.g., associated or unassociated) to one or more radio bearers, SDAPs, PDCPs, LCHs, carriers or component carriers (e.g., CCs in a CA configuration), BWPs, and radio links / interfaces (e.g., Uu links or sidelinks) that may be used to deliver PDUs, for example, in the UL or DL ​​direction.

[0073] Throughout the embodiments herein, XR / application-aware data transmission / reception or XR / application-aware QoS processing may correspond to one or more of the following, e.g., PDU sets or PDU set processing, application / higher-layer importance / priority, and / or QoS processing. A PDU set (e.g., media unit, video frame, etc.) may be composed of one or more PDUs. A PDU set may be associated with PDU-set-level QoS requirements (e.g., data rate, latency, error rate, reliability) that may be applicable to one or more PDUs (e.g., all PDUs) associated with the PDU set. Different PDUs within a PDU may be associated with individual PDU-level QoS requirements. Such associations and interdependencies may be visible to the AS layer (e.g., using associated IDs) and / or may be processed at the AS layer with awareness of the association during transmission in the UL and reception in the DL of data. Different PDUs within a PDU set or each PDU within a PDU set may be associated with a different application / higher-layer importance / priority value. Such associations and interdependencies may be visible to the AS layer (e.g., using associated IDs) and / or may be processed at the AS layer with awareness of the associations during transmission of data in the UL and / or reception in the DL.

[0074] Different PDUs within a PDU set or one or more PDUs within 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 locations of video frames whose data are carried by PDUs / PDU sets; a PDU / PDU set carrying a field of view (FoV) spatial location may be associated with higher spatial importance than a non-FoV spatial location) or temporal importance (e.g., temporal sequence of video frames whose data are carried by PDUs / PDU sets; a PDU / PDU set carrying a base video frame, such as an I-frame, may be associated with higher temporal importance than a difference video frame, such as a P-frame / B-frame). Such importance values ​​may be visible to the AS layer (e.g., by means of associated IDs / markers / indicators) during data transmission and reception, possibly enabled by application awareness.

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

[0076] Throughout the embodiments 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 size and / or priority (e.g., importance); PDUs within a PDU set may have dependencies among each other; PDUs within a PDU set may have joint QoS requirements (e.g., PDU set delay bound, PDU set error rate, PDU set throughput); PDUs and PDU sets may be characterized by intra-PDU set dependencies (e.g., varying importance between PDUs and / or the presence of redundant PDUs) and / or inter-PDU set dependencies (e.g., a next / new PDU set may be similar to or different from a previous PDU set); PDU sets may be characterized by jitter and / or non-integer periodicity values ​​(e.g., due to a PDU set generation rate that may typically follow a video frame generation rate of 60 fps or 120 fps). The PDU set may be characterized by a variable periodicity value (eg, due to a video encoder that may vary its frame generation rate during runtime).

[0077] Throughout the embodiments herein, WTRU actions related to application actions and / or AS layer actions to ensure / support differentiated QoS may correspond to one or more of the following actions. For example, the WTRU actions may include determining metadata of an application (e.g., an XR application), determining / generating application content, performing measurements and reporting, processing / forwarding data / PDUs / PDU sets and QoS associated with the PDUs / PDU sets, and / or processing / forwarding information related to connectivity with the network and / or other WTRUs. The WTRU determining application metadata may involve determining one or more of FoV / visual perimeter, 2D / 3D size, borders, spatial attributes, and FoV boundaries based on measurements in 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). The WTRU determining application metadata may include 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 an image, may be quantified and evaluated by the image resolution (e.g., number of density of megapixels). The WTRU determining the application metadata may involve determining the importance and / or priority of the FoV content. The importance may be associated with the spatial and / or temporal importance of the content / data. For example, the spatial / temporal importance values ​​may indicate absolute or relative importance associated with the FoV content. The spatial importance may be associated with one or more segments / tiles / slices / locations 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.

[0078] A WTRU determining / generating application content may involve determining / capturing, by the WTRU / node, for itself and / or on behalf of another WTRU / node, one or more 2D / 3D images / video frames associated with the FoV boundary / perimeter / boundary defined by the FoV metadata. For FoV content mapping, the WTRU may determine the images / video frames using a visual sensor (e.g., 2D / 3D camera, lidar), an RF sensor (e.g., RF transceiver, radar), an audio sensor (e.g., sonar), and / or the like. Mapping the FoV may also be referred to herein as sensing FoV content or capturing FoV content. A WTRU determining / generating application content may include recording / capturing audio frames either as part of the real-world environment or as part of an overlaid soundtrack / audio file (the audio file originates from a source other than the current real-world environment being mapped).

[0079] The WTRU may perform measurements of the attitude (e.g., 6 degrees of difference (DoD) / 3DoD orientation, location / position), speed of movement / movement, and / or the like of the user / WTRU and / or other objects (e.g., virtual or real) with which the user may interact. The WTRU may send and / or report the attitude measurements to the network periodically or upon detecting an event trigger (e.g., a change in the attitude 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, visual signals, and / or the like. The WTRU may perform measurements of an air link interface (e.g., Uu link, SL) associated with the WTRU. A WTRU may trigger reference signal transmission and / or measurements in one or more other WTRUs (e.g., over the Uu link and / or sidelink). A WTRU may send measurement reports to the network and / or another WTRU.

[0080] The WTRU may perform processing / forwarding of data / PDUs / PDU sets and processing of QoS associated with the PDUs / PDU sets. Data may possibly include any of media / image / video frames, sensor data, and measurement data (e.g., attitude measurements, link / channel measurements) determined by the WTRU to support application / service / network requests associated with the WTRU. The WTRU may send and / or receive data to / from one or more destinations, including RAN nodes (e.g., gNBs), CN functions / entities, and / or application functions (e.g., hosted in the WTRU or in the network). During transmission / reception, the WTRU may perform splitting / merging of data / PDUs in one or more QoS flows into one or more transmission configurations.

[0081] The WTRU may process / transfer information related to connectivity with the network and / or other WTRUs. For example, the WTRU may send capability information to the network, which may include capabilities for supporting one or more interfaces and / or for coordinating and / or interacting with other WTRUs / devices (e.g., via an SL interface), which may or may not be co-located with the WTRU. The WTRU may also, or alternatively, receive configuration, which may include receiving an RRC configuration from the gNB and / or an NAS layer configuration from the CN. The WTRU may also, or alternatively, send and / or receive assistance data to / from the network associated with traffic, QoS, scheduling, and / or the like to support UL / DL transmissions. The WTRU may also, or alternatively, send requests for radio resources and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

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

[0083]

number

[0084] If the WTRU is configured to transmit a code block group-based transmission by receiving higher layer parameters codeBlockGroupTransmission in PUSCH-ServingCellConfig for an initial transmission of the TB as indicated by the "New Data Indicator" field of the scheduling downlink control information (DCI), the WTRU may expect the CBGTI field to indicate that each of the CBGs (e.g., all CBGs) of the TB should 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 transmit a code block group-based transmission by receiving higher layer parameters codeBlockGroupTransmission in PUSCH-ServingCellConfig for a retransmission of the TB as indicated by the "New Data Indicator" field of the scheduling DCI, the WTRU may include the CBGs (e.g., only the CBGs) indicated by the CBGTI field of the scheduling DCI.

[0085] A bit value of '0' in the CBGTI field may indicate that the corresponding CBG may not be transmitted, and '1' indicates that the corresponding CBG may be transmitted. The order of the CBGTI field bits may be such that the CBGs are mapped in order from CBG number 0 starting from the MSB.

[0086] CBG-based transmission is beneficial for traffic with large transport block sizes because in the event of erroneous reception, a portion of the CBG of the entire transport block may need to be retransmitted (e.g., only a portion of the CBG of the entire transport block may need to be retransmitted). XR traffic may be characterized by frequent arrival rates, large payload sizes, and sometimes bursty packets (hence large TBs), as well as quasi-periodicity. As a result, XR services may require high capacity with strict low latency requirements. However, HARQ retransmissions due to large TB sizes for XR services may be expected to provide utilization and consequently impact system capacity. Therefore, CBG-based transmission for XR may significantly improve resource utilization and capacity. However, CBG-based transmission may add overhead to HARQ feedback (e.g., adding one bit to DCI per CBG). Currently, the number of CBs and CBGs in a TB may be fixed, and application / PDU level awareness may not be available to the WTRU and / or gNB when they segment the TB and determine the number of CBGs to use. Each segment and PDU (e.g., all segments and PDUs) is given equal importance, which may limit the possibility of applying efficient methods to dynamically adapt the number of CBGs in the TB to XR traffic.

[0087] Embodiments may be described herein for maintaining overhead and / or improving efficiency in HARQ feedback as the number of CBGs increases. Embodiments may also be described herein for dynamically performing grouping of CBs within a TB according to PDU / PDU set level importance priorities.

[0088] Embodiments for supporting CBG-based transmission for XR services may be described herein. The WTRU may dynamically and / or semi-statically adapt the number of CBGs used for UL transmission of the TB by selecting from a set of values ​​to be used for the number of CBGs based on attributes of the PDU / PDU set received from higher layers, including required limits on QoS. The WTRU may send assistance information to the network (e.g., base station) regarding the selected number of CBGs to be used during UL transmission and initiation.

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

[0090] The traffic information obtained by each WTRU in a cooperative group of WTRUs from the application / upper layer / network may include, but is not limited to, an identifier / ID, a traffic type associated with a data flow for each application, supported traffic attributes, and / or QoS requirements or expected QoS associated with the data. The identifier / ID may include an identifier / ID associated with an 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 group of QoS flows, a group of forwarding configurations, a group of devices / WTRUs). The identifier / ID may include an ID of an individual QoS flow, a mapping configuration, and / or a forwarding configuration. The identifier / ID may include a data type / message ID (e.g., PDU set ID, PDU ID, ID associated with attitude 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 PDUs / PDU sets / flows and one or more DL PDUs / PDU sets / flows).

[0091] The traffic information obtained by each WTRU in a cooperative group of WTRUs from the application / upper layer / network may include traffic types associated with data flows for each application. The WTRU may receive information about different data / QoS flows associated with the application, and 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, attitude / positioning data, audio data, and / or the like.

[0092] The traffic information obtained from the application / upper layer / network by each WTRU in a cooperative group of WTRUs may include attributes of the supported traffic. For example, the WTRU may receive information regarding the traffic characteristics / patterns of different data / QoS flows associated with an application, including whether the data is periodic, aperiodic, semi-persistent, quasi-periodic, and / or the like. The traffic characteristics may include one or more periodicity values ​​of the flows. The WTRU may receive information regarding the expected number of PDUs per PDU set in one or more flows per application. The information regarding the number of PDUs per PDU set may also include statistical / distribution information such as average, minimum, maximum, standard deviation values, etc. 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), an indication of the start / first and / or end / last PDU of the PDU set, and / or an indication of the association / dependency of the PDUs within the PDU set (e.g., PDU set ID, importance / priority value).

[0093] Traffic information obtained by each WTRU in a cooperative group of WTRUs from an application / upper layer / network may include QoS requirements or expected QoS associated with the data. For example, a WTRU may receive QoS requirements or expected QoS for one or more flows associated with an application, which may include data rate, latency, reliability, absolute / relative priority values, and / or the like. Information regarding QoS requirements may also or alternatively include statistical / distribution information such as average, minimum, maximum, standard deviation values, etc. A WTRU may also or alternatively receive an indication that such QoS requirements or expected QoS may refer to different QoS granularities, such as per PDU, per PDU subgroup within a PDU (e.g., one or more PDUs), per PDU set, per group of PDU sets, per flow, and / or per session.

[0094] The WTRU may send information to the network to support dynamic selection of the number of CBGs during UL transmission. For example, the WTRU may send information to the network to enable dynamic selection of the number of CBGs during UL transmission based on traffic characteristics associated with and / or available in one or more flows for data communication (e.g., for receiving / transmitting data in one or more flows). The WTRU may send the information to the network via AS layer signaling (e.g., RRC signaling and / or messages, MAC CE, control PDU, or UCI) or non-AS (Non-AS, NAS) layer signaling (e.g., PDU session-related messages).

[0095] The information sent by the WTRU may include applications supported by the WTRU. The WTRU may send numbers and / or IDs associated with the supported applications. The WTRU may also, or alternatively, send information regarding relative / absolute priority values ​​associated with the supported applications.

[0096] The information sent by the WTRU may include the data flows associated with the applications. The WTRU may send the numbers and / or IDs associated with the supported data flows for each application. The WTRU may also, or alternatively, send information regarding relative / absolute priority values ​​associated with the data flows.

[0097] The information sent by the WTRU may include data / traffic types associated with data flows for each application. The WTRU may send information about the data types carried by different flows associated with applications in each WTRU. The different flows associated with 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, attitude / positioning data, and / or audio data.

[0098] The information sent by the WTRU may include traffic characteristics and / or parameters of data / traffic associated with a data flow per application and / or per WTRU. The WTRU may send information regarding characteristics of single or multiple flow traffic associated with an application, including whether the data in each flow is periodic, aperiodic, semi-persistent, quasi-periodic, and / or the like. The WTRU may send information regarding the number of PDUs expected per PDU set in one or more flows per application. The information regarding the number of PDUs per PDU set may also or alternatively include statistical information such as average, minimum, maximum, standard deviation, etc. The WTRU may send QoS requirements (per PDU and / or per PDU set) of one or more flows associated with each application, including data rate, latency, reliability, absolute / relative priority values, and / or the like.

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

[0100] The WTRU may send 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 send the above information to the network during connectivity / session establishment and / or (re)configuration. For example, the WTRU may send the above information to the network during RRC connection, PDU session, application session establishment, and / or (re)configuration. The WTRU may send the above information when changing the RRC state for any of the WTRUs in a cooperating WTRU group.

[0101] The WTRU may send the above information when modifying / updating the data flows for each application, for example, the WTRU may send the above information when adding a new flow and / or releasing an existing flow associated with an application.

[0102] The WTRU may send the above information when it receives upper layer / application information, for example, when it receives an indication (e.g., from an application function hosted in the WTRU or in the network) that indicates a change in supported data types, traffic characteristics, QoS requirements, and / or the like.

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

[0104] A WTRU may receive configuration information from the network associated with power saving schemes 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 can dynamically and / or semi-statically adapt the number of CBGs to use when transmitting 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 to use for UL transmissions. For example, the WTRU may receive a maximum number of CBGs per TB that the WTRU is permitted to use. The WTRU may also, or alternatively, receive a set of possible numbers of CBGs that the WTRU can adapt to for a given TB per application.

[0105] The configuration information received by the WTRU may include a threshold value related to a TB size for each application. For example, the WTRU may receive a threshold value related to a minimum TB size for using CBG-based and / or TB-based transmission.

[0106] 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 QoS required per PDU / PDU set. The specific QoS-related values ​​may include, for example, PDU / PDU set-level delay bounds and / or PDU / PDU set-level error rate bounds. The WTRU may additionally or alternatively receive joint QoS requirements for PDUs across multi-flow traffic, for example, joint latency bounds associated with the time difference between the reception time of a PDU in a first flow and the reception time of another PDU in a second flow.

[0107] 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.

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

[0109] 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 associated with, for example, a number of initial UL / DL transmissions.

[0110] 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 pre-assigned to the WTRU with a given periodicity for uplink transmissions of one or more physical uplink shared channels (PUSCHs).

[0111] The configuration information received by the WTRU may include a delay budget value. For example, the delay budget value may include a PDU / PDU set level delay limit. The delay budget value may set the maximum duration a PDU / PDU set can spend being processed for transmission by lower layers in the WTRU and over the air until it arrives at the receiver (e.g., at the receiver's MAC entity).

[0112] A WTRU (e.g., any WTRU in a cooperative WTRU group) may receive the configuration information, for example, via AS layer signaling (e.g., RRC signaling / messages, MAC CE or DCI) or non-AS (NAS) layer signaling (e.g., PDU session-related messages).

[0113] The WTRU may assist the network in dynamically and / or semi-statically adapting the number of CBGs used for UL transmission of TBs to XR traffic (e.g., UL retransmission of TBs to XR traffic). The WTRU may assist the network (e.g., base station) in adapting the number of CBGs when transmitting (e.g., retransmitting) TBs in the UL. The WTRU may have received a set of values related to the number of CBGs for a given size of TB that the WTRU can adapt to. The WTRU may determine whether a dynamic PUSCH resource grant is temporally later than a second PUSCH transmission opportunity corresponding to a configured resource grant. If the dynamic PUSCH resource grant is temporally later than a second PUSCH transmission opportunity corresponding to a configured resource grant and at least one of a plurality of CBGs corresponding to one or more PDUs of a first PDU set is not successfully transmitted, the WTRU may determine whether to retransmit at least one of a plurality of CBGs corresponding to one or more PDUs of 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 the amount of time remaining in the delay budget for the first PDU set. In one example, the WTRU may receive a first and / or default number of CBGs (CBG1) and a second number of CBGs (CBG2) for a TB of a given size, where CBG1 < CBG2. The WTRU may then receive from an application / upper layer an XR data burst consisting of one or more PDUs / PDU sets and an indicator of a delay bound at the PDU / PDU set level (e.g., within the PDU header). The WTRU may use the indicated delay bound at the PDU / PDU set level (e.g., within the PDU / PDU set header) to determine whether to use the first and / or default number of CBGs (CBG1) or the second number of CBGs (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 associated with the delay bound (e.g., an XR data burst may be transmitted via multiple small-sized TBs over multiple slots), the WTRU may use a first and / or default number of CBGs (CBG1) when transmitting TBs in the UL. A second number of CBGs (CBG2) may be transmitted in the received dynamic resource grant. If the indicated PDU / PDU set-level delay bound is less than a configured threshold associated with the delay bound (e.g., an XR data burst needs to be transmitted with a large TB over a single slot), the WTRU may send an indication to the network (NW) to use the second number of CBGs for the WTRU's next UL transmission, and / or the WTRU may receive a resource grant from the gNB and transmit TBs in the UL using the second number of CBGs (CBG2) in the received resource grant. If all of the second number of CBGs (CBG2) are transmitted in the next UL transmission, the WTRU may send an indication to cancel the received dynamic resource grant. In addition, at least one CBG to be retransmitted is negatively acknowledged.

[0114] The WTRU may send an indication that the second PUSCH transmission opportunity corresponding to the configured resource grant includes a retransmission of at least one CBG corresponding to one or more PDUs of the first PDU set. 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 at the MAC layer. Since multiple HARQ processes may be running in parallel, each HARQ process may be assigned a HARQ process ID / number. In legacy procedures, a given PUSCH transmission may maintain the HARQ process ID assigned during the initial transmission and HARQ retransmissions. The HARQ process ID may be released, and possibly assigned to a subsequent PUSCH transmission, only after the MAC layer receives an ACK indicating successful reception of the PUSCH to which the HARQ process ID belonged.

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

[0116] The WTRU may incrementally or decrementally adapt the number of CBGs it uses when transmitting in the UL from a set of available numbers of CBGs (e.g., {CBG0>CBG1>CBG2}). The set of numbers of CBGs the WTRU is configured to adapt to (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 UL traffic. In one example, the WTRU may send assistance information regarding UL traffic to the network, including the expected number of PDUs per PDU set in one or more flows per application, by providing statistical information such as average, minimum, maximum, and standard deviation values. Based on the provided statistics, the network may determine a set of numbers of CBGs the WTRU can adapt to and / or send an indication to the WTRU. Alternatively, the WTRU may determine the set of numbers of CBGs based on application / higher layer information available to the WTRU. The WTRU may send assistance information to the network indicating the set of numbers of CBGs the WTRU prefers to use.

[0117] The WTRU may receive feedback indicating whether one or more CBGs corresponding to one or more PDUs were successfully or unsuccessfully received. The feedback may indicate dynamic PUSCH resource grants for retransmissions of one or more CBGs corresponding to one or more PDUs that were unsuccessfully received. For example, the WTRU may then start transmitting a first set of TBs in the UL using an initial number of CBGs (e.g., CBG0) and / or start a counter to determine the number of initial UL transmissions made before receiving a given number of NACKs. If the number of initial UL transmissions (e.g., as determined by the counter) exceeds a threshold T1 without receiving a NACK for at least X% of the CBGs relative to the total number of CBGs in the TB, the WTRU may perform a course of action. For example, the WTRU may send an indication to the network to use CBG1 number of CBGs for UL transmissions starting from the next TB and / or receive an acknowledgment from the network to use CBG1 number of CBGs. Additionally, the feedback may be received in downlink control information (DCI).

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

[0119] After receiving an acknowledgement to use CBG2, the WTRU may start transmitting TBs using the CBG1 number of CBGs, resulting in an 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 threshold T1 or T2, the WTRU may maintain the number of CBGs currently in use and / or reset the counter.

[0120] The WTRU may accommodate a TB-specific number of CBGs in multi-slot transmissions of multiple TBs using a single DCI. In multiple PUSCH (multi-slot) scheduling, the WTRU may be configured to map PDU sets to TBs so that the TBs can be scheduled for UL transmission across multiple slots in descending order of priority (e.g., QoS). The WTRU may then determine the number of CBGs to use for each TB slot according to the priority. Determining the number of CBGs may result in using different numbers of CBGs across TBs in multi-PUSCH scheduling. In one example, the WTRU may receive configuration information from the network, which may include the 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, which may or may not overlap and which may be related to QoS requirements (e.g., delay bounds), and the number of CBGs to use 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 to the first TB, and so on.

[0121] The WTRU may start receiving higher layer data bursts consisting of one or more PDU sets and / or an indication of per-PDU-set and per-data-burst delay bounds (e.g., in the PDU header). The WTRU may determine the total number of TBs needed to transmit each PDU set (e.g., all PDU sets) based on the per-PDU-set and per-data-burst delay bounds. The WTRU may map PDUs / PDU sets to corresponding TBs according to the ascending order of per-PDU-set and per-data-burst delay bounds. For each TB in multi-slot scheduling, the WTRU may determine the number of CBGs for which the WTRU 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 of the TBs scheduled in multiple slots (e.g., all TBs). The WTRU may send assistance information to the network including the number of CBGs per TB that may be used during UL transmissions of multiple PUSCHs. The WTRU may receive a scheduling grant that includes an acknowledgment to use the determined number of CBGs per TB when transmitting multi-slot traffic.

[0122] In an exemplary embodiment, as further described herein, the WTRU may determine, for each transport block (TB), the number of codeblock groups (CBGs) to use when transmitting XR data in the uplink (UL) based on the quality of service (QoS) of the XR data (e.g., the latency bound for transmitting a set of protocol data units (PDUs)). The WTRU may be configured to receive, from the gNB, configuration information including a first / default number of CBGs per TB (CBG1) and a second number of CBGs per TB (CBG2) (CBG1 < CBG2), as well as a latency threshold. The WTRU may receive, from a higher layer, an XR data burst including one or more PDU sets and / or an indicator of the latency bound at the data burst level (e.g., within the PDU header). If the latency bound is greater than the latency threshold (e.g., the XR data burst can be transmitted via a plurality of small-sized TBs over a plurality of slots), the WTRU may use the default number of CBGs per TB (CBG1) when transmitting data in the UL. If the latency bound is less than the latency threshold (e.g., the XR data burst needs to be transmitted via a large TB over a single slot), the WTRU may send an indicator to the NW regarding using 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) consisting of the second number of CBGs (CBG2) using the received resource grant.

[0123] In another example embodiment, as described further herein, the WTRU may adjust the number of CBGs to use when transmitting in the UL based on the percentage of CBGs for which a NACK is received during a specified period. The WTRU may receive configuration information including the number of CBGs to use 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 a NACK for at least X% of the total number of CBGs used. The WTRU may transmit a first TB with the initial number (e.g., N0) of CBGs in the UL 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., as determined by the counter) exceeds the threshold C1 before receiving a NACK for at least X% of the CBGs, the WTRU may send an indication to the network to use N1 number of CBGs in the next UL transmission and / or the WTRU may pause the counter and start using N1 number of CBGs after receiving an acknowledgment from the NW. The HARQ feedback overhead may be reduced by N0-N1. While transmitting a TB with N1 CBGs, if the number of initial UL transmissions exceeds a threshold C2 before receiving a NACK for at least X% of the CBGs, the WTRU may send an indication to the network to use N2 CBGs in the next UL transmission and / or reset a counter, and start using N2 CBGs after receiving an acknowledgment from the NW. The HARQ feedback overhead may be reduced by N0-N2. If the WTRU receives a NACK for at least X% of the CBGs before the counter exceeds threshold C1 or C2, the WTRU may maintain the number of CBGs currently in use and / or reset the counter.

[0124] In another example embodiment, as described herein, a 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 multiple-PUSCH (multi-slot) scheduling. The WTRU may determine the number of CBGs to use for each TB according to priority, which may result in using different numbers of CBGs across TBs in multi-PUSCH scheduling. The WTRU may be configured to receive configuration information that may include the maximum number of CBGs in each TB (e.g., all TBs). The WTRU may receive, from higher layers, data bursts consisting of one or more PDU sets and / or an indication (e.g., in a PDU header) of delay bounds per PDU set and per data burst. The WTRU may determine the number of TBs / slots for transmitting each PDU set (e.g., all PDU sets) based on the delay bounds per PDU set and per data burst. The WTRU may determine the number of CBGs per TB (e.g., carrying each PDU set) for each TB (e.g., all TBs) based on the maximum number of CBGs, delay bound, and / or the determined number of TBs / slots. The WTRU may transmit an indication to the gNB regarding the determined number of CBGs per TB. The WTRU may receive resource grants for multiple TBs (e.g., multi-slot scheduling). The WTRU may use the received resource grant to transmit TBs (e.g., carrying PDU sets) including the determined number of CBGs per TB.

[0125] 2A-2C illustrate three exemplary 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. PDU set 204 may include multiple PDUs 202a-202e. Each PDU 202a-202e may include multiple CBGs (e.g., four CBGs). CBGs may be acknowledged (ACK-ed) and / or unacknowledged (NACK-ed). For example, CBG 3 in PDU 202b and CBG 2 in PDU 202d are NACK-ed, while CBGs 1-4 in PDU 202c are ACK-ed. Similarly, PDU set 212 may include multiple PDUs (e.g., five 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 slot (UL slot). One or more downlink slots (DL slots) may exist between the first PUSCH transmission opportunity and the second PUSCH transmission opportunity.

[0126] 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. The WTRU may fail to transmit at least one CBG corresponding to the first PDU set 204 during the first transmission opportunity. For example, the WTRU may fail to transmit NACKed CBG3 in PDU 202b and NACKed CBG2 in PDU 202d. The WTRU may receive feedback when at least one CBG corresponding to the first PDU set 204 was not successfully transmitted. For example, the at least one CBG corresponding to the first PDU set 204 that was not successfully transmitted may constitute a bundle 210 of one or more CBGs. The bundle 210 may include all NACKed CBGs in the first PDU set 204, e.g., CBG3 in PDU 202b and CBG2 in PDU 202d. The feedback may be received in downlink control information (DCI) 206. The feedback received in DCI 206 may be received in a DL slot between one or more DL slots.

[0127] The WTRU may determine whether the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity. In FIG. 2A , the WTRU may determine that the dynamic PUSCH resource grant is not later in time (e.g., earlier in time) than the second PUSCH transmission opportunity. Thus, the WTRU may retransmit at least one CBG corresponding to the unsuccessfully transmitted first PDU set 204 via the dynamic PUSCH resource grant 208 before the second PUSCH transmission opportunity. The PDU set 212 may be transmitted in the second PUSCH transmission opportunity.

[0128] 2B , a bundle 210 including all NACKed CBGs in the first PDU set 204 (e.g., CBG3 in PDU 202b and CBG2 in PDU 202d) may not be successfully transmitted in the first PUSCH transmission opportunity. After receiving 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) corresponding to the unsuccessfully transmitted first PDU set 204 via the second PUSCH transmission opportunity corresponding to the configured resource grant. Additionally, 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. A bundle 210 including all NACKed CBGs 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 PDU set 212 (e.g., PDUs 1-4 in PDU set 212) in the second PUSCH transmission opportunity. One or more extra CBGs in PDU set 212 may not be transmitted in the second PUSCH transmission opportunity. The WTRU may transmit 216a one or more extra CBGs in PDU set 212 (e.g., PDU 214) in the dynamic PUSCH resource grant allocated for retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set 204.

[0129] 2C , bundle 210 including all NACKed CBGs in first PDU set 204 (e.g., CBG3 in PDU 202b and CBG2 in PDU 202d) may not be successfully transmitted in the first PUSCH transmission opportunity. After receiving feedback in 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) corresponding to the first PDU set 204 that was not successfully transmitted via the second PUSCH transmission opportunity corresponding to the configured resource grant. Additionally, 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. The bundle 210 including all NACKed CBGs in the first PDU set 204 (e.g., CBG3 in PDU 202b and CBG2 in PDU 202d) may be retransmitted in the second PUSCH transmission opportunity along with all CBGs in all PDUs of the PDU set 212. If all CBGs corresponding to one or more PDUs of the second PDU set 212 are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, the WTRU may send an indication to cancel the dynamic PUSCH resource grant in 216b. The method mentioned above may utilize the configured resource grant available for CBG retransmission before the expiration of the PDU set latency budget for the first PDU set 204. This may enable the WTRU to achieve the strict high reliability and low latency requirements imposed on XR applications.

[0130] 3 is a flowchart illustrating a method performed by a WTRU to retransmit 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 transmitted during a first PUSCH transmission opportunity. The method may encompass, for example, the three example retransmissions discussed above in FIGS. 2A-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 configured resource grants for one or more physical uplink shared channels (PUSCH resources). At 304, the WTRU may transmit multiple code block groups (CBGs) corresponding to one or more PDUs of the first protocol data unit (PDU) set using the first PUSCH transmission opportunity corresponding to the configured resource grant. If at least one of the multiple CBGs corresponding to one or more PDUs of 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 retransmission of at least one of the multiple CBGs. At least one of the multiple CBGs corresponding to one or more PDUs of the first PDU set to be retransmitted may be 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 (e.g., earlier in time) than the second PUSCH transmission opportunity, the WTRU may retransmit at least one CBG corresponding to one or more PDUs of the first PDU set via the dynamic PUSCH resource grant at 310, as shown in FIG. 2A.If the dynamic PUSCH resource grant is later in time than the second PUSCH transmission opportunity, the WTRU may determine 312 whether to retransmit at least one of the multiple CBGs corresponding to one or more PDUs of 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.

[0131] In one example, if the remaining delay budget is less than a threshold at 314, at least one CBG may be retransmitted using a second PUSCH transmission opportunity corresponding to the configured resource grant at 318. One or more CBGs corresponding to one or more PDUs of the second PDU set may be transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant. For example, if all CBGs corresponding to one or more PDUs of the second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant, the WTRU may send an indication to cancel the dynamic PUSCH resource grant at 320, as shown in FIG.

[0132] In another example, if the remaining delay budget is greater than a threshold at 316, at least one CBG may be retransmitted using a second PUSCH transmission opportunity corresponding to a configured resource grant at 322. The at least one CBG corresponding to one or more PDUs of the second set may be transmitted in a dynamic PUSCH resource grant allocated for retransmission of the at least one CBG corresponding to one or more PDUs of the first PDU set, as shown in FIG.

[0133] The WTRU may further send an indication that the second PUSCH transmission opportunity corresponding to the configured resource grant includes a retransmission of at least one CBG corresponding to one or more PDUs of the first PDU set. The indication may be a Hybrid Automatic Repeat Request (HARQ) process ID. For example, the configuration information may also include a threshold associated with the one or more HARQ transmissions. The WTRU may retransmit the at least one CBG corresponding to the one or more PDUs of the first PDU set.

[0134] While features and elements have been provided above in particular combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. The present disclosure should not be limited in terms of the specific embodiments described herein; these embodiments are intended as illustrations of various aspects. It will be apparent to those skilled in the art that many modifications and variations can be made without departing from the spirit and scope of the present invention. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly stated as such. Functionally equivalent methods, apparatus, and articles of manufacture within the scope of the present disclosure, in addition to those enumerated herein, will be apparent to those skilled in the art from the foregoing description. Such modifications and variations are intended to fall within the scope of the appended claims. The present disclosure should be limited only by the terms of such claims, along with the full scope of equivalents to which such claims are entitled. It is understood that the present disclosure is not limited to any particular method or system.

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

[0136] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or “image” may mean any of a snapshot, a single image, and / or multiple images displayed over time, or any suitable combination thereof. As another 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 several embodiments of a WTRU, (iii) a wireless-enabled and / or wired-enabled (e.g., tetherable) device configured with, among other things, some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired-enabled device configured with less than all of the structure and functionality of a WTRU, or (iv) the like. Details of an exemplary WTRU that may represent any WTRU described herein are provided herein with respect to FIGS. 1A-1D . As another example, various embodiments disclosed herein above and below are described 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 adaptive reality experience.

[0137] Additionally, the methods provided herein may be implemented in a computer program, software, or firmware embodied in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media that are distinct from signals include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

[0138] Variations of the methods, apparatus, articles of manufacture, 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 construed as limiting the scope of the following claims. For example, the embodiments provided herein include handheld devices, which may include or be utilized with any suitable voltage source, such as a battery providing any suitable voltage.

[0139] Furthermore, in the embodiments provided herein, references are made to processing platforms, computing systems, controllers, and other devices that include processors. These devices may include at least one central processing unit ("Central Processing Unit" (CPU)) and memory. In accordance with the practices of those skilled in the art of computer programming, references to acts and symbolic representations of operations or instructions may be performed by various CPUs and memories. Such acts and operations or instructions may be referred to as being "executed," "executed by a computer," or "executed by a CPU."

[0140] Those skilled in the art will understand that the operations and symbolically represented operations or instructions include the manipulation of electrical signals by a CPU. The electrical system represents data bits that may cause a resulting transformation or reduction of the electrical signals, and maintains the data bits in memory locations in a memory system, thereby reconfiguring or otherwise altering the operation of the CPU and the processing of other signals. The memory locations in which the data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties that correspond to or represent the data bits. It should be understood that embodiments are not limited to the platforms or CPUs mentioned above, and that other platforms and CPUs may support the provided methods.

[0141] 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 a CPU. The computer-readable medium may include computer-readable media that reside exclusively on a processing system, or distributed, cooperative, or interconnected among multiple interconnected processing systems, which may be local or remote to a processing system. It should be understood that embodiments are not limited to the memories mentioned above, and that other platforms and memories may support the provided methods.

[0142] In an illustrative 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.

[0143] The foregoing detailed description has described various embodiments of devices and / or processes through the use of block diagrams, flowcharts, and / or examples. To the extent that such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, those skilled in the art will understand that each function and / or operation in such block diagrams, flowcharts, or examples can be individually and / or collectively implemented by a wide range of hardware, software, firmware, or substantially any combination thereof. In exemplary embodiments, some portions of the subject matter described herein can be implemented via an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), and / or other integrated formats. Those skilled in the art will recognize that certain aspects of the embodiments disclosed herein may be equivalently implemented, in whole or in part, in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as substantially any combination thereof, and that designing circuitry and / or writing software and / or firmware code is well within the skill of those skilled in the art in light of this disclosure. Those skilled in the art will understand that the subject matter mechanisms described herein may be distributed as program products in various forms, and that the illustrative embodiments of the subject matter described herein apply regardless of the particular type of signal-bearing medium used to actually effect the distribution. Examples of signal bearing media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tape, computer memory, and transmission media such as digital and / or analog communications media (e.g., fiber optic cables, wave guides, wired communications links, wireless communications links, etc.).

[0144] Those skilled in the art will recognize that it is common in the art to describe devices and / or processes in the manner described herein and then use engineering techniques 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 through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system may generally include one or more of the following: a system unit housing; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computational entities, such as an operating system, drivers, a graphical user interface, and application programs; one or more interaction devices, such as a touchpad or screen; and / or a control system, including feedback loops and control motors (e.g., feedback for sensing position and / or velocity, control motors for moving and / or adjusting components and / or quantities). A typical data processing system may be implemented utilizing any suitable commercially available components, such as those typically found in data computing / communication systems and / or network computing / communication systems.

[0145] The subject matter described herein may, in some cases, illustrate different components that are contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and that in fact many other architectures that achieve the same functionality may be implemented. Conceptually, any arrangement of components to achieve the same functionality is effectively “associated” such that the desired functionality may be achieved. Thus, any two components herein that combine to achieve a particular function may be considered to be “associated” with each other such that the desired functionality is achieved, regardless of the architecture or intervening components. Similarly, any two components so associated may be considered to be “operably connected” or “operably coupled” to each other to achieve the desired functionality, and any two components that can be associated in this way may also be considered to be “operably couplable” to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, components that are physically matable and / or physically interacting, and / or components that are wirelessly interacting and / or wirelessly interacting, and / or components that logically interact and / or logically interacting.

[0146] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for purposes of clarity.

[0147] In general, it will be understood by those skilled in the art that the terms used in this specification, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as “open” terms (e.g., the term “comprising” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including, but not limited to,” etc.). Where a specific number of introduced claim recitations are intended, such intention will be explicitly stated in the claim; in the absence of such a statement, it will be further understood by those skilled in the art that no such intention exists. For example, where only one item is intended, the term “single” or similar language may be used. To assist in understanding, the following appended claims and / or description of this specification may include 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 suggesting that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim containing such an introduced claim recitation to embodiments containing only one such recitation, even if the same claim also contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same applies to the use of definite articles used to introduce claim recitations. Additionally, even when a specific number of introduced claim recitations is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the simple recitation "two recitations" without other modifiers means at least two recitations, or more than two recitations).Furthermore, when notation similar to "at least one of A, B, and C, etc." is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, and C" would include, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). When notation similar to "at least one of A, B, or C, etc." is used, such structure is generally intended as the meaning that one of ordinary skill in the art would understand the notation (e.g., "a system having at least one of A, B, or C" would include, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together, etc.). It will be further understood by those skilled in the art that any disjunctive word and / or phrase 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, either of the terms, or both terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B." Additionally, as used herein, the term "any of," followed by a list of items and / or a list of categories of items, is intended to include "any of," "any combination of," "any plurality of," and / or "any combination of" the items and / or categories of items, individually 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 "number" is intended to include any number, including zero. Also, as used herein, the term "multiple" is intended to be synonymous with "plurality."

[0148] Additionally, where features or aspects of the disclosure are described in terms of a Markush group, those skilled in the art will recognize that the disclosure is also thereby described in terms of any individual element or subgroup of elements of the Markush group.

[0149] As will be understood by those skilled in the art, for all purposes, including in terms of providing a written description, all ranges disclosed herein encompass any possible subranges and combinations of subranges. Any recited range can be readily recognized as fully descriptive and allowing the same range to be broken down into at least equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each range discussed herein can be easily broken down into a lower third, middle third, upper third, etc. Also, as will be understood by those skilled in the art, all terms such as "up to," "at least," "greater than," "less than," etc., refer to ranges that are inclusive of the recited numbers and that can be subsequently broken down into subranges as discussed above. Finally, as will be understood by those skilled in the art, ranges include each individual element. Thus, for example, a group having 1 to 3 cells refers to a group having 1, 2, or 3 cells. Similarly, a group having 1 to 5 cells refers to a group having 1, 2, 3, 4, or 5 cells, and so on.

Claims

1. A wireless transmission / reception unit (WTRU), The system receives configuration information including a delay budget value and an indication of configured resource permissions for one or more physical uplink shared channel (PUSCH) resources. Using a first PUSCH transmission opportunity corresponding to the configured resource authorization, transmit multiple code block groups (multiple CBGs) corresponding to one or more PDUs of the first protocol data unit set (first PDU set), Feedback is received indicating that at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set was not successfully received, and the feedback indicates a dynamic PUSCH resource authorization for retransmission of at least one of the plurality of CBGs. The dynamic PUSCH resource authorization is determined to occur later in time than the second PUSCH transmission opportunity corresponding to the configured resource authorization. Using the second PUSCH transmission opportunity corresponding to the configured resource authorization, determine whether to retransmit at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set. The at least one CBG corresponding to one or more PDUs of the first PDU set is configured to retransmit Processor WTRU equipped with.

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

3. The WTRU according to claim 1, wherein at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set, which will be retransmitted, is given a negative response.

4. The WTRU according to claim 1, wherein the dynamic PUSCH resource authorization occurs earlier than the second PUSCH transmission opportunity corresponding to the configured resource authorization, and the processor is further configured to retransmit the at least one CBG corresponding to one or more PDUs of the first PDU set via the dynamic PUSCH resource authorization.

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

6. The WTRU according to claim 5, wherein the processor is further configured to send an indication to cancel the dynamic PUSCH resource grant when all CBGs corresponding to one or more PDUs of the second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource grant.

7. The WTRU according to claim 1, wherein at least one CBG corresponding to one or more PDUs of a second PDU set is transmitted in the dynamic PUSCH resource authorization allocated for retransmission of the at least one CBG corresponding to one or more PDUs of the first PDU set.

8. The WTRU according to claim 1, wherein the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource authorization when the remaining delay budget is less than a threshold, and the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource authorization when the remaining delay budget is greater than the threshold.

9. The WTRU according to claim 1, wherein the processor is further configured to send an indication that the second PUSCH transmission opportunity corresponding to the configured resource authorization includes a retransmission of the at least one CBG corresponding to one or more PDUs of the first PDU set, the indication being a Hybrid Auto Retransmission Request (HARQ) process ID.

10. The WTRU according to claim 9, further comprising the configuration information thresholds associated with one or more HARQ transmissions.

11. A method performed by a wireless transmit / receive unit (WTRU), The steps include receiving configuration information including a delay budget value and an indication of configured resource permissions for one or more physical uplink shared channel (PUSCH) resources, The steps include: using a first PUSCH transmission opportunity corresponding to the configured resource authorization, transmitting multiple code block groups (multiple CBGs) corresponding to one or more PDUs of a first protocol data unit set (first PDU set); Steps include receiving feedback indicating that at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set was not successfully received, wherein the feedback indicates a dynamic PUSCH resource authorization for retransmission of at least one of the plurality of CBGs, The steps include determining that the dynamic PUSCH resource authorization occurs later in time than the second PUSCH transmission opportunity corresponding to the configured resource authorization, The steps include determining whether to retransmit at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set using the second PUSCH transmission opportunity corresponding to the configured resource authorization, The steps include: retransmitting the at least one CBG corresponding to one or more PDUs of the first PDU set; A method for providing this.

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

13. The method according to claim 11, wherein at least one of the plurality of CBGs corresponding to one or more PDUs in the first PDU set that will be retransmitted is given a negative response.

14. The dynamic PUSCH resource authorization occurs earlier than the second PUSCH transmission opportunity corresponding to the configured resource authorization. The step of retransmitting the at least one CBG corresponding to one or more PDUs of the first PDU set via the dynamic PUSCH resource authorization. The method according to claim 11, further comprising:

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

16. The method of claim 15, further comprising the step of sending an indication to cancel the dynamic PUSCH resource authorization if all CBGs corresponding to one or more PDUs in the second PDU set are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource authorization.

17. The method according to claim 11, wherein at least one CBG corresponding to one or more PDUs of a second PDU set is transmitted in the dynamic PUSCH resource authorization allocated for retransmission of the at least one CBG corresponding to one or more PDUs of the first PDU set.

18. The method according to claim 11, wherein the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource authorization if the remaining delay budget is less than a threshold, and the at least one CBG is transmitted using the second PUSCH transmission opportunity corresponding to the configured resource authorization if the remaining delay budget is greater than the threshold.

19. The method according to claim 11, further comprising the step of sending an indication that the second PUSCH transmission opportunity corresponding to the configured resource authorization includes a retransmission of the at least one CBG corresponding to one or more PDUs of the first PDU set, wherein the indication is a Hybrid Automated Retransmission Request (HARQ) process ID.

20. The method according to claim 19, wherein the configuration information further includes thresholds associated with one or more HARQ transmissions.

Images