EP4691110A1

EP4691110A1 - Configured grant muting pattern for configured grant pusch usage

Info

Publication number: EP4691110A1
Application number: EP24722926.3A
Authority: EP
Inventors: Jaya Rao; Senay NEGUSSE; Paul Marinier; Tejaswinee LUTCHOOMUN; Oumer Teyeb; Ananth KINI; Ahmed Mostafa; Ognen OGNENOSKI
Original assignee: InterDigital Patent Holdings Inc
Current assignee: InterDigital Patent Holdings Inc
Priority date: 2023-04-04
Filing date: 2024-04-04
Publication date: 2026-02-11
Also published as: KR20250171348A; CN121195584A; WO2024211522A1

Abstract

Instrumentalities are described for determining an indication of a CG muting pattern for CG RUSCH usage. A WTRU may receive configuration information comprising one or more of a multi-PUSCH configured grant (CG) configuration, a set of one or more CG muting patterns, criteria for selecting one or more CG muting patterns, or threshold values associated with one or more of payload size, remaining delay, and number of repetitions. The WTRU may receive a plurality of PDUs associated with a PDU set. The WTRU may determine a RUSCH usage pattern based on at least the plurality of PDUs associated with the PDU set. The WTRU may select one or more configured grant muting patterns from a configured set based on at least the determined RUSCH usage pattern. The WTRU may transmit an indication containing an index to the selected one or more configured grant muting patterns.

Description

CONFIGURED GRANT MUTING PATTERN FOR CONFIGURED GRANT PUSCH USAGE

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63/457,036, filed April 4, 2023, the contents of which is incorporated by reference herein.

BACKGROUND

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

SUMMARY

[0003] Systems, methods, and instrumentalities are described herein that may be associated with providing an indication of a configured grant (CG) muting pattern for CG physical uplink shared channel (PUSCH) usage. A wireless transmit and receive unit (WTRU) may receive configuration information. The configuration information may comprise, for example, one or more of a multi-PUSCH configured grant (CG) configuration, a set of one or more CG muting patterns, criteria for selecting one or more CG muting patterns, or threshold values associated with one or more of payload size, remaining delay, or number of repetitions. Each muting pattern may indicate a subset of CG PUSCH occasions and location of the PUSCH occasions that are muted/unused over a time window. The criteria for selecting one or more CG muting patterns may be specified to minimize the number of unmatched occasions, where the unmatched occasions correspond to PUSCH occasions that do not match with unmuted occasions.

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

[0005] The WTRU may select one or more configured grant muting patterns from a configured set based on at least the determined PUSCH usage pattern. The WTRU may select the one or more configured grant muting patterns based on the determined PUSCH usage pattern using criteria such as, for example, to minimize the number of unmatched occasions in each CG muting pattern with respect to the determined PUSCH usage pattern. The unmatched occasions may comprise, for example, a number of used PUSCH occasions in the traffic pattern that do not match with the unmuted occasions. The WTRU may combine multiple CG muting patterns, which may be referred to as a union of patterns, that may result in meeting the criteria. For example, the combined multiple CG muting patterns may meet the criteria of minimizing the number of unmatched occasions in each CG muting pattern.

[0006] The WTRU may transmit an indication containing an index to the selected one or more configured grant muting patterns.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

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

[0009] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1 A according to an embodiment.

[0010] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 2 depicts an example implementation of a WTRU determining PUSCH usage.

[0012] FIG. 3 depicts an example implementation of determining a location to send an indication of

PUSCH usage. [0013] FIG. 4 depicts an example implementation for determining to update information provided in a first indication regarding the usage of CP PUSCH occasions.

[0014] FIGs. 5A and 5B depict an example implementation of selecting and indicating a preconfigured CG muting pattern.

[0015] FIG. 6 depicts an example implementation of a WTRU transmitting an indication to activate a selected FDRA configuration.

[0016] FIG. 7 depicts an example implementation of a WTRU determining to time-shift (e.g., delay) a subset of PUSCH occasions.

DETAILED DESCRIPTION

[0017] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings.

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

[0019] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a ON 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a “station” and/or a “ST A”, 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 cellular telephone, 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 (loT) device, a watch or other wearable, 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 an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0020] The communications 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 interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B (eNB), a Home Node B, a Home eNode B, a gNode B (gNB), a NR NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

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

[0022] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT). [0023] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may 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 (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA).

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

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

[0026] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may 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).

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

[0028] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize 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, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106/115.

[0029] The RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 may provide call control, billing services, mobile location-based services, pre-paid calling, 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 appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

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

[0031] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology. [0032] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0033] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0036] The transceiver 120 may 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 noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 , for example.

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

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

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

[0040] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs 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. The peripherals 138 may include one or more sensors, the sensors may be one or more of 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.

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

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

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

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

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

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

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

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

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

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

[0051] In representative embodiments, the other network 112 may be a WLAN.

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

[0053] When using the 802.11 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0054] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

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

[0056] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0057] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may 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 sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports (e.g., only supports) a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0058] In the United States, the available frequency bands, which may be used by 802.11 ah, 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.11 ah is 6 MHz to 26 MHz depending on the country code.

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

[0060] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

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

[0062] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may 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 the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0063] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface. [0064] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

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

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

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

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

[0069] In view of Figures 1A-1 D, and the corresponding description of Figures 1A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0070] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, 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 purposes of testing and/or may perform testing using over-the-air wireless communications.

[0071] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0072] Disclosed herein are implementations for supporting Multi-PUSCH (physical uplink shared channel) CG (configured grant) in wireless systems. A WTRU may transmit assistance information associated with multi-PUSCH CG to a network. The WTRU may receive information/indications associated with multi-PUSCH CG config from the network. The events and/or conditions may be associated with triggering the indication of PUSCH usage in multi-PUSCH CG. The WTRU may determine the PUSCH usage based on a dynamically signaled time window. The WTRU may determine the location to transmit the indication on PUSCH usage. The WTRU may determine to update the indication on PUSCH usage. The WTRU may select a preconfigured CG muting pattern for indicating the PUSCH usage. The WTRU may determine the FDRA (frequency domain resource allocation) config and transmit an indication to request activation/deactivation of an FDRA config for multi-PUSCH CG. The WTRU may determine to timeshift PUSCH occasions in multi-PUSCH CG.

[0073] The term extended Reality (XR) may 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 among them. Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering may be designed to mimic, e.g., 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 limits defined by the application. Augmented Reality (AR) may involve a user being provided with additional information or artificially generated objects/items or content overlaid upon their current environment. Mixed Reality (MR) may be an advanced form of AR where some virtual elements may be inserted into the physical scene with the intent to provide the illusion that these elements are part of the real scene. XR may include real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0074] The notion of immersion in the context of XR applications/services may refer to the sense of being surrounded by the virtual environment as well as providing the feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality practically indiscernible from actual reality. [0075] In examples, a WTRU may correspond to an XR device/node, e.g., any XR device/node, which may come in variety of form factors. A WTRU (e.g., an XR WTRU) may include, but not is limited to the following: Head Mounted Displays (HMD); optical see-through glasses and camera see-through HMDs for AR and MR; mobile devices with positional tracking and camera; wearables; haptic gloves; haptic body suit; haptic shoes; etc. Additionally, several different types of XR WTRU may be envisioned based on XR device functions such as, for example, 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 device/nodes/WTRUs may be grouped into a collaborative XR group for supporting any of XR applications/experience/services. [0076] In XR services and applications, the traffic may consist of data/PDUs which may be associated with an application data Unit (ADU), a PDU set, or a data burst. In an example, the PDUs belonging to a PDU set may be associated with different segments or components of a video frame or a video slice. A data burst may consist of one or more PDU sets that may be transmitted/received over a time window. For example, a number of PDUs in a PDU set or data burst transmitted in UL and/or received in DL may be dependent on the type of the media frame (e.g., 3D video frame, audio frame).

[0077] In an XR application, e.g., a typical XR application, a WTRU may transmit XR traffic consisting of one or more PDUs/PDU sets in uplink (UL) (e.g., pose, gesture, video data) and/or may receive XR traffic in downlink (DL) (e.g., video, audio, haptics). Such traffic may be transmitted and/or received periodically or aperiodically in one or more data flows (e.g., quality of service (QoS) flows). During UL transmissions, XR traffic may arrive from the application layer at a WTRU and/or from different devices/terminals/WTRUs (via sidelink) at different time instances. Such XR traffic may be characterized by different traffic attributes such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU/PDU set level priority/importance and different levels of inter-dependencies between PDUs/PDUs sets. Such XR traffic (e.g., PDU/PDU sets) received by the WTRU from higher layers or other devices/terminals may also experience different delays, jitter, data rate and loss rate. To ensure that the 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 may be performed on a timely basis considering the PDU set attributes. To ensure quality of experience (QoE), the PDUs within a PDU set or different PDU sets generated at the transmitting side of the application may be expected to be delivered to the receiving side of the application within a QoS (e.g., PDU-set delay budget (PSDB), PDU-set integrated handling indication (PSIHI)).

[0078] In XR traffic, the different PDUs or PDU sets may contribute to different user experiences (e.g., QoE). As such, the PDUs/PDU sets may be associated with different importance/priority values from application layer perspective. It may also be that the one or more PDU sets transmitted sequentially in time domain may be inter-dependent with each other in different ways. In other words, unlike the existing QoS framework where all PDUs/PDU sets in a flow may be provided with the same forwarding treatment by assuming equal importance/priority, the PDUs/PDU sets in a data burst for XR traffic may be, e.g., need to be, differentiated and handled differently QoS-wise at the lower layers, e.g., irrespective of whether the PDUs/PDU sets may be in one or more QoS flows, during scheduling and transmissions in UL and/or DL. [0079] The inter-dependencies between the PDUs/PDU sets in a single or multiple QoS flows may result in different challenges for meeting the QoS at PDU set level during transmission in UL and DL. For example, if the PDUs from different PDU sets may be multiplexed into the same radio bearer or logical channels and subsequently mapped to different occasions/slots/periods in the resources (e.g., CG), tracking the association between the PDUs for meeting the PDU-set level QoS may be challenging, if, for example, there may be delays and jitter during reception and processing. Systems that ensure proper mapping and/or multiplexing of the PDUs/PDU sets to one or more configured resources over time and frequency domain such as PUSCH occasions or resource block groups (RBGs) considering traffic characteristics (e.g., delays and jitter during reception of PDUs/PDU sets over SL or from higher layers, variable payload sizes and variable priority/importance) to meet PDU set-level QoS during UL transmissions are unknown.

[0080] A WTRU supporting an XR experience may be receiving data units (e.g., PDUs, PDU sets or data bursts) from higher layers or different devices, such as AR glasses and haptics gloves (e.g., via SL). Such data units, which may have variable payload sizes, different periodicity and different interdependencies may be further processed and transmitted by the WTRU in the UL. To avoid latency during scheduling of resources during UL transmission of the data units, the WTRU may be configured with configured grants (CG).

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

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

[0083] The WTRU may transmit an indication of any unused CG PUSCH occasions to the network. But indicating the PUSCH usage based, e.g., only based, on the payload of data in the buffers at the WTRU without considering overall XR traffic attributes/patterns (e.g., PDU/PDU set arrival, remaining delay, jitter) may result in not meeting the associated QoS and inefficiency for resource usage since the WTRU may inaccurately indicate a higher PUSCH usage than actually used during UL transmission.

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

[0085] An issue to be addressed includes how to ensure QoS of XR data units (e.g., PDUs, PDU sets and data bursts) using multi-PUSCH CG when considering XR traffic attributes (e.g., remaining delay, reliability, jitter). An issue to be addressed includes how to indicate the usage of CG resources to the network on a timely basis to improve resource usage efficiency.

[0086] Transmission of indication of PUSCH usage over a time window or period may be provided. A WTRU may receive configuration information which may comprise, for example, a multi-PUSCH CG configuration, which may be referred to as CG config. The WTRU may receive, from, for example, a higher layer, PDUs of a PDU set.

[0087] The WTRU may receive from a network (NW) device, e.g., in DCI (downlink control information), a request for PUSCH usage. The request for PUSCH usage may comprise, for example, a time window, which may be referred to as a time period, associated with PUSCH usage. The time window may be indicated by a start offset PUSCH occasion and duration within which the WTRU may indicate the number and location of used/unused PUSCHs.

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

