Grant Mute Pattern Configured for Grant Push Usage

Description

1 / 106 “Grant Mute Pattern Configured for Grant Push Use” Cross-reference to related requests

[001] This application claims the benefit of U.S. Provisional Application No. 63 / 457,036, filed April 4, 2023, the content of which is incorporated by reference into the present invention. BACKGROUND

[002] Mobile communications using wireless communication continue to evolve. A fifth generation may be called 5G. A previous (legacy) generation of mobile communication may be, for example, the fourth generation (4G) of long-term evolution (LTE). SUMMARY

[003] Systems, methods and instrumentation are described in the present invention which can be associated with providing an indication of a configured grant (CG) muting pattern for use of a physical uplink shared channel (PUSCH) CG. A wireless transmit and receive unit (WTRU) can receive configuration information. The configuration information may comprise, for example, one or more configured grant (CG) settings for multi-PUSCH, a set of one or more CG muting patterns, criteria for selecting the one or more CG muting patterns, or threshold values ​​associated with one or more payload sizes, remaining delay, or number of repetitions.Each muting pattern can indicate a subset of PUSCH occasions with configured grant (CG) and the location of PUSCH occasions that are muted / unused over a time window. Criteria for selecting one or more CG muting patterns can be specified to minimize the number of non-matching occasions. Petition 870250088293, dated 09 / 29 / 2025, page 12 / 140 2 / 106 where non-matching occasions correspond to PUSCH occasions that do not correspond to non-silenced occasions.

[004] The WTRU can be configured to determine, for example, to receive, a plurality of PDUs associated with a set of PDUs. The WTRU can determine a PUSCH usage pattern based on at least the plurality of PDUs associated with the set of PDUs. A PUSCH usage pattern can indicate whether each of a plurality of PUSCH occasions associated with the PUSCH usage pattern is used or not. The WTRU can determine the PUSCH usage pattern, for example, based on determining that a payload of multiplexed PDUs in a PUSCH occasion is above a first payload threshold value and / or below a second payload threshold value, for example, per PUSCH occasion. The WTRU can determine the PUSCH usage pattern based on determining a remaining delay of a set of PDUs being less than or equal to a delay threshold value that may be, for example, associated with a PDU set delay budget (PSDB).WTRU can determine the pattern of PUSCH usage based on determining whether a number of repetitions per PDU in the PDU set is above a first repetition threshold value or below a second repetition threshold value, which may be associated, for example, with a PDU set error rate (PSER).

[005] WTRU may select one or more configured grant muting patterns from a set configured based on at least the determined PUSCH usage pattern. WTRU may select one or more configured grant muting patterns based on the determined PUSCH usage pattern using criteria such as minimizing the number of mismatched occasions in each CG muting pattern relative to the determined PUSCH usage pattern. Mismatched occasions may include, for example, a series of PUSCH occasions used in the traffic pattern that does not Petition 870250088293, dated 09 / 29 / 2025, page 13 / 140 3 / 106 correspond to non-muted occasions. WTRU can combine multiple CG muting patterns, which can be called pattern union, which may result in meeting the criteria. For example, multiple combined CG muting patterns may meet the criteria of minimizing the number of non-matching occasions in each CG muting pattern.

[006] WTRU can transmit an indication containing an index for one or more selected configured grant muting patterns. BRIEF DESCRIPTION OF THE DRAWINGS

[007] FIG. 1A is a system diagram that illustrates an example communications system in which one or more advertised modes can be implemented;

[008] FIG. 1B is a system diagram illustrating an example of a wireless transmit / receive unit (WTRU) that can be used within the communications system illustrated in FIG. 1A according to one embodiment;

[009] FIG. 1C is a system diagram that illustrates an example of a radio access network (RAN) and an example of a core network (CN core network) that can be used within the communications system illustrated in FIG. 1A according to a modality.

[010] FIG. 1D is a system diagram that illustrates another example of RAN and another example of CN that can be used within the communications system illustrated in FIG. 1A according to a modality.

[011] FIG. 2 illustrates an example of implementing a WTRU by determining the use of PUSCH.

[012] FIG. 3 describes an example of implementing a location determination for sending a PUSCH usage indication. Petition 870250088293, dated 09 / 29 / 2025, page 14 / 140 4 / 106

[013] FIG. 4 illustrates an example of implementation to determine the updating of information provided in a first indication on the use of CP PUSCH occasions.

[014] FIGS. 5A and 5B illustrate an example of implementing the selection and indication of a pre-configured CG muting pattern.

[015] FIG. 6 describes an example of implementing a WTRU transmitting an indication to activate a selected FDRA configuration.

[016] FIG. 7 describes an example of implementing a WTRU by determining the time offset (e.g., delay) of a subset of PUSCH occasions. DETAILED DESCRIPTION

[017] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the attached drawings.

[018] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed modalities may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, streaming, etc., to multiple wireless users. The communications system 100 may allow multiple wireless users to access this content by sharing system resources, including wireless bandwidth.For example, 100 communication systems 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-tailed single-word (UW) discrete Fourier transform (ZT) propagation OFDM (ZT UW DTS-s OFDM), single-word OFDM (UW-OFDM), feature block filtered OFDM, filter bank multicarrier (FBMC), and the like. Petition 870250088293, dated 09 / 29 / 2025, page 15 / 140 5 / 106

[019] As shown in FIG. 1A, the communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, an ON 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, although it is recognized that the disclosed embodiments may encompass any number of WTRUs, base stations, networks and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station and / or an ST, may be configured to transmit and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook,A personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in industrial and / or automated process chain contexts), a consumer electronic device, a device operating on commercial and / or industrial wireless networks, and the like. Any of WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as UE.

[020] Communication systems 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interact with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110 and / or the networks 112. By way of example, base stations 114a, 114b may be a base station Petition 870250088293, dated 09 / 29 / 2025, p. 16 / 140 6 / 106 transceiver (BTS), a B-Node, an evolved B-Node (eNode B), a Home B-Node, a Home eNode B, a B(gNB), a B-Node NR, a site controller, an access point (AP), a wireless router, and the like. Although base stations 114a and 114b are each represented as a single element, it will be recognized that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[021] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be called a cell (not shown). These frequencies may be in the licensed spectrum, the unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service for a specific geographic area that may be relatively fixed or that may change over time. The cell may additionally be divided into cellular sectors. For example, the cell associated with base station 114a may be divided into three sectors.Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In another 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 desired spatial directions.

[022] Base stations 114a, 114b can communicate with one or more WTRUs 102a, 102b, 102c, 102d by means of an air interface 116, which can be any suitable wireless communication link (e.g., radio frequency) Petition 870250088293, dated 09 / 29 / 2025, p. 17 / 140 7 / 106 (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The 116 air interface can be established using any suitable radio access technology (RAT).

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

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

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

[026] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, 102c can implement access by Petition 870250088293, dated 09 / 29 / 2025, p. 18 / 140 8 / 106 LTE radio and NR radio access together, for example, using dual connectivity (DC) principles. Thus, the air interface used by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[028] Base station 114b in FIG. 1 A can be a wireless router, home Node-B, home eNode-B, or access point, for example, and can utilize any suitable RAT to facilitate wireless connectivity in a localized area, such as a workplace, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a highway, and the like. In one embodiment, base station 114b and WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another mode, base station 114b and WTRUs 102c, 102d can use a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.).) to establish a picocell or femtocell. As shown in FIG. 1 A, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not be. Petition 870250088293, dated 09 / 29 / 2025, page 19 / 140 9 / 106 required to access the Internet 110 via CN 106 / 115.

[029] RAN 104 / 113 may be in communication with CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in FIG.1A, it will be recognized that RAN 104 / 113 and / or CN 106 / 115 may be in direct or indirect communication with other RANs employing the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113, which may be using NR radio technology, CN 106 / 115 may also be in communication with another RAN (not shown) employing any of the GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technologies.

[030] CN 106 / 115 can also serve as a gateway for WTRUs 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include circuit-switched telephone networks providing plain old 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) in the TCP / IP Internet protocol suite. Networks 112 may include networks of Petition 870250088293, dated 09 / 29 / 2025, page 20 / 140 10 / 106 wired and / or wireless communication owned and / or operated by other service providers. For example, 112 networks may include another CN connected to one or more RANs, which may employ the same RAT as RAN 104 / 113 or a different RAT.

[031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multimode capabilities (for example, WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communication with different wireless networks via different wireless links). For example, WTRU 102c shown in FIG. 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and with base station 114b, which may employ IEEE 802 radio technology.

[032] FIG. 1B is a system diagram illustrating an example of a WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive 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 peripherals 138, among others. It will be recognized that the WTRU 102 may include any subcombination of the foregoing elements, remaining consistent with an embodiment.

[033] Processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. Processor 118 may Petition 870250088293, dated 09 / 29 / 2025, page 21 / 140 11 / 106 perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that allows the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. Although FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be recognized that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[034] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive infrared, ultraviolet, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 can be configured to transmit and / or receive both RF and light signals. It will be recognized that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[035] Although the transmit / receive element 122 is represented in FIG. 1 B as a single element, the WTRU 102 can include any number of transmit / receive elements 122. More specifically, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to transmit and receive wireless signals over the air interface 116.

[036] Transceiver 120 can be configured to modulate the signals that are to be transmitted by the transmit / receive element 122 and to demodulate the signals that are received by the transmit / receive element 122. As Petition 870250088293, dated 09 / 29 / 2025, page 22 / 140 12 / 106 as noted above, the WTRU 102 may have multimode capabilities. Thus, the 120 transceiver may include multiple transceivers to allow the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[037] The WTRU 102 processor 118 can be coupled to and can receive user input data from the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 can also send user data to the speaker / microphone 124, the keyboard 126, and / or the display / touchpad 128. In addition, the processor 118 can access information and store data in any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. Non-removable memory 130 can 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 card, a secure digital memory (SD) card, and the like.In other configurations, the 118 processor can access information and store data in memory that is not physically located in the WTRU 102, such as in a server or a home computer (not shown).

[038] Processor 118 can receive power from power source 134 and can be configured to distribute and / or control power to the other components in WTRU 102. Power source 134 can be any device suitable for powering WTRU 102. For example, power source 134 can 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, and the like.

[039] The 118 processor can also be coupled to the GPS 136 chipset, which Petition 870250088293, dated 09 / 29 / 2025, page 23 / 140 13 / 106 can be configured to provide location information (e.g., longitude and latitude) about the current location of WTRU 102. In addition to, or instead of, information from the GPS chipset 136, WTRU 102 may receive location information via air interface 116 from a base station (e.g., base stations 114a, 114b) and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be acknowledged that WTRU 102 may acquire location information through any suitable location determination method, remaining consistent with a mode.

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

[041] A WTRU 102 may include a full duplex radio for which the transmission and reception of some or all signals (e.g., associated with subframes) Petition 870250088293, dated 09 / 29 / 2025, page 24 / 140 14 / 106 specific to the uplink (e.g., for transmission) and to the downlink (e.g., for reception) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit to substantially reduce and / or eliminate self-interference by means of hardware (e.g., a choke) or signal processing by means of a processor (e.g., a separate processor (not shown) or by means of processor 118). In one embodiment, WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with subframes specific to the uplink (e.g., for transmission) or the downlink (e.g., for reception)) are permitted.

[042] FIG. 1C is a system diagram illustrating RAN 104 and CN 106 according to one mode. As noted above, RAN 104 can employ a radio technology - UTRA - to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 104 can also be in communication with CN 106.

[043] RAN 104 may include eNode-Bs 160a, 160b, 160c, although it is possible that RAN 104 may include any number of eNode-Bs, remaining consistent with one embodiment. eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communication with WTRUs 102a, 102b, 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, eNode-B 160a, for example, may use multiple antennas to transmit wireless signals and receive wireless signals from WTRU 102a.

[044] Each of the eNode-Bs 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, uplink (UL) and / or downlink (DL) user scheduling, and the like. As Petition 870250088293, dated 09 / 29 / 2025, p. 25 / 140 15 / 106 shown in FIG. 1C, the eNode-Bs 160a, 160b, 160c can communicate with each other through an X2 interface.

[045] The CN 106 shown in FIG. 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164 and a packet data network (PDN) (or PGW) gateway 166. Although each of the above elements is described as part of CN 106, it will be recognized that any of these elements may be owned and / or operated by an entity other than the CN operator.

[046] MME 162 can be connected to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via an S1 interface and can serve as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, 102c, carrier activation / deactivation, selecting a specific service gateway during an initial connection of WTRUs 102a, 102b, 102c, and similar. MME 162 can provide a control plane function to switch between RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

[047] SGW 164 can be connected to each of the eNodeBs 160a, 160b, 160c in RAN 104 via the S1 interface. SGW 164 can generally route and forward user data packets to / from WTRUs 102a, 102b, 102c. SGW 164 can perform other functions such as anchoring user planes during transfers between eNode-Bs, triggering paging when DL data is available to WTRUs 102a, 102b, 102c, managing and storing contexts of WTRUs 102a, 102b, 102c and the like.

[048] SGW 164 can be connected to PGW 166, which can provide WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between WTRUs 102a, 102b, 102c and IP-enabled devices. Petition 870250088293, dated 09 / 29 / 2025, p. 26 / 140 16 / 106

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

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

[051] In representative modalities, the other 112 network can be a WLAN.

[052] A WLAN in Basic Services Infrastructure Set (BSS) mode can have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or other type of wired / wireless network that carries inbound and / or outbound traffic from the BSS. Traffic to STAs originating outside the BSS can arrive via the AP and be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS can be sent to the AP to be provided to the respective destinations. Traffic between STAs within the BSS can be sent through the AP, for example, where the originating STA can send traffic to the AP and the AP can provide the traffic to the destination STA. Traffic between STAs within a BSS can be considered and / or referred to as point-to-point traffic.Point-to-point traffic can be sent between (e.g., directly between) source and destination STAs with a Direct Link System (DLS) configuration. In certain modes. Petition 870250088293, dated 09 / 29 / 2025, p. 27 / 140 In representative 17 / 106 configurations, DLS can use either 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all STAs) within or using IBSS can communicate directly with each other. The IBSS communication mode is sometimes referred to as ad-hoc communication mode here.

[053] When using the 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit a beacon on a fixed channel, such as a primary channel. The primary channel can have a fixed width (e.g., 20 MHz bandwidth) or a width dynamically defined through signaling. The primary channel can be the BSS's operating channel and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier-sensing multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, STAs (e.g., each STA), including the AP, can sense the primary channel. If the primary channel is sensed and / or determined to be occupied by a specific STA, that specific STA can back off. An STA (e.g., only one station) can transmit at any time on a given BSS.

[054] High-throughput (HT) STAs can use a 40 MHz wide channel for communication, for example, by combining the 20 MHz primary channel with an adjacent or non-adjacent 20 MHz channel to form a 40 MHz wide channel.

[055] Very high throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels or by combining two non-contiguous 80 MHz channels. Petition 870250088293, dated 09 / 29 / 2025, page 28 / 140 18 / 106, which can be called an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, can be passed through a segment analyzer that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed on each stream separately. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a transmit STA. At the receiver of the receive STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to a medium access control (MAC) layer, etc.

[056] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The operating channel and carrier bandwidths are reduced in 802.11af and 802.11ah compared to those used in 802.11 and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV white space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using non-TVWS spectrum. According to a representative embodiment, 802.11ah supports meter-type machine / control type communications, such as MTC devices in a macro coverage area. MTC devices may have certain features, for example, limited features, including support for (e.g., support only for) certain and / or limited bandwidths. MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[057] WLAN systems, which can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the highest common operational bandwidth supported by all. Petition 870250088293, dated 09 / 29 / 2025, p. 29 / 140 19 / 106 STAs in the BSS. The primary channel bandwidth can be defined and / or limited by an STA, among all STAs operating in a BSS, that supports the lowest bandwidth operating mode. In the 802.11 ah example, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sense and / or network allocation vector (NAV) settings may depend on the primary channel state. If the primary channel is busy, for example, due to an STA (which (for example, only supports) a 1 MHz operating mode) transmitting to the AP, all available frequency bands can be considered occupied, even if most frequency bands remain idle and could be available.

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

[059] FIG. 1D is a system diagram illustrating RAN 113 and CN 115 according to one mode. As noted above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also be in communication with CN 115.

[060] RAN 113 may include gNBs 180a, 180b, 180c, although it is possible that RAN 113 may include any number of gNBs while remaining consistent with a mode. gNBs 180a, 180b, 180c may each include one or more transceivers for communication with WTRUs 102a, 102b, 102c via the aé interface. Petition 870250088293, dated 09 / 29 / 2025, p. 30 / 140 20 / 106 area 116. In one embodiment, gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 180b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, 180c. Thus, gNB 180a, for example, may use multiple antennas to wirelessly transmit signals to and / or receive wireless signals from WTRU 102a. In another embodiment, gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be in unlicensed spectrum, while the remaining component carriers may be in licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[062] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a standalone and / or non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c can use one or more gNBs 180a, 180b, 180c as a point. Petition 870250088293, dated 09 / 29 / 2025, page 31 / 140 21 / 106 mobility docking. In a standalone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, WTRUs 102a, 102b, 102c can communicate with / connect to gNBs 180a, 180b, 180c while also communicating with / connecting to other RANs, such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c can implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, eNode-Bs 160a, 160b, 160c can serve as a mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput to support WTRUs 102a, 102b, 102c.

