Method and system for reliable and resource efficient transmission of augmented reality (XR) traffic

Abstract

Determination and / or indication of one or more transmission parameters for transmitting one or more protocol data units (PDUs) in a set of PDUs is described. A wireless transmit / receive unit (WTRU) receives a configuration set associated with one or more PDU set profiles. The WTRU receives one or more PDUs of a set of PDUs and information associated with a PDU set profile. If one or more conditions associated with the PDU set profile are satisfied, the WTRU determines a number of unused transmission opportunities available to repeat the one or more PDUs, thereby selecting a repetition pattern that allows at least a subset of the PDUs of the PDU set to be repeated. The WTRU sends an indication associated with the selected repetition pattern to the network. The WTRU transmits one or more PDUs of the set of PDUs based on the selected repetition pattern.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 531196, filed August 7, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] Extended Reality (XR) is a general term for different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and combinations of other such realities. In XR applications, XR data services can be generated non-periodically and / or in multiple data bursts. Different data bursts may have different Quality of Service (QoS) requirements. Furthermore, different data units within a data burst may also have different QoS requirements. Conventional data transmission technologies cannot meet the QoS requirements of XR data services, leading to inefficient use of resources such as wireless media and hardware. Moreover, conventional data transmission technologies result in latency and waiting times, which degrade the user experience of XR applications. Therefore, there is a need for an efficient data transmission and / or reception technology that can meet the QoS requirements of XR data services and effectively utilize resources. Summary of the Invention

[0003] This describes determining and indicating one or more transmission parameters for transmitting one or more Protocol Data Units (PDUs) in a PDU set based on a PDU set profile. This includes a Wireless Transmit / Receive Unit (WTRU) receiving a set of configurations from the network, including but not limited to a multi-PUSCH configuration, a set of repetition patterns that the WTRU can use, a set of Logical Channels (LCHs) associated with one or more PDU set profiles, correlation information between the PDU set error rate (PSER) and the maximum number of repetitions, and / or one or more thresholds associated with the PDU set profile. The WTRU receives one or more PDUs from one or more higher layers, along with information about the PDU set profile (e.g., PDU set size, PSER, etc.), and determines the mapping of one or more PDUs in the PDU set to one or more LCHs based on the PDU set profile. If one or more conditions associated with the PDU set profile are met (e.g., whether the PDU set size is greater than a first threshold indicating the PDU set size, and / or whether the PSER is greater than a second threshold indicating the PSER, etc.), the WTRU determines, based on the PDU set profile (e.g., payload size, PSER), the number of unused transmission opportunities (UTOs) (i.e., one or more unused PUSCHs) available to repeat one or more PDUs and / or one or more transport blocks (TBs), and selects a repetition mode that allows at least a subset of the PDUs in the PDU set to be repeated, based on the priority of the repetition mode, the number of PSERs and / or UTOs. The WTRU sends an indication (e.g., in uplink control information (UCI)) to the network regarding the selected repetition mode (e.g., the index and / or identifier (ID) of the selected repetition mode) during one or more CG PUSCH transmission opportunities (TOs). Based on the selected repetition mode, the WTRU uses one or more CG PUSCHs to transmit one or more PDUs from the PDU set.

[0004] In one embodiment, a method performed by a WTRU is provided. The method includes receiving configuration information comprising a plurality of CG PUSCH times and sending an indication of one or more transmission parameters associated with one or more PDUs of at least one PDU set. The method further includes determining one or more transmission parameters based on the configuration information and attributes of the plurality of PDU sets associated with the at least one PDU set. The method further includes transmitting one or more PDUs in one or more CG PUSCH times among the plurality of CG PUSCH times based on the one or more transmission parameters.

[0005] In one embodiment, a WTRU including a memory, a transceiver, and a processor is provided. The memory is configured to store one or more PDUs of at least one PDU set. The transceiver is configured to receive configuration information including multiple CG PUSCH times. The transceiver is configured to transmit indications of one or more transmission parameters associated with the one or more PDUs. The processor is configured to determine one or more transmission parameters based on the configuration information and multiple PDU set attributes associated with at least one PDU set. The transceiver is also configured to transmit one or more PDUs in one or more CG PUSCH times of the multiple CG PUSCH times based on the one or more transmission parameters.

[0006] In one embodiment, one or more transmission parameters include at least one repeating pattern.

[0007] In this embodiment, the configuration information also includes one or more of the following: (1) a threshold PDU set error rate (PSER), (2) a threshold PDU set size, (3) a set of repeating patterns, or (4) a maximum number of repeats. Each repeating pattern in the set of repeating patterns is associated with a priority.

[0008] In an embodiment, the WTRU determines one or more used CG PUSCH opportunities and one or more unused CG PUSCH opportunities from a plurality of CG PUSCH opportunities.

[0009] In this embodiment, WTRU selects a repetition pattern from the set of repetition patterns based on multiple PDU set attributes, the number of one or more unused CG PUSCH opportunities, and at least one threshold. WTRU determines the number of repetitions based on the maximum number of repetitions and multiple PDU set attributes.

[0010] In an embodiment, one or more transmission parameters indicate at least one of the following: the selected repetition pattern or the determined number of repetitions.

[0011] In an embodiment, the WTRU retransmits one or more PDUs during one or more unused CG PUSCH opportunities, based on at least one of the selected repetition pattern or the determined number of repetitions.

[0012] In an embodiment, the WTRU determines the PDU set size associated with at least one PDU set. The WTRU determines one or more transmission parameters based on a comparison between a threshold PDU set size and the PDU set size.

[0013] In an embodiment, the WTRU determines a PSER associated with at least one set of PDUs. The WTRU determines one or more transmission parameters based on a comparison between a threshold PSER and the determined PSER.

[0014] In this embodiment, the instruction is to transmit in uplink control information (UCI). Attached Figure Description

[0015] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, in which the same reference numerals denote the same elements.

[0016] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented.

[0017] Figure 1B This illustrates that, according to one embodiment, it is possible to Figure 1A The system diagram shown is of an example wireless transmit / receive unit (WTRU) used in the communication system.

[0018] Figure 1C This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system shown.

[0019] Figure 1D This illustrates that, according to an embodiment, it is possible to Figure 1A The system diagram shows another example RAN and another example core network (CN) used in the communication system shown.

[0020] Figure 2 This is a diagram illustrating an example of an instruction transmitted from a WTRU to a network according to an embodiment.

[0021] Figure 3 This is a flowchart illustrating an example method performed by a WTRU to send an instruction to the network according to an embodiment. Detailed Implementation

[0022] A Wireless Transmit / Receive Unit (WTRU) can correspond to any extended reality (XR) device and / or node that can have various form factors. A typical WTRU (e.g., an XR WTRU) can include, but is not limited to, head-mounted displays (HMDs), optical see-through glasses or camera-through HMDs for augmented reality (AR) and / or mixed reality (MR), mobile devices with position tracking units and cameras, wearable devices, haptic gloves, haptic body suits, haptic shoes, etc. Furthermore, several different types of XR WTRUs can be envisioned based on various XR device functions, such as XR device functions associated with displays, cameras, sensors, sensor processing, wireless connectivity, XR and / or media processing, and power supply, which will be provided by one or more devices, such as, but not limited to, wearable devices, actuators, controllers, and / or accessories. One or more devices, nodes, and / or WTRUs can be grouped into collaborative XR groups to support any of XR applications, experiences, and / or services.

[0023] In XR services and / or applications, XR traffic may include data associated with an Application Data Unit (ADU), a set of Protocol Data Units (PDUs), or a data burst. In the example, one or more PDUs in the PDU set may be associated with different segments and / or components of a video frame or video slice. A data burst may include one or more PDU sets that may be transmitted and / or received within a time window. For example, the number of PDUs in the PDU set or the data burst transmitted in the uplink (UL) and / or received in the downlink (DL) may depend on the type of media frame (e.g., 3D video frames, audio frames, etc.).