[0089] The WTRU may determine the PUSCH usage (e.g., a number and the locations of the PUSCH occasions) over the time window based on one or more of the following: a payload of PDU(s) multiplexed in one or more PUSCH occasions is less than (<) a payload threshold (e.g., a percentage of total payload of the PDU set); and a remaining delay of PDUs of the PDU set is less than (<) a delay threshold (e.g., the 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 next slot/period.)

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

[0091] The WTRU may transmit the PDUs using the indicated PUSCH occasions.

[0092] Indicating a CG muting pattern for CG PUSCH usage may be provided. A WTRU may receive config info, including, for example: a multi-PUSCH CG config; a set of one or more CG muting patterns (e.g., each muting pattern may indicate a subset of CG PUSCH occasions and a location of the PUSCH occasions that may be muted/unused over a time window); criteria for selecting one or more CG muting patterns (e.g., minimize the number of unmatched occasions); and threshold values associated with payload size, remaining delay, and/or number of repetitions. [0093] The WTRU may receive, e.g., from higher layers, PDUs of PDU sets. The WTRU may determine the PUSCH usage pattern (e.g., a number and location of the used PUSCH occasions) based on the received PDUs of the PDU set and one or more of the following criteria: a payload of PDU(s) multiplexed into 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)).

[0094] The 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 used PUSCH occasions in the traffic pattern that do not match with the unmuted occasions) in each CG muting pattern with respect to the determined PUSCH usage pattern; and/or the WTRU may combine multiple CG muting patterns (e.g., union of patterns) that may result in meeting the criteria.

[0095] The WTRU may transmit an indication containing the index(s) to the selected CG muting pattern(s).

[0096] A WTRU-assisted selection of FDRA (frequency domain resource allocation) configuration for multi-PUSCH CG may be provided. A WTRU may receive configuration information which may include, for example: at least one multi-PUSCH CG configuration; and/or one or more FDRA sub-configs and parameters associated with the sub-configs (e.g., start offset RBG, number of RBGs per FDRA sub-config, association information with a group of PUSCH occasion(s) in a CG period). At least one of the FDRA subconfig may be configured as a default FDRA sub-config.

[0097] The WTRU may receive, from higher layers, PDUs of PDU sets.

[0098] The WTRU may determine the FDRA sub-config for a group of PUSCH occasions and the

PUSCH usage information (e.g., number of used/unused PUSCH occasions) for a set of PUSCH occasions based on one or more of the following criteria: a payload of PDU(s) multiplexed into a PUSCH occasion with default FDRA sub-config 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 PDU set is less than or equal to a delay threshold value (e.g., associated with PSDB); 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). [0099] The WTRU may transmit an indication containing the selected FDRA sub-config and PUSCH usage information for the set of PUSCH occasions.

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

[0101] The WTRU may transmit the PDUs of a PDU set using resources in the activated FDRA subconfig and CG PUSCH occasions.

[0102] Time-shifting of PUSCH occasions in multi-PUSCH CG configuration may be provided. A WTRU may receive configuration information comprising, for example: a multi-PUSCH CG config; and a mapping relation between jitter range and start offset of a group of multi-PUSCH occasions in a CG period.

[0103] The WTRU may receive, e.g., from a higher layer, a first batch or plurality of PDUs of a PDU set.

[0104] The WTRU may determine a first group of PUSCHs occasions (e.g., a number of PUSCH occasions to be used) for transmitting the first batch of PDUs based on the payload sizes of the PDUs. [0105] The WTRU may determine the jitter range for receiving a second plurality or batch of PDUs of the PDU set based on the arrival time of the first plurality/batch of PDUs and the remaining time associated with PSDB.

[0106] The WTRU may determine a new start offset for a second group of PUSCH occasions for transmitting the second plurality/batch of PDUs based on the jitter range and the mapping relation (e.g., between jitter range and start offset).

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

[0108] The WTRU may trigger SR/BSR (scheduling req uest/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 applying the new start offset is greater than (>) a slot boundary; a delay for transmitting the second batch of PDUs in a next slot is greater than (>) PSDB; a total payload size of a second plurality/batch of PDUs is greater than (>) a size of a second group of PUSCH occasions within slot boundary after applying new start offset.

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

[0110] The WTRU may receive, e.g., from higher layers, the second plurality/batch of PDUs of the PDU set. [0111] The WTRU may 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 may correspond to any of QoS flows or data flows (e.g., flow of data consisting of one or more PDUs, PDU sets or data bursts, which may be inter-dependent with one and another 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 intended to a common destination device/WTRU or group of associated devices/WTRUs may be referred to as 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; PDU sets; data bursts; and/or group of frames/PDUs/PDU-sets/data bursts. Such data units, which may be transmitted or received by the WTRU may sequentially (e.g., one after the other) or in parallel (e.g., over different channels/links/resources), may or may not be inter-dependent with each other.

[0115] In examples, QoE may correspond to any of the following: application and/or higher layer metrics and measurements, which may be directly or indirectly detectable/visible at the WTRU and/or application function. Such QoE metrics and measurements may or may not be directly visi ble/detectable at the base station, for example. Such QoE metrics and measurements may be determi ned/performed as a function of QoS metrics/parameters (e.g., latency, data rate, reliability, RTT/MTP latency).

[0116] In examples, 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 for assigning COUNT/SNs for 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., set of one or more frequency/time/spatial resources such as symbols, slots, subcarriers, resource elements or beams). Radio resources may be associated with configurated grants (CG), dynamic grants (DG) and/or any other resource grants or grant free resources.

[0117] In examples, mapping configuration may correspond to any of the following: parameters and/or configurations associated with mapping from one or more of data units, PDUs, SDUs, PDU sets, data bursts, application data units (e.g., ADD), QoS or data flows (e.g., associated or non-associated), which may originate from any of application layer, higher layers, and network, on the one hand; and one or more radio bearers (e.g., DRBs, SRBs), sublayers or entities (e.g., SDAP, new layer, PDCP, RLC, MAC, PHY), LCHs, carriers or component carriers (e.g., CCs in CA configurations), BWPs, CG configurations/resources (e.g., CG periods, slots, PUSCH occasions, RBGs), HARQ processes and radio links/interfaces (e.g., Uu link or sidelinks), which may be used for delivering the data/PDUs in UL direction or DL direction, for example.

[0118] In examples, multi-PUSCH CG, may correspond to one or more configured resources 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 resources). A PUSCH occasion may consist of one or more resource blocks or resource block groups in the frequency domain.

[0119] In examples, PUSCH usage may refer to any of the number, location, position, or timing of one or more PUSCH occasions in one or more slots 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 may apply. PDU Set Delay Budget (PSDB) may indicate time between reception of the first PDU (e.g., at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU Set (e.g., at the network in UL). PDU Set Integrated Handling Indication (PSI HI) may indicate whether all PDUs of the PDU Set may be needed for the usage of PDU Set by application layer; PDU Set Error Rate (PSER) indicates an upper bound for a rate of non-congestion related PDU Set losses between RAN and the WTRU. Jitter may refer to variation with respect to 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 may be expected to be received periodically at different periodic time instances, jitter may refer to the variation with respect to the periodic time instances (e.g., for a data unit that may be received T1 ms in advance or T2 ms later than an expected time instance at T, the jitter range is T2 - T1). Jitter may refer to an instantaneous value or a statistical value (e.g., average, variance, standard deviation, max/min). Remaining delay may refer to the time duration remaining for receiving or transmitting one or more PDUs of a PDU set before the PSDB. Remaining delay may also be referred to as the time to live (TTL) associated with a PDU set.

[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 PDU set, ADU, or data burst; a PDU set; a data burst; Application/high layer importance/priority; and/or QoS/data flow.

[0122] With respect to attributes associated with PDU set, ADU or data burst, a PDU set (e.g., media unit, video frame) may comprise of one or more PDUs. Such PDUs within a PDU set or PDU sets within a data burst may be inter-dependent with each other at the application layer and/or lower layers (e.g., AS- layers). Such attributes may include any of, for example, the number of PDUs in a PDU set/data burst, payload sizes of one or more data units (e.g., PDUs/PDU set/data burst), the association/correlation between one or more data units, importance/priority of the data units, status of transmission (e.g., percentage of PDUs of one or more data units transmitted/received successfully), remaining delay for transmitting/receivi ng one or more PDUs within a PDU set/data burst delay bound(s), effective data rate and/or effective reliability associated with transmission of PDUs of one or more PDU sets/data bursts. In an example, such attributes associated with the data units may be visible at one or more lower layers (e.g., at PDCP, RLC, MAC, PHY sub-layers/layers), possibly for supporting additional actions (e.g., prioritizing, mapping to an LCH, multiplexing into one or more TBs, scheduling, triggering/transmitting an indication) based on any of the following: markings in the data units; reception of an indication such as a control PDU; mapping of the data units from a higher layer to a configuration associated with a lower layer; tracking of the attributes of the PDUs at any buffer associated with sublayer, radio bearer and/or logical channel; and/or restrictions associated with the sublayer, radio bearer and/or logical channel to which the data units may be mapped to.

[0123] With respect to markings in the data units, such markings may include, for example, sequence numbers, IDs, indexes, timestamps, and time offset values (e.g., with respect to a reference time) in the header of data units. Such markings may be made by higher layers, any preceding sub-layer/layer or another device/WTRU.

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

[0125] With respect to mapping of the data units from a higher layer to a configuration associated with a lower layer, the WTRU may have visibility of higher layer attribute(s) at a lower layer when mapping the PDUs to one or more radio bearers or logical channels (LCHs) that may be configured to provide similar forwarding treatment associated with the higher layer attribute(s) to the mapped PDU.

[0126] With respect to tracking of the attributes of the PDUs at any buffer associated with sublayer, radio bearer and/or logical channel, the WTRU may track the attributes associated with the data units based on any of the time elapsed since the reception of a first PDU of a PDU set, the remaining time for the PDUs of a PDU set for meeting PSDB, jitter between the arrival one or more PDUs within/across PDU sets, and/or percentage/payload size of remaining PDUs of a PDU set expected to be received.

[0127] With respect to restrictions associated with the sublayer, radio bearer and/or logical channel to which the data units may be mapped to, the WTRU may have visibility of the data units and determine the corresponding actions (e.g., perform prioritization per LCP, perform mapping to restricted CG configurations, CG periods or CG PUSCH occasions) based on the configured restrictions associated with the one or more sublayers, radio bearers and/or LCHs to which the data units may be mapped to.

[0128] A PDU set may be associated with PDU set-level QoS requirements (e.g., data rate, latency, error rate, reliability), which may be applicable for one or more or all 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 may refer to the data produced by the application in a short period of time, comprising PDUs from one or more PDU Sets. Such attributes, associations and inter-dependencies (e.g., intra-PDU set and/or inter-PDU set), including the 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) may be visible to the AS-layers (e.g., with associated IDs) and/or handled at the AS layers with the awareness of the association during data transmission in UL and reception in DL.

[0130] Application/high layer importance/priority may refer to the different PDUs in a PDU set or all PDUs in a PDU set may be associated with different application/high layer importance/priority values. Such an importance value may correspond to spatial importance (e.g., spatial position of the video frame whose data may be carried by the PDU/PDU set, where PDUs/PDU set carrying FoV spatial positions may be associated with higher spatial importance than non-FoV spatial positions) or temporal importance (e.g., time sequence of the video/application frame whose data may be carried by the PDU/PDU set, where PDUs/PDU sets carrying base video frames such as l-frame may be associated with higher temporal importance than differential video frames such as P-frame/B-frame). Such importance values may be visible to the AS layers (e.g., with associated IDs/markers/indications), possibly enabled by application awareness, during data transmission and reception. [0131] QoS/data flow may refer to the PDUs/PDU sets of an application that may be encoded and delivered by the application to WTRU (in UL) or network (in DL) via one or more QoS/data flows. The different QoS flows carrying the PDUs/PDU sets associated with an XR application/experience may be visible to the AS-layers (e.g., with associated IDs) and/or handled at the AS layers with the awareness 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: determining of content or metadata of an application; performing measurement and reporting; transmitting/forwarding of data units and/or ensuring QoS associated with the data units; and/or transmitting/forwarding of information/indications associated with connectivity with network and/or other WTRUs.

[0133] With respect to determining content or metadata of application (e.g., XR application), determining content or metadata may involve determining the importance and/or priority of the content in the data units. The importance may be associated with the spatial importance and/or temporal importance of content/data. The spatial/temporal importance value may indicate the absolute or relative importance associated with the content. Spatial importance may be associated with one or more segments/tiles/slices/positions of in spatial dimension. Temporal importance may be associated with one or more frames/subframes of in time dimension.

[0134] With respect to performing measurements and reporting, the WTRU may perform measurements of positioning/spatial/pose (e.g., 6DoD/3DoD orientation, location/position), rate of motion/movement, etc. of the user/WTRU and/or other objects (e.g., virtual or real) which the user may be interacting with. The WTRU may send/report the pose measurements to the network, periodically or when 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, sidelink RS), GNSS signals, unlicensed carriers, ultra-wideband signals, LIDAR signals, visual signals, etc. The WTRU may perform measurements of the radio link interfaces associated with the WTRU (e.g., Uu link, SL). The WTRU may trigger transmission and/or measurement of reference signals in other one or more WTRUs (e.g., via Uu link and/or sidelink). Measurement reports may be sent, for example, to a network and/or another WTRU.