[063] Each of the gNBs 180a, 180b, 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 the UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to user plane functions (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c can communicate with each other via an Xn interface.

[064] The CN 115 shown in FIG. 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b and possibly a Data Network (DN) 185a, 185b. Although each of the above elements is described as part of CN 115, it will be recognized that any of these Petition 870250088293, dated 09 / 29 / 2025, p. 32 / 140 22 / 106 elements may be owned and / or operated by an entity other than the NC operator.

[065] The AMF 182a, 182b can be connected to one or more gNBs 180a, 180b, 180c in RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, managing the log area, terminating NAS signaling, managing mobility, and the like. Network slicing can be used by AMF 182a, 182b to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being used by WTRUs 102a, 102b, 102c.For example, different network slices can be established for different use cases, such as services that rely on ultra-reliable low-latency access (URLLC), services that rely on enhanced massive mobile broadband access (eMBB), and services for machine-type communication access (MTC). AMF 162 can provide a control plane function to switch between RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[066] SMF 183a, 183b can be connected to AMF 182a, 182b on CN 115 via an N11 interface. SMF 183a, 183b can also be connected to UPF 184a, 184b on CN 115 via an N4 interface. SMF 183a, 183b can select and control UPF 184a, 184b and configure traffic routing through UPF 184a, 184b. SMF 183a, 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy and QoS enforcement, providing downlink data notifications, and the like. A PDU session type can be IP-based, non-IP-based, Petition 870250088293, dated 09 / 29 / 2025, p. 33 / 140 23 / 106 based on Ethernet and similar.

[067] UPF 184a, 184b can be connected to one or more gNBs 180a, 180b, 180c in RAN 113 via an N3 interface, which can provide WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between WTRUs 102a, 102b, 102c and IP-enabled devices. UPF 184, 184b can perform other functions such as packet routing and forwarding, user plane policy enforcement, multihomed PDU session support, user plane QoS handling, downlink packet buffering, mobility tethering provision, and the like.

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

[069] In view of Figures 1A-1D, and the corresponding description in Figures 1A-1D, one or more, or all, of the functions described in the present invention with respect to one or more of the following: WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, or any other devices described in this invention may be performed by one or more devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described in this invention. For example, the Petition 870250088293, dated 09 / 29 / 2025, p. 34 / 140 24 / 106 emulation devices can be used to test other devices and / or simulate network and / or WTRU functions.

[070] Emulation devices can be designed to implement one or more tests of other devices in a laboratory environment and / or in a carrier network environment. For example, one or more emulation devices may perform one or more, or all, of the functions while being wholly 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 emulation devices may perform one or more, or all, of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for testing purposes and / or may perform tests using wireless communications over the air.

[071] One or more emulation devices may perform one or more functions, including all, without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in a test scenario in a test laboratory and / or an undeployed wired and / or wireless communication network (e.g., test) to implement tests of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communications via RF circuits (e.g., which may include one or more antennas) may be used by emulation devices to transmit and / or receive data.

[072] Implementations for supporting Multi-PUSCH (shared physical channel uplink) CG (configured lease) in wireless systems are disclosed in the present invention. A WTRU can transmit support information associated with the multi-PUSCH CG to a network. The WTRU can receive information / indications associated with the network's multi-PUSCH CG configuration. The events Petition 870250088293, dated 09 / 29 / 2025, page 35 / 140 25 / 106 and / or conditions may be associated with triggering the PUSCH usage indication in multi-PUSCH CGs. The WTRU may determine PUSCH usage based on a dynamically signaled time window. The WTRU may determine the location to transmit the PUSCH usage indication. The WTRU may determine the update of the PUSCH usage indication. The WTRU may select a pre-configured CG muting pattern to indicate PUSCH usage. The WTRU may determine the FDRA (frequency domain resource allocation) configuration and transmit an indication to request activation / deactivation of an FDRA configuration for multi-PUSCH CGs. The WTRU may determine the offset of PUSCH occasions in multi-PUSCH CGs.

[073] The term Extended Reality (XR) can be an umbrella term for different types of immersive experiences, including, for example, Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and the realities interpolated between them. Virtual Reality (VR) is a rendered version of a delivered visual and sound scene. The rendering can be designed to mimic, for example, as naturally as possible, the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world to an observer or user as they move within the boundaries defined by the application. Augmented Reality (AR) can involve providing the user with additional information or artificially generated objects / items or content superimposed on their current environment.Mixed reality (MR) can be an advanced form of AR where some virtual elements can be inserted into the physical scene with the intention of providing the illusion that these elements are part of the real scene. XR can include combined real and virtual environments and human-machine interactions generated by computer technology and wearable devices.

[074] The notion of immersion in the context of XR applications / services can be Petition 870250088293, dated 09 / 29 / 2025, page 36 / 140 26 / 106 refers to the sensation of being surrounded by the virtual environment, as well as providing the feeling of being physically and spatially located in the virtual environment. Levels of virtuality can range from partial sensory inputs to fully immersive multisensory inputs, leading to a virtual reality that is virtually indistinguishable from real reality.

[075] In examples, a WTRU can correspond to an XR device / node, for example, any XR device / node, which can come in a variety of form factors. A WTRU (e.g., an XR WTRU) can include, but is not limited to, the following: head-mounted displays (HMDs); augmented reality optical glasses and HMDs with cameras for AR and MR; mobile devices with positional tracking and camera; wearables; tactile gloves; full-body tactile suits; tactile footwear; etc. In addition, various types of WTRUs for XR can be designed based on the functions of the XR device, such as display, camera, sensors, sensor processing, wireless connectivity, XR / media processing, and power supply, to be provided by one or more devices, wearables, actuators, controllers, and / or accessories.One or more devices / nodes / WTRUs can be grouped into a collaborative XR group to support any XR application / experience / service.

[076] In XR services and applications, traffic can consist of data / PDUs that may be associated with an application data unit (ADU), a set of PDUs, or a data burst. For example, PDUs belonging to a set of PDUs may be associated with different segments or components of a video frame or video slice. A data burst may consist of one or more sets of PDUs that may be transmitted / received over a time window. For example, the number of PDUs in a set of PDUs or a data burst transmitted in UL and / or received in DL may depend on the media frame type (e.g., media frame). Petition 870250088293, dated 09 / 29 / 2025, p. 37 / 140 27 / 106 3D video, audio frame).

[077] In an XR application, for example, a typical XR application, a WTRU can transmit XR traffic consisting of one or more PDUs / sets of PDUs on an uplink (UL) (e.g., pose, gesture, video data) and / or can receive XR traffic on a downlink (DL) (e.g., video, audio, tactile). This traffic can be transmitted and / or received periodically or aperiodically in one or more data streams (e.g., Quality of Service (QoS) streams). During UL transmissions, XR traffic can arrive from the application layer on a WTRU and / or from different devices / endpoints / WTRUs (via side link) at different time instances. This XR traffic can be characterized by different traffic attributes, such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable priority / importance per PDU / PDU set, and different levels of interdependencies between PDUs / PDU sets.This XR traffic (e.g., PDU / PDU sets) received by the WTRU from upper layers or other devices / endpoints may also exhibit different delays, jitter, data rate, and loss rate. To ensure that QoS (e.g., PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), PDU Set Integrated Handling Indication (PSI HI)) is met, prioritization, multiplexing, scheduling, and resource allocation can be performed in a timely manner, considering the attributes of the PDU set. To ensure Quality of Experience (QoE), PDUs within a PDU set or different PDU sets generated on the application's transmit side are expected to be delivered to the application's receive side within a QoS (e.g., PDU Set Delay Budget (PSDB), PDU Set Integrated Handling Indication (PSI HI)).

[078] In XR traffic, different PDUs or sets of PDUs can contribute to different user experiences (e.g., QoE). In this way, Petition 870250088293, dated 09 / 29 / 2025, page 38 / 140 28 / 106 PDUs / PDU sets can be associated with different importance / priority values ​​from the application layer perspective. It may also be that one or more sets of PDUs transmitted sequentially in the time domain may be interdependent on each other in different ways. In other words, unlike the existing QoS structure, where all PDUs / PDU sets in a flow can receive the same forwarding treatment, assuming equal importance / priority, PDUs / PDU sets in a data burst for XR traffic may, for example, need to be differentiated and treated differently in terms of QoS at lower layers, for example, regardless of whether the PDUs / PDU sets are in one or more QoS flows, during scheduling and transmissions in UL and / or DL.

[079] The interdependencies between PDUs / PDU sets in one or more QoS streams can result in different challenges to meeting QoS at the PDU set level during transmission in UL and DL. For example, if PDUs from different PDU sets can be multiplexed on the same radio channel or logical channels and subsequently mapped to different occasions / slots / periods in the resources (e.g., CG), tracking the association between the PDUs to meet the PDU set QoS level can be challenging if, for example, there are delays and flicker during reception and processing.Systems that ensure proper mapping and / or multiplexing of PDUs / PDU clusters to one or more configured resources across time and frequency domains, such as push occasions or resource block groups (RBGs), considering traffic characteristics (e.g., delays and jitter during PDU / PDU cluster reception over SL or higher layers, variable payload sizes, and variable priority / importance) to meet PDU cluster-level QoS during UL transmissions are unknown. Petition 870250088293, dated 09 / 29 / 2025, page 39 / 140 29 / 106

[080] A WTRU supporting an XR experience may be receiving data units (e.g., PDUs, sets of PDUs, or bursts of data) from higher layers or different devices, such as AR glasses and haptic gloves (e.g., via SL). These data units, which may have varying payload sizes, different periodicity, and different interdependencies, may be further processed and transmitted by the WTRU in the UL. To avoid latency during resource scaling during the UL transmission of data units, the WTRU may be configured with configured leases (CG).

[081]

[0081] In configured systems, grants can support the configuration of a single PUSCH occasion per slot in a CG period. Enhancements for XR can include support for CG with multiple PUSCH occasions per CG period. This CG configuration can be used to transmit XR data units (e.g., PDU sets) of larger payload sizes with low latency. Enhancements can be provided for WTRU to dynamically indicate any unused PUSCH occasions.

[082] As a result of delays and jitter, which may be, for example, variation with respect to a periodic arrival of data, during the reception and processing of data in the WTRU (e.g., from application / upper layers or other device / UE over SL), some of the PDUs within and / or between sets of PDUs may be delayed and unable to be transmitted on time, even if the WTRU may be configured with CG with multiple PUSCH occasions per CG period (multi-PUSCH CG).

[083] WTRU can transmit an indication of any unused CG PUSCH occasions for the network. But indicating the use of PUSCH based, for example, only on the data payload in the WTRU buffers without considering the general XR traffic attributes / patterns (e.g., arrival of the PDU / PDU set, Petition 870250088293, dated 09 / 29 / 2025, p. 40 / 140 30 / 106 remaining delay, jitter) can result in failure to meet the associated QoS and inefficient use of resources, as WTRU may inaccurately indicate a higher PUSCH usage than actually used during UL transmission.

[084] Indicating the expected usage of PUSCH (e.g., a number of PUSCH resources used / not used) too early may result in resource unavailability and additional delays for the WTRU, as the network may reallocate the configured PUSCH resources to other WTRUs. Indicating too late may not be helpful, as the network may not have enough time to reallocate the resources to other WTRUs.

[085] One issue to be addressed includes how to guarantee QoS of XR data units (e.g., PDUs, PDU sets, and data bursts) using multi-PUSCH CG while considering XR traffic attributes (e.g., remaining delay, reliability, jitter). Another issue to be addressed includes how to indicate CG resource usage to the network in a timely manner to improve resource utilization efficiency.

[086] The transmission of PUSCH usage indication over a time window or period may be provided. A WTRU may receive configuration information which may include, for example, a multi-PUSCH CG configuration, which may be called a CG configuration. The WTRU may receive, for example, from a higher layer, PDUs from a set of PDUs.

[087] The WTRU can receive a PUSCH usage request from a network device (NW), for example, in DCI (down-link control information). The PUSCH usage request can include, for example, a time window, which can be called a time period, associated with the PUSCH usage. The time window can be indicated by an initial PUSCH offset occasion and duration within which the WTRU can indicate the number and location of the PUSCHs used / not used. Petition 870250088293, dated 09 / 29 / 2025, page 41 / 140 31 / 106

[088] WTRU can determine the remaining delay of PDUs based on the arrival time of PDUs (e.g., time elapsed since the arrival of the first PDU in the LCH buffer) and the PSDB.

[089] WTRU may determine the use of PUSCH (e.g., a number and locations of PUSCH occasions) over the time window based on one or more of the following: a payload of multiplexed PDU(s) in one or more PUSCH occasions is less than (<) a payload threshold (e.g., a percentage of the total payload of the PDU set); and a remaining PDU delay from the PDU set is less than (<) a delay threshold (e.g., WTRU may determine a PUSCH occasion as unused if the remaining delay is above the delay threshold and the PDU can be delayed to a later slot / period).

[090] WTRU can transmit an indication about the use of PUSCH (for example, a first N of M configured PUSCH occasions) over the time window on the first PUSCH occasion.

[091] WTRU can transmit PDUs using the indicated PUSCH occasions.

[092] A CG muting pattern can be provided for use with CG PUSCH. A WTRU can receive configuration information, including, for example: a CG configuration for multiple PUSCH; a set of one or more CG muting patterns (e.g., each muting pattern can indicate a subset of CG PUSCH occasions and a location of the PUSCH occasions that can be muted / not used in a time window); criteria for selecting the one or more CG muting patterns (e.g., minimizing the number of non-matching occasions); and threshold values ​​associated with payload size, remaining delay, and / or number of repetitions.

[093] A WTRU can receive, for example, PDUs from higher layers. Petition 870250088293, dated 09 / 29 / 2025, page 42 / 140 32 / 106 sets of PDUs. WTRU can determine the pattern of PUSCH usage (e.g., the number and location of PUSCH occasions used) based on the PDUs received from the PDU set and one or more of the following criteria: a payload of multiplexed PDU(s) in a PUSCH occasion is above a first payload threshold value and / or below a second payload threshold value (per PUSCH occasion); a remaining delay of a PDU set is less than or equal to a delay threshold value (associated with PSDB (PDU set delay budget)); and / or a number of repetitions per PDU of a PDU set is above a first repetition threshold value and / or below a second repetition threshold value (associated with PSER (PDU set error rate)).

[094] WTRU may select one or more CG muting patterns from the configured set based on the determined PUSCH usage pattern and one or more of the following criteria: minimize the number of unmatched occasions (e.g., a number of PUSCH occasions used in the traffic pattern that do not match the unmuted occasions) in each CG muting pattern relative to the determined PUSCH usage pattern; and / or WTRU may combine multiple CG muting patterns (e.g., pattern merging) that may result in meeting the criteria.

[095] WTRU can transmit an indication containing the index(es) for the selected CG muting pattern(s).

[096] A WTRU-assisted selection of FDRA (frequency domain resource allocation) configuration for multi-PUSCH CG (multiPUSCH CG) can be provided. A WTRU can receive configuration information that may include, for example: at least one multi-PUSCH CG configuration; and / or one or more FDRA sub-configurations and parameters associated with the sub-configurations (e.g., initial RBG offset, number of RBGs per FDRA sub-configuration, information on association with a group of occasions of Petition 870250088293, dated 09 / 29 / 2025, page 43 / 140 33 / 106 (PUSCH during a CG period). At least one of the FDRA subconfigurations can be configured as a default FDRA subconfiguration.

[097] A WTRU can receive PDUs from higher layers, as sets of PDUs.

[098] WTRU can determine the FDRA subconfiguration for a group of PUSCH occasions and the PUSCH usage information (e.g., number of PUSCH occasions used / not used) for a set of PUSCH occasions based on one or more of the following criteria: a multiplexed PDU payload(s) in a PUSCH occasion with default FDRA subconfiguration is above a first payload threshold value and / or below a second payload threshold value (e.g., per PUSCH occasion); a remaining delay of a set of PDUs is less than or equal to a delay threshold value (e.g., associated with PSDB); a number of repetitions per PDU of a set of PDUs is above a first repetition threshold value and / or below a second repetition threshold value (e.g., associated with PSER).

[099] WTRU can transmit an indication containing the selected FDRA subconfiguration and PUSCH usage information for the set of PUSCH occasions.

[0100] The WTRU may receive (e.g., in DCI) an activation indication in the selected or new FRDA subconfiguration and / or a deactivation indication for the default FDRA subconfiguration for the corresponding set of PUSCH occasions.

[0101] WTRU can transmit PDUs from a set of PDUs using resources on occasions when FDRA subconfiguration is enabled and CG PUSCH is enabled.

[0102] A time offset of push occasions can be provided in CG configuration for multiple pushes. A WTRU can receive configuration information comprising, for example: a CG configuration for Petition 870250088293, dated 09 / 29 / 2025, page 44 / 140 34 / 106 multiple PUSCH events; and a mapping relationship between the jitter interval and the initial offset of a group of multi-PUSCH events in a CG period.

[0103] A WTRU can receive, for example, from a higher layer, a first batch or plurality of PDUs from a set of PDUs.

[0104] The WTRU can determine an initial set of PUSCH occasions (e.g., a number of PUSCH occasions to be used) to transmit the first batch of PDUs based on the payload sizes of the PDUs.

[0105] The WTRU can determine the jitter interval for receiving a second plurality or batch of PDUs from the PDU pool based on the arrival time of the first plurality / batch of PDUs and the remaining time associated with PSDB.

[0106] WTRU can determine a new initial offset for a second group of PUSCH occasions to transmit the second plurality / batch of PDUs based on the jitter interval and mapping relationship (e.g., between the jitter interval and the initial offset).

[0107] WTRU can transmit an indication (e.g., in CG-UCI) about the new start offset of the second group of PUSCH occasions and the first batch of PDUs in the first group of PUSCH occasions.

[0108] WTRU may trigger SR / BSR (Stagger Request / Buffer Status Report) for DG (Dynamic Grant) based on one or more of the following conditions: a subset of a second group of PUSCH occasions after the application of the new initial offset is greater than (>) a slot threshold; a delay to transmit the second batch of PDUs in a subsequent slot is greater than (>) PSDB; a total payload size of a second plurality / batch of PDUs is greater than (>) the size of a second group of PUSCH occasions within the slot threshold after the application of the new initial offset.

[0109] WTRU may receive (for example, in DCI) a confirmation indication of a new start shift for the second group of occasions of Petition 870250088293, dated 09 / 29 / 2025, p. 45 / 140 35 / 106 Push and / or DG resources.

[0110] The WTRU can receive, for example, from higher layers, the second plurality / batch of PDUs from the set of PDUs.

[0111] The WTRU can transmit the second plurality / batch of PDUs in the second set of PUSCH occasions with a new start offset.

[0112] In examples, the network may include any of a base station (e.g., gNB, TRP, RAN node, access node), core network function (e.g., AMF, SMF, PCF, NEF) and an application function (e.g., edge server function, remote server function), for example.

[0113] In examples, flows can correspond to any of the QoS flows or data flows (e.g., data flow consisting of one or more PDUs, sets of PDUs, or data bursts, which may be interdependent with each other and / or associated with one or more QoS requirements, e.g., latency, data rate, reliability, or RTT latency). Different flows, possibly originating from a common application / experience source and / or destined for a common target device / WTRU or group of associated devices / WTRUs, may be called associated flows or correlated flows.

[0114] In examples, a data unit may refer to any of the following: one or more frames (e.g., media / video / audio frame or slice / segment); PDUs; sets of PDUs; data bursts; and / or group of frames / PDUs / sets of PDUs / data bursts. These data units, which may be transmitted or received by the WTRU, may be sequential (e.g., one after the other) or in parallel (e.g., through different channels / links / resources), and may or may not be interdependent with each other.

[0115] In examples, QoE can correspond to any of the following: application and / or top-layer metrics and measurements, which may be directly or indirectly detectable / visible in the WTRU and / or application function. These metrics Petition 870250088293, dated 09 / 29 / 2025, p. 46 / 140 36 / 106 and QoE measurements may or may not be directly visible / detectable at the base station, for example. These metrics and QoE measurements can be determined / executed as a function of QoS metrics / parameters (e.g., latency, data rate, reliability, RTT / MTP latency).

[0116] In examples, the forwarding configuration may correspond to any of the following: radio bearers (e.g., data radio bearers (DRBs) and / or signaling radio bearers (SRBs)); logical channels (LCHs); logical channel groups (LCGs); configuration parameters in the individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, other new protocol layers); configuration to be applied to assign COUNT / SNs to PDUs / PDU sets / data bursts; parameters associated with logical channel prioritization (LCP) (e.g., priority, PBR, BSD); BWPs; carriers; radio links / interfaces (Uu links, SLs); and radio resources (e.g., a set of one or more frequency / time / space resources, such as symbols, slots, subcarriers, resource elements or bundles).Radio resources can be associated with configured grants (CG), dynamic grants (DG), and / or any other resource grants or grant-free resources.