[0024] In typical XR applications, the WTRU transmits XR services comprising one or more PDUs and / or sets of one or more PDUs in UL communications (e.g., gestures, video data) and / or receives XR services in DL communications (e.g., video, audio, haptic). XR services can be transmitted and / or received periodically or non-periodically in one or more data streams (e.g., Quality of Service (QoS) streams). During UL transmission, XR services may arrive at different times from the application layer at the WTRU and / or from different devices, terminals, or WTRUs (e.g., via sidelinks (SL)). XR services can be characterized by various attributes, such as, but not limited to, variable payload size per PDU set, variable number of PDUs per PDU set, variable level importance per PDU and / or per PDU set, and / or different levels of interdependence between one or more PDUs and / or sets of one or more PDUs. XR services received by the WTRU (e.g., one or more PDUs and / or sets of one or more PDUs) may experience varying latency, jitter, data rates, and / or loss rates. To ensure QoS and a high user experience (for example, Quality of Experience (QoE)), it is important that data transmission and / or reception, as well as other related functions (e.g., prioritization, multiplexing, or scheduling), are performed in a timely manner with XR awareness (e.g., being aware of the attributes of one or more PDU sets).

[0025] In many embodiments, one or more transmission parameters are provided for determining and / or indicating one or more PDUs in a PDU set based on the PDU set profile. In many examples, the WTRU receives a set of configurations from the network, including but not limited to a Multi-Physical Uplink Shared Channel (PUSCH) configuration, a set of repetition patterns that the WTRU can use, a set of logical channels (LCHs) associated with one or more PDU set profiles, association information between the PDU set error rate (PSER) and / or the maximum number of repetitions, and / or one or more thresholds associated with the PDU set profile. The WTRU receives one or more PDUs of the PDU set and information about the PDU set profile (e.g., PDU set size, PDU set error rate (PSER), etc.) from one or more higher layers, and determines a mapping of one or more PDUs of the PDU set to one or more LCHs based on the PDU set profile. If any conditions associated with the PDU set profile are met (e.g., whether the size of the PDU set is greater than a first threshold indicating the PDU set size, and / or whether the PSER is greater than a second threshold indicating the PSER), the WTRU determines, based on the PDU set profile (e.g., payload size, PSER), the number of unused transmission opportunities (UTOs) (i.e., unused PUSCHs) available to repeat one or more PDUs and / or transport blocks (TBs), and selects a repetition mode that allows at least a subset of the PDUs in the PDU set to be repeated, based on the priority of the repetition mode, the number of PSERs and / or UTOs. The WTRU sends an indication to the network (e.g., in uplink control information (UCI)) on the selected repetition mode (e.g., the index / ID of the mode) during one or more configured permitted (CG) PUSCH transmission opportunities (TOs). Based on the selected repetition mode, the WTRU uses one or more CGPUSCHs to transmit one or more PDUs in the PDU set.

[0026] Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access this content by sharing 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 Discrete Fourier Spread Spectrum OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

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

[0028] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home node Bs, home eNodeBs, next-generation NodeBs (e.g., gNode Bs (gNBs)), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each described as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base station and / or network elements.

[0029] Base station 114a may be part of RAN 104, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may also be divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in an embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In an embodiment, 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.

[0030] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

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

[0032] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0033] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish air interface 116 using new radio (NR).

[0034] In this embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0035] In other embodiments, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0036] For example, Figure 1ABase station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c and 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, it is not required that base station 114b access Internet 110 via CN 106.

[0037] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although in Figure 1A As not shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which may utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0038] CN 106 can also serve as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0040] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

[0041] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding / decoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, and transceiver 120 can be coupled to transmitting / receiving element 122. Although Figure 1B While processor 118 and transceiver 120 are described as separate components, it should be understood that processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

[0043] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in an embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0044] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 can have multi-mode capability. Therefore, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

[0046] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering 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.

[0047] 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) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116, and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0048] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, humidity sensors, etc.

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

[0050] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0051] RAN 104 may include eNode-Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

[0053] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] The MME 162 can connect to each eNode-B 162a, 162b, 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0055] The SGW 164 can connect to each eNode B 160a, 160b, or 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, or 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover; triggering paging when DL data is available for WTRUs 102a, 102b, or 102c; and managing and storing the context of WTRUs 102a, 102b, or 102c.

[0056] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks such as Internet 110, to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0057] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network such as PSTN 108 to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0058] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is conceivable that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0060] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP can access or peer into a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the AP via it. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be sent via the AP, where the source STA can send traffic to the AP, and the AP can deliver traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peering traffic. Peering traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the "self-organizing" communication mode in this document.

[0061] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0062] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels.

[0063] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration described above can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0064] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV Blank (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS. According to a representative embodiment, 802.11ah may support metering-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain very long battery life).

[0065] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by one of the STAs operating in the BSS that supports the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (supporting only the 1MHz operating mode) is sending data to the AP, all available bands can be considered busy, even if most available bands remain idle.

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

[0067] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0068] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In the embodiments, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0069] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0070] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, while also communicating / connecting with another RAN such as eNode-Bs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0071] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing user plane data to User Plane Functions (UPF) 184a and 184b, and routing control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0073] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases (e.g., services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc.). AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi).

[0074] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure the routing of services through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0075] UPF 184a and 184b can be connected to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. This interface can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0076] CN 106 can facilitate communication with other networks. For example, CN 106 may include, or be able to communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) serving as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In an embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via UPFs 184a and 184b through the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0077] Given Figure 1A-1D as well as Figure 1A-1D As described in the corresponding descriptions herein, one or all of the functions described for one or more of the WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN 185a-b, and / or any other device described herein (one or more) 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.

[0078] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing and / or performing tests using over-the-air wireless communication.

[0079] One or more emulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios outside of deployment (e.g., testing) wired and / or wireless communication networks and / or test laboratories to implement testing of one or more components. One or more emulation devices may be test equipment. Emulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0080] The WTRU supporting XR experiences, i.e., XR services and / or applications, can receive one or more data units (e.g., one or more PDUs, PDU sets, data bursts and / or bitstreams, etc.) from one or more higher layers or from different devices (e.g., but not limited to AR glasses and haptic gloves) (e.g., via side links (SL)). Data units that may have variable payload sizes, different periodicities, jitter and different interdependencies can be further processed and transmitted by the WTRU in the UL.