[0135] With respect to transmitting/forwarding of data units and/or ensuring QoS associated with the data units, data units may include any of media/image/video frames, sensor data, and measurement data (e.g., pose measurements, link/channel measurements) determined by a WTRU, possibly for supporting 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 in the WTRU or in the network). The WTRU may perform splitting/merging of data units in one or more QoS flows into one or more forwarding configurations during transmission/receptions.

[0136] Transmitting/forwarding of information/indications associated with connectivity with network and/or other WTRUs may comprise sending capability information to a network, including a capability for supporting one or more traffic flows with different XR traffic patterns (e.g., periodic/aperiodic, PDU sets with variable payload sizes), a capability for performing application layer measurements (e.g., QoE measurements, application buffer measurements, RTT measurements), and/or a capability for detecting changes to traffic patterns. Transmitting/forwarding of information/indications may comprise transmitting inter-WTRU coordination capability information to a network, including a capability for supporting one or more interfaces, a capability to coordinate and/or interact with other WTRUs/devices (e.g., via SL interfaces), which may be co-located or non-co-located with the WTRU. Transmitting/forwarding of information/indications may comprise transmitting RACH preamble(s) for initial access or for (re)establishing connectivity with a RAN node, cell or another WTRU. Transmitting/forwarding of information/indications may comprise receiving configuration, including receiving RRC configuration from gNB and/or NAS-layer configuration from CN. Transmitting/forwarding of information/indications may comprise transmitting and/or receiving assistance data to/from network associated with traffic, QoS, scheduling, etc., for supporting UL/DL transmissions. Transmitting/forwarding of information/indications may comprise transmitting requests for radio resources and/or resource grants (e.g., dynamic grants, semi- static/configured grants).

[0137] Implementations for meeting QoS when configured with multi-PUSCH CG may be provided. The data units consisting of any of PDUs, PDU sets or data bursts associated with XR traffic may be marked by the WTRU (in UL at SDAP, PDCP, RLC, MAC layer) and transmitted with multi-PUSCH CG with one or more of the following: Sequence Numbers (SNs): SNs may be marked on a per PDU, per PDU set or per data burst basis wherein the different types of SNs may include COUNTS, hyper-frame 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 of a PDU set may be required to be delivered); PDU set attributes: type, total payload size (e.g., bits/bytes, number of PDUs), start PDU of a PDU set/data burst, end/last PDU of a PDU set/data burst (end marker); and/or Timing/count information: Timestamp indicating the time when a PDU may be generated or received in a buffer, remaining delay with respect to a delay budget (e.g., PSDB), hop count (e.g., a number of traversed or remaining hops), timing offset with respect to a reference time (e.g., SFN, arrival time of first PDU of PDU set). [0138] Such marking (e.g., in the PDU headers) may be used by the transmitting and/or receiving entities for performing certain actions associated with any of determining whether the data units may be prioritized and/or multiplexed in one or more TBs, the number of TBs that may be used, whether the data units may be delivered in one or more slots/periods, whether the data units may be delayed to subsequent slots/periods, a number of repetitions that may be applied for the data units or a subset of the data units.

[0139] The data units consisting of any of PDUs, PDU sets or data bursts associated with XR traffic, with the same or different QoS requirements/characteristics, may be mapped to one or more forwarding configurations using mapping configurations. The different forwarding configurations may be configured to achieve/enforce different QoS when transmitting the PDUs/PDU sets with multi-PUSCH CG. The PDU sets received from application in one or more QoS flows may be mapped using a mapping configuration (e.g., at 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 may be possibly associated/grouped for achieving/ensuring PDU set level QoS. Upon mapping, a set of parameters (e.g., priority, PBR, BSD) and/or configurations (e.g., LCP restrictions) may be applied at the forwarding configurations for achieving/enforcing 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 the PDUs of different PDU sets or PDU sets of 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 flows, the WTRU may apply certain mapping, buffer/queue management and adaptation mechanisms at one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC) such that the expected QoS for the PDUs/PDU sets may be satisfied. A similar approach may be applied if the WTRU expects to receive any of the PDU/PDU sets in DL from the network. For ensuring QoS of the data units, the different layers in the forwarding configuration may be configured with different configuration parameters. Such configuration parameters may include support for reordering of the PDUs/PDU sets at PDCP, support for AM/UM in RLC, LCP rules/restrictions and associated LCH parameters (e.g., PBR, BSD, priority) at MAC and number of HARQ transmissions.

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

[0142] The expected QoS may be stricter or relaxed than the default QoS metric applied associated with the PDUs/PDU sets. For example, if a PDU set arrives late at the WTRU or the importance value for the PDU set is indicated to be high (e.g., above a threshold), having experienced more delay and jitter at the application layer (e.g., due to encoder) or reception over SL (e.g., due to congestion), the expected latency to be satisfied during transmission over the Uu link for the PDU set will be lower than the default PSDB that may be used, e.g., may typically be used, for sending the PDUs of the PDU set. If a PDU set arrives early or the importance value for the PDU is indicated to be low (e.g., below a threshold), the expected latency during transmission over the Uu link may be considered to be more relaxed than the PSDB that may be used, e.g., may normally be used, for sending such PDUs. In examples, the expected QoS may vary dynamically based on the QoS experienced during reception and/or importance/priority indications, where for a fixed QoS (e.g., PDB, PER, PSDB, PSER) an increase/decrease in the expected QoS prior to reception may translate to decrease/increase in the expected QoS during transmission/reception over the radio link (e.g., Uu link, SL).

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

[0144] The WTRU may assist the network for configuring and/or indicating the usage of the resources associated with the multi-PUSCH CG based on any of the following: configurations; triggering events; and/or conditions/criteria received from a network and/or application. The WTRU may be configured with one or more conditions and/or configurations associated with the usage 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 when detecting a change of such expected QoS. [0145] A WTRU may transmit assistance information associated with multi-PUSCH CG to the network. The WTRU may send information associated with multi-PUSCH CG to the network, including any information for configuring one or more CG configurations with multi-PUSCH occasions/resources at the WTRU, information related to the usage of the multi-PUSCH CG configuration(s) (e.g., a number of PUSCH occasions used or unused by the WTRU) and information for making adaptations to the multi- PUSCH CG configuration(s). The information sent by WTRU for configuring or indicating the usage of multi-PUSCH CG may be associated with XR traffic (e.g., periodicity of PDUs/PDU sets, payload sizes of PDU set, association of PDUs to PDU sets) expected to be transmitted in UL or received in DL. Such information may enable the network to have awareness of the traffic characteristics, and configure/adapt the resources associated with multi-PUSCH CG at the WTRU. In examples, such information associated with multi-PUSCH CG may be transmitted by the WTRU to one or more other WTRUs (e.g., over SL) if the WTRUs may be associated with a common group or XR experience.

[0146] The information/indications associated with configuration, usage or adaptations associated with multi-PUSCH CG may be sent by the WTRU to the network or other WTRUs as one or more of the following message types: capability information; assistance information; preferred/desired configuration information (e.g., preferred forwarding and/or resource configurations/parameters to apply in UL/DL); status information/indication (e.g., associated with any of the AS-layers); resource usage information (e.g., expected usage of resources or PUSCH occasions); measurement/status reports (e.g., pending data in buffer, data expected to be received, remaining delay, jitter); and/or request/response messages (e.g., request for activation/deactivation of a CG configuration or set of parameters associated with multi-PUSCH CG, request for time-frequency resources, request for adapting parameters/configuration of multi-PUSCH CG).

[0147] The information may be sent by WTRU in any of the following methods: periodically (e.g., using one or more configured periodicity values); aperiodically or dynamically (e.g., when detecting triggering events/conditions described herein or as an update indication when detecting a change in information sent previously); and/or semi-persistent (e.g., sent periodically with a periodicity value or in a burst manner over a time window/duration).

[0148] The WTRU may switch between a first periodicity value and a second periodicity value for sending information, possibly based on the type of event detected (e.g., change in 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 may change between sending information periodically and aperiodically based on whether any change and/or amount of change is determined in the information to be reported. [0149] The WTRU may send the information/indications associated with multi-PUSCH CG to network via, for example, one or more of the following message types: RRC signaling and/or 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, padding BSR, enhanced BSR, pre-emptive BSR, delay status report (DSR) which may include remaining delay information and/or amount of time elapsed since data arrival in buffer, elastic BSR which may be scalable/adjustable by sending subsequent indications, possibly without cancelling an earlier BSR); UCI (e.g., single bit SR, multi-bit SR, feedback, ACK/NACK, CSI report); CG-UCI (e.g., one or more bitmaps or set of parameters such as start offset and number of PUSCH occasions); PUSCH (e.g., indication such as CG-UCI may be multiplexed in PUSCH along with data); Non- AS (NAS) layer 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: I dentifiers/l Ds; priority of CG resources/configurations or data; devices associated with the application; data/traffic types associated with the data flows; traffic characteristics and/or parameters associated with any of QoS flows, PDU sets, and data bursts; buffer information at application layers/higher layers/AS layers; QoS requirements or expected QoS associated with the data; CG resource usage; preferred/desired configuration information; information on updated forwarding configurations applied at WTRU; indication for activating/deactivating configurations; and/or measurements related to application/AS layer.

[0151] With respect to identifiers/IDs, the 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/resources (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 duration/window when there may or may not be data for transmission); IDs/indexes associated with CG muting patterns (e.g., a muting pattern may indicate the occasions/slots over a time duration/window when there may not be any configured PUSCH resource/occasion); IDs associated with HARQ processes (e.g., HARQ process IDs associated with one or more PDUCH occasions, TBs, PDUs or PDU sets); Group ID (e.g., associated with group of forwarding configurations, group of devices/WTRUs); IDs of individual QoS flows, mapping configurations, and/or forwarding 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., ID or SNs indicating the association and/or dependency between one or more PDUs, PDU sets, data bursts, and/or flows). [0152] With respect to priority of CG resources/configurations or data, a WTRU may comprise information on the relative/absolute priority values associated with one or more CG PUSCH occasions or CG periods, and data expected to be mapped to the PUSCH occasions/CG periods.

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

[0154] With respect to Data/T raffic types associated with the data flows, the WTRU may send information on different data/QoS flows associated with an application, where the data type may include video data (e.g., l-frame data, P-frame data, B-frame data), RGB-D data, 360 degrees video data, haptics data, pose/positioning data, audio data, etc.