[0117] In examples, the mapping configuration may correspond to any of the following: parameters and / or settings associated with the mapping of one or more data units, PDUs, SDUs, sets of PDUs, data bursts, application data units (e.g., ADD), QoS, or data streams (e.g., associated or unassociated), which may originate from any application layer, upper layers, and network, on the one hand; and one or more radio carriers (e.g., DRBs, SRBs), sublayers, or entities (e.g., Petition 870250088293, dated 09 / 29 / 2025, p. 47 / 140 37 / 106 example, SDAP, new layer, PDCP, RLC, MAC, PHY), LCHs, carriers or component carriers (e.g., CCs in CA configurations), BWPs, CG configurations / features (e.g., CG periods, slots, PUSCH occasions, RBGs), HARQ processes, and radio links / interfaces (e.g., Uu link or side links), which can be used to deliver the data / PDUs in the UL direction or in the DL direction, for example.

[0118] In examples, a multi-PUSCH CG may correspond to one or more configured features or configured grant (CG) configurations, where each CG configuration may consist of a set of consecutive or non-consecutive PUSCH occasions per slot and / or per CG period. In examples, the following may apply: a multi-PUSCH CG may consist of one or more CG periods (e.g., each CG period may repeat periodically with a certain periodicity value); a CG period in a multi-PUSCH CG may consist of one or more consecutive or non-consecutive slots; a slot in a CG period of a multi-PUSCH CG may consist of one or more consecutive or non-consecutive PUSCH occasions; a PUSCH occasion in a slot / CG period of a multi-PUSCH CG may consist of one or more consecutive or non-consecutive symbols with a certain symbol length (e.g., time domain features).A push event can consist of one or more resource blocks or groups of resource blocks in the frequency domain.

[0119] In examples, the use of PUSCH may refer to any number, location, position, or time of one or more PUSCH occasions in one or more intervals or periods, which may be associated with one or more multi-PUSCH CG configurations.

[0120] In examples, the following definitions of traffic requirements and characteristics can be applied. The PDU Set Delay Budget (PSDB) can indicate the time between receiving the first PDU (e.g., at the WTRU in UL) and the Petition 870250088293, dated 09 / 29 / 2025, pp. 48 / 140 38 / 106 successful delivery of the last PDU from a set of PDUs (e.g., in the UL network). The PDU Set Integrated Handling Indication (PSI HI) can indicate whether all PDUs in the PDU Set may be required for the application layer to use the PDU Set; the PDU Set Error Rate (PSER) indicates an upper limit for a non-congestion-related PDU Set loss rate between the RAN and WTRU. Jitter can refer to the variation from an expected time instance during which one or more data units may be received or transmitted.For example, for a set of data units that can be expected to be received periodically at different periodic time instances, jitter can refer to the variation relative to the periodic time instances (e.g., for a data unit that can be received T1 ms before or T2 ms after an expected time instance at T, the jitter interval is T2 - T1). Jitter can refer to an instantaneous value or a statistical value (e.g., mean, variance, standard deviation, max. / min.). Remaining delay can refer to the time remaining to receive or transmit one or more PDUs from a set of PDUs before the PSDB. Remaining delay can also be called the time-to-live (TTL) associated with a set of PDUs.

[0121] In examples, XR / application-aware data transmissions / receptions or XR / application-aware QoS handling may correspond to any of the following: attributes associated with the PDU set, ADU, or data burst; a set of PDUs; a data burst; application importance / priority / high tier; and / or QoS / data stream.

[0122] With respect to the attributes associated with the PDU set, ADU, or data burst, a PDU set (e.g., media unit, video frame) may comprise one or more PDUs. These PDUs within a PDU set or PDU sets within a data burst may be interdependent. Petition 870250088293, dated 09 / 29 / 2025, p. 49 / 140 39 / 106 teeth together in the application layer and / or lower layers (e.g., AS layers). Such attributes may include any of the following, for example, the number of PDUs in a set of PDUs / data bursts, payload sizes of one or more data units (e.g., PDUs / set of PDUs / data bursts), the association / correlation between one or more data units, importance / priority of data units, transmission status (e.g., percentage of PDUs from one or more data units successfully transmitted / received), remaining delay for transmission / receipt of one or more PDUs within a data burst / set of PDUs delay limit(s), effective data rate and / or effective reliability associated with the transmission of PDUs from one or more sets of PDUs / data bursts.In one example, such attributes associated with data units may be visible in one or more lower layers (e.g., in PDCP, RLC, MAC, PHY sublayers / layers), possibly to support additional actions (e.g., prioritize, map to an LCH, multiplex into one or more TBs, schedule, trigger / transmit an indication) based on any of the following: markings on the data units; receiving an indication, such as a control PDU; mapping of data units from a higher layer to a configuration associated with a lower layer; tracking of PDU attributes in any buffer associated with the sublayer, radio carrier, and / or logical channel; and / or constraints associated with the sublayer, radio carrier, and / or logical channel to which the data units may be mapped.

[0123] With regard to markings on data units, such markings may include, for example, sequence numbers, IDs, indexes, timestamps, and time offset values ​​(e.g., relative to a reference time) in the header of the data units. These markings may be made by higher layers, any sublayer / previous layer, or another device / WTRU. Petition 870250088293, dated 09 / 29 / 2025, p. 50 / 140 40 / 106

[0124] With regard to receiving an indication, such as a control PDU (e.g., application / upper layer / NAS indication, PDCP control PDU, RLC control PDU, MAC CE, DCI / UCI), such an indication may be received by a WTRU from a higher / lower layer, from another device / WTRU (e.g., over SL) and from the network, for example.

[0125] With regard to mapping data units from a higher layer to a configuration associated with a lower layer, the WTRU can have visibility of higher layer attributes in a lower layer by mapping PDUs to one or more radio carriers or logical channels (LCHs) that can be configured to provide similar routing treatment associated with the higher layer attributes for the mapped PDU.

[0126] With regard to tracking PDU attributes in any buffer associated with the sublayer, radio carrier and / or logical channel, WTRU can track attributes associated with data units based on any elapsed time since the reception of a first PDU from a set of PDUs, the time remaining for the PDUs in a set of PDUs to meet the PSDB, jitter between the arrival of one or more PDUs within / through the sets of PDUs and / or percentage / size of the payload of the remaining PDUs from a set of PDUs that are expected to be received.

[0127] With respect to the restrictions associated with the sublayer, radio carrier, and / or logical channel to which data units can be mapped, the WTRU can have visibility of the data units and determine the corresponding actions (e.g., perform prioritization by LCP, perform mapping for restricted CG configurations, CG periods, or PUSCH occasions with configured grant (CG)) based on the configured restrictions associated with one or more sublayers, radio carriers, and / or LCHs to which data units can be mapped. Petition 870250088293, dated 09 / 29 / 2025, p. 51 / 140 41 / 106

[0128] A set of PDUs can be associated with PDU-level QoS requirements (e.g., data rate, latency, error rate, reliability), which may be applicable to one or more or all of the PDUs associated with a PDU set. The different PDUs in a PDU set may be associated with individual PDU-level QoS requirements.

[0129] A data burst can refer to data produced by the application in a short period of time, comprising PDUs from one or more sets of PDUs. Such attributes, associations, and interdependencies (e.g., intra-PDU set and / or inter-PDU set), including start / end indication of a PDU set / data burst (e.g., via sequence number, start / end indication), start / end time, duration, payload sizes, periodicity, importance / priority, and QoS (e.g., PSDB) can be visible to AS layers (e.g., with associated IDs) and / or manipulated in AS layers with knowledge of the association during data transmission in UL and reception in DL.

[0130] Application / high-layer importance / priority can refer to different PDUs within a PDU set, or all PDUs within a PDU set can be associated with different application / high-layer importance / priority values. This importance value can correspond to spatial importance (e.g., spatial position of the video frame whose data can be carried by the PDU / PDU set, where PDUs / PDU sets carrying FoV spatial positions may be associated with greater spatial importance than non-FoV spatial positions) or temporal importance (e.g., temporal sequence of the video frame / application whose data can be carried by the PDU / PDU set, where PDUs / PDU sets carrying base video frames, such as l-frame, may be associated with greater temporal importance than differential video frames, such as P-frame / B-frame). These importance values Petition 870250088293, dated 09 / 29 / 2025, p. 52 / 140 42 / 106 cia may be visible to AS layers (e.g., with associated IDs / markers / indicators), possibly enabled by application awareness, during data transmission and reception.

[0131] QoS / data stream can refer to the PDUs / sets of PDUs of an application that can be encoded and delivered by the application to the WTRU (in UL) or network (in DL) via one or more QoS / data streams. The different QoS streams that carry the PDUs / sets of PDUs associated with an application / XR experience can be visible to the AS layers (e.g., with associated IDs) and / or handled in the AS layers with knowledge of the association during data transmission and reception.

[0132] WTRU actions or WTRU behavior, possibly related to application actions and / or AS layer actions, may correspond to one or more of the following: determination of content or metadata of an application; execution of measurements and reports; transmission / forwarding of data units and / or guarantee of QoS associated with data units; and / or transmission / forwarding of information / indications associated with network connectivity and / or other WTRUs.

[0133] With regard to determining the content or metadata of the application (e.g., XR application), determining the content or metadata may involve determining the importance and / or priority of the content in the data units. Importance may be associated with the spatial and / or temporal importance of the content / data. The value of spatial / temporal importance may indicate the absolute or relative importance associated with the content. Spatial importance may be associated with one or more segments / blocks / slices / positions in the spatial dimension. Temporal importance may be associated with one or more frames / subframes in the temporal dimension. Petition 870250088293, dated 09 / 29 / 2025, page 53 / 140 43 / 106

[0134] With regard to measurement and reporting, the WTRU may perform positioning / spatial / pose measurements (e.g., 6DoD / 3DoD orientation, location / position), motion rate / movement, etc. of the user / WTRU and / or other objects (e.g., virtual or real) with which the user may be interacting. The WTRU may send / report pose measurements to the network periodically or upon detecting event triggers (e.g., change in pose measurements above / below a threshold). The WTRU may perform measurements of one or more reference signals or channels (e.g., SSB, CSI-SR, PRS, side link RS), GNSS signals, unlicensed carriers, ultra-wideband signals, LIDAR signals, visual signals, etc. The WTRU may perform measurements of radio link interfaces associated with the WTRU (e.g., Uu link, SL).A WTRU can trigger the transmission and / or measurement of reference signals in one or more other WTRUs (e.g., via Uu link and / or side link). Measurement reports can be sent, for example, to a network and / or another WTRU.

[0135] With regard to the transmission / forwarding of data units and / or QoS guarantee associated with data units, data units may include any of the media / image / video frames, sensor data, and measurement data (e.g., pose measurements, link / channel measurements) determined by a WTRU, possibly to support an application / service / network request associated with the WTRU. For example, the WTRU may send and / or receive data to / from one or more destinations / entities, including another WTRU / device (e.g., via SL), RAN node (e.g., gNB), CN function / entity, application function (e.g., hosted on the WTRU or on the network). The WTRU may perform data unit splitting / merging into one or more QoS streams in one or more routing configurations during transmissions / receptions.

[0136] The transmission / forwarding of information / indications associated with connectivity to the network and / or other WTRUs may include sending Petition 870250088293, dated 09 / 29 / 2025, p. 54 / 140 44 / 106 capacity information for a network, including a capacity to support one or more traffic flows with different XR traffic patterns (e.g., periodic / aperiodic PDU sets with varying payload sizes), a capacity to perform application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements), and / or a capacity to detect changes in traffic patterns. Information / indication transmission / forwarding may comprise the transmission of coordination capacity information between WTRUs for a network, including a capacity to support one or more interfaces, a capacity to coordinate and / or interact with other WTRUs / devices (e.g., via SL interfaces), which may or may not be colocated with the WTRU.Information / indication transmission / forwarding may include the transmission of RACH preamble(s) for initial access or to (re)establish connectivity with a RAN node, cell, or other WTRU. Information / indication transmission / forwarding may include receiving configuration, including receiving gNB RRC configuration and / or CN NAS layer configuration. Information / indication transmission / forwarding may include the transmission and / or reception of assistance data to / from the network associated with traffic, QoS, scheduling, etc., to support UL / DL transmissions. Information / indication transmission / forwarding may include the transmission of radio resource requests and / or resource grants (e.g., dynamic grants, semi-static / configured grants).

[0137] Implementations to meet QoS when configured with multi-PUSCH CG can be provided. Data units consisting of any PDU, set of PDUs, or data bursts associated with XR traffic can be marked by WTRU (in UL at the SDAP, PDCP, RLC, and MAC layers) and transmitted with multi-PUSCH CG with one or more of the following: Sequence numbers Petition 870250088293, dated 09 / 29 / 2025, p. 55 / 140 45 / 106 (SNs): SNs can be marked by PDUs, by PDU set, or by data burst, where different types of SNs can include COUNTS, hyperframe numbers (HFNs), and PDU SNs; QoS attributes: QFI, PSER, PSDB, PDU set integrated handling indication (PSI HI) (e.g., a flag indicating whether all PDUs in a PDU set can be delivered); PDU set attributes: type, total payload size (e.g., bits / bytes, number of PDUs), initial PDU of a PDU set / data burst, final / last PDU of a PDU set / data burst (end marker);and / or timing / counting information: Timestamp indicating when a PDU can be generated or received in a buffer, remaining delay relative to a delay budget (e.g., PSDB), hop count (e.g., a number of hops traversed or remaining), time offset relative to a reference time (e.g., SFN, arrival time of the first PDU in the set of PDUs).

[0138] Such marking (for example, in PDU headers) may be used by transmitting and / or receiving entities to perform certain actions associated with any of the following: determining whether data units can be prioritized and / or multiplexed into one or more TBs, the number of TBs that can be used, whether data units can be delivered in one or more slots / periods, whether data units can be delayed to subsequent slots / periods, a number of repetitions that can be applied to the data units or a subset of the data units.

[0139] Data units consisting of any PDU, PDU set, or data bursts associated with XR traffic, with the same or different QoS requirements / characteristics, can be mapped to one or more forwarding configurations using mapping configurations. Different forwarding configurations can be configured to achieve / enforce different QoS when transmitting PDUs / PDU sets with multi-PUSCH CG. The sets of Petition 870250088293, dated 09 / 29 / 2025, page 56 / 140 46 / 106 PDUs received from the application in one or more QoS streams can be mapped using a mapping configuration (e.g., in SDAP, PDCP) to one or more forwarding configurations (e.g., DRBs with common / different PDCP entities or LCHs with different configurations), where the forwarding configurations can possibly be associated / grouped to achieve / enforce PDU set-level QoS. In the mapping, a set of parameters (e.g., priority, PBR, BSD) and / or configurations (e.g., LCP restrictions) can be applied to the forwarding configurations to achieve / enforce PDU set-level or data burst-level QoS for the PDUs / PDU sets in the buffers associated with the forwarding configurations.

[0140] It may be possible that PDUs from different PDU sets or PDU sets from a data burst received from application / higher layers may have different expected QoS (e.g., remaining delay) to be satisfied during transmission. Based on the determination of the expected QoS for the PDUs / PDU sets received or to be received in QoS streams, the WTRU can apply certain mapping, buffer / queue management, and adaptation mechanisms in one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC) so that the expected QoS for the PDUs / PDU sets can be satisfied. A similar approach can be applied if the WTRU expects to receive any of the PDU sets / PDUs in DL from the network. To guarantee the QoS of the data units, the different layers in the routing configuration can be configured with different configuration parameters.These configuration parameters may include support for PDU / PDU set reordering in PDCP, AM / UM support in RLC, LCP rules / constraints and associated LCH parameters (e.g., PBR, BSD, priority) in MAC, and HARQ transmission number. Petition 870250088293, dated 09 / 29 / 2025, page 57 / 140 47 / 106

[0141] The term Expected QoS can be used to denote the expected margin of a given QoS metric (e.g., latency, data rate, reliability) before the arrival of data consisting of any PDU, sets of PDUs, and data bursts, or when data may be received in one or more buffers / sublayers in the WTRU. Expected QoS corresponds to a duration of time available in the WTRU from reception (e.g., from upper layers or another WTRU / device) until successful delivery of data over the radio link (e.g., Uu link or side link). Expected QoS can also correspond to the remaining delay or time to live (TTL) (e.g., maximum time available for buffering, processing, and delivery) for an individual PDU, set of PDUs, or data burst.Expected QoS can be determined based on indicators / markers on PDUs / PDU sets (e.g., QFI, timestamps, start / end markers, PDU set ID / index in the PDU / PDU set packet headers), based on an indication from higher / previous layers (e.g., control PDU), based on the use of timers that can be set upon receiving PDUs / PDU sets (e.g., arrival of the first PDU in the PDU set) and restarted / stopped at the end of a configured time duration, for example. Similar mechanisms (e.g., based on indicators / markers and / or timers) can be applied to change different mapping and / or forwarding configurations to ensure expected QoS.

[0142] The expected QoS may be more stringent or relaxed than the standard QoS metric applied to the PDUs / PDU clusters. For example, if a PDU cluster arrives late in the WTRU or the importance value for the PDU cluster is indicated as high (e.g., above a threshold), having experienced more latency and jitter in the application layer (e.g., due to Petition 870250088293, dated 09 / 29 / 2025, p. 58 / 140 48 / 106 encoder) or reception over SL (e.g., due to congestion), the expected latency to be satisfied during transmission over the Uu link for the set of PDUs will be less than the standard PSDB that can be used, for example, can normally be used, to send the PDUs of the set of PDUs. If a set of PDUs arrives earlier or the importance value for the PDU is indicated as low (e.g., below a threshold), the expected latency during transmission over the Uu link can be considered more relaxed than the PSDB that can be used, for example, can normally be used, to send such PDUs.In examples, the expected QoS can vary dynamically based on the QoS experienced during reception and / or indications of importance / priority, where for a fixed QoS (e.g., PDB, PER, PSDB, PSER), an increase / decrease in expected QoS before reception can translate into a decrease / increase in expected QoS during transmission / reception over the radio link (e.g., Uu, SL link).

[0143] WTRU actions when configured with multi-PUSCH CG can be provided. In examples, WTRU can be configured with multi-PUSCH CG to support transmission and / or reception of data units consisting of any PDU, sets of PDUs and data bursts in one or more streams in UL and / or DL, while meeting the QoS associated with the data units.

[0144] WTRU can assist the network in configuring and / or indicating the use of resources associated with multi-PUSCH CG based on any of the following: configurations; trigger events; and / or conditions / criteria received from a network and / or application. WTRU can be configured with one or more conditions and / or configurations associated with the use of multi-PUSCH CG during UL transmissions. Such conditions and / or configurations may be related to, or may reflect, an expected QoS to be achieved for the data units during UL transmission or upon detecting a change in that expected QoS.

[0145] A WTRU can transmit service information associated with Petition 870250088293, dated 09 / 29 / 2025, p. 59 / 140 49 / 106 Multi-PUSCH CG to the network. WTRU may send information associated with multi-PUSCH CG to the network, including any information to configure one or more CG configurations with multi-PUSCH occasions / features on WTRU, information related to the use of multi-PUSCH CG configurations (e.g., a number of PUSCH occasions used or not used by WTRU), and information to make adaptations to the multi-PUSCH CG configurations. The information sent by WTRU to configure or indicate the use of multi-PUSCH CG may be associated with XR traffic (e.g., PDU / PDU cluster periodicity, PDU cluster payload sizes, PDU association with PDU clusters) that must be transmitted in UL or received in DL. This information may allow the network to be aware of the traffic characteristics and configure / adapt the features associated with multi-PUSCH CG on WTRU.In examples, such information associated with the multi-PUSCH CG can be transmitted by the WTRU to one or more other WTRUs (e.g., via SL) if the WTRUs can be associated with a common group or XR experience.