[0081] In a typical scenario, the WTRU transmits XR services comprising one or more PDUs and / or sets of one or more PDUs in the UL (e.g., gestures, and / or video data), and / or receives XR services in the DL (e.g., video, audio, and / or haptic data). XR services can be transmitted and / or received periodically or non-periodically in one or more data streams (e.g., QoS streams). During UL transmission, XR services may arrive at different times from the application layer at the WTRU and / or from different devices, terminals, or the WTRU (e.g., via SL). XR services can be characterized by one or more service attributes, such as, but not limited to, variable payload size for each PDU set, variable number of PDUs for each PDU set, variable priority and / or importance value for each PDU, variable level priority and / or importance value for each PDU set, and / or different levels of interdependence between one or more PDUs and / or sets of one or more PDUs. XR services (e.g., one or more PDUs and / or sets of one or more PDUs) received by the WTRU from one or more higher-layer or other devices and / or terminals may also experience varying latency, jitter, data rates, and / or loss rates. To ensure that one or more QoS requirements and / or conditions (e.g., PDU set delay limit (PSDB), PDU set error rate (PSER), and / or PDU set comprehensive processing indication (PSIHI), the WTRU can prioritize, multiplex, schedule, and / or allocate resources in a timely manner based on one or more PDU set attributes. To ensure Quality of Experience (QoE), one or more PDUs within or within different PDU sets generated at the transmitting side of the XR application are expected to be delivered to the receiving side of the application within the QoS requirements and / or conditions (e.g., PSDB, PSER, and / or PSIHI). In the example, PDU set attributes may include one or more XR service attributes, such as, but not limited to, the payload size of each PDU set, the number of PDUs in each PDU set, the priority and / or importance values ​​of the PDUs in the PDU set, the priority and / or importance values ​​of the PDU set, and / or the interdependencies between one or more PDUs and / or one or more PDU sets. In the example, PDU set attributes may include one or more of PSDB, PSER, and / or PSIHI. In the example, PDU set attributes may include one or more QoS parameters and / or one or more QoE parameters.

[0082] In XR services, different PDUs and / or PDU sets can contribute to different user experiences (e.g., QoE). Thus, from an application layer perspective, different PDUs and / or PDU sets can also be associated with different importance and / or priority values. This is because one or more PDU sets transmitted sequentially in the time domain can depend on each other in different ways. In other words, unlike existing QoS frameworks where all PDUs and / or all PDU sets in a data stream and / or QoS stream are provided with the same forwarding treatment by assuming equal importance and / or priority, during scheduling and transmission in UL and / or DL, one or more PDUs and / or one or more PDU sets in an XR service data burst may need to be differentiated and processed differently based on different QoS requirements and / or conditions at one or more lower layers, regardless of whether one or more PDUs and / or one or more PDU sets are in one or more QoS streams.

[0083] Interdependencies between one or more PDUs and / or sets of PDUs in a single QoS stream and / or multiple QoS streams can lead to varying challenges in meeting QoS conditions and / or requirements at the PDU set level during transmission in UL and / or DL. For example, when one or more PDUs from different PDU sets can be multiplexed into the same radio bearer and / or the same logical channel, and subsequently mapped to different times, slots, and / or periods in one or more resources (e.g., configured allowances (CGs)), tracking the correlations between one or more PDUs to meet QoS conditions and / or requirements at the level of one or more PDU sets can be challenging, especially when delays and / or jitter may be present during reception and / or processing. Examples such as the following may be helpful: Considering service characteristics used to meet PDU set-level QoS conditions and / or requirements during UL transmission (e.g., latency and / or jitter during reception of one or more PDUs and / or one or more PDU sets on the SL or from one or more higher layers, variable payload size, and / or variable priority and / or importance values), ensure that one or more PDUs and / or one or more PDU sets are correctly mapped and / or multiplexed to one or more configured resources (e.g., CGs) in the time and / or frequency domains, such as one or more PUSCH timings (e.g., PUSCH) or resource block groups (RBGs).

[0084] The XR enhancements include support for multiple PUSCH TOs within one or more time slots to accommodate the transmission of one or more PDU sets with large payload sizes. Furthermore, multiple PUSCH TOs per time slot can be statically configured across one or more CG cycles, or can be provided to the WTRU using a DCI, such as, but not limited to, Default Grant (DG). In multiple CG PUSCH TOs, the WTRU can be configured with one or more parameters, such as a RepK value, indicating the number of TOs within the CG cycle, where the RepK value indicates the number of repetitions of a single PUSCH timing. The multiple PUSCH CG configuration, TOs, and one or more frequency domain resources (e.g., modulation and coding scheme (MCS) indices) in addition to one or more transmission parameters can be semi-statically configured over multiple cycles of the CG. Additionally, each PUSCH timing in a time slot can be associated with a Hybrid Automatic Repeat Request (HARQ) procedure identifier (ID).

[0085] In current systems, one or more transmission parameters (e.g., link adaptation) and one or more retransmission schemes are configured based on achievable target error rates (e.g., block error rate (BLER) and / or packet error rate (PER)) for packets or TBs to ensure reliable packet reception within the packet delay budget (PDB). This approach treats each TB independently and with equal importance, ensuring that all QoS requirements and / or conditions, such as reliability and / or latency requirements, are met for each TB. In multi-PUSCH transmissions of TBs comprising one or more PDUs from one or more PDU sets, ensuring that one or more QoS requirements and / or conditions for each PUSCH transmission are met may not guarantee that QoS requirements at the PDU set level (e.g., data rate, latency, error rate (e.g., BLER and / or PER), and / or reliability, etc.) are met.

[0086] In a multi-PUSCH transmission of one or more PDU sets, the retransmission of one or more TBs is based on an indication sent by the network (NW) to the WTRU. This indication includes a new resource grant (e.g., DG and / or CG) allocated for the retransmission of one or more TBs. The allocated resource grant is associated with one or more HARQ procedure IDs, which are associated with the timing of the one or more TBs and / or one or more PUSCHs to be retransmitted. The network may send indications for retransmitting TBs (e.g., allocating DG and / or CG) multiple times until the TB is successfully received.

[0087] Even if the network ensures that all PDUs in a multi-PUSCH transmission of a PDU set are successfully received within the PDB, the network may not be able to guarantee that all PDU set-level QoS requirements and / or conditions (e.g., PSER and / or PSDB) are met. Because the network may not have knowledge and / or information related to the PDU set profile (e.g., PDU set-level QoS, payload size, etc.) for UL transmissions, the network may not allocate resources to allow retransmission of one or more PDUs within the PSDB.

[0088] In the embodiments, the system and method aim to provide efficient resource utilization and high reliability in transmitting XR services of multiple TB. Throughout the embodiments described herein, for example, the network may include any of the following: base stations (e.g., gNBs, Transmit and Receive Points (TRPs), RAN nodes, and / or access nodes, etc.), core network functions (e.g., Access and Mobility Management Functions (AMF), Session Management Functions (SMF), Policy Control Functions (PCF), and / or Network Exposure Functions (NEF), etc.), and / or application functions (e.g., edge server functions and / or remote server functions, etc.). Throughout the embodiments herein, one or more flows may correspond to any of the following: one or more QoS flows and / or one or more data flows (e.g., flows of data comprising one or more PDUs, one or more sets of PDUs, and / or one or more data bursts, for example, they may be interdependent with each other and / or associated with one or more QoS requirements and / or conditions, such as, but not limited to, latency, data rate, reliability, and / or, round-trip time (RTT) latency, etc.). Different flows that may originate from a common application and / or a common experience source and / or are intended to reach a common destination device and / or destination WTRU or a set of associated devices and / or a set of WTRUs may be referred to as associated flows or related flows. Throughout the embodiments herein, a data unit may refer to any of the following: one or more frames (e.g., media frames, video frames and / or audio frames and / or slices and / or segments associated with frames), one or more PDUs, one or more sets of PDUs, one or more data bursts, a set of frames, a set of PDUs, a set of PDUs, a set of data bursts and / or one or more bitstreams, etc. Data units that may be transmitted and / or received by WTRUs sequentially (e.g., one after another) or in parallel (e.g., through different channels, links and / or resources, etc.) may be interdependent or may not be interdependent.

[0089] Throughout the embodiments described herein, forwarding configuration may be associated with any one or more of the following: radio bearers (e.g., data radio bearers (DRB), signaling radio bearers (SRB), transport radio bearers and / or PDU collection bearers, etc.), one or more logical channels (LCH), one or more logical channel groups (LCG), one or more configuration parameters (e.g., configuration information) in one or more individual layers within the AS protocol stack (e.g., Serving Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC), Physical Layer (PHY) and / or other protocol layers, etc.), one or more parameters associated with Logical Channel Prioritization (LCP) (e.g., one or more priority and / or importance values ​​and / or levels, Prioritized Bit Rate (PBR) and / or Bucket Size Duration (BSD), etc.), one or more bandwidth portions (BWP), one or more carriers, one or more radio links and / or interfaces (e.g., Uu links and / or SL, etc.), and / or one or more radio resources (e.g., one or more frequency, time and / or spatial resources, such as but not limited to symbols, time slots, subcarriers, resource elements and / or beams). For example, a radio resource may be associated with one or more CGs, dynamic licenses, one or more default licenses, any other resource licenses, and / or unlicensed resources, but is not limited to these.

