Support for Code Block Group (CBG) based submissions

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 on September 28, 2022, and U.S. Provisional Patent Application No. 63 / 526,579, filed on July 13, 2023, the entire contents of each of these provisional applications being incorporated herein by reference.

Background Art

[0002] Code Block Group (CBG) - based transmission is beneficial for traffic with large transport block sizes because, in case of mis - reception, only a part (CBG) of all transport blocks needs to be re - transmitted. Extended Reality (XR) traffic is an example of traffic characterized by a large payload size, and sometimes bursty packets (and thus large transport blocks (TBs)) in addition to a frequent arrival rate and quasi - periodicity. As a result, XR services and other traffic may require high capacity along with strict low - latency requirements.

Summary of the Invention

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

[0004] A WTRU may receive configuration information. The configuration information may be, for example, a delay budget value and / or a configured resource grant for one or more physical uplink shared channels (PUSCH resources) IndicationThis may include: The WTRU may use a first PUSCH transmission opportunity corresponding to a configured resource authorization to transmit multiple code block groups (CBGs) corresponding to one or more PDUs in a first set of protocol data units (PDUs). If at least one of the multiple CBGs corresponding to one or more PDUs in the first set of PDUs is not successfully received, the WTRU may receive feedback. For example, the feedback may indicate a dynamic PUSCH resource authorization for retransmission of at least one of the multiple CBGs. At least one of the multiple CBGs corresponding to one or more PDUs in the first set that should 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 authorization is temporally later than a second PUSCH transmission opportunity. If a dynamic PUSCH resource authorization is not later in time than (e.g., earlier in time than) a second PUSCH transmission opportunity, the WTRU may retransmit at least one CBG corresponding to one or more PDUs in the first PDU set via the dynamic PUSCH resource authorization. If a dynamic PUSCH resource authorization is later in time than a second PUSCH transmission opportunity, the WTRU may determine whether to retransmit at least one of several CBGs corresponding to one or more PDUs in the first PDU set using the dynamic PUSCH resource authorization or using a second PUSCH transmission opportunity corresponding to a configured resource authorization. For example, the determination may be based on the amount of time remaining in the delay budget for the first PDU set and a threshold.

[0005] For 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 authorization. One or more CBGs corresponding to one or more PDUs in a second set of PDUs may be transmitted in a second PUSCH transmission opportunity corresponding to the configured resource authorization. For example, if all CBGs corresponding to one or more PDUs in a second set of PDUs are transmitted in a second PUSCH transmission opportunity corresponding to the configured resource authorization, the WTRU will cancel the dynamic PUSCH resource authorization. Indication It can be sent.

[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 authorization. At least one CBG corresponding to one or more PDUs in the second set may be transmitted in a dynamic PUSCH resource authorization allocated for the retransmission of at least one CBG corresponding to one or more PDUs in the first set of PDUs.

[0007] The WTRU further states that a second PUSCH transmission opportunity corresponding to a configured resource authorization includes a retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set. Indication It can be sent. Indication This could be a hybrid automatic repeat request (HARQ) process ID. For example, the configuration information may also include thresholds associated with one or more HARQ transmissions. The WTRU may retransmit at least one CBG corresponding to one or more PDUs in the first set of PDUs. [Brief explanation of the drawing]

[0008] A more detailed understanding can be obtained from the following detailed description, which is given as an example in conjunction with the attached drawings. The figures in such drawings, as well as the detailed description, are embodiments. Therefore, the figures and detailed description should not be considered limiting, and other similarly effective embodiments are possible and likely. [Figure 1A] This is an exemplary system diagram illustrating an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is an exemplary system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used in a communication system illustrated in Figure 1A, according to one embodiment. [Figure 1C] This is an exemplary system diagram illustrating an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in a communication system illustrated in Figure 1A according to one embodiment. [Figure 1D] This is an exemplary system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used in the communication system illustrated in Figure 1A according to one embodiment. [Figure 2A] Three exemplary retransmissions of at least one code block group (CBG) corresponding to a first set of packet data units (PDUs) are illustrated after at least one CBG was not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 2B] Three exemplary retransmissions of at least one code block group (CBG) corresponding to a first set of packet data units (PDUs) are illustrated after at least one CBG was not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 2C]Three exemplary retransmissions of at least one code block group (CBG) corresponding to a first set of packet data units (PDUs) are illustrated after at least one CBG was not successfully transmitted during a first physical uplink shared channel (PUSCH) transmission opportunity. [Figure 3] This flowchart illustrates how a radio transmit / receive unit (WTRU) may perform actions to retransmit at least one CBG corresponding to a first PDU set after the CBG corresponding to the first PDU set was not successfully transmitted during a first PUSCH transmit opportunity. [Modes for carrying out the invention]

[0009] Exemplary network for implementation of the present invention Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message delivery, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the 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 filtering OFDM, and filter bank multicarrier (FBMC).

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

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

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

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

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

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

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

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

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

[0019] The base station 114b in FIG. 1A can be, for example, a wireless router, a home node B, a home e-node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as an office, 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 can implement a wireless 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 can implement a wireless 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

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

[0021] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, and these networks and devices 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 a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may employ the same RAT or a different RAT than the RAN104 / 113.

[0022] Some or all of the WTRU102a, 102b, 102c, 102d within the communication system 100 may include multimode capabilities (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in FIG. 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

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

[0024] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B depicts the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0025] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 may be a radiator / 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 optical 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] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

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

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

[0029] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), 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, the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with the embodiments.

[0031] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, 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, and the like. The peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0032] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in 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., chokes) or via signal processing via a processor (e.g., a separate processor (not shown) or processor 118). In embodiments, WRTU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception).

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

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

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

[0036] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned elements is depicted as part of CN106, it should be understood that any of these elements may be owned and / or operated by a legal entity other than the CN operator.

[0037] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0038] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0039] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

[0041] While the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (e.g., temporarily or permanently).

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