[0146] Information / indications related to the configuration, use, or adaptations associated with the multi-PUSCH CG can be sent by the WTRU to the network or other WTRUs as one or more of the following message types: capacity information; support information; preferred / desired configuration information (e.g., preferred routing and / or resource configurations / parameters to be applied in UL / DL); status information / indications (e.g., associated with any of the AS layers); resource usage information (e.g., expected resource usage or PUSCH occasions); measurement / status reports (e.g., data pending in buffer, data expected to be received, remaining delay, jitter); and / or request / response messages (e.g., request to activate / deactivate a CG configuration or parameter set associated with the multi-PUSCH CG, request for time resources). Petition 870250088293, dated 09 / 29 / 2025, pp. 60 / 140 50 / 106 frequency, request for parameter adjustment / configuration of the multiPUSCH control center).

[0147] Information can be sent by the WTRU in any of the following methods: periodically (for example, using one or more configured periodicity values); aperiodically or dynamically (for example, upon detecting triggering events / conditions described in the present invention or as an update indication upon detecting a change in previously sent information); and / or semi-persistent (for example, sent periodically with a periodicity value or intermittently over a time / duration window).

[0148] The WTRU can switch between a first periodicity value and a second periodicity value to send information, possibly based on the type of event detected (e.g., change in the type of PDU set to be transmitted in UL, buffer occupancy delay is greater than a threshold value, remaining delay for PDU set is less than a threshold value). The WTRU can switch between periodic and aperiodic sending of information, depending on whether any change and / or amount of change is determined in the information to be reported.

[0149] The WTRU can send the information / indications associated with the multi-PUSCH CG to the network through, for example, one or more of the following message types: Signaling and / or RRC messages (e.g., via SRBO, SRB1, SRB2, SRB3, SRB4); Control PDUs associated with any of the AS layers (e.g., SDAP (Service Data Adaptation Protocol) control PDU, PDCP control PDU, RLC control PDU); UL MAC CE (e.g., new MAC CE, regular BSR, periodic BSR, filling BSR, enhanced BSR, preventive BSR, delay status report (DSR) which may include remaining delay information and / or elapsed time since data arrived in the buffer, elastic BSR which may be scalable / adjustable by sending subsequent indications, possibly without canceling a previous BSR); UCI (e.g., single-bit SR, multi-bit SR, Petition 870250088293, dated 09 / 29 / 2025, p. 61 / 140 51 / 106 feedback, ACK / NACK, CSI report); CG-UCI (e.g., one or more bitmaps or parameter set such as initial offset and number of PUSCH occasions); PUSCH (e.g., indication of how CG-UCI can be multiplexed into PUSCH along with data); non-AS layer (NAS) signaling (e.g., PDU session-related messages); and / or application layer signaling / messages.

[0150] The information / indications associated with multi-PUSCH CG, sent by the WTRU to the network or other WTRUs, may include a combination of one or more of the following: Identifiers / IDs; resource / configuration priority or CG data; application-associated devices; data / traffic types associated with data flows; traffic characteristics and / or parameters associated with any QoS flows, PDU sets, and data bursts; buffer information at application layers / upper layers / AS layers; QoS requirements or expected QoS associated with the data; CG resource usage; preferred / desired configuration information; information about updated forwarding configurations applied in the WTRU; indication to enable / disable configurations; and / or measurements related to the application / AS layer.

[0151] With regard to identifiers / IDs, WTRU may send one or more IDs / indexes including, for example, one or more of the following: IDs associated with an application (e.g., application ID, service ID, session ID, application configuration ID); IDs / indexes associated with CG configurations / features (e.g., TDRA, FDRA, CG periods, PUSCH occasions, BWP); IDs / indexes associated with traffic patterns (e.g., a traffic pattern may indicate the occasions / slots over a time period / window when there may or may not be data to transmit); IDs / indexes associated with CG muting patterns (e.g., a muting pattern may indicate the occasions / slots over a time period / window when there may not be any feature / occasion). Petition 870250088293, dated 09 / 29 / 2025, page 62 / 140 52 / 106 PUSCH configured); IDs associated with HARQ processes (e.g., HARQ process IDs associated with one or more PDUCH instances, TBs, PDUs, or PDU sets); Group ID (e.g., associated with a routing configuration group, device group / WTRUs); Individual QoS flow IDs, mapping configurations, and / or routing configurations; Data Unit Types / Message IDs and / or SNs (e.g., Data Burst ID, PDU Set ID, PDU ID); and / or Association ID (e.g., IDs or SNs that indicate association and / or dependency between one or more PDUs, PDU sets, data bursts, and / or flows).

[0152] With regard to the priority of CG resources / configurations or data, a WTRU may comprise information about the relative / absolute priority values ​​associated with one or more CG PUSCH occasions or CG periods, and data that is expected to be mapped to the PUSCH occasions / CG periods.

[0153] With regard to devices associated with the application, WTRU may send the number and / or IDs associated with the supported devices and / or the association of devices by application.

[0154] With regard to the data / traffic types associated with data streams, WTRU can send information about different data streams / QoS associated with an application, where the data type can include video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, tactile data, pose / positioning data, audio data, etc.

[0155] With regard to traffic characteristics and / or parameters associated with any of the QoS flows, PDU sets and data bursts, WTRU may send information about traffic characteristics / patterns of the different QoS flows, including whether the data is periodic, aperiodic, semi-persistent, Petition 870250088293, dated 09 / 29 / 2025, p. 63 / 14053 / 106 quasi-periodic, etc. Traffic characteristics may include one or more flow periodicity values. WTRU may send information about the payload sizes of PDU sets and an expected number of PDUs per PDU set in one or more flows. Information about the payload size of the PDU set or the number of PDUs per PDU set may also include statistical / distribution information such as mean, minimum, maximum, and / or standard deviation values. Information related to the PDU set may include an indication of the start / first and / or end / last PDU of a PDU set and an indication of the association / dependency of PDUs in a PDU set (e.g., PDU set ID, importance / priority value).The WTRU can send information about data bursts in one or more QoS streams, including the number of PDU sets (e.g., instantaneous, average, maximum, minimum), data burst payload size in bit / byte units (e.g., instantaneous, average, maximum, minimum), periodicity, importance / priority, start and end indication of a data burst (e.g., ID of the first PDU / PDU set, ID of the last PDU / PDU set), and dependency information within the data burst and between multiple data bursts (e.g., indicating whether PDU sets in one or more data bursts may be dependent). The WTRU can send information related to UL and / or DL ​​delay, including the remaining delay relative to the PSDB and the elapsed time since the PDUs / PDU sets arrive at a WTRU (e.g., in one or more buffers on the WTRU).This delay information, which can be sent per stream, per radio carrier, per LCH, per PDU set, or per PDU, can include the interval, average, maximum and minimum values, for example. WTRU can send jitter-related information in UL and / or DL. This jitter information, which can be sent per stream, per radio carrier, per LCH, per PDU set, or per PDU, can include the interval, average, maximum and minimum values, for example. WTRU can send... Petition 870250088293, dated 09 / 29 / 2025, page 64 / 140 54 / 106 Information on the importance / priority of any of the data units (e.g., PDUs, sets of PDUs, data bursts) to be transmitted / received in UL / DL. WTRU may send indications if it detects any changes in UL / DL traffic patterns (e.g., changes in periodicity, changes in average payload sizes, changes in jitter interval). WTRU may send information on a forecast of the UL and / or DL ​​traffic pattern for future / expected data (e.g., timing information indicating the timing of the PUSCH, time interval or CG periods when the data should arrive, payload size of the expected data, importance of the expected data, level of uncertainty and / or confidence of the expected data, or forecast associated with the expected data over a time / duration window).

[0156] With regard to buffer information in application layers / upper layers / AS layers, WTRU may send information about the amount of data payload or buffer level (e.g., with respect to one or more configured threshold values) in the application, including data waiting to be delivered to lower layers for UL transmission and / or data received in DL that may be waiting to be delivered to upper layers / application.This buffer information can be reported, for example, in terms of one or more of the following: estimated or measured time duration for data waiting in the buffer before being delivered to lower layers or consumed by the application; data buffered in the application / upper layer, new layer, SDAP, PDCP, RLC, MAC, LCG, LCHs; and / or payload size (e.g., total, snapshot, average, maximum, minimum) at the granularity of one or more data units (e.g., PDUs, set of PDUs, burst of data).

[0157] With regard to QoS requirements or expected QoS associated with data, WTRU can send the QoS requirements or expected QoS of one or more data streams or units (e.g., PDUs, sets of PDUs, bursts of Petition 870250088293, dated 09 / 29 / 2025, p. 65 / 140 55 / 106 data points), including data rate, latency, reliability, absolute / relative priority values, etc. Information on QoS requirements may also include statistical / distributional information such as mean, minimum, maximum, and standard deviation values. The WTRU may also indicate that such QoS requirements or expected QoS can be supported at different QoS granularities, such as: per PDU, per PDU subgroup within a PDU set (e.g., one or more PDUs), per PDU set, per group of PDU sets, per flow, per session. The WTRU may also indicate a time window (e.g., start time, duration, end time) during which such QoS requirements or expected QoS may be applicable at different QoS granularities.WTRU can indicate that the expected QoS should be achieved at different resource granularities, such as the following: by group of one or more CG configurations, CG periods, time intervals, push occasions, radio blocks, groups of radio blocks.

[0158] Regarding the use of CG resources, WTRU may send information / indications associated with the use of PUSCH CG occasions and / or resources in one or more CG configurations. This usage information may include the number of PUSCH occasions in a time window (e.g., one or more CG slots or periods) that should or should not be used during UL transmissions. The length of each PUSCH occasion, in terms of the number of symbols per PUSCH occasion, may be the same or different, for example. This usage information may also include the number of resource blocks or resource block groups (RBGs) in the frequency domain resource allocation (FDRA) in a set of one or more PUSCH occasions that may or may not be expected to be used during the UL transmission.This usage information may also include the number of PUCCH occasions or features (e.g., SR, HARQ feedback, CSI report) that should or should not be used in a set of one or more slots. Petition 870250088293, dated 09 / 29 / 2025, page 66 / 140 56 / 106 CG periods during UL transmissions. The WTRU may indicate information about the use of such CG resources (e.g., a number of PUSCH occasions or resources used or not) as one or more of the following: initial offset of a PUSCH occasion and the number of consecutive PUSCH occasions; bitmap with a certain length corresponding to the number of PUSCH occasions or slots in one or more CG periods, where a '1' bit in the bitmap may indicate whether a PUSCH occasion or slot should be used or not used by the WTRU, where such a bitmap may allow indicating the use of non-consecutive PUSCH occasions or slots; information about PUSCH occasions that should be used or not used / ignored (e.g., N of M occasions) in a time window due to jitter or delays in traffic arrival time;one or more gap values ​​indicating the number of PUSCH occasions expected to be used or not used between at least two sets of PUSCH occasions, wherein such gap value may be indicated in the form of an initial gap offset symbol / occasion / slot / period and the gap length (e.g., a number of symbols / occasions / slots / periods);and / or a validity period for the indicated CG resource usage (e.g., in ms or in the number of slots or periods during which the indicated CG resource usage can be considered valid). The WTRU may determine the frequency change of the indication on the use of PUSCH (e.g., a number of times the indication can be triggered in a time window) as a function of the jitter range (e.g., minimum / maximum value), jitter duration (e.g., whether the observed jitter can be sustained for a duration), data priority / importance, and / or data QoS (e.g., PSDB). For example, for a set of high-priority or high-QoS PDUs, the WTRU may choose to indicate unused PUSCH occasions after, for example, only after, the observation of sustained high jitter (e.g., over a duration). In the case of a defined low-priority PDU or a defined PDU with lower QoS, the WTRU may indicate the use of PUSCH; Petition 870250088293, dated 09 / 29 / 2025, page 67 / 140 57 / 106 earlier, even if the accuracy of the information in the indication is low. The WTRU can transmit the indication on the use of CG resources (e.g., use of PUSCH) in, for example, one or more of the following: UCI (e.g., using the pre-configured PUCCH resource, which can be configured with any of the periodic resources with a certain periodicity, configuration by CG, period by CG, by LCH, by radio carrier and / or set by PDU); CG-UCI (e.g., with new information elements attached to the existing CG-UCI or one or more existing information elements in the existing CG-UCI can be reused / replaced by PUSCH usage information); and / or New UCI on PUSCH usage (e.g., can be multiplexed with PUSCH).

[0159] With regard to preferred / desired configuration information, WTRU may send to the network one or more preferred mapping configurations, forwarding configurations, and / or resource configurations (e.g., CG, DG), including specific parameters associated with the forwarding / resource configurations. This preference information, associated with multi-PUSCH CG, may include any number of active CG configurations, CG configuration periodicity, number of slots per CG period (e.g., consecutive and / or non-consecutive slots), number of PUSCH occasions per slot / period (e.g., consecutive and / or non-consecutive occasions), number of HARQ processes, MCS to be applied in one or more PUSCH occasions, and other parameters associated with TDRA and / or FRDA configurations. WTRU may associate and / or indicate weight / probability values ​​to different CG / resource configurations when sending requests related to the preferred configuration.The weight / probability value can be determined based on the probability of a configuration being applied during transmission. The network can use this weight / probability information to determine and provide WTRU with a matching configuration and / or to enable / disable a configuration that may match the weight values ​​indicated by the network. Petition 870250088293, dated 09 / 29 / 2025, p. 68 / 140 58 / 106 WTRU. A WTRU can indicate uncertainty information (e.g., percentage / probability) associated with the use of any of the CG features (e.g., PUSCH occasions or intervals) in one or more time / duration windows (e.g., one or more CG intervals or periods).

[0160] With regard to information about updated forwarding configurations applied to a WTRU, information about any updated forwarding configurations associated with configured radio carriers, LCHs, LCGs and / or links may include, for example, one or more of the following: absolute / relative importance / priority values ​​associated with UP / CP configurations (e.g., radio carriers, logical channels, links);and / or LCP configuration: for example, WTRU can indicate updated LCP rules / restrictions (e.g., restrictions associated with mapping DRB / LCHs to resource grants or CG) that can be applied to a set of forwarding / resource configurations (e.g., CG), whether such LCP rules / restrictions can be temporarily changed for a period of time, conditional LCP configurations applicable upon detecting certain configured events (e.g., sudden increase in the number of PDUs / data with high QoS requirements), fallback / default LCP configurations.

[0161] With regard to a request to enable / disable settings, the WTRU may send a request to the network to request the enable / disable of a mapping / forwarding / resource setting and / or parameters associated with the settings, possibly pre-configured in the WTRU. The WTRU may include the configuration / parameter ID when sending the request request.

[0162] With regard to application / AS layer-related measurements, WTRU can send RSRP, RSRQ, RSSI measurements of signals, channels, radio links, carriers, etc., possibly associated with one or more WTRU actions. For example, WTRU can send QoS-related time measurements. Petition 870250088293, dated 09 / 29 / 2025, p. 69 / 140 59 / 106 arrival time, delays, jitter and number of PDUs / PDU sets / data bursts received possibly over a period of time, change in QoS (e.g., increase / decrease in data rate, latency, jitter, reliability), TTL associated with the PDUs / PDU sets / data bursts and / or remaining time for delivery of the PDUs / PDU sets / data bursts.

[0163] The implementations described in the present invention may use any one or more of the information elements (e.g., support information, preferred settings) sent by the WTRU to the network.

[0164] A WTRU may receive information / indications associated with the configuration of multi-PUSCH CG for a network. The WTRU may receive information / indications to support any procedures, mechanisms, rules, actions, etc., associated with the use of multi-PUSCH CG during UL transmissions of any data unit (e.g., PDUs, sets of PDUs, and data bursts) in one or more data / QoS streams. Such indications may include configuration information associated with multi-PUSCH CG settings / parameters or any associated signaling (e.g., dynamic activation / deactivation of multi-PUSCH CG settings and / or parameters).

[0165] Information / indications can be received by the WTRU from a network periodically (e.g., with one or more periodicity values ​​configured), aperiodically / dynamically (e.g., status indication / information, configuration update or request / solicitation messages) and / or on a semi-persistent basis (e.g., sent periodically over a time / duration window).

[0166] The WTRU can receive any of the information / indications (for example, described in the present invention) associated with the multi-PUSCH CG by means of, for example, one or more of the following: RRC signaling and / or messages; PDUs Petition 870250088293, dated 09 / 29 / 2025, pp. 70 / 140 60 / 106 control signals associated with any of the AS layers (e.g., SDAP control PDU, PDCP control PDU); DL MAC CE; DCI; PUSCH; non-AS layer (NAS) signaling (e.g., a PDU session establishment response or a PDU session modification command); and / or application layer signaling / messages.

[0167] With regard to RRC signaling and / or messages (e.g., dedicated / unicast signaling via any SRB or transmission / SIB), RRC signaling can be used to configure any parameters (e.g., MCS, FDRA, TDRA) associated with Type 1 and Type 2 multi-PUSCH CGs. RRC signaling can be used to enable / disable Type 1 multi-PUSCH CGs.

[0168] With regard to DL MAC CE, MAC CE can be used to receive a subset of parameters (e.g., TDRA or FRDA parameters in multi-PUSCH CG) associated with Type 1 and Type 2 multi-PUSCH CG.

[0169] With regard to DCI, DCI can be used to receive a subset of feature parameters (e.g., one or more SLIV indications to indicate TDRA and PUSCH occasions in multi-PUSCH CG) associated with Type 1 and Type 2 multi-PUSCH CG. DCI can be used to receive activation / deactivation indication for Type 2 multi-PUSCH CG (multi-PUSCH CG). A subset of feature parameters can be provided via common group signaling, common cell signaling, or WTRU-specific signaling.

[0170] The information / indications associated with multi-PUSCH CG (e.g., configurations and parameters) that can be received by a network WTRU, semi-statically or dynamically, may include a combination of one or more of the following: CG resource configurations / parameters; other resource configurations / parameters; mapping / forwarding configurations and associated parameters; AS layer status information / indications; validity information; and / or threshold values. Petition 870250088293, dated 09 / 29 / 2025, page 71 / 140 61 / 106

[0171] CG resource configurations / parameters may comprise the CG configuration type for multiple PUSCH and / or parameters associated with multi-PUSCH CG resources / configurations. With respect to the CG configuration type for multiple PUSCH, the type may include any of Type 1 (e.g., resource parameters and enable / disable indication may be provided via RRC signaling), Type 2 (e.g., resource parameters may be provided via RRC signaling, and another subset of resource parameters and enable / disable indication may be provided via DCI or MAC CE) and a new Type 3 (e.g., a subset of resource parameters may be provided via RRC / MAC CE / DCI signaling and another subset of parameters may be selected by WTRU).