[0090] Throughout the embodiments herein, one or more PDU sets and corresponding one or more characteristics and / or properties can refer to any one or more PDU sets, such as including, but not limited to, one or more data units (e.g., one or more PDUs) associated with media units or video frames and / or slices. PDU sets and / or data units within data bursts can be interdependent at the application layer and / or at one or more lower layers (e.g., the AS layer). For example, the attributes and / or properties of a PDU set can differ from each other in aspects such as the number of PDUs in the PDU set, payload size, correlation within the PDU set, importance and / or priority values ​​and / or levels of data units, transmission status (e.g., the percentage of PDUs that have successfully transmitted and / or received one or more data units), effective data rate and / or effective reliability associated with transmission, etc. In the example, attributes and / or properties associated with one or more PDU sets may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, and / or PHY sublayers and / or layers, etc.) and may be used to support one or more additional actions and / or functions (e.g., prioritization, mapping to LCH, multiplexing to one or more TBs, and / or scheduling, etc.). This can be based on one or more of the following: tags in one or more data units (e.g., tags in one or more frames, one or more slices and / or subframes, one or more PDUs and / or one or more PDU sets, etc.), indication of reception, mapping of one or more data units, tracking of attributes and / or parameters, and one or more restrictions associated with the corresponding layer and / or sublayer. For example, tags may include, but are not limited to, one or more sequence numbers, IDs, indexes, timestamps, and / or time offset values ​​(e.g., relative to a reference time) in the header of one or more data units. Tags may be created by one or more higher layers, any preceding sublayers and / or layers, another device, and / or another WTRU. Receive, for example, instructions from control PDUs (e.g., application, higher and / or NAS layer instructions, PDCP control PDUs, RLC control PDUs, MAC control elements (CEs), DCIs and / or UCIs, etc.). For example, such instructions may be received by the WTRU from a higher and / or previous layer, from another device and / or WTRU (e.g., via SL), and / or from the network.

[0091] One or more data units can be mapped from a higher layer to a configuration associated with one or more lower layers. For example, when one or more PDUs are mapped to one or more radio bearers, one or more LCHs, one or more TBs, and / or one or more HARQ procedures (which can be configured to provide similar forwarding processing), the WTRU can have visibility of one or more higher-layer attributes at one or more lower layers.

[0092] Track one or more attributes of one or more PDUs at any buffer associated with one or more sublayers, one or more radio bearers, one or more LCHs and / or one or more HARQ procedures. For example, the WTRU may track one or more attributes associated with one or more PDU sets based on at least any of the following: the time elapsed since the first PDU of the PDU set was received, the remaining time for one or more PDUs in the PDU set to satisfy the PSDB, the jitter between arrivals of one or more PDUs within and / or across one or more PDU sets, the percentage of one or more remaining PDUs in the PDU set expected to be received, and / or the payload size.

[0093] Restrictions associated with one or more data units of one or more PDU sets to which they can be mapped, including one or more sublayers, one or more radio bearers, one or more LCHs, and / or one or more HARQ procedures. For example, a WTRU may have visibility of one or more data units and, based on restrictions of one or more configurations associated with one or more data units to which they can be mapped, determine corresponding actions and / or functions (e.g., performing priority for each LCP, performing mapping to one or more restricted CG configurations, one or more TBs, one or more HPIs).

[0094] One or more PDU sets and corresponding characteristics and / or properties may refer to data bursts and / or data generated by an application within a short period of time, including one or more PDUs from one or more PDU sets. Attributes (i.e., characteristics and / or properties), associations, and interdependencies (e.g., within and / or between PDU sets) include, but are not limited to, start and / or end indications of PDU sets and / or data bursts (e.g., via sequence number (SN), start and / or end indications, and / or timestamps, etc.), start and / or end times, duration, corresponding payload size, periodicity, importance and / or priority values, and QoS (e.g., PSDB), and may be visible to and / or processed by one or more AS layers (e.g., with associated IDs), which are aware of this association during data transmission in the UL and / or reception in the DL.

[0095] One or more PDU sets and associated characteristics and / or properties can refer to application and / or higher-level importance and / or priority values. This is because different PDU sets and / or all PDUs in a PDU set can be associated with different importance and / or priority values. Importance and / or priority values ​​can correspond to spatial importance (e.g., the spatial location of video frames whose data is carried by one or more PDU sets, where one or more PDU sets carrying the field-of-view (FoV) spatial location can be associated with higher spatial importance than non-FoV spatial locations) and / or temporal importance (e.g., the temporal sequence of video frames and / or application frames whose data is carried by one or more PDU sets, where one or more PDU sets carrying basic video frames such as I-frames can be associated with higher temporal importance than differential video frames such as P-frames and / or B-frames). During data transmission and / or reception, importance and / or priority values ​​may be visible to the AS layer.

[0096] One or more PDU sets and associated characteristics and / or properties can refer to one or more QoS flows and / or one or more data flows: one or more PDUs and / or one or more PDU sets of an application can be encoded by the application and delivered to the WTRU (in the UL) and / or the network (in the DL) via one or more QoS flows and / or one or more data flows. In this regard, different QoS flows and / or different data flows carrying one or more PDUs and / or one or more PDU sets associated with an XR application and / or experience can be visible to and / or processed at the AS layer, which is aware of this association during data transmission and / or reception.

[0097] Throughout the embodiments described herein, the PDU set profile may include, but is not limited to, service characteristics and one or more PDU set-level QoS requirements and / or conditions relating to one or more of the following: PSDB, PSIHI, PSER, jitter, and / or residual delay. PSDB refers to the time between receiving the first PDU (at the UPF in DL, at the WTRU in UL) and successfully delivering the last arriving PDU in the PDU set (at the WTRU in DL, at the UPF in UL). PSDB is an optional parameter and, when provided, can replace PDB. PSIHI indicates whether the application layer requires all PDUs in the PDU set. PSER defines the upper limit of the non-congestion-related PDU set loss rate between the RAN and WTRU. Jitter may refer to a change relative to an expected time instance during which one or more data units can be received and / or transmitted. For example, jitter can refer to the variation relative to the periodic time for a set of data units that may be expected to be received periodically at different periodic times (e.g., for data units that may be received T1 milliseconds earlier and / or T2 milliseconds later than the expected time T, the jitter range is T2-T1). Jitter can refer to instantaneous values ​​or statistical values ​​(e.g., mean, variance, standard deviation, maximum and / or minimum values, etc.). Remaining delay can refer to the remaining duration of one or more PDUs in the PDU set before the PSDB (Presentation Presence Delay) for receiving and / or transmitting. Remaining delay can also be referred to as the Time to Live (TTL) associated with the PDU set.

[0098] Throughout the embodiments described herein, a multi-PUSCH CG may correspond to one or more configured resources or one or more CG configurations, wherein each CG configuration may include a set of continuous and / or discontinuous PUSCH opportunities per slot and / or per CG period. In the examples, a multi-PUSCH CG may include one or more CG periods (e.g., each CG period may repeat periodically with a certain period value), the CG periods in a multi-PUSCH CG may include one or more continuous or discontinuous slots, the slots in the CG periods of a multi-PUSCH CG may include one or more continuous and / or discontinuous PUSCH opportunities, and / or the slots in the slots and / or the PUSCH opportunities in the slots and / or CG periods of a multi-PUSCH CG may include one or more continuous and / or discontinuous symbols with a specific symbol length (e.g., one or more time-domain resources). A PUSCH opportunity may include one or more resource blocks or groups of resource blocks in the frequency domain. Throughout the embodiments described herein, PUSCH usage may refer to any of the number, location, position, and / or timing of one or more PUSCH opportunities in one or more slots and / or one or more CG periods, which may be associated with one or more multi-PUSCH CG configurations.