[0155] With respect to traffic characteristics and/or parameters associated with any of QoS flows, PDU sets, and data bursts, the WTRU may send information on traffic characteristics/patterns of the different QoS flows, including whether the data is periodic, aperiodic, semi-persistent, quasi-periodic, etc. The traffic characteristics may include the one or more periodicity values of the flow. The WTRU may send information on the payload sizes of PDU sets and a number of PDUs expected per PDU set in one or more flows. The information of payload size of PDU set or the number of PDUs per PDU set may also include statistical/distribution information such as mean, min, max, and/or standard deviation values. The information related to PDU set may include an indication of start/first and/or end/last PDU of a PDU set, and an indication of the association/dependency of the PDUs in a PDU set (e.g., ID of PDU set, importance/priority value). The WTRU may send information on data bursts in one or more QoS flows, including the number of PDU sets (e.g., instantaneous, mean, max, min), payload size of data burst in units of bits/bytes (e.g., instantaneous, mean, max, min), periodicity, importance/priority, start and end indication of a data burst (e.g., ID of first PDU/PDU set, ID of last PDU/PDU set), and dependency information within data burst and across multiple data bursts (e.g., indicating whether PDU sets in one or more data bursts may be dependent). The WTRU may send information related to the delay in UL and/or in DL, including remaining delay with respect to PSDB, and time elapsed since the PDUs/PDU set arrive at a WTRU (e.g., at one or more buffers at the WTRU). Such delay information which may be sent on a per flow, per radio bearer, per-LCH, per-PDU set or per PDU basis, may include the range, mean, maximum and minimum value, for example. The WTRU may send information related to the jitter in UL and/or in DL. Such jitter information which may be sent on a per flow, per-radio bearer, per-LCH, per-PDU set or per PDU basis, may include the range, mean, maximum and minimum value, for example. The WTRU may send information on the importance/priority of any of the data units (e.g., PDUs, PDU sets, data bursts) to be transmitted/received in UL/DL. The WTRU may send indications if detecting any changes to the UL/DL traffic patterns (e.g., changes to periodicity, changes to mean payload sizes, changes to jitter range). The WTRU may send information on a prediction of traffic pattern in UL and/or DL for upcoming/expected data (e.g., timing information indicating the PUSCH occasion, time slot or CG periods when the data is expected to arrive, payload size of expected data, importance of data expected, uncertainty and/or confidence level of expected data or prediction associated with the expected data over a time window/duration.)

[0156] With respect to buffer information at application layers/higher layers/AS layers, the WTRU may send information on the amount of data payload or the buffer level (e.g., with respect to one or more configured threshold values) at the application, including data waiting to be delivered to lower layers for UL transmission and/or data received in DL which may be waiting to be delivered to higher layers/application. Such buffer information may be reported, for example, in terms of one or more of the following: estimated or measured time duration for the data waiting in the buffer before delivered to lower layers or consumed by application; data buffered at application/higher layer, new layer, SDAP, PDCP, RLC, MAC, LCG, LCHs; and/or payload size (e.g., total, instantaneous, mean, max, min) at the granularity of one or more data units (e.g., PDUs, PDU set, data burst).

[0157] With respect to QoS requirements or expected QoS associated with the data, the WTRU may send the QoS requirements or expected QoS of the one or more flows or data units (e.g., PDUs, PDU sets, data bursts), including data rate, latency, reliability, absolute/relative priority values, etc. The information on QoS requirements may also include statistical/distribution information such as mean, min, max, standard deviation values. The WTRU may also indicate that such QoS requirements or expected QoS may be supported on different QoS granularities such as, for example, the following: 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 to the different QoS granularities. The WTRU may indicate such expected QoS to be achieved on different resource granularities such as, for example, the following: per group of one or more CG configurations, CG periods, time slots, PUSCH occasions, radio blocks, radio block groups.

[0158] With respect to CG resource usage, the WTRU may send information/indications associated with the usage of the CG PUSCH occasions and/or resources in one or more CG configurations. Such usage information may include the number of PUSCH occasions in a time window (e.g. one or more slots or CG periods) expected to be used or not used during UL transmissions. The length of each PUSCH occasion, in terms of number of symbols per PUSCH occasion, may be either the same or different, for example. Such usage information may also include the number of resource blocks or resource block groups (RBGs) in the frequency domain resource allocation (FDRA) on a per set of one or more PUSCH occasions that may be expected to be used or not used during UL transmission. Such usage information may also include the number of PUCCH occasions or resources (e.g., SR, HARQ feedback, CSI report) expected to be used or not used in a set of one or more slots or CG periods during UL transmissions. The WTRU may indicate information on the usage of such CG resources (e.g., a number of used or unused PUSCH occasions or resources) as one or more of the following: start 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 bit ‘1’ in the bitmap may indicate whether a PUSCH occasion or slot is expected to be used or unused by the WTRU wherein such a bitmap may allow indicating the usage of non-consecutive PUSCH occasions or slots; information on PUSCH occasions expected to be used or unused/skipped (e.g., N out of M occasions) in a time window due to jitter or delays in traffic arrival time; one or more gap value indicating the number of PUSCH occasions expected to be used or unused between at least two sets of PUSCH occasions, wherein such a gap value may be indicated in the form of a start offset symbol/occasion/slot/period of the gap and the length of the gap (e.g., a number of symbols/occasions/slots/periods); and/or a validity duration of the indicated CG resource usage (e.g., in ms or in number of slots or periods during which the indicated CG resource usage may be assumed to be valid). The WTRU may determine to change the transmission frequency of the indication on PUSCH usage (e.g., a number of times the indication may be triggered in a time window) as a function of jitter range (e.g., min/max value), jitter duration (e.g., whether the observed jitter may be sustained over a duration), priority/importance of data and/or QoS of data (e.g., PSDB). For example, for a set of high priority or high QoS PDUs, the WTRU may choose to indicate the unused PUSCH occasions after, e.g., only after, observation of a sustained (e.g., over a duration) high jitter. For the case where low priority PDU set or PDU set with lower QoS, the WTRU may indicate the PUSCH usage sooner even if the accuracy of the information in the indication may be low. The WTRU may transmit the indication on CG resource usage (e.g., PUSCH usage) in, for example, one or more of the following: UCI (e.g., using preconfigured PUCCH resource, which may be configured with any of periodic resources with certain periodicity, per-CG configuration, per-CG period, per-LCH, per-radio bearer, and/or per-PDU set); CG-UCI (e.g., with new information elements appended to existing CG-UCI or one or more of existing information elements in existing CG-UCI may be repurposed/replaced with PUSCH usage info); and/or New UCI on PUSCH usage (e.g., may be multiplexed with PUSCH).

[0159] With respect to preferred/desired configuration information, the 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. Such preference information, associated with multi-PUSCH CG, may include any of the number of CG active configurations, periodicity of CG configuration, 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 at one or more PUSCH occasions, and other parameters associated with TDRA and/or FRDA configurations. The WTRU may associate and/or indicate weight/probability values to different CG/resource configurations when sending requests related to preferred configuration. The weight/probability value may be determined based on the likelihood of a configuration to be applied during transmission. The network may use such weight/probability information for determining and providing to the WTRU a combined configuration and/or for activating/deactivating a configuration that may match with the weight values indicated by WTRU. The WTRU may indicate uncertainty information (e.g., percentage/probability) associated with the usage of any of the CG resources (e.g., PUSCH occasions or slots) over one or more time windows/duration (e.g., one or more slots or CG periods).

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

[0161] With respect to an indication for activating/deactivating configurations, the WTRU may send an indication to the network to request for activating/deactivating a mapping/forwarding/resource configuration and/or parameters associated with the configurations, possibly preconfigured in the WTRU. The WTRU may include the ID of the configuration/parameter when sending the request indication.

[0162] With respect to measurements related to application/AS layer, the WTRU may send RSRP, RSRQ, RSSI measurements of the signals, channels, radio links, carriers, etc., possibly associated with the one or more WTRU actions. For example, the WTRU may send the QoS related measurements related to arrival time, delays, jitter, and number of PDUs/PDU sets/data bursts received possibly over a time duration, change in the 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 delivering the PDUs/PDU sets/data bursts. [0163] The implementations described herein may use any of the one or more information elements (e.g., assistance information, preferred configurations) sent by the WTRU to the network.

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

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

[0166] The WTRU may receive any of the information/indications (e.g., described herein) associated with multi-PUSCH CG via, for example, one or more of the following: RRC signaling and/or messages; control PDUs associated with any of the AS layers (e.g., SDAP control PDU, PDCP control PDU); DL MAC CE; DCI; PUSCH; Non-AS (NAS) layer signaling (e.g., a PDU Session Establishment Response or a PDU Session Modification Command); and/or Application layer signaling/messages.

[0167] With respect to RRC signaling and/or messages (e.g., dedicated/unicast signaling via any of SRBs, or broadcast/SIB), RRC signaling may be used for configuring any parameters (e.g., MCS, FDRA, TDRA) associated with Type 1 and Type 2 multi-PUSCH CG. RRC signaling may be used for activating/deactivating Type 1 multi-PUSCH CG.

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

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

[0170] The information/indications associated with multi-PUSCH CG (e.g., configurations and parameters) which may be received by a WTRU from the network, 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.

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

[0172] The parameters associated with multi-PUSCH CG resources/configurations may include, for example, one or more the following: frequency hopping (e.g., whether intra-slot or inter-slot frequency hopping may be allowed); DMRS configuration (e.g., symbols/resources used for DMRS for one or more PUSCH occasions or slots); MSC table (e.g., whether the same or different set of MCS may be applied to the one or more PUSCH occasions in a CG period, wherein WTRU may 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); resource for UCI on PUSCH usage (e.g., whether the resource for sending the UCI on PUSCH usage in multi-PUSCH CG may be PUSCH or PUCCH); location of UCI on PUSCH usage (e.g., one or more locations corresponding to PUSCH or PUCCH occasions for transmitting the UCI on PUSCH usage, wherein an indication is provided of whether the UCI on PUSCH usage is to be transmitted on all PUSCH occasions expected to be used in a time window); Beta offset for UCI on PUSCH usage; RBG size (e.g., a number of consecutive or non-consecutive RBs associated with one or more PUSCH occasions); Power control loop to use; PUSCH alpha value; Bandwidth part 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 over multiple PUSCH occasions); Min distance per repetition (e.g., minimum number of symbols/slots/occasions before repeating a TB in multi-PUSCH CG); Min distance for receiving HARQ feedback (e.g., minimum number of symbols/slots/occasions before an implicit or explicit ACK/NACK feedback may be expected by WTRU for a HARQ process associated with a TB may be transmitted in a PUSCH occasion in multi-PUSCH CG); Periodicity (e.g., associated with CG period of multi-PUSCH CG); Configured grant timer (e.g., time duration for the WTRU to determine whether the transmissions in one or more PUSCH occasions may be successful/not successful, wherein the WTRU may assume ACK if no indications are received upon transmission and the CG timer expires, and the WTRU may assume a NACK if dynamic grant for retransmission is received along with the HARQ process ID in DCI); TDRA parameters associated with PUSCH occasion (e.g., one or more SLIV values where each SLIV may indicate the start offset symbol of a PUSCH occasion and length/number of symbols per PUSCH occasion, index to a row of a preconfigured mapping relation/table associated with TDRA where the row may indicate one or more SLIV values corresponding to different PUSCH occasions in a CG period); FDRA parameters associated with PUSCH occasions (e.g., one or more resource indicator values (RIV) corresponding to number of consecutive resource blocks or resource block groups, index to a row of a preconfigured mapping relation/table associated with FDRA where the row may indicate one or more RIV values corresponding to one or more PUSCH occasions in a CG period); Transmission parameters (e.g. antenna port, pathloss reference index); CG retransmission timer (e.g., time duration for the WTRU to perform autonomous retransmission of a TB, wherein the WTRU may perform retransmission of a TB in the next PUSCH occasion after the CG retransmission timer expires if no indication corresponding to the HARQ process associated with the TB may be received); Number of PUSCH occasions in a slot; Number of slots in a CG period; and/or Start offset of PUSCH occasions and/or CG period in multi-PUSCH CG configuration.

[0173] With respect 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 respect to semi-persistent scheduling (SPS) resources/configurations for DL data receptions, the parameters associated with SPS resources/configurations may include any of periodicity, start offset, duration, BWPs, numerology/SCS values, number of PRBs, number of occasions, number of PDSCH slots per occasion, maximum number/duration/length of PDSCH, one or more MCS values for the SPS PDSCH occasions, antenna ports, etc., for example.

[0174] The WTRU may receive at least one set of configuration parameters associated with default forwarding configuration (e.g., default set of LCHs), which may be activated and/or used during normal scenarios for transmitti ng/recei vi ng data, for example. The WTRU may also receive another set of configuration parameters which may be associated with exceptional operation, possibly activated and/or used when detecting any of the triggering events/conditions (described herein).

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