[0043] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic in and / or out of the BSS. Traffic originating outside the BSS and destined for an STA may reach and be delivered to the STA via an AP. Traffic originating from an STA for a destination outside the BSS may be sent to an AP to be delivered to its respective destination. Traffic between STAs within the BSS may be sent, for example, via an AP; a source STA may send traffic to an AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) 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 Independent BSS (IBSS) mode may not have APs, and STAs in or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.

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

[0045] High-throughput (HT) STAs may use a 40 MHz wide channel 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] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, the data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the operation 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 bandwidth and carrier 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 the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for certain and / or limited bandwidths (e.g., support only for those bandwidths). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).

[0048] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 1 MHz mode, even if other STAs in the AP and 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) settings may depend on the status of the primary channel. For example, if the primary channel is busy due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could potentially be available.

[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] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

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

[0052] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes of varying or expandable lengths (e.g., containing a varying number of OFDM symbols and / or having an absolute time of varying length) or transmission time intervals (TTI).

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

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

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

[0056] AMF182a and 182b can be connected to one or more gNB180a, 180b, and 180c in RAN113 via the N2 interface and can function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 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, and services for machine type communication (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

[0058] UPF184a and 184b may be connected via the N3 interface to one or more gNB180a, 180b, and 180c in RAN113, thereby providing WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

[0059] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local data networks (DN) 185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

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

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

[0062] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory 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 (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.

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

[0064] The term Extended Reality (XR) can be used as a comprehensive 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. 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 they move within limits defined by the application. AR may include 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 several virtual elements are inserted into a physical scene with the intention of providing the illusion that these elements are part of a real-world scene. XR may include combined real and virtual environments and human-machine interactions generated by computer technology and / or wearables.

[0065] In the context of XR services, the concept of immersion can refer to providing a sense of being surrounded by a virtual environment, as well as a sense of being physically and spatially located within that virtual environment. The level of virtualization can 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 can 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, wireless beacons, GPS, inertial sensors, and / or similar. Such spatial tracking can be performed at different levels, such as 3 degrees of freedom (DoF) – e.g., rotational motion along the X, Y, and Z axes, or 6DoF – e.g., rotational and / or translational motion along the X, Y, and Z axes. Such spatial tracking can lead to interactions for experiencing some form of virtual content. Users can act within extended reality and / or interact with elements within extended reality. For example, actions and / or interactions may include movement, gestures, and eye-tracking. Spatial tracking can be an enabler for immersive XR experiences. For example, some form of head and / or motion tracking can ensure that simulated visual and / or auditory components from the user's viewpoint are updated to match the user's movement. Inaccurate and / or delayed spatial tracking can cause discomfort and / or motion sickness for the user.

[0067] The network described herein may refer to one or more base stations (e.g., gNBs), where each base station may be associated with one or more transmission / reception points (TRPs) or any other nodes in the radio access network.

[0068] A WTRU can correspond to any XR device / node delivered in various form factors. A WTRU (e.g., an XR WTRU) can take various forms, including head-mounted displays (HMDs), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearables, and / or similar devices. In addition to the above, several different types of XR WTRUs can be envisioned based on XR device capabilities, for example, one or more devices, wearables, actuators, controllers, and / or accessories that provide displays, cameras, sensors, sensor processing, wireless connectivity, XR / media processing, power supplies, and / or similar devices. One or more devices / nodes / WTRUs can be grouped into a collaborative XR group to support any of the XR applications / services.

[0069] Throughout the embodiments described herein, the network may include, for example, base stations (e.g., gNB, TRP, RAN nodes, access nodes), core network functions (e.g., AMF), and application functions (e.g., edge server functions, remote server functions).

[0070] Throughout the embodiments of this specification, a flow may correspond to one or more QoS flows and / or data flows. For example, a data flow may consist of one or more PDUs or sets of PDUs. One or more PDUs or sets of PDUs may be associated with one or more QoS requirements. One or more QoS requirements may include latency, data rate, reliability, and / or RTT latency. Different flows that may originate from a common application / experience source and / or target a common destination device / WTRU or group of associated devices / WTRUs may be referred to as associated flows or correlated flows.

[0071] Throughout the embodiments of this specification, a transport configuration may correspond to one or more of the following: radio bearers (e.g., data radio bearers (DRB) and / or signaling radio bearers (SRB)), logical channels (LCH), logical channel groups (LCG), configuration parameters in individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, other protocol layers), parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD), BWP, carriers, radio links / interfaces (Uu links, SL), and / or radio resources. For example, radio resources may include one or more sets of frequency / time / spatial resources, such as time slots, subcarriers, or beams. Radio resources may also be associated with configured grants (CG), dynamic grants (DG), and / or any other resource grants or grant-free resources.

[0072] Throughout the embodiments of this specification, the 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 side links) which can be used to deliver PDUs in, for example, UL or DL ​​directions.