[0099] Figure 2 This is a diagram illustrating an example of an instruction transmitted from WTRU 202 to base station 204 in network 200 according to an embodiment. In the example, WTRU 202 determines and / or instructs changes to one or more transmission parameters in a multi-PUSCH configuration. For example, at 206, WTRU 202 receives configuration information from base station 204 indicating adjustments to one or more transmission parameters when transmitting one or more PDUs in a PDU set. For example, WTRU 202 multiplexes one or more PDUs in the PDU set into one or more TBs and / or one or more HARQ processes. At 208, WTRU 202 determines and / or generates one or more transmission parameters associated with the PDU set. Because WTRU 202 selects a repetition mode based on the PDU set profile, it uses one or more resources in the multi-PUSCH configuration to repeat one or more PDUs. At 210, WTRU 202 sends the instruction to base station 204. At 212, after the initial transmission of the first subset of PDUs, WTRU 202 also dynamically selects the number of repetitions of the remaining subset of PDUs in the PDU set based on the remaining delay and downlink feedback information. At 214, WTRU 202 receives one or more indications (e.g., feedback) from network 200 from base station 204, which are associated with the first subset of PDUs and / or the first subset of the TB associated with the PDU set sent to base station 204. WTRU 202 determines the repetition pattern of the second subset of PDUs to be applied to the PDU set based on the remaining error budget and / or remaining delay, and / or WTRU 202 may determine one or more increments and / or one or more decrements for adjusting the MCS index in the multi-PUSCH CG based on the PDU set profile. At 216, WTRU 202 sends the second subset of PDUs to base station 204.

[0100] Figure 3This is a flowchart illustrating an example method 300 for sending instructions performed by a WTRU according to an embodiment. At 305, the WTRU receives a configuration set, including but not limited to a multi-PUSCH configuration, a set of repetition patterns that the WTRU can use, a set of LCHs associated with one or more PDU set profiles, association information between PSER and maximum repetition count, and / or one or more thresholds associated with one or more PDU set profiles. At 310, the WTRU receives one or more PDUs from one or more higher layers and / or information about the PDU set profiles, i.e., one or more PDU set attributes (e.g., PDU set size and / or PSER, etc.). The WTRU determines the mapping of one or more PDUs in one or more PDU sets to one or more LCHs based on the corresponding one or more PDU set profiles. At 315, the WTRU identifies one or more used and / or unused CG PUSCH moments (i.e., one or more used and / or unused CG PUSCH TOs). In the example, the WTRU determines that PUSCH moments in the multi-PUSCH configuration are not used. In the example, as described below, a PUSCH time slot is not used if no PDU is scheduled for transmission during the PUSCH time slot, and / or if the payload size of one or more PDUs multiplexed into the PUSCH time slot is below a threshold. In further examples, one or more unused PUSCH time slots (i.e., one or more unused CG PUSCH TOs) can be one or more PUSCH time slots that are not expected to be used by WTRUs for data transmission. In the example, one or more unused PUSCH time slots can include consecutive PUSCH time slots and / or can appear in the gaps between one or more used PUSCH time slots.

[0101] At 320, the WTRU determines one or more conditions associated with one or more PDU sets. These conditions may include one or more thresholds (e.g., threshold 1, threshold 2, etc.) associated with attributes of one or more PDU sets. At 325, the WTRU checks whether any of the one or more conditions are met. Specifically, the WTRU compares one or more thresholds with the corresponding PDU set attributes to check if the PDU set attribute exceeds a threshold. For example, the WTRU checks whether the size of the PDU set exceeds a threshold PDU set size indicated by a first threshold (i.e., threshold 1). In further examples, the WTRU checks whether the PSER associated with one or more PDUs and / or one or more PDU sets exceeds a threshold PSER indicated by a second threshold (i.e., threshold 2).

[0102] If at 325, the WTRU determines that any conditions associated with the PDU set profile are met (e.g., the size of the PDU set exceeds a first threshold and / or the number of PSERs associated with the PDU set exceeds a second threshold), then at 330, the WTRU determines, based on the PDU set profile (e.g., payload size and / or PSER, etc.), the number of UTOs (i.e., unused CG PUSCH opportunities) available for repeating one or more PDUs and / or one or more TBs. At 335, the WTRU selects a repeating mode based on the priority of the repeating mode, the number of PSERs and / or UTOs, which allows repeating at least a subset of the PDUs in the one or more PDU sets. The WTRU generates one or more transmission parameters and / or one or more retransmission parameters, which may include the selected repeating mode, UTOs, and / or the number of repeats, etc. At 340, the WTRU generates indications associated with one or more transmission and / or retransmission parameters.

[0103] If at 325, the WTRU determines that one or more conditions associated with the PDU set profile are not met, then at 345, the WTRU determines one or more CG PUSCH TOs used for the transmission of one or more PDU sets. Furthermore, at 350, the WTRU generates an indication associated with one or more transmission parameters, indicating one or more CG PUSCH TOs used for the transmission of one or more PDU sets.

[0104] At 355, the WTRU sends an indication to the network (e.g., in UCI). In some examples, the WTRU sends the indication at one or more CG PUSCH times. Furthermore, at 360, the WTRU uses one or more CG PUSCH times to transmit and / or retransmit one or more PDUs from one or more PDU sets, based on one or more transmission and / or retransmission parameters respectively.

[0105] In more example embodiments, when transmitting one or more PDUs from one or more PDU sets, the WTRU may receive configuration information instructing adjustments to one or more transmission parameters. In an example, the WTRU determines to change one or more transmission parameters (e.g., repetition count, repetition mode, and / or MCS value, etc.) when transmitting one or more PDUs from one or more PDU sets using one or more resources in a multi-PUSCH configuration, based on one or more of the following: one or more PDU set profiles, the payload size of one or more PDUs in one or more PDU sets, and the number of PUSCH times expected to be used and / or not used (e.g., PUSCH usage). For example, a multi-PUSCH CG configuration may be associated with one or more CG resources (e.g., in a multi-PUSCH CG configuration) or DG resources (e.g., a single DCI or multiple DCIs scheduling multiple PUSCHs).

[0106] In the example, for a multi-PUSCH configuration, the WTRU can determine the UTO corresponding to any PUSCH timing not used for UL transmission based on the payload size and / or the arrival of one or more PDUs in the LCH buffer. The WTRU can then utilize one or more available resources in the UTO and determine one or more transmission parameters (e.g., the number of repetitions of one or more TBs, the selected repetition pattern, adjustments to the MCS value), which can provide improved reliability and ensure successful transmission of one or more PDUs within the PSDB. When determining one or more transmission parameters, the WTRU can consider one or more available resources associated with the multi-PUSCH configuration to ensure that reliability and / or latency requirements during the transmission of one or more PDU sets are met.