[0176] With respect 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 AS protocol stack (e.g., RRC, SDAP, PDCP, RLC, MAC, PHY or any new layer). The configurations parameters to be applied at different layers may include, for example, one or more of the following: RLC: whether AM/UM/TM is to be applied and parameters associated with AM/UM/TM operation; MAC: LCH parameters (e.g., priority, PBR, BSD for PDU and/or PDU set level), LCP configurations (e.g., rules/restrictions/policy for PDU and/or PDU set level handling, time duration for changing between different LCP rules/policy), and/or configurations for multiplexing/assembly/reordering; and/or SDAP/PDCP: 1 -to-1 , 1-to-M or N-to-M mapping configurations, markings/indications/IDs to apply (e.g., associated with handling QoS flows, PDU sets, data busts, association information between PDU sets and data bursts), range of values associated with importance/priority information to identify in the PDUs/PDU sets. A SDAP mapping configuration may refer to information and/or criteria that may be used to map the data units (e.g., PDUs, PDU sets, data bursts) at the SDAP layer to one or more PDCP entities/sublayers or DRBs. A PDCP mapping configuration may refer to information and/or criteria that may be used to map the data units at the PDCP layer to one or more RLC entities/sublayers or LCHs.

[0177] AS layer status information/indications may comprise I dentifiers/l Ds. For example, the WTRU may receive information on 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 group of PUSCH occasions, CG slots, CG periods, CG configurations, group of forwarding configurations, group of devices/WTRUs); IDs/indexes of individual PUSCH occasions, CG slots, CG periods, CG configurations, forwarding configurations; and/or Data type/message ID (e.g., PDU set ID, data burst ID, flow ID, PDU ID).

[0178] With respect to validity information, the WTRU may receive validity information associated with the resource configurations (e.g., multi-PUSCH CG configurations, CG periods, CG slots, set of PUSCH occasions) indicating whether/when the configurations may be considered to be valid or invalid, based on one or more of triggering events/conditions. The WTRU may also receive information on whether the configurations are to be deactivated and/or released when determining them to be invalid. For example, the WTRU may receive information on whether the resource configurations are to be considered as valid/invalid based on the RRC state of the WTRU (e.g., CONNECTED, INACTIVE, IDLE) and/or when transitioning between different RRC states. In another example, the WTRU may assume the resource configurations to be valid or invalid based on whether the one or more timer values associated with the configurations are running or expired. The WTRU may receive an indication on 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, the buffer occupancy threshold values associated with any of forwarding configurations may indicate the maximum/minimum amount of data units in one or more granularities/types including PDUs, PDU sets 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 at MAC).

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

[0181] Delay threshold values may be associated with one or more upper and/or lower bound values corresponding to maximum/minimum delay value and/or remaining delay values (e.g., with respect to PSDB) associated with reception, buffering and/or transmission of any of data units (e.g., PDUs, PDU sets, data bursts). Such delay threshold values may be intended 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 bound values corresponding to the difference between a first delay value (e.g., default delay) and a second delay value (e.g., new/updated delay value).

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

[0184] Correlation time window may correspond to the minimum time difference between two triggering events (e.g., buffer level measurements, PDU/PDU set arrival time), where the two events may be considered as correlated between one and another when they occur within the correlation time window. If the two events occur at time instances beyond the correlation time window, they may be considered as independent. The WTRU may use the correlation time window for determining whether to send a new or updated indication on PUSCH usage to network.

[0185] The implementations described herein may use any of the one or more of the, e.g., above, information/indications received by the WTRU from the network.

[0186] Events/conditions associated with triggering the indication on PUSCH usage in multi-PUSCH CG may be provided.

[0187] The WTRU may be configured with one or more events/conditions related to performing 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 of PDU sets from higher layers or other devices/WTRUs, delay for processing and transmitting the data, jitter between arrival of different batches of inter-dependent data units, payload size of data units received and expected to be received); determining new or updated resource usage (e.g., used/unused PUSCH occasions, CG slots/periods, RBGs, TDRA, FDRA) over a time window; transmitting an indication on PUSCH usage when configured with multi-PUSCH CG; transmitting an indication for requesting to update any of the configurations resources or parameters associated with multi-PUSCH CG.