[0073] Throughout the embodiments of this specification, XR / application-aware data transmission / reception or XR / application-aware QoS processing may correspond to one or more of the following: for example, PDU sets or PDU set processing, application / high-layer importance / priority, and / or QoS processing. A PDU set (e.g., media unit, video frame, etc.) may consist 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) which may be applicable to one or more PDUs associated with the PDU set (e.g., all PDUs). Different PDUs in 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 processed at the AS layer by recognizing the associations during data transmission in UL and reception in DL. Different PDUs within a PDU set or each PDU within a PDU set may be associated with different application / high-layer importance / priority values. Such associations and interdependencies may be visible to the AS layer (for example, using associated IDs) and / or may be recognized and processed at the AS layer during data transmission in UL and / or reception in 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., a PDU / PDU set carrying field of view (FoV) spatial locations may be associated with a higher spatial importance than non-FoV spatial locations, i.e., the spatial location of the video frame data carried by the PDU / PDU set) or temporal importance (e.g., a PDU / PDU set carrying base video frames such as I-frames may be associated with a higher temporal importance than differential video frames such as P-frames / B-frames, i.e., the temporal sequence of the video frame data carried by the PDU / PDU set). Such importance values ​​may be enabled during data transmission and reception, possibly by application recognition (e.g., associated ID / marker / Indication (Using this method) it may be visible to the AS layer.

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

[0076] Throughout the embodiments of this specification, one or more 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 video frame) may contain multiple PDUs. PDUs within the same PDU set may have the same or different payload sizes and / or priorities (e.g., importance). PDUs within a PDU set may have dependencies on one another. PDUs within a PDU set may have joint QoS requirements (e.g., PDU set delay limits, PDU set error rates, PDU set throughput). PDUs and PDU sets may be characterized by dependencies within PDU sets (e.g., changes in importance between PDUs and / or the existence of redundant PDUs) and / or dependencies between PDU sets (e.g., the next / new PDU set may be similar to or different from the previous PDU set). A PDU set may be characterized by jitter and / or non-integer periodicity values ​​(e.g., by a PDU set generation rate that may typically follow a video frame generation rate of 60 fps or 120 fps). The PDU set can be characterized by a variable periodic value (for example, by a video encoder that can change the frame generation rate during runtime).

[0077] Throughout the embodiments of this specification, WTRU actions related to application actions and / or AS layer actions for ensuring / supporting differentiated QoS may correspond to one or more of the following actions: For example, a WTRU action may include determining metadata for an application (e.g., an XR application), determining / generating, measuring and reporting application content, processing / transferring data / PDU / PDU sets and processing the QoS associated with PDU / PDU sets, and / or processing / transferring information related to connectivity with networks and / or other WTRUs. A WTRU determining application metadata may involve determining one or more of FoV / visual perimeter, 2D / 3D size, boundaries, 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). A WTRU determining application metadata may include determining the quality of FoV content. For example, a WTRU can determine whether FoV content is of high quality, which, in the case of an image, can be quantified and evaluated by image resolution (e.g., the number of density of megapixels). Determining the metadata of an application may involve determining the importance and / or priority of the FoV content. Importance may be associated with the spatial and / or temporal importance of the content / data. For example, a spatial / temporal importance value may indicate the absolute or relative importance associated with the FoV content. Spatial importance may be associated with one or more segments / tiles / slices / locations of the FoV in the spatial dimension. Temporal importance may be associated with one or more frames / subframes of the FoV in the temporal dimension.

[0078] A WTRU that determines / generates application content may involve determining / capturing one or more 2D / 3D image / video frames associated with the FoV boundary / surroundings / boundaries defined by FoV metadata, either for itself or on behalf of another WTRU / node. In the case of FoV content mapping, a WTRU may determine image / video frames using visual sensors (e.g., 2D / 3D cameras, lidars), RF sensors (e.g., RF transceivers, radars), audio sensors (e.g., sonar), and / or similar. Hereinafter, FoV mapping may also be referred to as sensing FoV content or capturing FoV content. A WTRU that determines / generates application content may include recording / capturing audio frames, either as part of the real environment or as part of an overlaid soundtrack / audio file (the audio file originates from a source other than the current real environment being mapped).

[0079] The WTRU may perform measurements of the user / WTRU and / or other objects (e.g., virtual or real) that the user may be interacting with (e.g., orientation of 6 degrees of difference (DoD) / 3DoD, location / position), velocity of motion / movement, and / or similar. The WTRU may send and / or report attitude measurements to the network periodically or when an event trigger (e.g., change in attitude measurement above / below a threshold) is detected. The WTRU may perform measurements of one or more of the following: reference signals (e.g., SSB, channel state information (CSI)-SR, physical reference signal (PRS), sidelink reference signal (RS)), GNSS signals, unauthorized carriers, ultra-wideband signals, LIDAR signals, visual signals, and / or similar. The WTRU may perform measurements of the radio link interface associated with the WTRU (e.g., Uu link, SL). A WTRU may trigger the transmission and / or measurement of a reference signal in one or more other WTRUs (e.g., via Uu links and / or side links). A WTRU may send measurement reports to the network and / or other WTRUs.

[0080] A WTRU may perform data / PDU / PDU set processing / transfer and QoS processing associated with the PDU / PDU set. The data may include, depending on the circumstances, 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. A WTRU may send and / or receive data to and 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 on the network). During transmission / reception, a WTRU may split / merge data / PDUs in one or more QoS flows into one or more transport configurations.

[0081] A WTRU may process / transmit information related to connectivity with the network and / or other WTRUs. For example, a WTRU may send capability information to the network, which may include the ability to support one or more interfaces and / or the ability to cooperate and / or interact with other WTRUs / devices (e.g., via SL interfaces), whether or not they are co-located with the WTRU. A WTRU may also, or alternatively, receive configurations, including receiving RRC configurations from gNBs and / or NAS layer configurations from CNs. A WTRU may also, or alternatively, send and / or receive support data to and from the network associated with traffic, QoS, scheduling, and / or similar, in order to support UL / DL transmissions. A WTRU may also, or alternatively, send requests for radio resources and / or resource authorizations (e.g., dynamic authorizations, semi-static / configured authorizations).