[0107] In the example, the WTRU can receive configuration information and / or one or more configuration parameters (e.g., the number of PUSCH opportunities per slot, the number of slots per CG period, etc.) associated with one or more PDUs from one or more PDU sets from the network, used to transmit one or more TBs comprising one or more PDUs from one or more PDU sets. The WTRU can receive configuration sets from various sources. The WTRU can receive a set of repetition patterns indicating a set of repetition patterns that can be used with the multi-PUSCH configuration for repeating transmissions of one or more TBs comprising one or more PDUs from one or more PDU sets. For example, a set of repetition patterns can indicate a TO or position in the multi-PUSCH configuration, which can be used to repeat one or more TBs and RVs associated with such repetition. The WTRU can also receive priorities associated with a set of repetition patterns, which can be associated with one or more PDU set profiles associated with one or more PDU sets. Different repetition patterns can be associated with different sets of parameters, such as, but not limited to, any of the following: length, number of repetitions, location carrying the repetition, index and / or ID, etc. The WTRU can receive configuration sets from configuration information relating to the association between one or more PDU set profiles (e.g., PSER) and the maximum allowed number of repetitions. For example, the WTRU may receive mappings and / or tables, including but not limited to associations between the maximum number of repetitions for a given PSER, such as the maximum number of repetitions X allowed for a PDU set requiring Y% PSER. The WTRU may receive a configuration set including one or more thresholds associated with one or more PDU set profiles. For example, one or more thresholds may be related to the payload size of one or more PDU sets. The payload size may indirectly indicate the number of PUSCH opportunities that can or cannot be used in a multi-PUSCH configuration. The WTRU may also receive one or more thresholds associated with PSER, which may indicate the priority and / or importance level of a PDU set. The WTRU may receive a configuration set including information that associates a set of LCHs with one or more PDU set profiles. For example, one or more PDU sets with similar profiles mapped to the same LCH. The WTRU may receive a configuration set including but not limited to the percentage of allowed UTOs and association information between one or more PDU set profiles. In the example, the network may provide one or more restrictions on how the WTRU uses UTOs, perhaps to limit excessive resource usage. For example, the WTRU can receive configuration information via AS layer signaling (e.g., RRC signaling and / or messages, MAC CE or DCI) or non-AS (NAS) layer signaling (e.g., one or more PDU session-related messages).

[0108] The WTRU can receive one or more PDUs from one or more PDU sets, along with information associated with the corresponding PDU set profiles (e.g., PSER, PSDB, and / or payload size). The WTRU can select and / or forward one or more PDUs from one or more PDU sets to one or more radio bearers and / or one or more LCHs based on a set of parameters associated with the one or more PDUs and / or one or more PDU sets, including but not limited to importance and / or priority values, arrival time windows of the one or more PDUs, payload sizes of the one or more PDUs, and QoS of the one or more PDUs and / or one or more PDU sets (e.g., PSDB, PSIHI, and / or PSER). The WTRU can determine the mapping from one or more PDUs from one or more PDU sets to one or more LCHs based on the corresponding PDU set profiles (e.g., PSER and / or PSDB, etc.). This mapping ensures that one or more PDUs from one or more PDU sets are grouped within the same TB and / or consecutive TBs. WTRU can multiplex one or more PDUs from one or more PDU sets into multiple TBs and / or multiple HARQ procedures. In the example, for a PDU set comprising N PDUs mapped to M LCHs, a subset of the N PDUs can be multiplexed into a TB according to the LCP procedure, based on the resource allowance size associated with the TB and the priority of the M LCHs. The remaining subset of PDUs can be multiplexed into one or more other TBs. Since the M LCHs may also include other PDUs that may not be associated with the PDU set, one or more TBs can include combinations of N PDUs from the PDU set and non-PDU sets. In the example, WTRU can be configured with one or more constraints such that when multiplexing PDUs into one or more LCHs leading to one or more TBs, the N PDUs from the PDU set take precedence over PDUs associated with other non-PDU sets. Different TBs comprising different subsets of PDUs from the PDU set can be associated with one or more HARQ procedures, where each HARQ procedure can be associated with a HARQ procedure ID. One or more TBs can be sent by WTRU in UL at different PUSCH times in a multi-PUSCH configuration.

[0109] For example, based on association and / or constraint information between a PDU set, one or more LCHs, and one or more HARQ procedures, the WTRU (e.g., in the MAC sublayer) can know which PDUs in one or more LCHs are mapped to one or more TBs and / or one or more HARQ procedures. The WTRU can send an indication to the NW along with information about which TBs include PDUs associated with the PDU set. The indication can be sent with one or more TBs (e.g., in a UCI and / or MAC CE multiplexed with one or more PUSCHs) or in a separate indication (e.g., in a UCI in the Physical Uplink Control Channel (PUCCH)). For example, one or more TBs including one or more PDUs of the PDU set can include flags or IDs (e.g., the ID and / or index of the PDU set) indicating that one or more TBs include interdependent data. In another example, the WTRU can select a subset of HARQ procedure IDs from a configured set of IDs and indicate the selected IDs in one or more TBs to implicitly indicate to the NW that the TB includes interdependent data.

[0110] The WTRU can select the repetition mode to use based on a PDU set profile to reuse one or more PDUs in a multi-PUSCH configuration. In the example, the WTRU can select a repetition mode from a pre-configured set of repetition modes to use on a configured multi-PUSCH transmission cycle based on one or more PDU set profiles. For example, if the size of the PDU set scheduled for transmission during a multi-PUSCH transmission period is greater than a payload size threshold and / or if the PSER of one or more PDU sets is greater than an error threshold (e.g., for the threshold PSER), the WTRU can determine the number of available PUSCH times, including one or more unused times within the configured multi-PUSCH that are not used to carry any PDUs and / or TBs and can be used to reuse PDUs and / or TBs belonging to one or more PDU sets. In the example, if no PDUs are scheduled for transmission during a PUSCH time and / or if the payload size of one or more PDUs from one or more PDU sets multiplexed into a PUSCH time is less than a threshold, the WTRU can determine that the PUSCH time in the multi-PUSCH configuration is unused. The WTRU can select a repetition mode to use within the available set of PUSCH times that has not been used to repeat the transmission of one or more PDUs from one or more PDU sets. In the example, the WTRU may select the repetition mode based on the priority of the available modes, the mapping of PSERs to the PDU sets, and / or the number of unused PUSCHs.

[0111] In the example, the WTRU may send one or more indications to the network (e.g., in UCI) that are selected and / or used to send a repeating pattern for one or more PDUs from one or more PDU sets. The indication sent by the WTRU may include an index or ID that refers to a repeating pattern from the set of repeating patterns available for WTRU retransmission. The indication may also implicitly or explicitly include information about a set of used and / or unused and / or used PUSCH moments in a multi-PUSCH configuration, a subset of which is used for repeating one or more PDUs. The indication may also include one or more HARQ process IDs corresponding to one or more TBs, which include one or more PDUs from one or more repeating PDU sets. During the transmission of PDUs and / or one or more TBs, the WTRU may multiplex the indication (e.g., in UCI) within one or more PUSCH moments.

[0112] After the initial transmission, the WTRU can dynamically select the number of repetitions for the remaining subset of PDUs in one or more PDU sets based on the remaining delay and / or downlink feedback information. In the example, after the initial transmission of the first subset of PDUs in the PDU set, the WTRU can dynamically determine the number of repetitions and / or repetitions to apply when transmitting one or more PDUs in the subset of repetitive PDUs, based on indications received from the network (e.g., in the DCI). The WTRU can apply repetitions when transmitting the second subset of PDUs and / or a subset of PDUs scheduled for transmission in the later stages of a multi-PUSCH configuration cycle.

[0113] In the example, the WTRU can receive configuration information from the network and / or one or more parameters associated with one or more multi-PUSCH configurations (e.g., the number of PUSCH opportunities per slot and / or the number of slots per CG cycle, etc.), which are used to transmit one or more TBs comprising one or more PDUs from one or more PDU sets. The WTRU can also receive a set of thresholds associated with one or more residual error budgets for one or more PDU sets. The WTRU can also receive thresholds associated with the residual latency relative to the PSDB of the corresponding PDU set.