[0172] The parameters associated with multi-PUSCH CG features / settings may include, for example, one or more of the following: frequency hopping (e.g., whether intra-slot or inter-slot frequency hopping can be allowed); DMRS configuration (e.g., symbols / features used for DMRS for one or more PUSCH occasions or slots); MSC table (e.g., whether the same or a different set of MCS can be applied to one or more PUSCH occasions in a CG period, where WTRU can be configured to use high MCS values ​​for an initial subset of one or more PUSCH occasions and low MCS values ​​for a later subset of one or more PUSCH occasions in a slot / period); feature for UCI in PUSCH usage (e.g., whether the feature for sending UCI in PUSCH usage in multi-PUSCH CG can be PUSCH or PUCCH);Location of the UCI in PUSCH usage (e.g., one or more locations corresponding to PUSCH occasions or PUCCH for UCI transmission in PUSCH usage, where an indication is given as to whether the UCI in PUSCH usage should be transmitted on all PUSCH occasions expected to be used in a time window); Beta offset for UCI usage in PUSCH; RGB size (by; Petition 870250088293, dated 09 / 29 / 2025, page 72 / 140 62 / 106 example, a number of consecutive or non-consecutive RBs associated with one or more PUSCH occasions); Power control loop to be used; Alpha value of the PUSCH; Bandwidth portion and numerology (e.g., SCS values); Number of HARQ processes (e.g., whether a HARQ process is configured per PUSCH occasion or configured for multiple PUSCH occasions); Repetition K (e.g., number of repetitions allowed for a TB to be repeated and transmitted across multiple PUSCH occasions); Minimum distance per repetition (e.g., minimum number of symbols / slots / occasions before repeating a TB in multi-PUSCH CG); Minimum distance to receive HARQ feedback (e.g., minimum number of symbols / slots / occasions before implicit or explicit ACK / NACK feedback can be expected by the WTRU for a HARQ process associated with a TB that can be transmitted in a multi-PUSCH PUSCH occasion);Periodicity (e.g., associated with the multi-PUSCH CG period); Configured grant timer (e.g., time duration for the WTRU to determine whether transmissions on one or more PUSCH occasions can be successful / unsuccessful, where the WTRU can assume ACK if no indication is received on the transmission and the CG timer expires, and the WTRU can assume NACK if the dynamic grant for retransmission is received along with the HARQ process ID in DCI); TDRA parameters associated with the PUSCH occasion (e.g., one or more SLIV values ​​where each SLIV can indicate the initial offset symbol of a PUSCH occasion and the length / number of symbols per PUSCH occasion, index to a row of a pre-configured mapping relationship / table associated with the TDRA where the row can indicate one or more SLIV values ​​corresponding to different PUSCH occasions in a CG period);FDRA parameters associated with push occasions (e.g., one or more feature indicator values ​​(RIVs) corresponding to the number of consecutive feature blocks or groups of feature blocks, index for a row of a relation / table of; Petition 870250088293, dated 09 / 29 / 2025, page 73 / 140 63 / 106 pre-configured mapping associated with FDRA where the line can indicate one or more RIV values ​​corresponding to one or more PUSCH occasions in a CG period); Transmission parameters (e.g., antenna port, path loss reference index); CG retransmission timer (e.g., time duration for the WTRU to perform autonomous retransmission of a TB, where the WTRU can perform retransmission of a TB on the next PUSCH occasion after the CG retransmission timer expires if no indication corresponding to the HARQ process associated with the TB can be received); Number of PUSCH occasions in a slot; Number of slots in a CG period; and / or Initial offset of PUSCH occasions and / or CG period in the multi-PUSCH CG configuration.

[0173] With regard to other resource configurations / parameters, the WTRU may receive one or more other resource configurations, including, for example, the following: Semi-persistent scheduling (SPS) resources / configurations for DL ​​data receptions; dynamic grant resources for UL data transmission (e.g., triggered by UCI, SR, BSR, MAC CE); and / or dynamic scheduling resources for DL ​​data receptions (e.g., triggered by DCI, PDCCH, MAC CE). With regard to semi-persistent scheduling (SPS) resources / configurations for DL ​​data receptions, the parameters associated with SPS resources / configurations may include any periodicity, initial offset, duration, BWPs, numerology / SCS values, number of PRBs, number of occasions, number of PDSCH slots per occasion, number / duration / maximum length of PDSCH, one or more MCS values ​​for the SPS PDSCH occasions, antenna ports, etc., for example.

[0174] The WTRU can receive at least one set of configuration parameters associated with the default forwarding configuration (e.g., default set of LCHs), which can be enabled and / or used during normal scenarios for data transmission / reception, for example. The WTRU can also receive Petition 870250088293, dated 09 / 29 / 2025, page 74 / 140 64 / 106 another set of configuration parameters that can be associated with exceptional operation, possibly activated and / or used upon detecting any of the triggering events / conditions (described in the present invention).

[0175] The WTRU can receive default priority values ​​associated with resource configurations (e.g., CG). For example, a first resource configuration can be associated with a first priority value, and a second resource configuration can correspond to a second priority value. The first and second resource configurations can be associated with the same set of radio carriers or LCHs. A first set of priority values ​​can aim to achieve standard QoS performance (e.g., standard latency, standard data rate), and a second set of priority values ​​can aim to achieve exceptional QoS performance (e.g., peak / burst data rate, very low latency) for the PDUs / sets of PDUs using the first and second resource configurations during transmission.

[0176] With regard to mapping / forwarding configurations and associated parameters, the WTRU may receive one or more configurations and / or sets of parameters to be applied at different layers of the AS protocol stack (e.g., RRC, SDAP, PDCP, RLC, MAC, PHY, or any new layer).The configuration parameters to be applied in different layers may include, for example, one or more of the following: RLC: whether AM / UM / TM should be applied and parameters associated with the AM / UM / TM operation; MAC: LCH parameters (e.g., priority, PBR, BSD for PDU and / or PDU set level), LCP settings (e.g., rules / constraints / policies for PDU handling and / or PDU set level, time duration for change between different LCP rules / policies) and / or settings for multiplexing / assembly / reordering; and / or SDAP / PDCP: 1-to-1, 1-to-M or N-to-M mapping settings, tags / indications / IDs to be applied (e.g., associated with handling). Petition 870250088293, dated 09 / 29 / 2025, page 75 / 140 65 / 106 QoS flows, PDU sets, data interruptions, association information between PDU sets and data bursts), range of values ​​associated with importance / priority information to be identified in PDUs / PDU sets. An SDAP mapping configuration can refer to information and / or criteria that can be used to map data units (e.g., PDUs, PDU sets, data bursts) in the SDAP layer to one or more PDCP or DRB entities / sublayers. A PDCP mapping configuration can refer to information and / or criteria that can be used to map data units in the PDCP layer to one or more RLC or LCH entities / sublayers.

[0177] AS layer status information / indications may include identifiers / IDs. For example, the WTRU may receive information about one or more IDs to apply during transmission / reception, including, for example, one or more of the following: WTRU IDs, e.g., C-RNTI, l-RNTI, NAS IDs, TMSI / IMSI; Group IDs / indexes (e.g., associated with a group of PUSCH occasions, CG slots, CG periods, CG settings, routing settings group, device / WTRU group); IDs / indexes of individual PUSCH occasions, CG slots, CG periods, CG settings, routing settings; and / or data / message type IDs (e.g., PDU set ID, data burst ID, flow ID, PDU ID).

[0178] Regarding validity information, WTRU may receive validity information associated with resource settings (e.g., multi-PUSCH CG settings, CG periods, CG slots, PUSCH occasion set) indicating whether / when the settings can be considered valid or invalid, based on one or more triggering events / conditions. WTRU may also receive information about whether settings should be disabled and / or released upon determining them to be invalid. For example, WTRU may receive Petition 870250088293, dated 09 / 29 / 2025, page 76 / 140 66 / 106 information about whether resource configurations should be considered valid / invalid based on the WTRU's RRC state (e.g., CONNECTED, INACTIVE, INACTIVE) and / or when transitioning between different RRC states. In another example, the WTRU might assume that resource configurations are valid or invalid based on whether one or more timer values ​​associated with the configurations are running or have expired. The WTRU might receive an indication as to whether to release any of the forwarding configurations.

[0179] Threshold values ​​may comprise, for example, one or more of the following: buffer occupancy threshold; PDU / PDU set payload size threshold values; delay threshold values; delay difference threshold values; reliability threshold values; and / or correlation time window. With respect to buffer occupancy threshold, buffer occupancy threshold values ​​associated with any of the routing configurations may indicate the maximum / minimum amount of data units in one or more granularities / types, including PDUs, sets of PDUs, and data bursts (e.g., in terms of total payload size / volume) that are in one or more buffers (e.g., SDAP buffer, PDCP buffer, LCH buffer on MAC).

[0180] With respect to the payload size threshold values ​​of the PDU / PDU cluster, the payload size threshold values ​​may be associated with one or more upper and / or lower threshold values ​​corresponding to the total payload size (e.g., in bits or bytes) of one or more PDUs, PDU clusters, and / or data bursts. The payload size threshold values ​​may be associated with one or more upper and / or lower threshold values ​​corresponding to the total number of PDUs in a PDU cluster or the total number of PDU clusters in a data burst.

[0181] Delay threshold values ​​can be associated with one or more va Petition 870250088293, dated 09 / 29 / 2025, p. 77 / 140 67 / 106 upper and / or lower threshold values ​​corresponding to the maximum / minimum delay value and / or remaining delay values ​​(e.g., with respect to PSDB) associated with the reception, buffering, and / or transmission of any of the data units (e.g., PDUs, sets of PDUs, bursts of data). These delay threshold values ​​may aim to identify and / or determine the maximum / minimum latency tolerated by the network, application, and / or WTRU, possibly as a result of delays due to processing, jitter, transmission, congestion, etc.

[0182] Delay difference threshold values ​​may be associated with one or more upper and / or lower threshold values ​​corresponding to the difference between a first delay value (e.g., standard delay) and a second delay value (e.g., new / updated delay value).

[0183] The reliability threshold values ​​corresponding to the achievable reliability for one or more sets of PDUs during transmission can be associated with a minimum (e.g., lower limit) or maximum (e.g., upper limit) number of repetitions or retransmissions of the PDUs in the set of PDUs. A TB carrying one or more PDUs from a set of PDUs can be expected to be transmitted with at least N repetitions (e.g., on N PUSCH occasions with independent channel conditions) to meet the reliability requirement of the set of PDUs. The reliability threshold can correspond to a certain percentage value of the set of PDUs that is successfully received to be considered as meeting the reliability requirement of the set of PDUs.

[0184] The correlation time window can correspond to the minimum time difference between two trigger events (e.g., buffer level measurements, PDU / PDU set arrival time), where the two events can be considered correlated with each other when they occur within the correlation time window. If the two events occur in time instances beyond Petition 870250088293, dated 09 / 29 / 2025, page 78 / 140 68 / 106 of the correlation time window, they can be considered independent. WTRU can use the correlation time window to determine whether to send a new or updated indication about the use of PUSCH to the network.

[0185] The implementations described in the present invention may use any one or more of the above information / indications received by the WTRU from the network.

[0186] Events / conditions associated with triggering the indication when using PUSCH in multi-PUSCH CG can be provided.

[0187] A WTRU can be configured with one or more events / conditions related to the execution of certain actions associated with one or more of the following: determining a new or updated traffic pattern over a time window (e.g., arrival of PDUs from upper-layer PDU sets or other devices / WTRUs, delay for data processing and transmission, jitter between the arrival of different batches of interdependent data units, payload size of received and expected data units); determining the use of new or updated resources (e.g., used / unused PUSCH occasions, CG slots / periods, RBGs, TDRA, FDRA) over a time window; transmitting an indication about PUSCH usage when configured with multi-PUSCH CG; transmitting an indication to request the update of any resources or configuration parameters associated with multi-PUSCH CG.

[0188] Such trigger events / conditions may be associated with ensuring that the expected QoS is met when transmitting data units (e.g., PDUs, sets of PDUs, data bursts) in UL while efficiently using the configured multi-PUSCH CG resources. Such trigger events / conditions may dictate the time instances (e.g., symbols, occasions, intervals, or periods) at which an action may be performed by the WTRU. For example, the WTRU may indicate the number and locations of PUSCH CG occasions within a time window (e.g., consisting of one or more slots or CG periods) that should be executed. Petition 870250088293, dated 09 / 29 / 2025, p. 79 / 140 69 / 106 may be used and / or not used. The WTRU may select one or more PUCCH occasions to send an indication about the use of PUCCH based on the detection of triggering events / conditions. Such conditions / events may include a combination of one or more of the following: indication / request from the network; indication / information from application / upper layers or other device / WTRU; buffer status and loading in forwarding configurations (e.g., DRBs / LCHs); configuration change(s) in the WTRU; timing / time stamp information, possibly associated with expected QoS; measurements on Uu links and / or side links; compensation based on expected QoS status; property associated with the CG resource; and / or detection of QoS events.

[0189] With respect to a network indication / request, the WTRU may receive an indication / request from the network (e.g., gNB) as to whether the configured multi-PUSCH CG resources are being used or not. The indication may be received semi-statically (during or after multi-PUSCH CG configuration) or dynamically. The WTRU may trigger an indication about PUSCH usage, described herein, based on the indication / request received from the network. The indication / request about PUSCH usage may be received by the WTRU based on one or more of the following: configuration per CG; period per CG; slot; occasion per PUSCH; process per HARQ; PDU; set per PDU; data burst; data flow / QoS; routing configuration (e.g., radio carrier or LCH); and / or configuration per resource. Such an indication / request may be received by the WTRU on RRC, MAC CE, another control PDU, or DCI.

[0190] With regard to an indication / information from application / upper layers or another device / WTRU, the WTRU can perform any of the WTRU actions (described in the present invention) upon receiving an indication from application / upper layers or another WTRU (e.g., over SL). Such an indication may include information about changing traffic patterns associated with Petition 870250088293, dated 09 / 29 / 2025, pp. 80 / 140 70 / 106 generation / processing / receiving XR data units in one or more streams.

[0191] In one example, the application or another WTRU can indicate to the WTRU information about the expected number of QoS streams that can be associated with the application, expected number of PDUs per set of PDUs, whether any of the PDUs / sets of PDUs are dependent, expected frame / set of PDUs in subsequent time instances (e.g., next frame generation instance), expected change in the importance / priority distribution of generated PDUs, expected increase / decrease in latency (e.g., due to processing in the codec / application or due to congestion / delays in the SL) and / or jitter for delivery of data units in UL and / or DL, expected change in the TTL associated with the data units, expected change in the movement / movement of the WTRU / user (e.g., increase / decrease in movement rate), etc.

[0192] A WTRU may receive an indication from higher layers or from another WTRU indicating the arrival of one or more data units (e.g., in a batch / burst) at the WTRU. Information about the arrival of PDUs may include the expected time (e.g., time interval / frame) of data unit generation and the expected time of reception at the WTRU. This information may be indicated to a WTRU via timestamps and / or sequence numbers.

[0193] The WTRU can be triggered to perform any of the WTRU actions based on an importance / priority indication of the data units. The WTRU can trigger an action (e.g., update resource usage) to retransmit a lost / missing PDU and / or transmit delayed PDUs with compensation (e.g., low latency) upon receiving an indication containing an importance / priority value greater than a threshold. Petition 870250088293, dated 09 / 29 / 2025, page 81 / 140 71 / 106

[0194] Buffer status and loading in routing configurations (e.g., DRBs / LCHs) may include at least one condition associated with, for example, one or more of the following measures or combinations of measures (e.g., against a threshold): the amount of XR data units in one or more buffers associated with routing configurations, possibly over a period of time or time window; the arrival / departure rate of data units in one or more buffers associated with routing configurations; the average, maximum, and minimum size / volume of data units in a buffer associated with routing configurations (e.g., number of PDUs in the LCH buffer); the amount of time spent by one or more data units in buffers associated with routing configurations; and / or the number of routing configurations that meet a condition / threshold associated with the amount of data, arrival rate,Data units (e.g., total payload size). A WTRU can perform any of the actions described in the present invention if at least one data unit in a forwarding configuration (e.g., UL LCH buffer waiting to be transmitted in UL) is in the buffer for a period of time greater than a timeout value. For example, a WTRU can perform any of the actions described in the present invention (e.g., sending an indication about the use of PUSCH) if the buffer status (e.g., total payload size) exceeds a limit. Other buffer status metrics that can be monitored to determine the expected QoS include the number of buffered data units that may be above / below a limit configured in one or more associated routing configurations and / or the arrival / departure rate of the data unit in the buffer relative to a configured arrival / departure rate.

[0195] With regard to changing the configuration(s) in the WTRU, the WTRU can be triggered to perform any of the WTRU actions when determining Petition 870250088293, dated 09 / 29 / 2025, p. 82 / 140 72 / 106 a change in a mapping configuration, forwarding configuration, and / or resource configuration, including changing at least one of the parameters in the mapping configuration (e.g., mapping a QoS flow to a new forwarding configuration), changing DRB / LCH parameters (e.g., priority, PDB, PBR), changing the LCP configuration (e.g., updating LCP rules or restrictions), changing QoS data units (e.g., PSDB, PSER, PSIHI), and / or changing resource configurations / parameters (e.g., CG, DG, SPS). A WTRU may be triggered to perform one or more WTRU actions if the CDRX / DRX configuration and any of the associated parameters applied in the WTRU are modified / updated, which may impact the traffic pattern and / or resource usage of the CG.

[0196] With regard to time / time stamp information possibly associated with expected QoS, WTRU can track time-related information (e.g., timestamp, sequence number, marker, or time control PDU) on one or more data units received in a previous time window to determine latency or jitter. Time information can be used, for example, to determine if / how QoS can be met for new / upcoming data units in the next time window using configured resources (e.g., PUSCH occasions in one or more slots / periods). In one example, time information can be determined / indicated as a deadline / latency threshold and / or survival time that can be met per PDU, per set of PDUs, per data burst, or per QoS stream.This timing information can be determined through one or more associated / correlated QoS flows, including correlated UL flows, for example. Timing information can also be determined / indicated based on counting (e.g., counting data units). WTRU can trigger an action upon determining new or updated timing information. WTRU. Petition 870250088293, dated 09 / 29 / 2025, page 83 / 140 73 / 106 can send information / indications / reports to the network periodically or based on the setting / expiration of a timer.

[0197] With regard to measurements on Uu links and / or side links, WTRU can perform measurements on the Uu and / or SL link, for example, corresponding to RSRP, RSSI, CQI, and CSI, to determine the expected QoS for the data units expected to be received (e.g., over SL) and / or transmitted (over the Uu link). Channel / load measurements taken over a configured time period can indicate whether the data units can achieve the expected QoS during transmission and / or reception, or whether they can exceed the QoS budget (e.g., PSDB) when using the configured CG features. WTRU can trigger an action based on measurements on the Uu and / or SL link, for example.

[0198] WTRU can determine Uu or SL link conditions based on the number of ARQ / HARQ (ACK / NACK) feedback messages and / or ARQ / HARQ retransmissions made through one or more HARQ processes associated with the routing configurations applied for sending the data units. A ReTx count above a threshold may result in poor Uu link / SL conditions and therefore reduced remaining delay or TTL.