[0082] If the WTRU is configured to use CBG-based transmission by receiving the higher-layer parameter 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 a WTRU is configured to send a code block group-based transmission by receiving the higher-layer parameter codeBlockGroupTransmission in PUSCH-ServingCellConfig for the initial transmission of a 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 TB's CBGs (e.g., all CBGs) should be transmitted, and the WTRU may include each of the TB's code block groups (e.g., all code block groups). If a WTRU is configured to send a code block group-based transmission by receiving the higher-layer parameter codeBlockGroupTransmission in PUSCH-ServingCellConfig for the retransmission of a TB, as indicated by the “New Data Indicator” field of the Scheduling DCI, the WTRU may include the CBGs (e.g., only 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, while "1" indicates that the corresponding CBG may be transmitted. The order of the bits in the CBGTI field 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 misinterpretation, only a portion of the CBG in the entire transport block may need to be retransmitted (e.g., only a portion of the CBG in the entire transport block may need to be retransmitted). XR traffic can be characterized by frequent arrival rates, large payload sizes, and sometimes bursty packets (and therefore large TBs), as well as quasi-periodicity. As a result, XR services may demand high capacity along with strict low-latency requirements. However, HARQ retransmission for large TB sizes for XR services can be expected to provide utilization and consequently impact system capacity. Therefore, CBG-based transmission for XR can significantly improve resource utilization and capacity. However, CBG-based transmission may add overhead to HARQ feedback (e.g., 1 bit added to DCI per CBG). Currently, the number of CBs and CBGs within a TB may be fixed, and when a WTRU and / or gNB segments the TB and determines the number of CBGs to use, application / PDU level awareness (information) may not be available to the WTRU and / or gNB. Each segment and PDU (e.g., all segments and PDUs) is given equal importance, which may limit the possibility of applying an efficient method to dynamically adapt the number of CBGs in the TB to XR traffic.

[0087] This specification may describe embodiments for maintaining overhead and / or improving efficiency in HARQ feedback as the number of CBGs increases. This specification may also describe embodiments for dynamically performing the grouping of CBs within a TB according to the importance priority of the PDU / PDU set level.

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

[0089] WTRU is an explicit or implicit piece of information received from an application / upper layer / network / Indication Using this, determine the size of the TB and the number of CBGs that can be used when transmitting in UL, and then send to the network (base station). Indication It can send information. For example, a WTRU can receive information periodically or aperiodically / dynamically in RRC signaling, MAC CE, DCI, NAS layer signaling, and / or application layer signaling.

[0090] Traffic information obtained from applications / higher layers / networks by each WTRU within a WTRU coordinating group may include, but are not limited to, identifiers / IDs, traffic types associated with per-application data flows, supported traffic attributes, and / or QoS requirements or expected QoS associated with the data. Identifiers / IDs may include identifiers / IDs associated with an application (e.g., application ID, service ID, session ID, application configuration ID). Identifiers / IDs may include group IDs (e.g., associated with a group of QoS flows, a group of forwarding configurations, or a group of devices / WTRUs). Identifiers / IDs may include IDs for individual QoS flows, mapping configurations, and / or forwarding configurations. Identifiers / IDs may include data type / message IDs (e.g., PDU set ID, PDU ID, ID associated with attitude information, FoV information, media / video frame information). Identifiers / IDs may include association IDs (e.g., IDs or sequence numbers indicating an association between one or more UL PDUs / PDU sets / flows and one or more DL PDUs / PDU sets / flows).

[0091] Traffic information obtained by each WTRU within a WTRU coordinating group from the application / upper layer / network may include traffic types associated with application-specific data flows. WTRUs may receive information about different data / QoS flows associated with the application, and 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 similar.

[0092] Traffic information obtained from applications / higher layers / networks by each WTRU within a WTRU coordinating group may include attributes of supported traffic. For example, a WTRU may receive information about 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 similar. Traffic characteristics may include one or more periodicity values ​​for the flow. A WTRU may receive information about the expected number of PDUs per PDU set in one or more flows per application. Information about the number of PDUs per PDU set may also include statistical / distribution information such as mean, minimum, maximum, and standard deviation values. Information related to PDU sets may include the size of the PDU set (e.g., total payload, number of PDUs in the PDU set), and the start / first and / or end / last PDUs of the PDU set. Indication , and / or associations / dependencies of PDUs within a PDU set Indication (For example, it may include the ID of the PDU set and its importance / priority value.)

[0093] Traffic information obtained by each WTRU within a WTRU coordinating group from the 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 similar. Information regarding QoS requirements may also, or alternatively, include statistical / distribution information such as mean, minimum, maximum, and standard deviation values. A WTRU may also, or alternatively, 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. Indication It can receive.

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

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

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

[0097] The information transmitted by a WTRU may include data / traffic types associated with application-specific data flows. A WTRU may transmit information about data types carried by different flows associated with applications within each WTRU. These different flows associated with applications within 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 transmitted by a WTRU may include traffic characteristics and / or parameters of data / traffic associated with data flows per application and / or per WTRU. A WTRU may transmit information about the characteristics of one or more flow traffic associated with an application, including whether the data within each flow is periodic, aperiodic, semi-persistent, quasi-periodic, and / or similar. A WTRU may transmit information about the expected number of PDUs per PDU set in one or more flows per application. Information about the number of PDUs per PDU set may also, or alternatively, include statistics such as mean, minimum, maximum, and standard deviation values. A WTRU may transmit QoS requirements (per PDU and / or per PDU set) for one or more flows associated with each application, including data rate, latency, reliability, absolute / relative priority values, and / or similar.

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

[0100] A WTRU may send the above information to the network under various conditions. For example, these conditions may include detecting one or more events. For example, a WTRU may send the above information to the network during connectivity / session establishment and / or (re)configuration. For example, a WTRU may send the above information to the network during RRC connection, PDU session, application session establishment and / or (re)configuration. A WTRU may send the above information when changing the RRC state in any of the WTRUs in a cooperative WTRU group.

[0101] WTRUs may send the above information when modifying / updating data flows on an application-by-application basis. For example, WTRUs may send the above information when adding a new flow and / or releasing an existing flow associated with an application.

[0102] WTRUs may send the above information when receiving higher-layer / application information. For example, WTRUs may indicate changes in supported data types, traffic characteristics, QoS requirements, and / or similar. Indication The above information can be sent when it is received (for example, from an application function hosted in a WTRU or on a network).

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

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

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

[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 QoS required for each PDU / PDU set. Specific QoS-related values ​​may include, for example, delay limits and / or error rate limits at the PDU / PDU set level. The WTRU may additionally or alternatively receive joint QoS requirements for PDUs across multi-flow traffic, such as a joint latency limit 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] Configuration information received by the WTRU may include thresholds related to the number of HARQ retransmissions. For example, the WTRU may receive a threshold related to the maximum number of HARQ retransmissions allowed.

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

[0109] Configuration information received by the WTRU may include thresholds related to event counters. For example, the WTRU may receive thresholds related to event counters, such as the number of initial UL / DL transmissions.

[0110] Configuration information received by the WTRU may include configured resource permissions. For example, a WTRU may receive configured resource permissions for uplink resources. A configured resource permission may be a set of predetermined resource blocks pre-allocated to the WTRU at a given periodicity for uplink transmissions on one or more physical uplink shared channels (PUSCHs).

[0111] Configuration information received by the WTRU may include a delay budget value. For example, the delay budget value may include a delay limit at the PDU / PDU set level. The delay budget value may set the maximum duration that a PDU / PDU set can spend over the radio while being processed for transmission by lower layers within the WTRU before arriving at the receiver (e.g., the receiver's MAC entity).

[0112] A WTRU (e.g., any WTRU within a cooperative WTRU group) may receive configuration information via, for example, 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 the 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 the 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. Then, the WTRU may receive from an application / upper layer an XR data burst consisting of one or more PDUs / PDU sets and a delay bound at the PDU / PDU set level of IndicationThe WTRU may receive (for example, in the PDU header). The WTRU may use the delay limits of the PDU / PDU set level indicated (for example, in the PDU / PDU set header) to determine whether to use a first and / or default number of CBGs (CBG1) or a second number of CBGs (CBG2) when sending TBs in the UL. For example, if the delay limit of the indicated PDU / PDU set level is greater than the configured threshold associated with the delay limit (for example, an XR data burst may be sent through multiple slots with multiple small TBs), the WTRU may use the first and / or default number of CBGs (CBG1) when sending TBs in the UL. A second number of CBGs (CBG2) may be sent in the received dynamic resource authorization. If the delay limit of the indicated PDU / PDU set level is less than the configured threshold associated with the delay limit (for example, an XR data burst needs to be sent through a single slot with a large TB), the WTRU may use a second number of CBGs for the WTRU's next UL transmission. Indication The WTRU may send to the network (NW) and / or receive a resource authorization from the gNB and use a second number of CBGs (CBG2) in the received resource authorization to send a TB in the UL. If all second number of CBGs (CBG2) are sent in the next UL transmission, the WTRU may cancel the received dynamic resource authorization. Indication It may send a CBG. In addition, at least one CBG that should be retransmitted is met with a negative response.

[0114] The WTRU states that a second PUSCH transmission opportunity corresponding to a configured resource authorization includes a retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set. Indication It can be sent. IndicationThis could be a Hybrid Automatic Retransmission Request (HARQ) process ID. For 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 retain the HARQ process ID assigned during the initial transmission and HARQ retransmission. The HARQ process ID is released and may be 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 a dynamic PUSCH resource authorization is not later in time (e.g., earlier in time) than a second PUSCH transmission opportunity corresponding to a configured resource authorization, the WTRU may retransmit at least one CBG corresponding to one or more PDUs in the first set of PDUs via the dynamic PUSCH resource authorization.

[0116] A WTRU can incrementally or subtractively adapt the number of CBGs to use when transmitting in a UL from a set of available CBGs (e.g., {CBG0>CBG1>CBG2}). The set of CBGs to which the WTRU is configured to adapt (e.g., {CBG0>CBG1>CBG2}) may be received directly from the network as configuration information, or the set may be determined by the WTRU based on the past and / or current behavior of UL traffic. For example, the WTRU may transmit support information about UL traffic to the network, including the expected number of PDUs per PDU set in one or more flows per application, by providing statistics such as mean, minimum, maximum, and standard deviation values. Based on the provided statistics, the network may determine the set of CBGs to which the WTRU can adapt, and / or the WTRU IndicationIt may send this information. Alternatively, the WTRU may determine the set of CBGs based on the application / upper layer information available to the WTRU. The WTRU may send supporting information to the network indicating the set of CBGs it prefers to use.

[0117] The WTRU may receive feedback indicating whether one or more CBGs corresponding to one or more PDUs were successfully received or not. The feedback may indicate a dynamic PUSCH resource authorization for retransmitting one or more CBGs corresponding to one or more PDUs that were not successfully received. For example, the WTRU may then use an initial number of CBGs (e.g., CBG0) to initiate the transmission of a first set of TBs in the UL, 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., determined by the counter) exceeds a threshold T1 for at least X% of the total number of CBGs in the TB without receiving a NACK, the WTRU may perform a series of actions. For example, the WTRU may use a number of CBGs (CBG1) for UL transmissions starting from the next TB. Indication The system can send a signal to the network and / or receive an acknowledgment from the network to use a CBG of the number CBG1. In addition, feedback may be received in the Downlink Control Information (DCI).

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

[0119] After receiving an acknowledgment to use CBG2, the WTRU may begin transmitting TB using the number of CBGs in CBG1, resulting in overhead reduction for CBG1-CBG2. On the other hand, if the WTRU receives a NACK for at least X% or Y% of CBGs before the counter exceeds the threshold T1 or T2, the WTRU may maintain the number of CBGs currently in use and / or reset the counter.

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

[0121] WTRU is a higher layer data burst consisting of one or more PDU sets, and / or delay limits per PDU set and per data burst. IndicationIt may start receiving (e.g., within the PDU header). The WTRU may determine the total number of transport blocks (TBs) required to transmit each PDU set (e.g., all PDU sets) based on the delay limit per PDU set and the delay limit per data burst. The WTRU may map the PDU / PDU set to the corresponding TB in ascending order of the delay limit per PDU set and the delay limit per data burst. For each of the TBs in multi-slot scheduling, the WTRU may determine the number of codeblock groups (CBGs) that the WTRU can use, the total number of TBs to be used, and / or the maximum number of CBGs across each of the TBs (e.g., all TBs) scheduled in multiple slots, based on the indicated delay limit at the PDU / PDU set level. The WTRU may send assistance information including the number of CBGs per TB that may be used during UL transmission of multiple PUSCHs to the network. The WTRU may receive a scheduling grant including an acknowledgement for using 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 the number of CBGs to use per TB when transmitting XR data in UL based on the QoS of the XR data (e.g., the delay limit for transmitting a PDU set). The WTRU may be configured to receive configuration information from the gNB 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 delay threshold. The WTRU may receive from a higher layer an XR data burst including one or more PDU sets and / or a data burst level delay limit of IndicationIt may receive (for example, in the PDU header). If the delay limit is greater than the delay threshold (for example, an XR data burst may be transmitted over multiple slots over multiple small TBs), the WTRU may use a default number of CBGs per TB (CBG1) when transmitting data in the UL. If the delay limit is less than the delay threshold (for example, an XR data burst needs to be transmitted over a large TB in a single slot), the WTRU may use a second number of CBGs for the next UL transmission. Indication The data can be sent to the network, a resource authorization can be received from the gNB, and / or the received resource authorization can be used to send a TB consisting of a second number of CBGs (CBG2) (carrying XR data).

[0123] In another exemplary embodiment, as further described herein, the WTRU may adjust the number of CBGs to use when transmitting in a 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 a UL (e.g., {N0>N1>N2}) and / or counter thresholds (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 an initial number (e.g., N0) of CBGs in a 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., determined by the counter) exceeds threshold C1 before receiving a NACK for at least X% of the CBGs, the WTRU may use N1 number of CBGs in the next UL transmission. Indication The WTRU may send a signal to the network and / or pause the counter and begin using N1 number of CBGs after receiving an acknowledgment from the NW. The HARQ feedback overhead may be reduced by N0-N1. If the number of initial UL transmissions exceeds the threshold C2 before receiving a NACK for at least X% of the CBGs while transmitting a TB with N1 number of CBGs, the WTRU may use N2 number of CBGs in the next UL transmission. Indication The WTRU may send a NACK to the network and / or reset the counter, and after receiving an acknowledgment from the NW, begin using N2 number of CBGs. The HARQ feedback overhead may be reduced by N0-N2 only. If the WTRU receives a NACK for at least X% of CBGs before the counter exceeds the threshold C1 or C2, the WTRU may maintain the number of CBGs currently in use and / or reset the counter.

[0124] In another exemplary embodiment, as described herein, the WTRU may be configured to map PDU sets to TBs in a multi-PUSCH (multi-slot) scheduling so that TBs are scheduled in UL in descending order of priority (e.g., QoS). 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 a multi-PUSCH scheduling. The WTRU may be configured to receive configuration information which may include the maximum number of CBGs in each TB (e.g., all TBs). The WTRU may receive from a higher layer data bursts consisting of one or more PDU sets, and / or delay limits per PDU set and per data burst. Indication The WTRU may receive (for example, within the PDU header). Based on the delay limit per PDU set and the delay limit per data burst, the WTRU may determine the number of TB / slots to transmit each PDU set (e.g., all PDU sets). Based on the maximum number of CBGs, the delay limit, and / or the determined number of TB / slots, the WTRU may determine the number of CBGs per TB (carrying each PDU set) in each TB (e.g., all TBs). The WTRU may determine the number of CBGs per TB. Indication The WTRU may send this to the gNB. The WTRU may receive resource authorizations for multiple TBs (e.g., multi-slot scheduling). The WTRU may use the received resource authorizations to send a TB (e.g., carrying a set of PDUs) containing a determined number of CBGs per TB.

[0125] Figures 2A to 2C illustrate three exemplary retransmissions of at least one CBG corresponding to a first PDU set after at least one CBG was not successfully transmitted during a first PUSCH transmission opportunity. PDU set 204 may contain multiple PDUs 202a to 202e. Each PDU 202a to 202e may contain multiple CBGs (e.g., four CBGs). CBGs may be acknowledging (ACK-ed) and / or not acknowledging (NACK-ed). For example, CBG3 in PDU 202b and CBG2 in PDU 202d are NACK-ed, while CBG1 to 4 in PDU 202c are ACK-ed. Similarly, PDU set 212 may contain multiple PDUs (e.g., five PDUs), and each PDU may contain multiple CBGs. Each PUSCH transmission opportunity (e.g., the first PUSCH transmission opportunity, the second PUSCH transmission opportunity, etc.) may appear 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 push 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 NACK-ed CBG3 in PDU202b and NACK-ed CBG2 in PDU202d. The WTRU may receive feedback when at least one CBG corresponding to the first PDU set 204 was not successfully transmitted. For example, 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 NACK-ed CBGs in the first PDU set 204, for example, CBG3 in PDU202b and CBG2 in PDU202d. Feedback may be received in Downlink Control Information (DCI) 206. Feedback received in DCI 206 may be received within DL slots between one or more DL slots.

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

[0128] In Figure 2B, bundle 210, which contains all NACK-ed CBGs in the first PDU set 204 (e.g., CBG3 in PDU 202b and CBG2 in PDU 202d), may not be successfully transmitted during the first PUSCH transmission opportunity. After receiving feedback in DCI 206, the WTRU may determine that the dynamic PUSCH resource authorization is temporally later 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 authorization. In addition, the WTRU may compare the amount of time remaining in the delay budget for the first PDU set 204 with a threshold. In one example, the threshold may refer to an absolute time given in 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. Bundle 210, which includes all NACK-ed CBGs in the first PDU set 204 (e.g., CBG3 in PDU202b and CBG2 in PDU202d), may be retransmitted in a second PUSCH transmission opportunity along with one or more CBGs in PDU set 212 (e.g., PDU1-4 in PDU set 212). One or more extra CBGs in PDU set 212 may not be transmitted in the second PUSCH transmission opportunity. WTRU may transmit one or more extra CBGs in PDU set 212 (e.g., PDU214) in a dynamic PUSCH resource authorization allocated for the retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set 204 in 216a.

[0129] In Figure 2C, bundle 210, which contains all NACK-ed CBGs in the first PDU set 204 (e.g., CBG3 in PDU 202b and CBG2 in PDU 202d), may not be successfully transmitted during the first PUSCH transmission opportunity. After receiving feedback in DCI 206, the WTRU may determine that the dynamic PUSCH resource authorization occurs 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 authorization. In addition, the WTRU may compare the amount of time remaining in the delay budget for the first PDU set 204 with a threshold. The WTRU may determine that the amount of time remaining in the delay budget for the first PDU set 204 is less than the threshold. Bundle 210, which includes 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 PDU set 212. If all CBGs corresponding to one or more PDUs in the second PDU set 212 are transmitted in the second PUSCH transmission opportunity corresponding to the configured resource authorization, the WTRU may cancel the dynamic PUSCH resource authorization in 216b. Indication The method described above may utilize configured resource permissions available for CBG retransmission before the expiration of the PDU set delay budget for the first PDU set 204. This may enable the WTRU to achieve the stringent high reliability and low latency requirements imposed on XR applications.

[0130] Figure 3 is a flowchart illustrating how the WTRU may perform actions to retransmit at least one CBG corresponding to a first set of PDUs after the CBG corresponding to the first set of PDUs was not successfully transmitted during the first PUSCH transmission opportunity. This method may include, for example, the three exemplary retransmissions discussed above in Figures 2A-2C. This method may include receiving configuration information at 302, which may include, for example, delay budget values ​​and / or configured resource permissions for one or more physical uplink shared channels (PUSCH resources). IndicationThis may include: In 304, the WTRU may use a first PUSCH transmission opportunity corresponding to a configured resource authorization to transmit multiple code block groups (CBGs) corresponding to one or more PDUs of a first set of protocol data units (PDUs). If at least one of the multiple CBGs corresponding to one or more PDUs of the first set of PDUs is not successfully received, the WTRU may receive feedback in 306. For example, the feedback may indicate a dynamic PUSCH resource authorization 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 set that should be retransmitted may be NACKed. In one example, the feedback may be received in downlink control information (DCI). In 308, the WTRU may determine whether the dynamic PUSCH resource authorization is later in time than a second PUSCH transmission opportunity. If the dynamic PUSCH resource authorization is not later in time than (e.g., earlier in time than) the second PUSCH transmission opportunity, the WTRU may, in 310, retransmit at least one CBG corresponding to one or more PDUs of the first PDU set via the dynamic PUSCH resource authorization, as shown in Figure 2A. If the dynamic PUSCH resource authorization is later in time than the second PUSCH transmission opportunity, the WTRU may, in 312, determine whether to retransmit at least one of several CBGs corresponding to one or more PDUs of the first PDU set using the dynamic PUSCH resource authorization or using the second PUSCH transmission opportunity corresponding to the configured resource authorization. For example, the determination may be based on the amount of time remaining in the delay budget for the first PDU set and a threshold.

[0131] For example, if the remaining delay budget is less than a threshold at 314, at 318, at least one CBG may be retransmitted using a second PUSCH transmission opportunity corresponding to the configured resource authorization. One or more CBGs corresponding to one or more PDUs in a second PDU set may be transmitted in a second PUSCH transmission opportunity corresponding to the configured resource authorization. For example, if all CBGs corresponding to one or more PDUs in a second PDU set are transmitted in a second PUSCH transmission opportunity corresponding to the configured resource authorization, then, as shown in Figure 2C, the WTRU at 320 to cancel the dynamic PUSCH resource authorization Indication It can be sent.

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

[0133] The WTRU further states that a second PUSCH transmission opportunity corresponding to a configured resource authorization includes a retransmission of at least one CBG corresponding to one or more PDUs in the first PDU set. Indication It can be sent. Indication This could be a Hybrid Automatic Retransmission Request (HARQ) process ID. For example, the configuration information may also include thresholds associated with one or more HARQ transmissions. The WTRU may retransmit at least one CBG corresponding to one or more PDUs in the first set of PDUs.

[0134] While the features and elements are provided above in specific combinations, those skilled in the art will understand that each feature or element can be used individually or in any combination with other features and elements. This disclosure should not be limited in terms of the specific embodiments described herein, which are intended to be illustrative of various aspects. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope of the invention. No element, operation, or command used in the description of this application should be construed as important or essential to the invention unless expressly presented as such. In addition to those enumerated herein, functionally equivalent methods, apparatus, and articles within the scope of this disclosure 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. This disclosure should be limited only by the terms of such claims, along with the full scope of the equivalents to which the appended claims are entitled. It should be understood that this disclosure is not limited to any particular method or system.

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

[0136] It should also be understood that the terms used herein are for the purpose of describing only specific embodiments and are not intended to limit them. Where used herein, the terms “video” or “image” may mean any of a snapshot, a single image, and / or multiple images displayed over time, or any appropriate combination thereof. As another example, where referred herein, the terms “user equipment” and its abbreviation “UE,” the term “remote,” and / or the terms “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 (e.g., tetherable) device configured to have some or all of the structure and functions of a WTRU, (iii) a wireless-enabled and / or wired device configured to have fewer structure and functions than all of the structure and functions of a WTRU, or (iv) of the same kind. Details of exemplary WTRUs that may represent any WTRU described herein are provided herein with respect to Figures 1A to 1D. As another example, the various embodiments described above and below in this specification are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be used, and that some or all of the disclosure and the various disclosed embodiments may be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adaptive reality experience.

[0137] In addition, the methods provided herein may be implemented in computer programs, software, or firmware embedded in a computer-readable medium to be executed by a computer or processor. Examples of computer-readable mediums include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media 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 associated with the 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] Modifications of the methods, apparatus, manufactured articles, and systems provided herein are possible without departing from the scope of the invention. Considering the various embodiments to which it 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, embodiments provided herein include a handheld device which may include, or be utilized with, any suitable voltage source, such as a battery, that provides any suitable voltage.