[0114] The WTRU can receive a first subset of PDUs, comprising one or more PDUs from one or more PDU sets, and information associated with one or more PDU set profiles corresponding to the one or more PDU sets from one or more applications and / or higher layers. For example, the first subset of PDUs, comprising one or more PDUs from one or more PDU sets, may include information (e.g., in one or more PDU headers) including, but not limited to, the PDU set payload size, the total number of PDUs in the PDU set, PSER, and PSDB. The WTRU may also receive information including, but not limited to, the minimum percentage and / or number of PDUs in the PDU set, which can be successfully received for the PDU set to succeed. The WTRU may use one or more available resources in a multi-PUSCH configuration to send the first subset of PDUs and / or one or more TBs belonging to the PDU set.

[0115] The WTRU may receive one or more indications from the NW on a first subset of PDUs and / or one or more TBs of one or more PDU sets. In the example, the WTRU may receive the indications from the NW while performing a transmission of a first subset of PDUs in a PDU set. For example, the indications may provide feedback information and / or transmission status associated with a transmission of one or more TBs. For example, the indications may be received by the WTRU in DCI, DL MAC CE, and / or RRC signaling. The indications may be received in a single indication (e.g., in a single DCI) with information associated with a transmission of one or more TBs, or in multiple indications, where each indication may be associated with a transmission of one TB. The indications received by the WTRU may include, but are not limited to, one or more HARQ procedure IDs, NDI information about the associated HARQ procedure IDs, one or more resources for retransmission, and / or timing information for one or more resources for retransmission.

[0116] For example, for one or more HARQ procedure IDs, information about one or more HARQ procedures (e.g., IDs) can be provided in a single indication or multiple indications, where each indication can be associated with a HARQ procedure ID. When providing information about multiple HARQ procedures associated with multiple TBs of transmission, a bitmap format can be used. For example, each bit in the bitmap can be associated with a HARQ procedure ID and can indicate the acknowledgment (ACK) and / or negative acknowledgment (NACK) status of the corresponding TB's transmission. For example, the bitmap format can be associated with a downlink feedback indication (DFI). For example, for NDI information about a corresponding HARQ procedure ID, if the NDI flag of the HARQ procedure ID is toggled and / or reset, the WTRU can consider the transmission of the TB associated with the HARQ procedure ID to be successful. The WTRU can then release the data in the buffer associated with the HARQ procedure.

[0117] For resources used for retransmission, the resource can be associated with one or more HARQ procedure IDs, where the WTRU can use the resource for retransmitting the TB associated with the HARQ procedure. For example, the resource used for retransmission can be a DG, CG, or a combination of DG and CG. When the resource is a DG, the resource information can include, but is not limited to, any of the following: Time Domain Resource Allocation (TDRA) (e.g., PUSCH timing, start and length indication values ​​(SLIV), etc.), Frequency Domain Resource Allocation (FDRA) (e.g., the number of RBs and / or RBGs, etc.), and one or more transmission parameters (e.g., MCS, RV, etc.). When the resource is a CG, in addition to TDRA and / or FDRA, the information may also include activation indications for one or more CG configurations (e.g., the ID and / or index of the CG configuration).

[0118] For example, for timing information of resources used for retransmission, one or more PUSCH timings can be associated with at least one K2 value, where K2 can indicate timing, slots, and / or symbols, etc., used to perform TB retransmission. For example, timing information can be indicated relative to reference timing, slots, and / or symbols (e.g., SFN).

[0119] The WTRU determines the repetition pattern of a second subset of PDUs to be applied to the PDU set based on the remaining error budget and / or remaining delay. In the example, the WTRU may receive a second subset of PDUs, comprising one or more PDUs, from one or more application layers and / or higher layers. The WTRU may determine the remaining error budget of the PDU set based on information received from the NW regarding the transmission status of a first subset of PDUs in the PDU set (e.g., ACK and / or NACK information in a bitmap). The remaining error budget may also be determined based on the remaining PDUs to be transmitted within the second subset of the PDU set and one or more PDUs from the first subset of the PDU set scheduled for retransmission. Resources (e.g., DGs) for one or more PDUs from the first subset of the PDU set to be retransmitted may be provided to the WTRU, indicated in a single DCI or multiple DCIs (corresponding to the number of TBs to be retransmitted). The resource indication for retransmission may also include timing information indicating when the retransmission resources are available. For example, the remaining error budget of the PDU set may be the maximum number of PDUs scheduled for initial transmission and / or retransmission, for which successful reception is not required. WTRU can determine the delay budget relative to the PDU set based on the remaining TB and / or remaining PDUs scheduled for transmission and / or retransmission.

[0120] In the example, the WTRU can dynamically determine repetitions (e.g., the number of repetitions and / or repetition patterns, etc.) to be applied when transmitting and / or retransmitting the remaining subset of PDUs based on configured conditions using available DG and multi-PUSCH resources allocated for retransmissions of one or more PDUs from a first subset of PDUs. For example, if the remaining error budget of the remaining and / or second subset of PDUs in the PDU set is less than an error threshold, and / or if the remaining delay relative to the PSDB is less than a delay threshold, the WTRU can determine the number of unused PUSCH opportunities within the resources available in the multi-PUSCH configuration, and the DG allocated for retransmitting one or more PDUs and / or one or more TBs corresponding to the first subset of PDUs. This determination can be done based on the remaining payload size of one or more PDUs in the PDU set scheduled for initial transmission and / or retransmission. The WTRU can determine the number of repetitions and / or repetition patterns to use when retransmitting one or more PDUs from the remaining PDU set and / or the second subset of PDUs based on the available PUSCH opportunities, DG resources, and / or PSER in the multi-PUSCH configuration. In the example, WTRU can determine the repetition pattern based on a pre-configured mapping in a set of tables that provide the number of available PUSCH opportunities and the association between PSERs.

[0121] The WTRU may send one or more indications to the network (e.g., in UCI) associated with a repeating pattern applied to a subset of the remaining PDUs in the repeating PDU set. The indications sent by the WTRU may include an index and / or ID referring to a repeating pattern from that set of repeating patterns. The indications may also implicitly or explicitly include information about the timing of PUSCHs in a multi-PUSCH configuration, and DG resources for repeating one or more PDUs and / or one or more TBs associated with the subset of remaining PDUs and / or TBs. The indications may also include one or more HARQ process IDs corresponding to a TB that includes one or more PDUs in the repeating PDU set. During transmission, the WTRU may multiplex (e.g., in UCI) the indications in one or more PUSCHs. On the other hand, if the remaining error budget is higher than an error threshold and / or if the remaining delay relative to the PSDB is higher than a delay threshold, the WTRU may use one or more default transmission parameters, with or without repeating, when transmitting the remaining PDUs of the PDU set. In the example, a remaining error budget greater than the error threshold might mean that most of the PDUs in the PDU set have likely been successfully received, and the WTRU can tolerate transmitting and / or retransmitting the remaining PDUs with lower reliability (e.g., higher error tolerance and / or budget). A remaining delay greater than the delay threshold might indicate that the WTRU can tolerate waiting to receive an indication from the NW for retransmitting one or more PDUs from the remaining subset of PDUs to meet the PSER requirement of the PDU set without duplicating one or more PDUs.

[0122] WTRU can determine the increment and / or decrement for adjusting the MCS index in a multi-PUSCH CG based on the PDU set profile. In the example, WTRU can determine the increment and / or decrement values ​​for adjusting the MCS index based on one or more PDU set profiles to improve reliability and resource efficiency when using a multi-PUSCH CG to transport one or more PDU sets.