[0199] WTRU can be triggered to perform WTRU actions and / or send an indication to the network if channel measurements taken (e.g., RSRP, RSSI, RSRQ, CQI, CSI) on the Uu or SL link increase / decrease relative to a configured threshold and / or remain above / below a threshold for a specified period of time.

[0200] A WTRU can be triggered to perform WTRU actions if one or more QoS-related measurements (e.g., latency measured for data units in one or more routing configurations) exceed a certain threshold. Petition 870250088293, dated 09 / 29 / 2025, p. 84 / 140 74 / 106

[0201] The WTRU can trigger an action based on the determination of the time duration / jitter, or change in the time duration / jitter between the reception of consecutive PDUs associated with a set of PDUs or sets of consecutive PDUs associated with a burst of data, and / or reception of data units in one or more correlated streams in UL and / or DL. The WTRU can infer an increase / decrease in jitter between consecutive PDUs to determine if the processing load in the application / upper layer or congestion on SL may be high / low. In this case, to determine the time duration, the WTRU can set a timer if a first data unit (e.g., the first PDU of a set of PDUs) arrives and reset the timer if a second associated data unit (e.g., the second PDU of a set of PDUs) arrives.

[0202] With regard to compensation based on expected QoS status, the WTRU can be triggered to perform WTRU actions based on the determination of the expected QoS for one or more data units, including an indication of whether the data units may be delayed or arrive early during UL transmission. In this case, the WTRU can trigger an action so that delayed or early data units can be transmitted with a determined compensation value, for example, using configured resources (e.g., PUSCH occasions). The action(s) can be triggered if a change (e.g., higher / lower) in the expected QoS for the data units is detected within a given threshold.

[0203] WTRU may determine that the delayed PDU be sent using a previous PUSCH occasion or in a previous CG slot / period that allows for a compensation value to be met, where the compensation value may be determined by subtracting the expected latency from the actual latency.

[0204] With regard to the property associated with the CG resource (for example, Petition 870250088293, dated 09 / 29 / 2025, page 85 / 140 75 / 106 occasion of PUSH, CG slot, CG period), the WTRU can be configured with a specific property for the CG resource, such as a priority value or a configuration parameter that enables / disables the specific action for the CG resource. The WTRU can change the parameters of a CG resource associated with high priority, provided that the change affects, for example, only other CG resources of lower priority.

[0205] Regarding the detection of QoS events (e.g., increase in payload size, reception of high-importance data), QoS events may include increase events associated with an increase in the number of data units or payload size, possibly over a time window, indicated / marked with high importance / priority. Other QoS events may include QoS deflation associated with a decrease in the number of data units or payload size over a time window. WTRU may be triggered to perform WTRU actions upon detecting one or more QoS events, possibly considering the indicated / determined time duration during which the QoS events may persist. WTRU may, for example, perform other WTRU actions that may result in reverting to default settings, possibly after the termination of the detected QoS events, for example.If a peak event (e.g., an increase in total payload or the number of PDU sets) is detected, the WTRU may trigger an action to update the number of PUSCH occasions that should or should not be used in UL during the peak. Upon determining a decrease in the peak event or the end of the peak, the WTRU may revert to using the default number of PUSCH occasions used / not used.

[0206] Implementations for transmitting information about the use of PUSCH over a time window are disclosed.

[0207] A WTRU can determine the use of PUSCH based on a dynamically signaled time window. Petition 870250088293, dated 09 / 29 / 2025, page 86 / 140 76 / 106

[0208] The WTRU can determine PUSCH usage (e.g., number and timing of PUSCH occasions) if configured with multi-PUSCH CG to transmit one or more PDUs from at least one PDU pool based on a dynamically signaled time window from the network, the PDU payload size of a PDU pool in LCH buffers on the WTRU, and / or the remaining delay associated with a PSDB value of the PDU pool. Dynamic signaling of the PUSCH usage request along with a time window allows the WTRU to inform the network if, for example, and only if, the network needs the PUSCH usage information (e.g., during a high-load scenario) and under certain events / conditions detected on the WTRU (e.g., for data in the buffer with low remaining delay).

[0209] In examples, the WTRU may receive configuration information and / or parameters associated with one or more multi-PUSCH CG configurations (e.g., a number of PUSCH occasions per slot, a number of slots per CG period). The WTRU may receive one or more threshold values ​​associated with the payload size per PUSCH occasion and the remaining delay of a set of PDUs. For example, the payload size threshold may be indicated as one or more percentage values ​​of the resources in a PUSCH occasion that can be used to transmit data and control signaling.

[0210] A WTRU can receive one or more PDUs from a set of PDUs from higher layers or from another WTRU (e.g., over SL). The WTRU can select and / or forward the PDUs from the set of PDUs to one or more radio carriers and / or LCHs based on a set of parameters associated with the PDUs and / or set of PDUs, including importance / priority, PDU arrival time window, PDU payload sizes, PDU / set of PDUs QoS (e.g., PSDB, PSIHI, PSER), etc. The WTRU can determine the remaining delay of the set of PDUs based on the arrival time of the PDUs (e.g., time elapsed since the arrival of the first PDU from a set of PDUs in Petition 870250088293, dated 09 / 29 / 2025, p. 87 / 140 77 / 106 a buffer LCH) and the PSDB (Delay Budget of the Set of PDUs).

[0211] The WTRU may receive from the network (e.g., in DCI or MAC CE) a request to use PUSCH and / or a time window within which the WTRU may indicate the number and location of PUSCH occasions that can be expected to be used or not used by the WTRU. For example, the time window may be indicated by a starting offset (e.g., PUSCH start occasion, start interval, or CG period) and duration (e.g., number of consecutive PUSCH occasions, intervals, or CG periods). The time window may alternatively be indicated, for example, by an index to a row of a pre-configured mapping relation / table, indicating the starting offset and duration of the time window.

[0212] WTRU may determine the use of PUSCH (e.g., number and locations of PUSCH occasions expected to be used or not used by WTRU during UL transmission) over the indicated time window based on any one of several conditions or criteria. If the payload of one or more PDUs in the multiplexed PDU pool on a PUSCH occasion in the time window is less than or equal to a first payload threshold value (per PUSCH occasion) and / or greater than a second payload threshold value, WTRU may determine the PUSCH occasion as used. If the payload of one or more PDUs in the multiplexed PDU pool on a PUSCH occasion in the time window is less than the second payload threshold value (per PUSCH occasion), WTRU may determine the PUSCH occasion as not used.If one or more push occasions within the time window meet the payload criteria, WTRU may determine the corresponding push occasions as used or unused.

[0213] If the remaining delay of the PDUs in the PDU set is less than or equal to the delay limit associated with the PSDB, and / or the PDUs in the PDU set in the buffers can be multiplexed on PUSCH occasions within the time window, the WTRU Petition 870250088293, dated 09 / 29 / 2025, p. 88 / 140 78 / 106 can determine the PUSCH occasions as used. If the remaining delay of the PDUs in the PDU pool is greater than the delay limit associated with the PSDB and / or the PDUs could be delayed to the next slot or CG period outside the time window, the WTRU may determine the PUSCH occasions as unused.

[0214] If one or more conditions, for example, the conditions above, are not met, the WTRU may transmit an indication to the network to report the cause (e.g., with the index value) for not meeting the conditions or to request an update to the multi-PUSCH CG configuration (e.g., request for additional PUSCH occasions or DG feature in SR / BSR). Such an indication may be triggered due to the WTRU's inability to determine sufficient PUSCH occasions that should be used in the time window, or to determine with sufficient accuracy (e.g., confidence level) which PUSCH occasions should or should not be used in the time window.

[0215] WTRU can transmit, for example, one or more indications to the network about the specific use of PUSCH over the time window.For example, WTRU may transmit the indication about the use of PUSCH in, for example, one or more of the following: a first PUSCH occasion after receiving the request indication from the network (e.g., in DCI); a PUSCH occasion that is available k time units (e.g., ms, symbols, slots, periods) after receiving the request indication from the network, where k may be pre-configured (e.g., via RRC) or determined by WTRU based on traffic attributes (e.g., PDU set type, importance, remaining delay, jitter); a PUSCH occasion selected by WTRU from a set of pre-configured candidate PUSCH occasions, where the selection may be made based on a criterion associated with the traffic attributes and / or availability of the first PUSCH occasion; and / or all PUSCH occasions that may be available or used by WTRU over a duration / time window (e.g., one or more). Petition 870250088293, dated 09 / 29 / 2025, page 89 / 140 79 / 106 slots or periods (CG)

[0216] The WTRU can transmit the indication about the use of PUSCH in any UCI, CG-UCI or new UCI about the use of PUSCH. Such indication can be transmitted using the PUCCH feature or the PUSCH feature. The WTRU can transmit, for example, the PDUs from the set of PDUs using the PUSCH occasions indicated by the WTRU as used.

[0217] In examples, when transmitting the indication about the use of PUSCH, the WTRU can be configured to start a prohibition timer. The WTRU can retransmit the same indication or another indication about the use of PUSCH, for example, only after the prohibition timer has expired.

[0218] The WTRU can receive PDUs from various sets of PDUs associated with video frames and pose / haptic frames. Both types of PDU sets can be expected to be transmitted by the WTRU within their respective PSDBs and synchronization delay limits, corresponding to the delay difference between the transmission of one or more PDUs from a first set of PDUs (e.g., video frame) and the PDUs from a second set of PDUs (e.g., pose / haptic frames). The WTRU can determine the number of expected PUSCH occasions to be used or not in a time window (e.g., slots or CG periods) based on the payload sizes of both types of PDU sets, the remaining delay of both PDU sets, and the synchronization delay associated with both PDU sets.WTRU can transmit an indication to the network about the use of PUSCH, considering the QoS associated with both types of PDU sets, and multiplex the PDUs of both types of PDU sets on the respective occasions when PUSCH is indicated as being used.

[0219] FIG. 2 illustrates an example of implementing a WTRU to determine the use of PUSCH. In the example shown in FIG. 2, a WTRU can determine the use of PUSCH (e.g., number and timing of PUSCH occasions) with Petition 870250088293, dated 09 / 29 / 2025, pp. 90 / 140 80 / 106 based on a time window dynamically signaled by the network, the payload size of the PDUs of a PDU and the remaining delay associated with the PSDB.

[0220] A WTRU may determine the location for transmitting the indication regarding the use of PUSCH.

[0221] In examples, WTRU can determine the location (e.g., PUSCH occasion(s)) to send the indication on PUSCH occasions that are expected to be used or not used in subsequent intervals / periods based on a set of configured candidate locations and estimated delay / jitter to receive the expected PDUs from higher-tier PDU sets.

[0222] In examples, the WTRU may receive configuration information and / or parameters associated with one or more multi-PUSCH CG configurations (e.g., number of PUSCH occasions per slot, number of slots per CG period) and a time duration (e.g., in terms of one or more slots or CG periods, to determine and indicate PUSCH usage). The WTRU may receive, in the configuration, a set of one or more candidate locations (e.g., PUSCH occasions) to transmit the indication about PUSCH usage in a CG period.In the configuration, WTRU can receive a criterion for selecting a location from the set of candidate PUSCH occasion locations based on, for example, one or more of the following: PUSCH occasion closest to the maximum jitter relative to the first PUSCH occasion used; PUSCH occasion closest to the remaining delay associated with the PSDB of the PDU set; PUSCH occasion associated with the importance / priority of the PDU set; and / or PUSCH occasion associated with the payload size of the PDU set.

[0223] A WTRU can receive from higher layers or from another WTRU (e.g., over SL) a first batch of one or more PDUs from a set of PDUs. The WTRU can select and / or route the first batch of PDUs from the set of PDUs to one or more radio carriers and / or LCHs based on a set of Petition 870250088293, dated 09 / 29 / 2025, pp. 91 / 140 81 / 106 parameters associated with PDUs and / or PDU sets. WTRU can determine the payload information related to the expected second batch of one or more PDUs in the PDU set based on the corresponding information for the PDU set in the first PDU batch (e.g., information about the total payload size and / or total number of PDUs in the PDU set in the first PDU batch).

[0224] WTRU can determine the jitter range (e.g., maximum jitter value) for receiving a second batch of PDUs from the pool of PDUs based on the arrival time of the first batch of PDUs (e.g., time elapsed since the arrival of the first batch of PDUs in the LCH buffer) and the PSDB.

[0225] WTRU may determine the use of PUSCH (e.g., number and locations of PUSCH occasions expected to be used or not used by WTRU during UL transmission) over the configured time duration based on one or more conditions or criteria. For example, if the payload of the first and second batch of PDUs in the set of PDUs multiplexed in one or more PUSCH occasions is less than or equal to a first payload threshold value (per set of PUSCH occasions) and / or greater than a second payload threshold value, WTRU may determine the PUSCH occasions as used. If the total payload of the first and second batch of PDUs in the set of PDUs multiplexed in one or more PUSCH occasions is less than the second payload threshold value (per set of PUSCH occasions), WTRU may determine the PUSCH occasions as not used.

[0226] If the jitter value determined as the delay in arrival at the LCH buffers between the first batch of PDUs and the second batch of PDUs in the PDU set is less than or greater than a set of jitter threshold values, which may correspond to the length of one or more PUSCH occasions (e.g., number of symbols / slots), the WTRU may determine which PUSCH occasions may not Petition 870250088293, dated 09 / 29 / 2025, pp. 92-140 82 / 106 include none of the PDUs due to jitter as they are not used.

[0227] In examples, the determined PUSCH usage may consist of one or more of a first set of PUSCH occasions that may be used by a WTRU to transmit the first batch of PDUs, followed by one or more PUSCH occasions that may not be used due to instability, and followed by one or more second sets of PUSCH occasions that may be used to transmit the second batch of PDUs from the PDU set. If the total number of PUSCH occasions used in the first set and unused PUSCH occasions may exceed the total number of PUSCH occasions in one or more slots or CG periods, the second set of PUSCH occasions may be in subsequent slots or CG periods, for example.

[0228] The WTRU can select a location from the set of candidate locations based on the configured criteria to send the indication on the determined PUSCH usage. For example, the WTRU can select a location closest to the maximum jitter value relative to the first PUSCH occasion used. If the maximum jitter value is determined to be low or less than a threshold value, the WTRU can select the first PUSCH occasion for multiplexing and transmitting the indication. In examples, the WTRU can select N from M candidate locations to send the indication on the determined PUSCH usage, where N can be equal to or less than M. If the indication is sent to N locations as a bitmap, the bits in the bitmap can be updated to be consistent with the location where the bitmap can be sent.For example, for a bitmap with 4 bits corresponding to 4 PUSCH occasions, where the M candidate locations to send the indication about the use of PUSCH can be in all four (4) PUSCH occasions and the WTRU selects all four (4) occasions to send the indication (e.g., N=M), the bitmap sent in the first location can be '1101', in a second location can be '0101', in a third location can be '0001' and in a fourth location can be '0000'. Petition 870250088293, dated 09 / 29 / 2025, pp. 93 / 140 83 / 106

[0229] The WTRU can transmit, for example, one or more indications to the network regarding the determined PUSCH usage at the selected location. The WTRU can receive from a network (e.g., in RRC, MAC CE, or DCI signaling) an explicit (e.g., ACK / NACK) or implicit confirmation indication regarding the use of PUSCH occasions in subsequent slots or CG periods. For example, in the case of an implicit ACK, the WTRU may not receive any indication before the end of a timer initiated by the WTRU after sending the PUSCH usage indication. In the case of an implicit NACK, to transmit the second batch of PDUs, the WTRU may receive DG resources, an indication of other PUSCH occasions in the same or different multi-PUSCH CG configurations, or an indication of activation of another CG configuration.

[0230] WTRU can transmit the first batch of PDUs from the PDU pool using the first set of PUSCH occasions indicated by WTRU as used. Upon receiving the second batch of PDUs, WTRU can transmit the PDUs from the PDU pool using the second set of PUSCH occasions indicated by WTRU as used or using resources indicated by the network.

[0231] FIG. 3 describes an example of implementing a location determination for sending a PUSCH usage indication. A WTRU can determine the location (e.g., PUSCH occasion(s)) for sending the PUSCH usage indication based on a set of configured candidate locations and an estimated delay / jitter for receiving the expected PDUs from the PDU sets.

[0232] A WTRU may determine to update the indication regarding the use of PUSCH.

[0233] WTRU may determine that the information provided in a first indication regarding the use of CG PUSCH occasions needs updating by sending a second indication, based on updated / new information associated with traffic attributes (e.g., time of arrival, jitter, payload size). This Petition 870250088293, dated 09 / 29 / 2025, pp. 94 / 140 84 / 106 second indication can be transmitted within a configured time period, which may be allowed for WTRU if it is transmitting certain types of PDU sets (e.g., high-importance PDU sets).

[0234] The WTRU may receive configuration information and / or parameters associated with one or more multi-PUSCH CG configurations (e.g., number of PUSCH occasions per slot, number of slots per CG period). The WTRU may receive, in the configuration information, a maximum time duration (e.g., in ms, symbols, slots, periods) to update the PUSCH usage indication after sending an initial indication. The WTRU may receive, in the configuration information, one or more threshold values ​​associated with updating the PUSCH usage indication. These threshold values, for example, may include the payload size of a PDU set, the remaining delay, and the importance / priority of a PDU set.

[0235] A WTRU can receive, from higher layers or from another WTRU (e.g., over SL), a first batch of one or more PDUs from a set of PDUs. The WTRU can determine the PUSCH usage (e.g., expected number of PUSCH occasions used and / or not used in a time window) based on the attributes (e.g., payload size, remaining delay, jitter) associated with the first batch of PDUs and the expected second batch of PDUs. The WTRU can then transmit, for example, to the network a first indication of the determined PUSCH usage in a time window (e.g., one or more subsequent slots or CG periods).

[0236] A WTRU can receive a second batch of one or more PDUs from the PDU set from higher layers or from another WTRU (e.g., over SL). The WTRU can determine a change in PUSCH usage (e.g., number and location of PUSCH occasions previously determined as used and / or unused) if triggered by attributes associated with the second batch of PDUs, such as, Petition 870250088293, dated 09 / 29 / 2025, pp. 95 / 140 85 / 106 for example, payload size of the second batch of PDUs, arrival time of the second batch of PDUs, and the updated remaining delay associated with the set of PDUs.

[0237] The WTRU may trigger a second PUSCH usage indication if one or more of the following example conditions can be met: the time elapsed after the transmission of the first PUSCH usage indication is less than or equal to the configured maximum duration; the remaining delay of the PDU set is less than or equal to the delay limit; the priority of one or more LCHs containing the second batch of PDUs in the PDU set is greater than a priority limit; receipt of an indication (e.g., in DCI or MAC CE) requesting confirmation or update of PUSCH usage within a time window associated with the first PUSCH usage indication.

[0238] The WTRU may transmit a second indication regarding the use of PUSCH, possibly if any of the conditions, for example, the conditions above, can be met. The second indication regarding the use of PUSCH may contain the same information or updated information about the number and location of PUSCH occasions that are expected to be used or not used by the WTRU (for example, in a bitmap or in the initial offset and length indication). The second indication regarding the use of PUSCH may contain difference / delta information about the use of PUSCH in relation to the information transmitted in the first indication regarding the use of PUSCH. If any of the conditions, for example, the conditions above, are not met, the WTRU may not trigger and transmit a second indication regarding the use of PUSCH.