[0139] Furthermore, embodiments provided herein refer to other devices, including processing platforms, computing systems, controllers, and processors. These devices may include at least one central processing unit ("Central Processing Unit, CPU") and memory. According to the convention of those skilled in the art in the field of computer programming, references to operations and symbolic representations of arithmetic or instructions may be performed by various CPUs and memories. Such operations and arithmetic or instructions may be referred to as "executed," "executed by the computer," or "executed by the CPU."

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

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

[0142] In illustrative embodiments, any of the actions, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor in a mobile unit, a network element, and / or any other computing device.

[0143] In the detailed description above, various embodiments of devices and / or processes have been described through the use of block diagrams, flowcharts, and / or examples. Those skilled in the art will understand that, insofar as such block diagrams, flowcharts, and / or examples include one or more functions and / or operations, each function and / or operation in such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof. In exemplary embodiments, some parts of the subject matter described herein may be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integrated formats. Those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, in whole or in part, 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 substantially any combination thereof, and that designing circuits and / or writing software and / or firmware code is well within the scope of the art of those skilled in the art in light of this disclosure. Those skilled in the art will understand that mechanisms of the subject matter described herein can be distributed as various forms of program products, and that illustrative embodiments of the subject matter described herein are applicable regardless of the particular type of signal-carrying medium used to actually carry out the distribution. Examples of signal transmission media include, but are not limited to, recordable media such as floppy disks, hard disk drives, CDs, DVDs, digital tapes, and computer memory, as well as transmitting media such as digital communication media and / or analog communication media (e.g., optical fiber cables, waveguides, wired communication links, wireless communication 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 to integrate such described devices and / or processes into a data processing system using engineering techniques. 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, video display devices, memory such as volatile and non-volatile memory, processors such as microprocessors and digital signal processors, computing entities such as operating systems, drivers, graphical user interfaces, 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 using any suitable commercially available components, as is 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 other different components. Such depicted architectures are merely examples, and it should be understood that in practice, many other architectures can be implemented to achieve the same function. Conceptually, any arrangement of components to achieve the same function is effectively “associated” in such a way that the desired function can be achieved. Thus, any two components in this specification combined to achieve a particular function can be considered “associated” with each other, regardless of the architecture or intervening components, in such a way that the desired function can be achieved. Similarly, any two components thus associated can be considered “operably connected” or “operably coupled” with each other to achieve the desired function, and any two components that can be associated in this way can also be considered “operably coupled” with each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, physically matable and / or physically interacting components, and / or wirelessly interactable and / or wirelessly interacting components, and / or logically interacting and / or logically interactable components.

[0146] With regard to the use of substantially any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or singular to plural as appropriate to the context and / or use. Various singular / plural rearrangements may be explicitly described herein for clarity.

[0147] In general, it will be understood by those skilled in the art that the terms used herein, and in particular in the appended claims (e.g., the main body of the appended claims), are generally intended to be “open” terms (for example, the term “contains” should be interpreted as “contains, but not limited to,” the term “has” should be interpreted as “has at least,” and the term “includes” should be interpreted as “contains, but not limited to,” etc.). Where a specific number of introduced claims is intended, such intention is explicitly stated in the claim, and where there is no such statement, such intention is not present, it will be understood by those skilled in the art. For example, where only one item is intended, the term “single” or similar wording may be used. To aid understanding, the following appended claims and / or descriptions herein may include the use of the introductory phrases “at least one” and “one or more” to introduce the claims. However, the use of such phrases should not be interpreted as suggesting that the introduction of a claim description with the indefinite article "a" or "an" implies that any particular claim containing such an introduced claim description is limited to embodiments containing only one such description, even if the same claim contains an introduction phrase such as "one or more" or "at least one)" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of definite articles used to introduce a claim description. In addition, even if a specific number of introduced claim descriptions are explicitly described, a person skilled in the art will recognize that such descriptions should be interpreted as meaning at least the number described (for example, the simple description "two descriptions" without other modifiers means at least two descriptions or two or more descriptions).Furthermore, when similar notations are used, such structures are generally intended to convey a meaning that a person skilled in the art would understand (for example, "a system having at least one of A, B, and C" includes, but is not limited to, A only, B only, C only, A and B together, A and C together, B and C together, and / or a system having A, B, and C together, etc.). When similar notations are used, such structures are generally intended to convey a meaning that a person skilled in the art would understand (for example, "a system having at least one of A, B, or C" includes, but is not limited to, A only, B only, C only, A and B together, A and C together, B and C together, and / or a system having A, B, and C together, etc.). It will be further understood by those skilled in the art that any actual disjunctive words and / or phrases presenting two or more alternative terms in the specification, claims, or drawings should be understood as construed to include the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B.” Furthermore, 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 number of,” and / or “any number of,” items and / or categories of items, individually or in combination with other items and / or categories of other items. Furthermore, as used herein, the term “set” is intended to include any number of items, including zero. In addition, 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 “plural.”

[0148] In addition, if any feature or aspect of the present disclosure is described in terms of the Markush group, a person skilled in the art will recognize that the present disclosure is also described in terms of any individual element or subgroup of elements of the Markush group.

[0149] For all purposes, including providing written explanations, as can be understood by those skilled in the art, all scopes disclosed herein also encompass any possible sub-scopes and combinations of sub-scopes. Any listed scope can be readily recognized as fully explaining and enabling that the same scope can be decomposed into at least equal 1 / 2, 1 / 3, 1 / 4, 1 / 5, 1 / 10, etc. In non-limiting embodiments, each scope considered herein can be readily decomposed into a lower third, a middle third, an upper third, etc. Also, as can be understood by those skilled in the art, all phrases such as “up to,” “at least,” “greater than,” and “less than” include the number described and refer to a scope that can be later decomposed into sub-scopes, as considered above. Finally, as can be understood by those skilled in the art, a scope includes 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