[0123] In the example, the WTRU may receive configuration information from the network and / or one or more parameters associated with one or more multi-PUSCH configurations (e.g., the number of PUSCH opportunities per slot, the number of slots per CG period, etc.) for transmitting one or more TBs comprising one or more PDUs from one or more PDU sets. The WTRU may receive a set of LCHs associated with a set of PDU set profiles, used to map one or more PDUs belonging to the same PDU set in one or consecutive TBs. The WTRU may also receive a set of possible values ​​associated with the maximum increment and / or decrement values ​​to be applied to adjust the MCS index. The WTRU may also receive configuration information, including a set of tables and / or mappings associated with the PDU set profiles, unused PUSCH opportunities (e.g., PUSCH opportunities not intended for data transmission), and / or the MCS adjustments to be applied.

[0124] The WTRU can receive one or more PDUs from one or more higher layers, along with information associated with the PDU set profile (e.g., PSER, PSDB, payload size, etc.). The WTRU can determine the mapping of one or more PDUs in the PDU set to one or more LCHs based on the corresponding one or more PDU set profiles (e.g., PSER, PSDB, etc.) to ensure that one or more PDUs in the PDU set are grouped within the same TB and / or consecutive TBs.

[0125] In the example, the WTRU can determine unused PUSCH moments in a multi-PUSCH CG based on the number of TBs scheduled for transmission and / or multiplexing one or more TBs to one or more PUSCH moments. For example, depending on the arrival and / or jitter of one or more PDUs from one or more higher layers (e.g., the application layer, etc.), one or more TBs comprising one or more PDUs from one or more PDU sets can be mapped to gaps between consecutive PUSCH moments and / or between one or more TOs with PUSCH moments. Thus, one or more unused PUSCH moments can be gaps between consecutive PUSCH moments and / or between places where one or more used PUSCH moments occur.

[0126] In the example, the WTRU can use a mapping table to select adjustments (e.g., the amount of change in the MCS index) to be applied to the default MCS index based on one or more PDU set profiles (e.g., PSERs, etc.) and / or one or more unused PUSCH opportunities. For example, for a PDU set with X% PSERs and Z unused PUSCH opportunities in a multi-PUSCH CG, the WTRU can refer to the mapping table to obtain the maximum increment and / or decrement values ​​to be applied to the default MCS index to improve the reliability and / or efficiency of resource utilization during the transfer of one or more PDU sets. The WTRU can re-evaluate unused PUSCH opportunities based on the updated MCS index, which can thus change the number and / or size of one or more TBs scheduled within the multi-PUSCH CG. Based on the newly re-evaluated unused PUSCH opportunities and / or the updates applied to the MCS index, the WTRU can determine the repetition pattern applied to one or more PDUs in a repeating PDU set. For example, this approach could be designed to improve reliability and / or resource utilization during transmission of one or more PDUs and / or one or more TBs using a repetition pattern that ensures a higher number of repetitions, while a repetition pattern with a lower number of repetitions could be used during transmissions using a lower MCS value.

[0127] The WTRU may send one or more indications to the network (e.g., in UCI) that are associated with updates applied to the MCS index and / or repetition patterns used to send one or more PDUs from one or more PDU sets. The indications may also implicitly or explicitly include a set of unused PUSCH moments in a multi-PUSCH configuration, a subset of which is used for repetition of one or more PDUs. The indications may also include one or more HARQ process IDs corresponding to one or more TBs that include one or more PDUs from one or more PDU sets that are being repeated. The WTRU may multiplex (e.g., in UCI) the indications regarding MCS adjustments and / or repetitions for one or more PDUs during the transmission of the first PUSCH moment.

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

Claims

1. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive configuration information, which includes multiple configured allow (CG) Physical Uplink Shared Channel (PUSCH) timings; Sending an indication of one or more transmission parameters associated with one or more PDUs of at least one Protocol Data Unit (PDU) set. One or more transmission parameters are determined based on configuration information and multiple PDU set attributes associated with at least one PDU set; and Based on one or more transmission parameters, one or more PDUs are sent during one or more CG PUSCH times out of multiple CG PUSCH times.

2. The method according to claim 1, wherein, One or more transmission parameters include at least one repeating pattern.

3. The method according to claim 1, wherein, The configuration information also includes one or more of the following: Threshold PDU set error rate (PSER). Threshold PDU set size, A set of repeating patterns, where each repeating pattern in the set is associated with a priority, or Maximum number of repetitions.

4. The method according to claim 3, further comprising: Identify one or more used CG PUSCH opportunities and one or more unused CG PUSCH opportunities from a plurality of CG PUSCH opportunities.

5. The method according to claim 4, further comprising: Based on multiple PDU set attributes, the number of one or more unused CG PUSCH opportunities, and at least one threshold, select a repeating pattern from the set of repeating patterns; and The number of repetitions is determined based on the maximum number of repetitions and multiple PDU set attributes.

6. The method according to claim 5, wherein, One or more transmission parameters indicate at least one of the following: the selected repetition pattern or the determined number of repetitions.

7. The method according to claim 5, further comprising: Based on at least one of the selected repetition mode or the determined number of repetitions, retransmit one or more PDUs during one or more unused CGPUSCH opportunities.

8. The method according to claim 3, further comprising: Determine the size of the PDU set associated with at least one PDU set; and One or more transmission parameters are determined by comparing the threshold PDU set size with the PDU set size.

9. The method according to claim 3, further comprising: Identify the PSER associated with at least one set of PDUs; and One or more transmission parameters are determined by comparing the threshold PSER with the determined PSER.

10. The method according to claim 1, wherein, The instruction is sent in the uplink control information (UCI).

11. A wireless transceiver unit (WTRU), comprising: The memory is configured to store one or more PDUs, including at least one set of Protocol Data Units (PDUs); The transceiver is configured as follows: Receive configuration information, which includes multiple configured allowable (CG) physical uplink shared channel (PUSCH) timings, and Instructions to send one or more transmission parameters associated with one or more PDUs; and The processor is configured as follows: One or more transmission parameters are determined based on configuration information and multiple PDU set attributes associated with at least one PDU set. Based on one or more transmission parameters, one or more PDUs are sent during one or more CG PUSCH times among multiple CG PUSCH times.

12. The WTRU according to claim 11, wherein, One or more transmission parameters include at least one repeating pattern.

13. The WTRU according to claim 11, wherein, The configuration information also includes one or more of the following: Threshold PDU set error rate (PSER). Threshold PDU set size, A set of repeating patterns, where each repeating pattern in the set is associated with a priority, or Maximum number of repetitions.

14. The WTRU of claim 13, wherein the processor is configured to: Identify one or more used CG PUSCH opportunities and one or more unused CG PUSCH opportunities from a plurality of CG PUSCH opportunities.

15. The WTRU according to claim 14, wherein, The processor is also configured to: Based on multiple PDU set attributes, the number of one or more unused CG PUSCH opportunities, and at least one threshold, a repeating pattern is selected from this set of repeating patterns. The number of repetitions is determined based on the maximum number of repetitions and multiple PDU set attributes.

16. The WTRU according to claim 15, wherein, One or more transmission parameters indicate at least one of the following: the selected repetition pattern or the determined number of repetitions.

17. The WTRU of claim 15, wherein the transceiver is configured to: Based on at least one of the selected repetition mode or the determined number of repetitions, retransmit one or more PDUs during one or more unused CGPUSCH opportunities.

18. The WTRU according to claim 13, wherein, The processor is also configured to: Determine the size of the PDU set associated with at least one PDU set; and One or more transmission parameters are determined by comparing the threshold PDU set size with the PDU set size.

19. The WTRU according to claim 13, wherein, The processor is also configured to: Identify the PSER associated with at least one set of PDUs; and One or more transmission parameters are determined by comparing the threshold PSER with the determined PSER.

20. The WTRU of claim 11, wherein, The instruction is sent in the uplink control information (UCI).

Images