[0239] WTRU may transmit to the network the second indication of current PUSCH usage over the time window on any of the first available PUSCH occasions after determining the current PUSCH usage, on a PUSCH occasion selected by WTRU from a set of pre-configured candidate PUSCH occasions, or on a set of PUSCH occasions that Petition 870250088293, dated 09 / 29 / 2025, pp. 96 / 140 86 / 106 may be available or used by WTRU over a period / time window. This second indication regarding the use of PUSCH can be transmitted in any UCI, CG-UCI, or new UCI regarding the use of PUSCH. This second indication can be transmitted using the PUCCH feature or the PUSCH feature. WTRU can then transmit, for example, the second batch of PDUs from the PDU set using the PUSCH occasions indicated by WTRU as used.

[0240] FIG. 4 illustrates an example implementation for determining the update of information provided in a first indication about the use of PUSCH occasions. A WTRU can determine the update of information provided in a first indication about the use of PUSCH occasions with configured grant (CG) by sending a second indication, based on updated / new information associated with PDU arrival time, jitter, and PDU payload sizes.

[0241] In examples related to transmitting an indication about the use of PUSCH during a requested or configured time window, WTRU may receive configuration information, including a CG configuration for multiple PUSCH.

[0242] A WTRU can receive, for example, PDUs from a set of PDUs from higher layers.

[0243] The WTRU may receive a request from the network (NW) (e.g., in DCI) to use PUSCH. The request to use PUSCH may include, for example, a time window associated with the use of PUSCH. The time window may be indicated by an initial PUSCH displacement occasion and duration within which the WTRU may indicate the number and location of PUSCHs used / not used.

[0244] WTRU can determine the remaining delay of PDUs based on the arrival time of PDUs (e.g., time elapsed since the arrival of the first PDU in the LCH buffer) and the PSDB. Petition 870250088293, dated 09 / 29 / 2025, pp. 97 / 140 87 / 106

[0245] The WTRU may determine the use of PUSCH (e.g., number and locations of PUSCH occasions) over the time window based on, for example, one or more of the following: multiplexed PDU payload(s) in one or more PUSCH occasions being less than (<) a payload threshold (e.g., percentage of the total payload of the PDU set); and / or a remaining PDU delay from the PDU set being less than (<) a delay threshold (e.g., the WTRU may determine a PUSCH occasion as unused if the remaining delay is above a delay threshold and a PDU can be delayed to a later slot / period).

[0246] The WTRU may transmit an indication of PUSCH usage (e.g., the first N of M configured PUSCH occasions) over the time window on the first PUSCH occasion.

[0247] WTRU can transmit PDUs using the indicated PUSCH occasions.

[0248] Implementations to indicate a CG silencing pattern for use with CG PUSCH can be provided.

[0249] A WTRU can select a preconfigured CG muting pattern to indicate the use of PUSCH. The WTRU can transmit an indication of a selected CG muting pattern that can be correlated with the XR traffic pattern, and the use of PUSCH CG occasions can be determined by the WTRU. The WTRU can select and indicate a preconfigured CG muting pattern for XR traffic patterns, for example, certain deterministic XR traffic patterns, corresponding to the arrival and transmission of PDUs from sets of PDUs with low instability, fixed periodicity, and / or high importance.

[0250] WTRU may receive configuration information and / or parameters associated with one or more multi-PUSCH CG configurations (e.g., number of PUSCH occasions per slot, number of slots per CG period). Petition 870250088293, dated 09 / 29 / 2025, pp. 98 / 140 88 / 106

[0251] The WTRU can receive, in the configuration, one or more CG muting patterns, where each CG muting pattern can cover a time interval (e.g., a set of one or more PUSCH occasions, slots, or CG periods) and can indicate a subset of CG PUSCH occasions and the locations of the PUSCH occasions that are muted / unavailable. For example, for a CG configuration for multiple PUSCH consisting of 4 PUSCH occasions per slot and 2 slots per CG period, a first CG muting pattern can indicate the muting of all PUSCH occasions in the second slot and a second CG muting pattern can indicate the muting of the last 2 PUSCH occasions in the two (2) slots.The WTRU can receive, in the configuration, criteria for selecting one or more CG muting patterns based on the data unit traffic pattern that should be transmitted by the WTRU in UL and the use of PUSCH occasions. These criteria may consider XR and QoS traffic attributes, as well as payload sizes, PDU arrival time, remaining delay, jitter, and number of repetitions. For example, the criteria for selecting a CG muting pattern may include minimizing the number of mismatched occasions between the CG configuration for multiple PUSCHs and the number of PUSCH occasions expected to be used / not used in the corresponding time interval. Such criteria may allow minimizing the number of PUSCH occasions used and / or maximizing the number of unused PUSCH occasions when selecting a CG muting pattern.

[0252] The criteria for selecting a CG muting pattern may include association information between a set of CG muting patterns and XR traffic attributes (e.g., PDU sets), such as payload sizes, remaining delay, and jitter. A WTRU may select a first CG muting pattern (e.g., with a low number of unused PUSCH occasions in locations near the end of the muting pattern) to Petition 870250088293, dated 09 / 29 / 2025, pp. 99 / 140 89 / 106 transmit a PDU set with a payload size above a payload threshold and / or for remaining delay below a delay threshold. WTRU may select a second CG muting pattern (e.g., with a high number of unused PUSCH occasions at locations near the start of the muting pattern) for a PDU set with a payload size below a payload threshold and / or for remaining delay above a delay threshold.

[0253] The WTRU can receive, in configuration, for example, one or more threshold values ​​associated with the payload size on the occasion of a PUSCH, the remaining delay of a set of PDUs to meet the PSDB, and the number of repetitions of different PDUs in a set of PDUs to meet the PSER. These threshold values ​​can be used to determine the use of PUSCH occasions in a time interval based on the determined traffic pattern.

[0254] A WTRU can receive one or more PDUs from a set of PDUs from higher layers or from another WTRU (e.g., over SL). The WTRU can select and / or forward the PDUs from the set of PDUs to at least one radio carrier and / or LCH based on the importance / priority of the set of PDUs, arrival time of the PDUs, payload sizes of the PDUs, and QoS of the PDU / set of PDUs (e.g., PSDB, PSER).