[0188] Such triggering events/conditions may be associated with ensuring to meet the expected QoS when transmitting the data units (e.g., PDUs, PDU sets, data bursts) in UL while using the configured resources multi-PUSCH CG efficiently. Such triggering events/conditions may dictate the time instances (e.g., symbols, occasions, slots, or periods) an action may be performed by the WTRU. For example, the WTRU may indicate the number and the locations of the CG PUSCH occasions in a time window (e.g., consisting of one or more slots or CG periods) that are expected to be used and/or unused. The WTRU may select PUSCH one or more or PUCCH occasions for sending the indication on PUSCH usage based on detection of the 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/higher layers or from another device/WTRU; buffer status and loading at forwarding configurations (e.g., DRBs/LCHs; change of configuration(s) at the WTRU; timing/timestamp information, possibly associated with expected QoS; measurements on Uu links(s) and/or sidelinks; compensation based on status of expected QoS; property associated with CG resource; and/or detection of QoS events.

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

[0190] With respect to an indication/information from application/higher layers or from another device/WTRU, the WTRU may perform any of the WTRU actions (described herein) when receiving an indication from application/higher layers or another WTRU (e.g., over SL). Such an indication may include information on the change of traffic patterns associated with the generation/processing/reception of XR data units in one or more flows.

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

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

[0193] The WTRU may be triggered to perform any of WTRU action(s) based on an indication of importance/priority of the data units. The WTRU may trigger an action (e.g., update the resource usage) for retransmitting a lost/missing PDU and/or transmitting a delayed PDUs with compensation (e.g., low latency) when receiving an indication containing an importance/priority value higher than a threshold.

[0194] Buffer status and loading at forwarding configurations (e.g., DRBs/LCHs) may include at least a condition associated with, for example, one or more of the following or combinations of measurements (e.g., compared to a threshold): the amount of XR data units in one or more buffers associated with forwarding configurations, possibly over a period of time or time window; the rate of arri val/departure of data units in one or more buffers associated with forwarding configurations; the average, max, min size/volume of the data units in an buffers associated with forwarding configurations (e.g. number of PDUs in LCH buffer); the amount of time spent by one or more data units in buffers associated with the forwarding configurations; and/or the number of forwarding configurations meeting a condition/threshold associated with the amount of data, arrival rate, data units (e.g., total payload size). A WTRU may perform any of the actions described herein 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 larger than a threshold time value. For example, a WTRU may perform any of the actions described herein (e.g., send an indication on PUSCH usage) if the buffer status (e.g., total payload size) exceeds a threshold. Other buffer status metrics that may be monitored for determining the expected QoS include the number of data units buffered which may be above/below a configured threshold in one or more associated forwarding configurations, and/or the rate of data unit arri val/departure in the buffer with respect to a configured arri val/departure rate.

[0195] With respect to change of configuration(s) at the WTRU, the WTRU may be triggered to perform any of WTRU action(s) when determining a change to a mapping configuration, forwarding configuration and/or resource configuration, including changing at least one of the parameters at the mapping configuration (e.g., mapping a QoS flow to a new forwarding configuration), changing parameters of DRB/LCHs (e.g., priority, PDB, PBR), changing LCP configuration (e.g., updates to LCP rules or restrictions), changing QoS of data units (e.g., PSDB, PSER, PSIHI), and/or changing resource configurations/parameters (e.g., CG, DG, SPS). The WTRU may be triggered to perform a WTRU action(s) if the CDRX/DRX configuration and any of the associated parameters applied at the WTRU is modified/updated, which may possibly impact the traffic pattern and/or CG resource usage.

[0196] With respect to timing/timestamp information, possibly associated with expected QoS, the WTRU may track the timing related information (e.g., timestamp, sequence number, marker, or timing control PDU) in the one or more data units received in an earlier time window for determining the latency or jitter. The timing information may be used, e.g., may then be used, for determining whether/how QoS may be met for upcoming/new data units in the next time window using the configured resources (e.g., PUSCH occasions in one or more slots/periods). In an example, the timing information may be determined/indicated as a deadline/latency bound and/or survival time that may be satisfied on a per-PDU, per-PDU set, per- data burst or per-QoS flow basis. Such timing information may be determined across one or more associated/correlated QoS flows, including the correlated UL flows, for example. The timing information may also be determined/indicated on a count basis (e.g., data unit count). The WTRU may trigger an action if determining new or updated timing information. The WTRU may send information/indications/reports to network periodically or based on a setting/expiry of a timer.

[0197] With respect to measurements on Uu links(s) and/or sidelinks, the WTRU may perform measurements over the Uu link and/or SL, e.g., corresponding to RSRP, RSSI, CQI and CSI, for determining the expected QoS for the data units expected to be received (e.g., over SL) and/or transmitted (over Uu link). The channel/load measurements made over a certain configured time duration may indicate whether the data units may be able to achieve the expected QoS during transmission and/or reception, or may exceeded the QoS budget (e.g., PSDB) when using the configured CG resources. The WTRU may trigger an action based on the measurements on Uu link and/or SL, for example.

[0198] The WTRU may determine the Uu link or SL conditions based on the number of ARQ/HARQ (ACK/NACK) feedback messages and/or ARQ/HARQ retransmissions made over the one or more HARQ processes associated with the forwarding configurations applied for sending the data units. A ReTx count above a threshold may translate to poor Uu link/SL conditions, and hence, reduced remaining delay or TTL. [0199] The WTRU may be triggered to perform WTRU action(s) and/or send an indication to network if channel measurements made (e.g., RSRP, RSSI, RSRQ, CQI, CSI) on Uu link or SL increases/decreases with respect to a configured threshold and/or remains above/below a threshold for a certain time duration.

[0200] The WTRU may be triggered to perform WTRU action(s) if one or more QoS related measurements (e.g., latency measured for data units in one or more forwarding configurations) exceeds a certain threshold.

[0201] The WTRU may trigger an action, based on a determination of the time duration/jitter, or change in the time duration/jitter between reception of consecutive PDUs associated with an PDU set or consecutive PDU sets associated with a data burst, and/or reception of data units in one or more correlated flows in UL and/or DL. The WTRU may infer an increase/decrease in the jitter between consecutive PDUs for determining whether the processing load at application/higher layer or congestion over SL may be high/low. In this case, for determining the time duration, the WTRU may set a timer if a first data unit (e.g., first PDU of a PDU set) arrives and reset the timer if an associated second data unit (e.g., second PDU of PDU set) arrives. [0202] With respect to compensation based on status of expected QoS, the WTRU may be triggered to perform WTRU action(s) based on determination of expected QoS for one or more data units, including an indication on whether the data units may be either delayed or arrive early, during UL transmission. In this case, the WTRU may trigger an action such that the delayed or early data units may be transmitted with a determined compensation amount, for example, by using configured resources (e.g., PUSCH occasions). The action(s) may be triggered if detecting a change (e.g., higher/lower) in the expected QoS for the data units by a certain threshold.

[0203] The WTRU may determine the delayed PDU to be sent using an earlier PUSCH occasion or in an earlier CG slot/period that enables satisfying a compensation amount, where the compensation amount may be determined by subtracting the expected latency from actual latency.

[0204] With respect to property associated with CG resource (e.g., PUSCH occasion, CG slot, CG period), the WTRU may be configured with a property specific to the CG resource such as, for example, a priority value or a configuration parameter enabling/disabling the specific action for the CG resource. The WTRU may change the parameters of a CG resource associated with high priority as long as the change impacts, e.g., impacts only, other lower priority CG resources.

[0205] With respect to detection of QoS events (e.g., surge in payload size, reception of high importance data), QoS events may include surge 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. The WTRU may be triggered to perform WTRU action(s) when detecting one or more QoS events, possibly by considering the indicated/determined time duration the QoS events may be expected to persist. The WTRU may perform, e.g., may then perform, other WTRU actions that may result in falling back to the default configurations, possibly after the end of the detected QoS events, for example. If a surge event (e.g., increase in total payload or number of PDU sets) is detected, the WTRU may trigger an action to update the number of PUSCH occasions expected to be used or unused in UL for the duration of the surge. If determining reduction in the surge or end of surge event, the WTRU may fallback to using the default number of used/unused PUSCH occasions.

[0206] Implementations for transmission of indication on PUSCH usage over a time window are disclosed.

[0207] A WTRU may determine the PUSCH usage based on a dynamically signaled time window.

[0208] The WTRU may determine the PUSCH usage (e.g., number and timing of PUSCH occasions) if configured with multi-PUSCH CG for transmitting one or more PDUs of at least one PDU set based on a time window signaled dynamically by the network, the payload size of PDUs of a PDU set in LCHs buffers at the WTRU, and/or the remaining delay associated with a PSDB value of the PDU set. Dynamically signaling the request of PUSCH usage along with a time window allows the WTRU to report to the network if, e.g., only if, the network may need the information on PUSCH usage (e.g., during high load scenario) and under certain events/conditions detected at the WTRU (e.g., for data in 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 PDU set. For example, the payload size threshold may be indicated as a one or more percentage values of the resources in a PUSCH occasion that may be used for transmitting data and control signaling.

[0210] The WTRU may receive from higher layers or from another WTRU (e.g., over SL) one or more PDUs of a PDU set. The WTRU may select and/or forward the PDUs of the PDU set to one or more radio bearers and/or LCHs based on a set of parameters associated with the PDUs and/or PDU set including importance/priority, arrival time window of the PDUs, payload sizes of the PDUs, QoS of the PDU/PDU set (e.g., PSDB, PSIHI, PSER), etc. The WTRU may determine the remaining delay of the PDU set based on the arrival time of the PDUs (e.g., time elapsed since the arrival of the first PDU of a PDU set in an LCH buffer) and the PSDB (PDU Set Delay Budget).

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

[0212] The WTRU may determine the PUSCH usage (e.g., number and locations of the PUSCH occasions expected to be used or unused by the WTRU during UL transmission) over the indicated time window based on any of several conditions or criteria. If the payload of one or more PDUs of the PDU set multiplexed into 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, the WTRU may determine the PUSCH occasion as used. If the payload of the one or more PDUs of the PDU set multiplexed into a PUSCH occasion in the time window is less than the second payload threshold value (per PUSCH occasion), the WTRU may determine the PUSCH occasion as unused. If one or more PUSCH occasions in the time window satisfy the payload criteria, WTRU may determine the corresponding PUSCH occasions as used or unused.

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

[0214] If one or more conditions, e.g., the above conditions, are not fulfilled, the WTRU may transmit an indication to the network for reporting the cause (e.g., with the index value) for not fulfilling the conditions or for requesting to update the multi-PUSCH CG configuration (e.g., request for additional PUSCH occasions or DG resource in SR/BSR). Such an indication may be triggered due to the WTRU being unable to determine sufficient PUSCH occasions expected to be used in the time window, or being unable to determine with sufficient accuracy (e.g., confidence level) the PUSCH occasions expected to be used or unused in the time window.

[0215] The WTRU may transmit, e.g., may then transmit, to the network one or more indications on the determined PUSCH usage over the time window. For example, the WTRU may transmit the indication on PUSCH usage in, for example, one or more of the following: a first PUSCH occasion after receiving the request indication from 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 preconfigured (e.g., via RRC) or determined by WTRU based on traffic attributes (e.g., type of PDU set, importance, remaining delay, jitter); a PUSCH occasion selected by WTRU from a set of candidate preconfigured PUSCH occasions, where the selection may be made based on a criteria 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 time duration/window (e.g., one or more slots or CG periods)

[0216] The WTRU may transmit the indication on PUSCH usage in any of UCI, CG-UCI, or new UCI on PUSCH usage. Such an indication may be transmitted using PUCCH resource or PUSCH resource. The WTRU may transmit, e.g., may then transmit, the PDUs of the PDU set using the PUSCH occasions indicated by WTRU as used. [0217] In examples, upon transmitting the indication on PUSCH usage, the WTRU may be configured to start a prohibit timer. The WTRU may retransmit the same indication or another indication on PUSCH usage, for example, after, e.g., only after, the expiry of the prohibited timer.

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

[0219] FIG. 2 depicts an example implementation of a WTRU determining PUSCH usage. In the example shown in FIG. 2, a WTRU may determine the PUSCH usage (e.g., number and timing of PUSCH occasions) based on a time window dynamically signaled by the network, the payload size of PDUs of a PDU, and the remaining delay associated with PSDB.

[0220] A WTRU may determine the location to transmit the indication on PUSCH usage.

[0221] In examples, the WTRU may determine the location (e.g., PUSCH occasion(s)) to send the indication on PUSCH occasions expected to be used or unused in subsequent slots/periods based on a set of configured candidate locations and estimation of delay/jitter for receiving the expected PDUs of PDU sets from higher layers.

[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, for determining and indicating the PUSCH usage). The WTRU may receive, in the configuration, a set of one or more candidate locations (e.g., PUSCH occasions) for transmitting the indication on PUSCH usage in a CG period. The WTRU may receive, in the configuration, a criteria for selecting a location from the set of candidate PUSCH occasion locations based, for example, on one or more of the following: PUSCH occasion closest to maximum jitter relative to first used PUSCH occasion; PUSCH occasion closest to 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] The WTRU may receive from higher layers or from another WTRU (e.g., over SL), a first batch of one or more PDUs of a PDU set. The WTRU may select and/or forward the first batch of PDUs of the PDU set to one or more radio bearers and/or LCHs based on a set of parameters associated with the PDUs and/or PDU set. The WTRU may determine the payload information related to the expected second batch of one or more PDUs of the PDU set based on the information corresponding to the PDU set in the first batch of PDUs (e.g., information on total payload size and/or total number of PDUs of PDU set in first batch of PDUs).

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

[0225] The WTRU may determine the PUSCH usage (e.g., number and locations of the PUSCH occasions expected to be used or unused by the 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 of the PDU set multiplexed into 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, the WTRU may determine the PUSCH occasions as used. If the total payload of the first and second batch of PDUs of the PDU set multiplexed into one or more PUSCH occasions is less than the second payload threshold value (per set of PUSCH occasions), the WTRU may determine the PUSCH occasions as unused.

[0226] If the jitter value determined as the delay in arrival into LCH buffers between the first batch of PDUs and second batch of PDUs of 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 the PUSCH occasions that may not be expected to include any of the PDUs due to jitter as unused.

[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 for transmitting the first batch of PDUs, followed by one or more PUSCH occasions that may be unused due to jitter, and followed by one or more second set of PUSCH occasions that may be used for transmitting the second batch of PDUs of the PDU set. If the total number of used PUSCH occasions in the first set and unused PUSCH occasions may exceed the total number of PUSCH occasions in a 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 may select a location from the candidate set of locations based on the configured criteria for sending the indication on the determined PUSCH usage. For example, the WTRU may select a location closest to maximum jitter value relative to the first used PUSCH occasion. If the maximum jitter value is determined to be low or less than a threshold value, the WTRU may select the first PUSCH occasion for multiplexing and transmitting the indication. In examples, the WTRU may select N out of M candidate locations for sending the indication on the determined PUSCH usage, where N may be equal to M or less than M. If sending the indication in N locations as a bitmap, the bits in the bitmap may be updated to be consistent with the location in which the bitmap may be sent. For example, for a bitmap with 4 bits corresponding to 4 PUSCH occasions, where the M candidate locations for sending the indication on PUSCH usage may be in all four (4) PUSCH occasions and the WTRU selects all four (4) occasions for sending the indication (e.g., N=M), the bitmap sent in the first location may be ‘1101’, in a second location may be ‘0101’, in a third location may be ‘0001 ,’ and in a fourth location may be ‘0000’.

[0229] The WTRU may transmit, e.g., may then transmit, to the network one or more indications on the determined PUSCH usage in the selected location. The WTRU may receive from a network (e.g., in RRC signaling, MAC CE or DCI), an explicit (e.g., ACK/NACK) or implicit confirmation indication on the usage of the 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 expiry of a timer started by the WTRU after sending the PUSCH usage indication. In the case of an implicit NACK, for transmitting 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 configuration, or an indication of activation of another CG configuration.

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

[0231] FIG. 3 depicts an example implementation of determining a location to send an indication of PUSCH usage. A WTRU may determine the location (e.g., PUSCH occasion(s)) to send the indication on PUSCH usage based on a set of configured candidate locations and an estimation of delay/jitter for receiving the expected PDUs of PDU sets.

[0232] A WTRU may determine to update the indication on PUSCH usage.

[0233] The WTRU may determine to update the information provided in a first indication on the usage of CG PUSCH occasions by sending a second indication, based on updated/new information associated with the traffic attributes (e.g., arrival time, jitter, payload size). Such a second indication may be transmitted within a configured time duration, which may be allowed for the WTRU if transmitting certain type 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 info, a maximum time duration (e.g., in ms, symbols, slots, periods) for updating the PUSCH usage indication after sending an initial indication. The WTRU may receive, in configuration information, one or more threshold values associated with updating the PUSCH usage indication. Such threshold values, for example, may include payload size of a PDU set, remaining delay, and importance/priority of a PDU set.

[0235] The WTRU may receive, from higher layers or from another WTRU (e.g., over SL), a first batch of one or more PDUs of a PDU set. The WTRU may determine the PUSCH usage (e.g., expected number of used and/or unused PUSCH occasions 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 may transmit, e.g., may then transmit, to the network a first indication on the determined PUSCH usage in a time window (e.g., one or more subsequent slots or CG periods).

[0236] The WTRU may receive from higher layers or from another WTRU (e.g., over SL), a second batch of one or more PDUs of the PDU set. The WTRU may determine a change in the PUSCH usage (e.g., number and location of PUSCH occasions determined previously as used and/or unused) if triggered by attributes associated with the second batch of PDUs such as, 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 PDU set.

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

[0238] The WTRU may transmit the second indication on PUSCH usage, possibly if any of the conditions, e.g., above conditions, may be met. The second indication on PUSCH usage may contain the same or updated information on the number and location of the PUSCH occasions expected to be used or unused by WTRU (e.g., in a bitmap or in start offset and length indication). The second indication on PUSCH usage may contain difference/delta information on PUSCHs usage relative to the information transmitted in the first indication on PUSCH usage. If any of the conditions, e.g., above conditions, are not fulfilled, the WTRU may not trigger and transmit a second indication on PUSCH usage.

[0239] The WTRU may transmit to the network the second indication on the updated PUSCH usage over the time window in any of the first PUSCH occasion available after determining updated PUSCH usage, in a PUSCH occasion selected by the WTRU from a set of candidate preconfigured PUSCH occasions or in a set of PUSCH occasions that may be available or used by WTRU over a time duration/window. Such a second indication on PUSCH usage may be transmitted in any of UCI, CG-UCI, or new UCI on PUSCH usage. Such a second indication may be transmitted using PUCCH resource or PUSCH resource. The WTRU may transmit, e.g., may then transmit, the second batch of PDUs of the PDU set using the PUSCH occasions indicated by WTRU as used.

[0240] FIG. 4 depicts an example implementation for determining to update information provided in a first indication regarding the usage of CP PUSCH occasions. A WTRU may determine to update the information provided in a first indication on the usage of CG PUSCH occasions by sending a second indication, based on updated/new information associated with arrival time of PDUs, jitter, and PDU payload sizes.

[0241] In examples related to transmission of an indication on PUSCH usage over a requested or configured time window, the WTRU may receive configuration information, including a multi-PUSCH CG configuration.

[0242] The WTRU may receive, from, for example, higher layers, PDUs of a PDU set.

[0243] The WTRU may receive from the network (NW) (e.g., in DCI) a request for PUSCH usage. The request for PUSCH usage may comprise, for example, a time window associated with PUSCH usage. The time window may be indicated by a start offset PUSCH occasion and duration within which the WTRU may indicate the number and location of used/unused PUSCHs.

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

[0245] The WTRU may determine the PUSCH usage (e.g., number and locations of the PUSCH occasions) over the time window based on, for example, one or more of the following: payload of PDU(s) multiplexed in one or more PUSCH occasions being less than (<) a payload threshold (e.g., percentage of total payload of PDU set); and/or a remaining delay of PDUs of 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 next slot/period). [0246] The WTRU may transmit an indication on PUSCH usage (e.g., first N out of M configured PUSCH occasions) over the time window in the first PUSCH occasion.

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

[0248] Implementations for indicating a CG muting pattern for CG PUSCH usage may be provided.

[0249] A WTRU may select a preconfigured CG muting pattern for indicating the PUSCH usage. The WTRU may transmit an indication of a selected CG muting pattern which may be correlated with the XR traffic pattern and the usage of CG PUSCH occasions may be determined by the WTRU. The WTRU may select and indicate a preconfigured CG muting pattern for XR traffic patterns, e.g., certain deterministic XR traffic patterns, corresponding to the arrival and transmission of PDUs of PDU sets with low jitter, fixed periodicity, and/or high importance.

[0250] 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).

[0251] The WTRU may receive, in the configuration, one or more CG muting patterns, where each CG muting pattern may span a time interval (e.g., a set of one or more PUSCH occasions, slots or CG periods) and may indicate a subset of CG PUSCH occasions and the locations of the PUSCH occasions that are muted/unavailable. For example, for a multi-PUSCH CG configuration consisting of 4 PUSCH occasions per slot and 2 slots per CG period, a first CG muting pattern may indicate muting of all PUSCH occasions in the second slot and a second CG muting pattern may indicate muting of the last 2 PUSCH occasions in the two (2) slots. The WTRU may receive, in the configuration, criteria for selecting one or more CG muting patterns based on the traffic pattern of data units expected to be transmitted by the WTRU in UL and the usage of PUSCH occasions, which criteria may consider the XR traffic attributes and QoS 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 unmatched occasions between the multi-PUSCH CG configuration and the number of PUSCH occasions expected to be used/unused in the corresponding time interval. Such criteria may allow for minimizing the number of used PUSCH occasions 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 the association information between a set of CG muting patterns, and the XR traffic (e.g., PDU sets) attributes 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 at locations towards the end of the muting pattern) for transmitting a PDU set with a payload size above a payload threshold and/or for remaining delay below a delay threshold. The WTRU may select a second CG muting pattern (e.g., with a high number of unused PUSCH occasions at locations towards the beginning of the muting pattern) for a PDU set with a payload size below a payload threshold and/or for a remaining delay above a delay threshold.

[0253] The WTRU may receive, in configuration, for example, one or more threshold values associated with the payload size per PUSCH occasion, remaining delay of a PDU set for meeting the PSDB, and the number of repetitions of different PDUs in a PDU set for meeting the PSER. Such threshold values may be used for determining the usage of PUSCH occasions in a time interval based on the determined traffic pattern.

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

[0255] The WTRU may determine the PUSCH usage pattern (e.g., number and locations of the PUSCH occasions expected to be used or unused by the WTRU during UL transmission) over the time interval (e.g., configured/indicated with a start offset and duration) that may be aligned with the interval corresponding to the set of configured CG muting patterns. The WTRU may determine the PUSCH usage pattern over the time interval based on one or more conditions or criteria. If the payload of one or more PDUs of the PDU set multiplexed into a PUSCH occasion is less than or equal to a first payload threshold value (per PUSCH occasion) and/or greater than a second payload threshold value, the WTRU may determine the PUSCH occasion as used. If the payload of the one or more PDUs of the PDU set multiplexed into a PUSCH occasion is less than the second payload threshold value (per PUSCH occasion), the WTRU may determine the PUSCH occasion as unused.

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

[0257] If the number of repetitions of one or more PDUs (e.g., PDUs with a priority higher than a priority threshold value) of 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 any new or repetition PDUs as unused, for example. The WTRU may perform k repetitions of all or a subset of the PDUs of the PDU set for meeting the PSER.

[0258] The WTRU may 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 unmatched occasions (e.g., number of used PUSCH occasions that do not match with the unmuted occasions in the CG muting pattern) with respect to the determined PUSCH usage in the corresponding time window; a subset of occasions in the PUSCH usage pattern that may be unmatched with the occasions in the CG muting pattern may be delayed/advanced to one or more matching occasions in the CG muting pattern (e.g., such delaying/advancing 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 PSCH usage pattern); and/or select at least one CG muting pattern that results in minimizing the number of unmatched occasions between the CG muting pattern and the updated PUSCH usage pattern.

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

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

[0261] The WTRU may receive from the network (e.g., in RRC signaling, MAC CE or DCI), an explicit or implicit confirmation indication (ACK/NACK) on the CG muting pattern. In the case of an implicit ACK, the WTRU may not receive any indication before the expiry of a timer started by the WTRU after sending the indication on a selected CG muting pattern. In the case of an implicit NACK, for transmitting the second batch of PDUs, the WTRU may send an index to a network selected CG muting pattern, a new CG muting pattern, or an indication of activation of another multi-PUSCH CG or single PUSCH CG configuration. [0262] The WTRU may, e.g., may then, transmit the PDUs of the PDU set using the PUSCH occasions allowed by the determined or indicated CG muting pattern.

[0263] The WTRU may be configured with a set of one or more HARQ transmission patterns which may be associated with multi-PUSCH CG. Each HARQ transmission pattern may include a set of occasions corresponding to the PUSCH occasions in multi-PUSCH CG that may indicate the initial and retransmissions for one or more HARQ processes that may 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 may be used for the initial transmission, the n-i-k’th PUSCH occasion may be used for a first retransmission and the n+2k’th PUSCH occasion may be used for a second retransmission. Similarly, for a second HARQ process, the n+1 ’th PUSCH occasion may be used for the initial transmission, followed by the n+1 -i-k’th PUSCH occasion for the first retransmission. The values corresponding to n and k may be configured in the WTRU individually or via the HARQ transmission patterns. For example, the values of n and k may be different for different HARQ transmission patterns. The WTRU may select a HARQ transmission pattern and may indicate the selected pattern based on the traffic pattern and associated QoS.

[0264] The WTRU may be configured with a set of one or more HARQ transmission patterns, where each pattern may correspond to different redundancy version (RV) values at 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 may be used for the initial transmission with RV 0, the n-i-k’th PUSCH occasion may be used for a first retransmission with RV 2, the n+2k’th PUSCH occasion may be used for a second retransmission with RV 3 and the n+3k’th PUSCH occasion may be used for a third retransmission with RV 1 . The RV values may be different for different HARQ transmission patterns. The WTRU may 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 indicating CG muting pattern for CG PUSCH usage, the WTRU may receive config information which may include, for example, one or more of the following: a multi-PUSCH CG config; a set of one or more CG muting patterns (e.g., each muting pattern may indicate a subset of CG PUSCH occasions and a location of the PUSCH occasions that are muted/unused over a time window); criteria for selecting one or more CG muting patterns (e.g., minimize the number of unmatched occasions); and/or threshold values associated with payload size, remaining delay, and/or number of repetitions.

[0266] The WTRU may receive, from, for example, higher layers, PDUs of PDU sets. [0267] The WTRU may determine the PUSCH usage pattern (e.g., number and location of the used PUSCH occasions) based, for example, on the received PDUs of the PDU set and one or more of the following conditions or criteria: a payload of PDU(s) multiplexed into 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 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 the PDU set is above a first repetition threshold value and/or below a second repetition threshold values (e.g. .associated with PSER).

[0268] The 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 unmatched occasions (e.g., the number of used PUSCH occasions in the traffic pattern that do not match with the unmuted occasions) in each CG muting pattern with respect to the determined PUSCH usage pattern; and/or the WTRU may combine multiple CG muting patterns (e.g., union of patterns) that may result in meeting the criteria.

[0269] The WTRU may transmit an indication containing the index(s) to the selected CG muting pattern(s).

[0270] FIGs. 5A and 5B depict an example implementation for selecting and indicating a preconfigured CG muting pattern. The WTRU may select and indicate a preconfigured CG muting pattern (e.g., CG muting pattern 2) which may be closely correlated with the XR traffic pattern and the usage of CG PUSCH occasions determined by WTRU.

[0271] WTRU-assisted selection of FDRA configuration for multi-PUSCH CG may be provided.

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

[0273] 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 or dynamic signaling (e.g., in DCI or MAC CE), one or more FRDA sub-configurations (which may be referred to, for example, as FDRA sub-config). The one or more FDRA sub-configs may comprise, for example, one or more of the following parameters: index/ID of the FDRA sub-config( e.g., a group of FDRA sub-configs may be configured with a group index); indication of FRDA type (e.g., type 0 or type 1); I ndexes/IDs of one or more BWPs associated with the FDRA subconfiguration; start offset resource block (RB) or resource block group (RBG); RBG size (e.g., number of RBGs in a BWP); a set of consecutive or non-consecutive RBs or resource block groups (RBGs) (e.g., a set of consecutive RBGs may be indicated in the form of a resource indication value (RIV), consisting of the start offset RBG and length of consecutive RBGs) (e.g., a set of non-consecutive RBGs may be indicated in the form of a bitmap with a certain length, where each bit ‘1’ may indicate the availability/allocation of an RBG); 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 sub-configurations (e.g., group index). For example, a set of PUSCH occasions in a CG slot may be associated with a group index corresponding to a group of FDRA subconfigurations, where each sub-configuration may consist of a different start offset and number of RBGs. For example, the WTRU may be configured with multiple RIV values corresponding to the different FDRA sub-configs for a same set of one or more PUSCH occasions. A default FDRA sub-configuration may 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 sub-configuration and other FDRA sub-configurations may or may not overlap in the frequency domain. A new or non-default FDRA sub-configuration may be selected by the WTRU for an associated set of PUSCH occasions if the default FRDA sub-configuration is determined to be inadequate. In examples, the WTRU may receive one or more demodulation reference signal (DMRS) resource configurations and/or the association information indicating the association between the DMRS resources configurations and the FDRA-subconfigs. Such DMRS resource configurations may be received on the basis of per-set of consecutive or non-consecutive RBGs and/or per-set of PUSCH occasions.

[0274] The WTRU may receive, in the configuration information, criteria consisting of a set of threshold values for selecting one or more FDRA sub-configurations for a set of PUSCH occasions, slots or CG periods based on the traffic pattern and/or QoS. Such threshold values may include thresholds associated with payload size of PDU set, remaining delay, and number of repetitions for the PDUs of the PDU set. The WTRU may receive, in the configuration information, a maximum time duration (e.g., in terms of ms, symbols, slots, periods) for performing, for example, one or more of the following: determining whether the default FDRA sub-configuration associated with the set of PUSCH occasions, slots or CG periods is adequate; selecting a FDRA sub-configuration from the preconfigured set; and/or transmitting an indication for requesting the activation of the selected FDRA sub-configuration.

[0275] The WTRU may receive from higher layers or from another WTRU (e.g., over SL) one or more PDUs of a PDU set. The WTRU may determine the PUSCH usage pattern (e.g., number and locations of the PUSCH occasions expected to be used or unused) for a set of PUSCH occasions and/or may select an FDRA sub-configuration for the PUSCH occasions based on one or more conditions or criteria. If the payload of one or more PDUs of the PDU set multiplexed into a PUSCH occasion configured with a default FDRA sub-config (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 FRDA sub-config) as used. If the payload of the one or more PDUs of the PDU set multiplexed into a PUSCH occasion configured with default FDRA sub-config is less than the second payload threshold value (per PUSCH occasion and/or per default set of RBGs), the WTRU may determine the PUSCH occasion as unused.

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

[0277] If the PDUs of the PDU set cannot be transmitted within the remaining delay associated with PSDB when multiplexing the PDUs into the set PUSCH occasions configured with default FDRA subconfig, the WTRU may determine a subset of one or more initial PUSCH occasions and select a preconfigured FDRA sub-configuration for the initial subset of PUSCH occasions. The WTRU may determine the later subset of the PUSCH occasions as unused. The WTRU may select an FDRA subconfig for the initial subset of PUSCH occasions such that the PDUs of the PDU set may 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 sub-config consisting of 100 RBGs per PUSCH occasion, the WTRU may determine the subset of PUSCH occasions [0, 1] as used and PUSCH occasions [2, 3] as unused. For the used PUSCH occasions, the WTRU may select a FDRA sub-configuration with 200 RBGs such that the PDUs of the PDU set may be transmitted within the remaining delay. [0278] If the number of repetitions of one or more PDUs (e.g., PDUs with a priority higher than a priority threshold value) of 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 default FDRA sub-config as used. The WTRU may determine any of the PUSCH occasions with default FRDA sub-config that do not contain any new or repetition PDUs as unused.

[0279] The WTRU may transmit the indication on the selected FDRA sub-config containing the ID/index of the selected FDRA sub-config and the IDs/indexes to the PUSCH occasions/slots/periods to which the selected FDRA sub-config may be applied. Such an indication may contain a pair of information elements related to the index of the selected FDRA sub-config and the bitmap or start offset/length of the corresponding PUSCH occasions/slots/periods. In examples, the WTRU may transmit in an indication the index to the RIV associated with the selected FRDA sub-config. Such an indication may be transmitted in any UCI, CG-UCI, or new UCI. Such an indication may be transmitted using PUCCH resource or PUSCH resource. In examples, the WTRU may implicitly indicate the selected FDRA sub-config to the network by using a preconfigured DMRS resource configuration associated with the selected FDRA sub-config and/or transmitting the DMRS using the associated DMRS resource configuration.

[0280] The WTRU may receive from the network (e.g., in RRC signaling, MAC CE or DCI), signaling indication indicating the activation of the selected or a new FDRA sub-config (e.g., index of FDRA subconfig) and/or deactivation of the default FDRA sub-config. In examples, the WTRU may receive (e.g., in DCI) the indexes to one or more RIVs associated with the activated/deactivated FDRA sub-config for the set of PUSCH occasions expected to be used by the WTRU. The WTRU may transmit, e.g., may then transmit, the PDUs of the PDU set using the PUSCH occasions with resources in the activated FDRA subconfig.

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

[0282] The WTRU may receive, e.g., from higher layers, PDUs of PDU sets. The WTRU may determine the FDRA sub-config for a group of PUSCH occasions and the PUSCH usage information (e.g., number of used/unused PUSCH occasions) for a set of PUSCH occasions based, for example, on one or more of the following: a payload of PDU(s) multiplexed into a PUSCH occasion with default FDRA sub-config 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 values (e.g., associated with PSER).

[0283] The WTRU may transmit an indication containing the selected FDRA sub-config and PUSCH usage information for the set of PUSCH occasions.

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

[0285] The WTRU may transmit the PDUs of the PDU set using resources in the activated FDRA subconfig and CG PUSCH occasions.

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

[0287] Time-shifting of PUSCH occasions in multi-PUSCH CG config may be provided.

[0288] A WTRU may determine to time-shift PUSCH occasions in multi-PUSCH CG. In examples, the WTRU may determine to time-shift (e.g., advance or delay) a subset of PUSCH occasions in a CG period for transmitting a delayed plurality or batch of PDUs of a PDU set based on arrival time of an earlier plurality or batch of PDUs and jitter estimation. The WTRU may trigger SR/BSR to request for DG resources if the time-shifted PUSCH occasions are unable to 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 multi-PUSCH CG configurations (e.g., number of PUSCH occasions per slot, number of slots per CG period). A multi-PUSCH CG configuration may consist of one or more groups of consecutive or non-consecutive PUSCH occasions, where a second group may be separated from a first group by a default start offset value. The WTRU may receive configuration information and/or parameters further including, for example, an association information (e.g., mapping relation) between one or more jitter range values and start offset values for a group of multi-PUSCH occasions in a CG period. The different start offset values may be configured with different indexes/IDs.

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

[0291] The WTRU may determine the jitter range (e.g., maximum jitter value) for receiving a second plurality or batch of PDUs of the PDU set based on the arrival time of the first plurality or batch of PDUs (e.g., time elapsed since the arrival of first batch of PDU in a LCH buffer) and the remaining time associated with the PSDB. The WTRU may also determine a second batch of PUSCH occasions (e.g., number of PUSCH occasions expected to be used for second batch) based on the information on total payload size and/or total number of PDUs of a PDU set in first batch of PDUs. The WTRU may determine a new start offset for the second group of PUSCH occasions for transmitting the second batch of PDUs based on the determined jitter range and the configured association info. For example, the new start offset value may result in either advancing or delaying the PUSCH occasions in the second group by one or more time units (e.g., in terms ms, symbols, occasions, slots, periods), based on whether the second batch of PDUs of the PDU set are expected to arrive later or earlier in the buffer at the WTRU.

[0292] The WTRU may transmit an indication, to the network, on the new start offset value (e.g., index of start offset) corresponding to the second group of PUSCH occasions, and the number of PUSCH occasions expected to be used or unused in the second group. Such indication may be transmitted in one or more of UCI, CG-UCI, or new UCI. Such an indication may be transmitted using PUCCH resource or PUSCH resource. Such an indication may be transmitted along with the first batch PDUs of the PDU set using the first group of PUSCH occasions.

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

[0294] The WTRU may receive from the network (e.g., in MAC CE or DCI), a confirmation indication on the new start offset or a different start offset value (e.g., index) to be applied for the second group of PUSCH occasions. The WTRU may also receive (e.g., in DCI), the DG resources requested by 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 start offset, and/or with the DG resources. [0295] The WTRU may be configured to trigger and transmit an indication to request to activate/deactivate a subset of CG PUSCH occasions if the configured CG PUSCHs are not suitable (e.g., mismatch in quantity and timing) and/or if time-shifting the PUSCHs based on payload size of the PDU set and estimated jitter for the arrival of some PDUs of the PDU set.

[0296] In examples related to time-shifting of PUSCH occasions in multi-PUSCH CG config, the WTRU may receive configuration information comprising, for example, one or more of a multi-PUSCH CG config, and/or a mapping relation between jitter range and start offset of a group of multi-PUSCH occasions in a CG period.

[0297] The WTRU may receive, e.g., from a higher layer, a first batch of PDUs of a PDU set. The WTRU may determine a first group of PUSCHs occasions (e.g., a number of PUSCH occasions to be used) for transmitting the first plurality or batch of PDUs based on the payload sizes of the PDUs.

[0298] The WTRU may determine the jitter range for receiving a second batch of PDUs of the PDU set based on the arrival time of first batch of PDUs, and the remaining time associated with PSDB.

[0299] The WTRU may determine a new start offset for a second group of PUSCH occasions for transmitting the second plurality or batch of PDUs based on the jitter range and the mapping relation.

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

[0301] The 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 group of PUSCH occasions after applying a new start offset is greater than (>) a slot boundary; a delay for transmitting the second batch of PDUs in a next slot is greater than (>) PSDB; a total payload size of second batch of PDUs is greater than (>) a size of second group of PUSCH occasions within a slot boundary after applying the new start offset.

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

[0303] The WTRU may receive, e.g., from higher layers, the second batch of PDUs of the PDU set.

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

[0305] FIG. 7 depicts an example implementation of a WTRU determining to time-shift (e.g., delay) a subset of PUSCH occasions. In the example depicted in FIG. 7, the WTRU may determine to time-shift (e.g., delay) a subset of PUSCH occasions in slot 2 for transmitting a delayed batch of PDUs based on the determined jitter range of the PDUs. [0306] Although features and elements described herein are described in particular combinations, each feature or element may 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 herein may be provided for exemplary purposes and does not limit in any way the applicability of the described systems, methods, and instrumentalities to other wireless technologies and/or to wireless technology using different principles, when applicable. The term network in this disclosure may refer to one or more gNBs which in turn may be associated with one or more Transmission/Reception Points (TRPs) or any other node in the radio access network.

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

[0309] The processes described herein may be implemented in a computer program, software, and/or firmware incorporated 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 over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a 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-optical media, and/or optical media such as compact disc (CD)-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.

Claims

CLAIMS What is Claimed:

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

2. The WTRU of claim 1 , wherein the configuration information comprises one or more of: a multi- PUSCH CG configuration; one or more CG muting patterns; criteria for selecting one or more CG muting patterns; or threshold values associated with one or more of payload size, remaining delay, or number of repetitions.

3. The WTRU of claim 2, wherein each of the one or more CG muting patterns indicates a subset of PUSCH occasions and locations of the PUSCH occasions that are muted in a time window.

4. The WTRU of claim 2, wherein the criteria for selecting one or more CG muting patterns comprises criteria that minimize a number of unmatched occasions, the unmatched occasions corresponding to PUSCH occasions that do not match with unmuted occasions.

5. The WTRU of any of claims 1 to 4, wherein the plurality of PDUs are associated with a PDU set.

6. The WTRU of any of claims 1 to 5, wherein the PUSCH usage pattern indicates whether each of a plurality of PUSCH occasions associated with the PUSCH usage pattern is used or unused.

7. The WTRU of any of claims 1 to 6, wherein the processor configured to determine the PUSCH usage pattern based on at least the plurality of PDUs is configured to determine the PUSCH usage pattern based on at least a payload of PDUs multiplexed into a PUSCH occasion being above a first payload threshold value or below a second payload threshold value.

8. The WTRU of any of claims 1 to 6, wherein 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 a delay of a PDU set being less than a delay threshold.

9. The WTRU of any of claims 1 to 6, wherein 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 a number of repetitions per PDU of a PDU set being at least one of above a first repetition threshold or below a second repetition threshold.

10. The WTRU of any of claims 1 to 9, wherein the processor configured to select one or more CG muting patterns from the configured set based on at least the determined PUSCH usage pattern is further configured to select the one or more CG muting patterns from the configured set by combining multiple CG muting patterns to minimize a number of unmatched occasions in each of the one or more CG muting patterns with respect to the determined PUSCH usage pattern.

11 . The WTRU of any of claims 1 to 10, wherein the indication of the selected one or more CG muting patterns comprises an index associated with the selected one or more CG muting patterns.

12. A method of supporting wireless PUSCH usage comprising: receiving configuration information; determining a plurality of packet data units (PDUs), the plurality of PDUs being available for transmission; determining a physical uplink shared channel (PUSCH) usage pattern based on at least the plurality of PDUs; selecting one or more configured grant (CG) muting patterns from a configured set based on at least the determined PUSCH usage pattern; and sending an indication of the selected one or more CG muting patterns.

13. The method of claim 12, wherein the configuration information comprises one or more of: a multi- PUSCH CG configuration; one or more CG muting patterns; criteria for selecting one or more CG muting patterns; or threshold values associated with one or more of payload size, remaining delay, or number of repetitions.

14. The method of claim 13, wherein each of the one or more CG muting patterns indicates a subset of CG PUSCH occasions and locations of the CG PUSCH occasions that are muted in a time window.

15. The method of claim 13, wherein the criteria for selecting one or more CG muting patterns comprises criteria that minimize a number of unmatched occasions, the unmatched occasions corresponding to PUSCH occasions that do not match with unmuted occasions.

16. The method of any of claims 12 to 15, wherein determining the PUSCH usage pattern based on at least the plurality of PDUs comprises determining the PUSCH usage pattern based on at least a payload of PDUs multiplexed into a PUSCH occasion being above a first payload threshold value or below a second payload threshold value.

17. The method of claim 16, wherein determining the PUSCH usage pattern based on at least the plurality of PDUs further comprises determining the PUSCH usage pattern based on at least a delay of a PDU set being less than a delay threshold.

18. The method of claim 17, wherein determining the PUSCH usage pattern based on at least the plurality of PDUs further comprises determining the PUSCH usage pattern based on at least a number of repetitions per PDU of a PDU set being at least one of above a first repetition threshold or below a second repetition threshold.

19. The method of any of claims 12 to 18, wherein selecting one or more CG muting patterns from the configured set based on at least the determined PUSCH usage pattern further comprises selecting the one or more CG muting patterns from the configured set by combining multiple CG muting patterns to minimize a number of unmatched occasions in each of the one or more CG muting patterns with respect to the determined PUSCH usage pattern.

20. A wireless transmit and receive unit (WTRU) comprising: a processor configured to: receive configuration information; determine a plurality of packet data units (PDUs), the plurality of PDUs being available for transmission; determine a physical uplink shared channel (PUSCH) usage pattern based on at least the plurality of PDUs, the PUSCH usage pattern indicating whether each of a plurality of PUSCH occasions associated with the PUSCH usage pattern is used or unused; selecting one or more configured grant (CG) muting patterns from a configured set to minimize a number of unmatched occasions in each of the one or more CG muting patterns with respect to the determined PUSCH usage pattern; and send an indication of the selected one or more CG muting patterns.