[0255] WTRU can determine the pattern of PUSCH usage (e.g., number and locations of PUSCH occasions expected to be used or not used by WTRU during UL transmission) over the time interval (e.g., configured / indicated with a start offset and duration) that can be aligned with the interval corresponding to the set of configured CG muting patterns. WTRU can determine the pattern of PUSCH usage over the time interval based on one or more conditions or criteria. If the payload of one or more PDUs in the set of multiplexed PDUs on a PUSCH occasion is less than or equal to a first payload threshold value (on occasion of Petition 870250088293, dated 09 / 29 / 2025, pp. 100 / 140 90 / 106 If the payload of one or more PDUs in the multiplexed PDU array on a PUSCH occasion is less than the second payload threshold value (on the PUSCH occasion), and / or greater than a second payload threshold value, the WTRU may determine the PUSCH occasion as used.

[0256] If the remaining delay of the PDUs in the PDU set is less than or equal to the delay threshold associated with PSDB, and / or the PDUs in the PDU set in the buffers can be multiplexed into a set of one or more PUSCH occasions within the time window, WTRU may determine the PUSCH occasions as used. If the remaining delay of the PDUs in the PDU set is greater than the delay threshold associated with PSDB and / or the PDUs can be delayed to the next slot or CG period outside the time window, WTRU may determine the PUSCH occasions as unused.

[0257] If the number of repetitions of one or more PDUs (for example, PDUs with a priority greater than a priority threshold value) in the PDU set is less than or equal to a first repetition threshold value and / or greater than a second repetition threshold value, the WTRU may determine the corresponding PUSCH occasions in the time window as used. The WTRU may determine any of the PUSCH occasions in the time window that do not contain new or repeated PDUs as unused, for example. The WTRU may execute k repetitions of all or a subset of the PDUs in the PDU set to meet the PSER.

[0258] WTRU can select one or more CG muting patterns from the set of configured CG muting patterns based on the determined PUSCH usage pattern and one or more of the following example criteria: for each CG muting pattern, determine the number of mismatched occasions (e.g., number of PUSCH occasions used that do not match the unmuted occasions in the CG muting pattern) with respect to Petition 870250088293, dated 09 / 29 / 2025, pp. 101 / 140 91 / 106 PUSCH usage determined in the corresponding time window; a subset of occasions in the PUSCH usage pattern that may be incompatible with the occasions in the CG muting pattern may be delayed / advanced to one or more corresponding occasions in the CG muting pattern (e.g., such delay / advancement of occasions to generate an updated PUSCH usage pattern may be done if the remaining delay of the PDU set with the updated PUSCH usage pattern remains above a delay threshold value (e.g., PSDB of the PDU set may still be met with the updated PUSCH usage pattern); and / or select at least one CG muting pattern that results in minimizing the number of incompatible occasions between the CG muting pattern and the updated PUSCH usage pattern.

[0259] The WTRU may combine multiple CG muting patterns (e.g., pattern joining) that may result in meeting the PUSCH usage pattern and criteria. The WTRU may select multiple CG muting patterns. The WTRU may transmit the indication in one or more selected CG muting patterns containing the ID or indexes of the CG muting patterns in any UCI, CG-UCI, or new UCI. Such indication may be transmitted using PUCCH resources or PUSCH resources.

[0260] If the criteria for selecting at least one CG muting pattern are not met, the WTRU may, for example, perform one or more of the following actions: transmit an indication to the network to report the cause (e.g., with the index value) for not meeting the criteria; transmit an indication of PUSCH usage (e.g., number and location of PUSCH occasions used or not used, instead of the index of a selected CG muting pattern); and / or transmit a DG resource request (e.g., SR / BSR) or a request to update the resources in the CG configuration for multiple PUSCH.

[0261] WTRU can receive from the network (e.g., in RRC signaling, MAC Petition 870250088293, dated 09 / 29 / 2025, pp. 102 / 140 92 / 106 CE or DCI), an explicit or implicit acknowledgment (ACK / NACK) indication in the CG muting pattern. In the case of an implicit ACK, the WTRU may not receive any indication before the end of a timer initiated by the WTRU after sending the indication in a selected CG muting pattern. In the case of an implicit NACK, to transmit the second batch of PDUs, the WTRU may send an index for a selected CG muting pattern on the network, a new CG muting pattern, or an indication to activate another CG configuration for multiple PUSCH or single PUSCH CG.

[0262] A WTRU can, for example, then transmit the PDUs from the PDU set using the PUSCH occasions allowed by the determined or indicated CG muting pattern.

[0263] A WTRU can be configured with a set of one or more HARQ transmission patterns that can be associated with the multi-PUSCH CG. Each HARQ transmission pattern can include a set of occasions corresponding to the PUSCH occasions in the multi-PUSCH CG that can indicate the initial transmissions and retransmissions for one or more HARQ processes that can be used by the WTRU. For example, in a multi-PUSCH CG consisting of a set of PUSCH occasions in one or more slots or CG periods, for a first HARQ process, the nth PUSCH occasion can be used for the initial transmission, the nth-kth PUSCH occasion can be used for a first retransmission, and the nth-kth PUSCH occasion can be used for a second retransmission. Similarly, for a second HARQ process, the n+1 'th occasion of PUSCH can be used for the initial transmission, followed by the n+1 -i-k'th occasion of PUSCH for the first retransmission.The corresponding anek values ​​can be configured in the WTRU individually or via the HARQ transmission standards. For example, the nek values ​​can be different for different types of transmissions. Petition 870250088293, dated 09 / 29 / 2025, pp. 103 / 140 93 / 106 current HARQ transmission standards. WTRU can select a HARQ transmission standard and can indicate the selected standard based on the traffic pattern and associated QoS.

[0264] A WTRU can be configured with a set of one or more HARQ transmission patterns, where each pattern can correspond to different redundancy version (RV) values ​​in the different PUSCH occasions in the pattern. In a multi-PUSCH CG consisting of a set of PUSCH occasions in one or more slots or CG periods, for a first HARQ process with preconfigured RV values, the nth PUSCH occasion can be used for the initial transmission with RV 0, the nth-kth PUSCH occasion can be used for a first retransmission with RV 2, the nth-kth PUSCH occasion can be used for a second retransmission with RV 3, and the nth-kth PUSCH occasion can be used for a third retransmission with RV 1. The RV values ​​can be different for different HARQ transmission patterns. WTRU can select a HARQ transmission pattern with different RV values ​​and indicate the selected pattern based on the traffic pattern and associated QoS.

[0265] In connection with the indication of the CG muting pattern for use with CG PUSCH, WTRU may receive configuration information that may include, for example, one or more of the following: a CG configuration for multiple PUSCH; a set of one or more CG muting patterns (e.g., each muting pattern may indicate a subset of PUSCH occasions with configured grant (CG) and a location of the PUSCH occasions that are muted / not used in a time window); criteria for selecting the one or more CG muting patterns (e.g., minimizing the number of non-matching occasions); and / or threshold values ​​associated with payload size, remaining delay, and / or number of repetitions.

[0266] A WTRU can receive, for example, PDUs from higher layers. Petition 870250088293, dated 09 / 29 / 2025, pp. 104 / 140 94 / 106 sets of PDUs.

[0267] WTRU can determine the pattern of PUSCH usage (e.g., number and location of PUSCH occasions used) based on, for example, the PDUs received from the PDU pool and one or more of the following conditions or criteria: a payload of multiplexed PDU(s) in a PUSCH occasion is above a first payload threshold value and / or below a second payload threshold value (per PUSCH occasion); a remaining delay of the PDU pool is less than or equal to a delay threshold value (e.g., associated with PSDB); and / or a number of repetitions per PDU of the PDU pool is above a first repetition threshold value and / or below a second repetition threshold value (e.g., associated with PSER).

[0268] WTRU may select one or more CG muting patterns from the configured set based on the determined PUSCH usage pattern and one or more of the following conditions or criteria: minimize the number of non-matching occasions (e.g., the number of PUSCH occasions used in the traffic pattern that do not match the non-muted occasions) in each CG muting pattern relative to the determined PUSCH usage pattern; and / or WTRU may combine multiple CG muting patterns (e.g., pattern merging) that may result in meeting the criteria.

[0269] WTRU can transmit an indication containing the index(es) for the selected CG muting pattern(s).

[0270] FIGS. 5A and 5B illustrate an example implementation for selecting and indicating a pre-configured CG muting pattern. The WTRU can select and indicate a pre-configured CG muting pattern (e.g., CG 2 muting pattern) that may be closely correlated with the XR traffic pattern and the use of PUSCH CG occasions determined by the WTRU. Petition 870250088293, dated 09 / 29 / 2025, pp. 105 / 140 95 / 106

[0271] WTRU-assisted selection of the FDRA configuration for multi-PUSCH CG (multi-PUSCH CG) can be provided.

[0272] A WTRU can determine the FDRA configuration and can transmit an indication to request activation / deactivation of an FDRA configuration for multi-PUSCH CG (multi-PUSCH CG). The WTRU can select and / or transmit an indication to request activation, for example, dynamically activating or deactivating an FDRA configuration for one or more PUSCH CG occasions if configured with multi-PUSCH CG. This selection of an FDRA configuration from a set of pre-configured FDRAs can be performed by the WTRU based on the determination of XR and QoS traffic attributes (e.g., payload size of PDU sets, remaining delay of the PDU set, and number of repetitions).

[0273] The WTRU can receive configuration information and / or parameters associated with one or more multi-PUSCH CG configurations (e.g., number of PUSCH occasions per slot, number of slots per CG period). The WTRU can receive, in dynamic configuration or signaling (e.g., in DCI or MAC CE), one or more FRDA subconfigurations (which may be called, for example, FDRA subconfiguration).One or more FDRA subconfigurations may comprise, for example, one or more of the following parameters: FDRA subconfiguration index / ID (e.g., a group of FDRA subconfigurations may be configured with a group index); FRDA type indication (e.g., type 0 or type 1); indexes / IDs of one or more BWPs associated with the FDRA subconfiguration; initial offset feature block (RB) or feature block group (RBG); RBG size (e.g., number of RBGs in a BWP); a set of consecutive or non-consecutive RBs or feature block groups (RBGs) (e.g., a set of consecutive RBGs may be indicated in the form of a feature indication value (RIV), consisting of the initial RBG offset and length). Petition 870250088293, dated 09 / 29 / 2025, pp. 106 / 140 96 / 106 consecutive RGBs) (for example, a set of non-consecutive RGBs can be indicated in the form of a bitmap with a given length, where each '1' bit can indicate the availability / allocation of an RGB); and / or associated information indicating the mapping / association between the FDRA subconfiguration and a set of one or more PUSCH occasions, slots, or CG periods in a multi-PUSCH CG configuration. The associated information indicating the mapping / association between the FDRA subconfiguration and a set of one or more PUSCH occasions, slots, or CG periods in a multi-PUSCH CG configuration may comprise a set of one or more PUSCH occasions, slots, or CG periods in a multi-PUSCH CG associated with a group of FRDA subconfigurations (e.g., group index).For example, a set of PUSCH occasions in a CG slot can be associated with a group index corresponding to a group of FDRA subconfigurations, where each subconfiguration can consist of a different initial offset and number of RBGs. For example, the WTRU can be configured with multiple RIV values ​​corresponding to different FDRA subconfigurations for the same set of one or more PUSCH occasions. A default FDRA subconfiguration can be configured for a set of one or more PUSCH occasions, slots, or CG periods in a multi-PUSCH CG. The resources (e.g., RBs or RBGs) in the default FDRA subconfiguration and other FDRA subconfigurations may or may not overlap in the frequency domain. A new or non-default FDRA subconfiguration can be selected by the WTRU for an associated set of PUSCH occasions if the default FDRA subconfiguration is determined to be inadequate.In examples, the WTRU may receive one or more Demodulation Reference Signal (DMRS) feature configurations and / or association information indicating the association between the DMRS feature configurations and the FDRA subconfigurations. These DMRS feature configurations may be received based on consecutive or non-consecutive RGB sets and / or sets of... Petition 870250088293, dated 09 / 29 / 2025, pp. 107 / 140 97 / 106 occasions of PUSH.

[0274] The WTRU may receive, in the configuration information, criteria consisting of a set of threshold values ​​to select one or more FDRA subconfigurations for a set of PUSCH occasions, slots, or CG periods based on the traffic pattern and / or QoS. These threshold values ​​may include limits associated with the payload size of the PDU set, remaining delay, and number of repetitions for the PDUs in the PDU set. The WTRU may receive, in the configuration information, a maximum time duration (e.g., in terms of ms, symbols, slots, periods) to perform, for example, one or more of the following: determine if the default FDRA subconfiguration associated with the set of PUSCH occasions, slots, or CG periods is adequate; select an FDRA subconfiguration from the pre-configured set; and / or transmit a prompt to request activation of the selected FDRA subconfiguration.

[0275] A WTRU may receive one or more PDUs from a set of PDUs from higher layers or from another WTRU (e.g., over SL). The WTRU may determine the PUSCH usage pattern (e.g., number and locations of PUSCH occasions to be used or not) for a set of PUSCH occasions and / or may select an FDRA subconfiguration for the PUSCH occasions based on one or more conditions or criteria. If the payload of one or more PDUs in the set of multiplexed PDUs in a PUSCH occasion configured with a default FDRA subconfiguration (e.g., default set of RBGs) is less than or equal to a first payload threshold value (per PUSCH occasion and / or per default set of RBGs) and / or greater than a second payload threshold value, the WTRU may determine the PUSCH occasion (with default FDRA subconfiguration) as used.If the payload of one or more PDUs in the multiplexed PDU set in a PUSCH event configured with standard FDRA subconfiguration is... Petition 870250088293, dated 09 / 29 / 2025, pp. 108 / 140 If 98 / 106 is less than the second payload threshold value (for PUSCH operation and / or standard RGB array), WTRU may determine the PUSCH operation as not used.

[0276] If the remaining delay of the PDUs in the PDU pool is less than or equal to a delay limit associated with the PSDB, and / or the PDUs in the PDU pool in the buffers can be multiplexed into the set of PUSCH occasions configured with the default FDRA subconfiguration, the WTRU may determine the set of PUSCH occasions with the default FDRA subconfiguration as used. If the remaining delay of the PDUs in the PDU pool is greater than the delay limit associated with the PSDB and / or the PDUs can be delayed to the next slot or CG period outside the time window, the WTRU may determine the PUSCH occasions with the default FDRA configuration as unused.

[0277] If the PDUs in the PDU pool cannot be transmitted within the remaining delay associated with PSDB when multiplexing the PDUs into the defined PUSCH occasions configured with the default FDRA subconfiguration, the WTRU may determine a subset of one or more initial PUSCH occasions and select a pre-configured FDRA subconfiguration for the initial subset of PUSCH occasions. The WTRU may determine the subsequent subset of PUSCH occasions as unused. The WTRU may select an FDRA subconfiguration for the initial subset of PUSCH occasions so that the PDUs in the PDU pool can be multiplexed into the subset of PUSCH occasions with an extended number of RBGs and transmitted within the remaining delay.For example, for a set of PUSCH occasions [0, 1, 2, 4] with a default FDRA subset consisting of 100 RBGs per PUSCH occasion, the WTRU can determine the PUSCH occasion subset [0, 1] as used and the PUSCH occasions [2, 3] as unused. For the used PUSCH occasions, the WTRU can select an FDRA subset with 200 RBGs so that the PDUs... Petition 870250088293, dated 09 / 29 / 2025, pp. 109 / 140 99 / 106 of the PDU set can be transmitted within the remaining delay.

[0278] If the number of repetitions of one or more PDUs (for example, PDUs with a priority greater than a priority threshold value) in the PDU set is less than or equal to a first repetition threshold value and / or greater than a second repetition threshold value, the WTRU may determine the corresponding PUSCH occasions with the default FRDA subconfiguration as used. The WTRU may determine any of the PUSCH occasions with the default FRDA subconfiguration that do not contain any new or repeated PDUs as unused.

[0279] The WTRU can transmit the indication in the selected FDRA subconfiguration containing the ID / index of the selected FDRA subconfiguration and the IDs / indices for the PUSCH occasions / slots / periods to which the selected FDRA subconfiguration can be applied. Such an indication can contain a pair of information elements related to the index of the selected FDRA subconfiguration and the bitmap or initial offset / length of the corresponding PUSCH occasions / slots / periods. In examples, the WTRU can transmit in an indication the index for the RIV associated with the selected FDRA subconfiguration. Such an indication can be transmitted in any UCI, CG-UCI, or new UCI. Such an indication can be transmitted using the PUCCH feature or the PUSCH feature.In examples, WTRU can implicitly indicate the selected FDRA subconfiguration for the network by using a pre-configured DMRS resource setting associated with the selected FDRA subconfiguration and / or by transmitting DMRS using the associated DMRS resource setting.

[0280] The WTRU can receive from the network (e.g., in RRC, MAC CE, or DCI signaling) signaling indication indicating the activation of the selected FDRA subconfiguration or a new one (e.g., FDRA subconfiguration index) and / or deactivation of the default FDRA subconfiguration. In examples, the Petition 870250088293, dated 09 / 29 / 2025, pp. 110 / 140 100 / 106 WTRU can receive (e.g., in DCI) the indexes for one or more RIVs associated with the enabled / disabled FDRA subconfiguration for the set of PUSCH occasions that WTRU is expected to use. WTRU can then transmit, for example, the PDUs from the set of PDUs using the resourced PUSCH occasions in the enabled FDRA subconfiguration.

[0281] In examples related to WTRU-assisted selection of FDRA configuration / subconfiguration for multi-PUSCH CG (multi-PUSCH CG), the WTRU may receive configuration information that may include, for example, one or more of the following: at least one multi-PUSCH CG configuration; and / or one or more FDRA subconfigurations and parameters associated with the subconfigurations (e.g., initial RBG offset, number of RBGs per FDRA subconfiguration, information on association with a group of PUSCH occasion(s) in a CG period). At least one of the FDRA subconfigurations may be configured as a default FDRA subconfiguration.

[0282] The WTRU can receive, for example, PDUs from PDU sets from higher layers. The WTRU can determine the FDRA subconfiguration for a group of PUSCH occasions and the PUSCH usage information (e.g., number of PUSCH occasions used / not used) for a set of PUSCH occasions based, for example, on one or more of the following: a payload of multiplexed PDU(s) in a PUSCH occasion with default FDRA subconfiguration is above a first payload threshold value and / or below a second payload threshold value (per PUSCH occasion); a remaining delay of the PDU set is less than or equal to a delay threshold value (e.g., associated with PSDB); and / or a number of repetitions per PDU of a PDU set is above a first repetition threshold value and / or below a second repetition threshold value (e.g., associated with PSER).

[0283] A WTRU can transmit an indication containing the subconfiguration Petition 870250088293, dated 09 / 29 / 2025, pp. 111 / 140 101 / 106 of selected FDRA and PUSCH usage information for the set of PUSCH occasions.

[0284] The WTRU may receive (e.g., in DCI) an activation indication in the selected or new FRDA subconfiguration and / or a deactivation indication for the default FDRA subconfiguration for the corresponding set of PUSCH occasions.

[0285] WTRU can transmit PDUs from the PDU pool using resources on occasions when FDRA subconfiguration is enabled and CG PUSCH is enabled.

[0286] FIG. 6 describes an example of a WTRU implementation transmitting an indication to activate a selected FDRA configuration. The WTRU can transmit an indication to dynamically activate a selected FDRA configuration for one or more CG PUSCH occasions if configured with multiPUSCH CG.

[0287] Time offset of PUSCH occasions can be provided in CG configuration for multiple PUSCH.

[0288] A WTRU can determine the time offset of PUSCH occasions in multi-PUSCH CG. In examples, the WTRU can determine the time offset (e.g., advance or delay) of a subset of PUSCH occasions in a CG period to transmit a delayed plurality or batch of PDUs from a set of PDUs based on the arrival time of a previous plurality or batch of PDUs and jitter estimation. The WTRU can trigger the SR / BSR to request DG resources if the time-shifted PUSCH occasions cannot accommodate the delayed batch of PDUs within the remaining delay associated with PSDB.

[0289] In examples, the WTRU may receive configuration information and / or parameters including, for example, one or more multiPUSCH CG settings (e.g., number of PUSCH occasions per slot, number of slots per Petition 870250088293, dated 09 / 29 / 2025, pp. 112 / 140 102 / 106 CG period). A CG configuration for multiple PUSH events can consist of one or more groups of consecutive or non-consecutive PUSH occasions, where a second group can be separated from a first group by a default initial offset value. WTRU can receive configuration information and / or parameters, including, for example, association information (e.g., mapping relationship) between one or more jitter interval values ​​and initial offset values ​​for a group of multi-PUSH occasions in a CG period. The different initial offset values ​​can be configured with different indexes / IDs.

[0290] A WTRU may receive from higher layers or from another WTRU (via SL), a first batch of one or more PDUs from a set of PDUs. The WTRU may determine a first group of PUSCH occasions (e.g., number of PUSCH occasions expected to be used for the first batch) to transmit the first batch of PDUs based on the payload sizes of the received PDUs.

[0291] The WTRU can determine the jitter interval (e.g., maximum jitter value) for receiving a second plurality or batch of PDUs from the PDU pool based on the arrival time of the first plurality or batch of PDUs (e.g., time elapsed since the arrival of the first batch of PDUs in an LCH buffer) and the remaining time associated with the PSDB. The WTRU can also determine a second batch of PUSCH occasions (e.g., number of PUSCH occasions expected to be used in the second batch) based on information about the total payload size and / or total number of PDUs from a PDU pool in the first batch of PDUs. The WTRU can determine a new initial offset for the second group of PUSCH occasions to transmit the second batch of PDUs based on the determined jitter interval and the configured association information.For example, the new initial offset value may result in the push occasions in the second group being advanced or delayed by one or more time units (e.g., Petition 870250088293, dated 09 / 29 / 2025, pp. 113 / 140 103 / 106 example, in terms of ms, symbols, occasions, slots, periods), based on the expectation that the second batch of PDUs from the PDU set will arrive later or earlier in the WTRU buffer.

[0292] A WTRU can transmit an indication to the network about the new initial offset value (e.g., initial offset index) corresponding to the second group of PUSCH occasions, and the number of PUSCH occasions expected to be used or not used in the second group. Such an indication can be transmitted in one or more UCIs, CG-UCIs, or new UCIs. Such an indication can be transmitted using the PUCCH feature or the PUSCH feature. Such an indication can be transmitted along with the first batch of PDUs in the PDU pool using the first group of PUSCH occasions.

[0293] The WTRU may trigger and / or transmit an SR or BSR to request DG resources based on the detection of any of the following conditions: the location of at least one PUSCH occasion in the second group of PUSCH occasions after the application of the new initial offset exceeds the slot threshold; the delay to transmit the second batch of PDUs in the next slot period or CG is greater than the PSDB; and / or the total payload size of the second batch of PDUs is greater than the size of the second group of PUSCH occasions within the slot threshold after the application of a new initial offset.

[0294] The WTRU may receive from the network (e.g., on MAC CE or DCI) a confirmation indication regarding the new initial offset or a different initial offset value (e.g., index) to be applied to the second group of PUSCH occasions. The WTRU may also receive (e.g., on DCI) the DG resources requested by the WTRU. Upon receiving the second batch of PDUs, the WTRU may transmit the PDUs using the second group of PUSCH occasions, which may be time-shifted by the new / indicated initial offset and / or with the DG resources. Petition 870250088293, dated 09 / 29 / 2025, pp. 114 / 140 104 / 106

[0295] The WTRU can be configured to trigger and transmit an indication to request the activation / deactivation of a subset of configured grant (CG) PUSCH occasions if the configured CG PUSCHs are not suitable (e.g., mismatch in quantity and timing) and / or if the timing offset of the PUSCHs is based on the payload size of the PDU pool and the jitter estimate for the arrival of some PDUs from the PDU pool.

[0296] In examples related to the time shift of PUSCH occasions in a CG configuration for multiple PUSCH, the WTRU may receive configuration information comprising, for example, one or more multi-PUSCH CG configurations and / or a mapping relationship between jitter interval and initial shift of a group of multi-PUSCH occasions in a CG period.

[0297] The WTRU can receive, for example, from an upper layer, a first batch of PDUs from a set of PDUs. The WTRU can determine a first group of PUSCH occasions (e.g., a number of PUSCH occasions to be used) to transmit the first plurality or batch of PDUs based on the payload sizes of the PDUs.

[0298] WTRU can determine the jitter interval for receiving a second batch of PDUs from the PDU pool based on the arrival time of the first batch of PDUs and the remaining time associated with PSDB.

[0299] WTRU can determine a new start offset for a second group of PUSCH occasions to transmit the second plurality or batch of PDUs based on the jitter interval and mapping ratio.

[0300] WTRU can transmit an indication (e.g., in CG-UCI) about the new start offset of the second group of PUSCH occasions and the first batch of PDUs in the first group of PUSCH occasions.

[0301] WTRU may trigger SR / BSR for DG based, for example, on one or more of the following conditions or criteria: a subset of a second Petition 870250088293, dated 09 / 29 / 2025, pp. 115 / 140 105 / 106 group of PUSCH occasions after applying a new initial offset is greater than (>) a slot threshold; a delay to transmit the second batch of PDUs in a next slot is greater than (>) PSDB; a total payload size of the second batch of PDUs is greater than (>) the size of the second group of PUSCH occasions within a slot threshold after applying the new initial offset.

[0302] WTRU may receive (e.g., in DCI) a confirmation indication of a new start shift for the second group of PUSCH occasions and / or DG resources.

[0303] The WTRU can receive, for example, from higher layers, the second batch of PDUs from the PDU set.

[0304] WTRU can transmit the second batch of PDUs in the second set of PUSCH occasions with the new start offset.

[0305] FIG. 7 describes an example of implementing a WTRU by determining the time offset (e.g., delay) of a subset of PUSCH occasions. In the example shown in FIG. 7, the WTRU can determine the time offset (e.g., delay) of a subset of PUSCH occasions in slot 2 to transmit a delayed batch of PDUs based on the determined jitter interval of the PDUs.

[0306] Although the features and elements described in the present invention are described in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0307] The description of the present invention contained herein may be provided for exemplary purposes only and in no way limits the applicability of the systems, methods and instrumentation described to other wireless technologies and / or to wireless technology using different principles, where applicable. The term network in this disclosure may refer to one or more gNBs which, in turn, may be associated with one or more Petition 870250088293, dated 09 / 29 / 2025, pp. 116 / 140 106 / 106 Transmission / Reception Points (TRPs) or any other node in the radio access network.

[0308] Although the implementations described in the present invention may consider specific 3GPP protocols, it is understood that the implementations described in the present invention are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described in the present invention consider specific LTE, LTE-A, New Radio (NR) or 5G protocols, it is understood that the solutions described in the present invention are not restricted to this scenario and are also applicable to other wireless systems.

[0309] The processes described in the present invention can be implemented in a computer program, software and / or firmware embedded in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted by wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media, such as but not limited to, internal hard disks and removable disks, magneto media and optical media, such as compact discs, CD-ROMs and / or digital versatile discs (DVDs).A processor, in conjunction with software, can be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, or any host computer. Petition 870250088293, dated 09 / 29 / 2025, pp. 117 / 140

Claims

1 / 4 CLAIMS 1. Wireless transmit and receive unit (WTRU), CHARACTERIZED in that it comprises: a processor configured to: receive configuration information comprising a configured set of configured grant muting patterns (CG); determine a plurality of packet data units (PDUs), the plurality of PDUs being available for transmission; determine an uplink shared physical channel usage pattern (PUSCH) based on at least the plurality of PDUs; select one or more CG muting patterns from the configured set of CG muting patterns based on at least the determined PUSCH usage pattern; and send an indication of one or more selected CG muting patterns.

2. Wireless transmit and receive unit (WTRU), according to claim 1, CHARACTERIZED in that the configuration information further comprises one or more of the following: a CG configuration for multiple PUSH; criteria for selecting one or more CG muting patterns from the configured set of CG muting patterns; or threshold values ​​associated with one or more of the following: payload size, remaining delay, or number of repetitions.

3. Wireless transmission and reception unit (WTRU), according to claim 2, CHARACTERIZED in that each of the one or more muting patterns in the configured set of CG muting patterns indicates a subset of PUSCH occasions and locations of PUSCH occasions that are muted within a time window.

4. Wireless transmission and reception unit (WTRU), according to claim 2, CHARACTERIZED in that the criteria for selecting one or more CG muting patterns from the configured set of CG muting patterns comprise criteria that minimize a number of unmatched occasions, the unmatched occasions corresponding to PUSCH occasions that do not correspond to unmuted occasions.

5. Wireless transmitting and receiving unit (WTRU), according to any one of claims 1 to 4, CHARACTERIZED in that the plurality of PDUs is associated with a set of PDUs.

6. Wireless transmitting and receiving unit (WTRU), according to any one of claims 1 to 5, CHARACTERIZED in that the PUSCH usage pattern indicates whether each of a plurality of PUSCH occasions associated with the PUSCH usage pattern is used or not.

7. Wireless transmit and receive unit (WTRU), according to any one of claims 1 to 6, CHARACTERIZED in that the processor configured to determine the PUSCH usage pattern based on at least a plurality of PDUs is configured to determine the PUSCH usage pattern based on at least one payload of multiplexed PDUs on an occasion when PUSCH is above a first payload threshold value or below a second payload threshold value.

8. Wireless transmit and receive unit (WTRU), according to any one of claims 1 to 6, CHARACTERIZED in that the processor configured to determine the PUSCH usage pattern based on at least the plurality of PDUs is further configured to determine the PUSCH usage pattern based on at least one delay of a set of PDUs being less than a delay threshold.

9. Wireless transmit and receive unit (WTRU), according to any one of claims 1 to 6, CHARACTERIZED in that the processor configured to determine the PUSCH usage pattern based on at least the plurality of PDUs is further configured to determine the PUSCH usage pattern based on at least one number of repetitions per PDU of a set of PDUs being at least one above a first repetition threshold or below a second repetition threshold.

10. Wireless transmission and reception unit (WTRU), according to any one of claims 1 to 9, CHARACTERIZED in that the processor configured to select one or more CG muting patterns from the configured set of CG muting patterns based on at least the determined PUSCH usage pattern is further configured to select one or more CG muting patterns from the configured set of CG muting patterns by combining multiple CG muting patterns to minimize a number of mismatched occasions in each one or more CG muting patterns with respect to the determined PUSCH usage pattern.

11. Wireless transmission and reception unit (WTRU), according to any one of claims 1 to 10, CHARACTERIZED in that the indication of one or more selected CG muting patterns from the configured set of CG patterns comprises an index associated with one or more selected CG muting patterns.

12. Method of supporting the use of wireless PUSCH, CHARACTERIZED in that it comprises: receiving configuration information comprising a configured set of configured grant muting patterns (CG); determining a plurality of packet data units (PDUs), the plurality of PDUs being available for transmission; determining an uplink shared physical channel usage pattern (PUSCH) based on at least the plurality of PDUs; selecting one or more CG muting patterns from the configured set of CG muting patterns based on at least the determined PUSCH usage pattern; and Petition 870250088293, dated 09 / 29 / 2025, pp. 139 / 140 4 / 4 sending an indication of one or more selected CG muting patterns.

13. Method according to claim 12, CHARACTERIZED in that the configuration information further comprises one or more of the following: a CG configuration for multiple PUSH; criteria for selecting one or more CG muting patterns from the configured set of CG muting patterns; or threshold values ​​associated with one or more of the following: payload size, remaining delay, or number of repetitions.

14. Method according to claim 13, CHARACTERIZED in that each of the one or more CG muting patterns in the configured set of CG muting patterns indicates a subset of configured grant (CG) PUSCH occasions and locations of configured grant (CG) PUSCH occasions that are muted within a time window.

15. Method according to claim 13, CHARACTERIZED in that the criteria for selecting one or more CG muting patterns from the configured set of CG muting patterns comprise criteria that minimize a number of unmatched occasions, the unmatched occasions corresponding to PUSCH occasions that do not correspond to unmuted occasions. Petition 870250088293, dated 09 / 29 / 2025, p. 140 / 140

Images