Adaptive scheduling of PDU sets

Abstract

Systems, methods, and tools may schedule a set of protocol data units (PDUs). A wireless transmit receive unit (WTRU) may receive configuration information including a delay threshold and a configuration grant (CG) arrangement from a network node. The WTRU may receive a first subset of PDUs and related information from an application. The WTRU may estimate a payload size and a time of arrival for the second subset of PDUs. Based on the estimate of the first subset and the payload size, the WTRU may determine a first set of CG PUSCH occasions and a second set of CG PUSCH occasions. If the estimated time difference of arrival between the two subsets is greater than the delay threshold, the WTRU may identify an available CG PUSCH occasion. The information may be communicated to the network node.

Description

Background Art

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 395,983 filed on August 8, 2022, U.S. Provisional Application No. 63 / 410,941 filed on September 28, 2022, and U.S. Provisional Application No. 63 / 445,458 filed on February 14, 2023, the contents of which are incorporated herein by reference. Background Art

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation of mobile communications radio access technology (RAT) may be referred to as 5G New Radio (NR). The previous generation (legacy) mobile communications RAT may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Systems, methods, and tools may be configured for scheduling of a set of protocol data units (PDUs). A wireless transmit / receive unit (WTRU) may receive configuration information from a network node, the configuration information indicating a delay threshold and a configuration grant (CG) configuration, the configuration grant (CG) configuration including the number of PUSCH opportunities in a CG period. The WTRU may receive a first PDU subset of a set of protocol data units (PDUs) and information associated with the PDU set from an application. The PDU set may be associated with a CG period. The WTRU may determine an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set. The WTRU may determine a first group of CG PUSCH opportunities associated with the first PDU subset and a second group of CG PUSCH opportunities associated with the second PDU subset based on the payload size of the first PDU subset and the estimated payload size of the second PDU subset. Under the condition that the difference between the estimated arrival time of the second PDU subset and the arrival time of the first PDU subset is greater than the delay threshold, the WTRU may determine the available CG PUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset. The WTRU may send information indicating at least the available CG PUSCH opportunities, the first group of CG PUSCH opportunities, and the second group of CG PUSCH opportunities to the network node.

[0005] The information associated with the PDU set may include a total payload size of the PDU set and a delay bound. The WTRU may determine an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set based on the total payload size of the PDU and the delay bound.

[0006] The WTRU may estimate the available CG resources based on the difference between the number of PUSCH opportunities in the CG period and the sum of the PUSCH opportunities used in the first set of CG PUSCH opportunities and the second set of CG PUSCH opportunities.

[0007] The WTRU may send the information in the WTRU indication multiplexed with the first subset of the PDU set or sent separately from the first subset of the PDU set.

[0008] The WTRU may assign temporary or semi-persistent status to available CG PUSCH opportunities based on network traffic characteristics, and the temporary status may indicate applicability to the next PUSCH opportunity and the semi-persistent status may indicate applicability to one or more PUSCH opportunities.

[0009] The WTRU may use a bitmap vector or an offset value to encode information indicating available CG PUSCH opportunities. The bitmap vector may indicate the status of an upcoming PUSCH opportunity or timeslot, and the offset value may indicate a delay for the WTRU to skip a PUSCH opportunity.

[0010] The WTRU may receive an availability confirmation from the network node. The availability confirmation may indicate the approved number of PUSCH opportunities available within the CG period.

[0011] The WTRU may send an availability indication to the network node, and the availability indication may indicate the number of available PUSCH opportunities in the CG period.

[0012] Systems, methods, and tools may be configured for scheduling of a set of protocol data units (PDUs). A wireless transmit / receive unit (WTRU) may receive configuration information indicating a delay threshold and a configuration grant (CG) configuration. The WTRU may determine a first group of CG PUSCH opportunities associated with a first PDU subset and a second group of CG PUSCH opportunities associated with a second PDU subset based on a payload size of the first PDU subset and an estimated payload size of the second PDU subset. The first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities may be in a CG period from a CG configuration. The first PDU subset and the second PDU subset may include a set of PDUs associated with a CG period. Under the condition that the difference between the estimated arrival time of the second PDU subset and the arrival time of the first PDU subset is greater than the delay threshold, the WTRU may determine the available CG PUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset. The WTRU may send information indicating at least available CG PUSCH opportunities, a first group of CG PUSCH opportunities, and a second group of CG PUSCH opportunities to the network node.

[0013] A wireless transmit / receive unit (WTRU) may support adaptive scheduling for a set of protocol data units (PDUs). For example, the WTRU may determine a resource grant type for sending a set of PDUs based on a PDU set payload size threshold. For example, the WTRU may receive a total PDU set payload size threshold. The threshold may indicate a minimum threshold of the total PDU set payload size that may be transmitted together with a configuration grant (CG) resource. The WTRU may compare the PDU set payload size with the minimum threshold. Based on the condition that the PDU set payload size is less than the minimum threshold, a dynamic grant (DG) may be used as a resource grant type for transmitting a set of PDUs. Based on the condition that the PDU set payload size is not less than the minimum threshold, the WTRU may determine to use the CG as a resource grant type for transmitting at least a portion of the set of PDUs.

[0014] The WTRU may receive a first configuration authorization configuration and a second configuration authorization configuration. The second configuration authorization configuration may use any of a lower transmit power than the first configuration authorization configuration and a smaller number of physical resource blocks than the first configuration authorization configuration. The WTRU may send a first portion of a set of PDUs with the first configuration authorization configuration, and the set of PDUs may have a delay budget. The WTRU may estimate a delay associated with sending a second portion of the set of PDUs with the second configuration authorization configuration. Under the condition that the estimated delay is within the delay budget, the WTRU may send the second portion of the set of PDUs with the second configuration authorization configuration.

[0015] Under the condition that the estimated delay is outside the delay budget, the WTRU may send a second portion of the PDU set with the first configuration authorization configuration. The second portion may include PDUs in the PDU set that are not included in the first portion of the PDU set. When sending the second configuration authorization configuration, the WTRU may be associated with a low power mode.

[0016] The WTRU may receive a negative acknowledgement (NACK) threshold, and the number of NACKs reaching the NACK threshold may correspond to the WTRU switching to a low power mode.

[0017] In an example, the WTRU may support adaptive scheduling of PDU sets. Such a WTRU may be configured to perform one or more of the following: the WTRU may transmit assistance and / or status information associated with processing XR traffic and PDU sets; the WTRU may receive configuration and / or assistance information; the WTRU may trigger events and / or conditions during data transmission and / or reception; the WTRU may determine a resource grant type for sending a PDU set in the UL; the WTRU may determine an adjustment to CG resources based on variable PDU characteristics in the PDU set; the WTRU may determine to skip one or more CG opportunities based on a determination of jitter in the UL XR traffic; the WTRU may determine whether to use a CG configuration associated with higher reliability based on the status of the PDU set transmission; and / or the WTRU may determine to use SR resources associated with different LCHs based on a change in the priority of the PDUs in the PDU set.

[0018] The example WTRU may be configured to receive default CG resource configuration information, a minimum threshold and / or a maximum threshold. For example, the first PDU in the PDU set may be received from the application layer. PDU set information may be received. The PDU set information may include a PDU set payload size and / or a PDU set delay budget. The resource authorization type used to transmit the PDU set may be determined based on the PDU set information, the CG resource configuration information, the minimum threshold and / or the maximum threshold. For example, the PDU set payload size may be compared with the minimum threshold. Based on the condition that the PDU set payload size is less than the minimum threshold, a scheduling request (SR) request and a buffer status report (BSR) request for a dynamic grant (DG) may be transmitted. Based on the condition that the PDU set payload size is less than the minimum threshold, a single DG transmission may be used to transmit the PDU set. Based on the condition that the PDU set payload size is less than the minimum threshold, an indication that the CG opportunity is not available for sending the PDU set (e.g., an indication to avoid using the CG opportunity to send the PDU set) may be transmitted.

[0019] The expected delay for transmitting a PDU set may be determined based on the default CG resource configuration information and / or the PDU set payload size. For example, the expected delay may be compared with the PDU set delay budget. Based on the condition that the PDU set payload size does not exceed the maximum threshold and the expected delay is less than the PDU set delay budget, the CG resources may be used to transmit the PDU set in one or more CG opportunities.

[0020] The number of excess CG opportunities may be determined based on the PDU set delay budget and / or the default CG resource configuration information. The payload size that may be transmitted on the remaining CG opportunities may be determined based on the PDU set delay budget and / or the default CG resource configuration information. The number of excess CG opportunities may be transmitted. A request for the DG to transmit additional PDUs may be transmitted. The DCI may be monitored. Based on the DCI, information regarding the allocation of DG resources may be determined. PDU sets may be transmitted using CG and DG resources.

[0021] An example wireless transmit / receive unit (WTRU) may be configured to receive a default CG resource configuration (including, for example, the number of PUSCH time slots per opportunity, the periodicity, and the number of opportunities), a minimum threshold and a maximum threshold describing the total payload size that may be transmitted with the default CG resource configuration, a residual delay threshold for CG configuration switching, and a retransmission threshold per PDU for supporting adaptive scheduling. A first PDU associated with a PDU set may be received. PDU set information (e.g., a PDU set payload size and a PDU set delay budget) may be received. Such a WTRU may determine a resource authorization type (e.g., DG, CG, or CG+DG) for transmitting a PDU set based on the PDU set information, the default CG resource configuration, the minimum threshold, and the maximum threshold.

[0022] In an example where the PDU set payload size does not exceed a minimum threshold, such a WTRU may transmit an SR and / or BSR request for a DG. Such a WTRU may transmit a PDU set using a single DG transmission. Such a WTRU may indicate that a CG opportunity associated with a default CG resource configuration will not be used to transmit a PDU set. In an example, such a WTRU may transmit explicit information about a PDU set delay budget. In an example, such information about a PDU set delay budget may be implicit for an XR application type. Such information may be used to allocate a DG PUSCH timeslot prior to a PDU set delay deadline. Advantageously, by transmitting a request for a single DG, such a WTRU may save transmit power by transmitting a PDU set in fewer DG PUSCH timeslots than the PUSCH timeslots of a single CG occasion.

[0023] In examples where the PDU aggregate payload size reaches or exceeds a minimum threshold, the WTRU may determine the expected latency associated with transmitting the PDU aggregate based on the default CG resource configuration and the PDU aggregate payload size. In such examples where the PDU aggregate payload size does not exceed the maximum threshold and the expected latency is less than the PDU aggregate delay budget, such a WTRU may transmit the PDU aggregate using CG resources in one or more CG opportunities.

[0024] The WTRU may determine the number of excess CG opportunities and the payload size that may be transmitted on the remaining CG opportunities based on the PDU set delay budget and the default CG resource configuration. Such a WTRU may indicate the number of excess CG opportunities. Such a WTRU may transmit a request for DG (e.g., via SR and / or BSR) resource allocation. Such a WTRU may monitor the DCI for information about the allocation of DG resources. Upon receiving the allocation of DG resources, such a WTRU may transmit a PDU set using the CG and DG resources.

[0025] An example WTRU may be configured to receive configuration information, a remaining delay threshold for CG configuration switching, and a retransmission threshold per PDU for supporting adaptive scheduling. Such configuration information may include a first CG configuration (e.g., low reliability: high modulation and coding scheme (MCS) and a low number of physical resource blocks (PRBs)) and a second CG configuration (e.g., high reliability: low MCS and a high number of PRBs). One or more PDUs associated with a PDU set and an indication of a PDU set delay budget may be received. The WTRU may select a first CG configuration for transmitting the PDU. In the case of retransmissions, the WTRU may use the first CG configuration until the retransmission threshold is reached. In an example where the retransmission threshold is exceeded (e.g., the WTRU receives a NACK after reaching the retransmission threshold), the WTRU may determine the remaining delay based on the PDU set delay budget regarding the time spent on retransmissions. In an example where the remaining delay is less than the remaining delay threshold, the WTRU may select a second CG configuration for transmitting the remaining PDUs associated with the PDU set. In an example, the WTRU may transmit an indication (e.g., in a MAC CE or UCI or UCI+PUSCH) indicating a switch or requesting a switch to a second CG configuration. In an example where the retransmission threshold is not exceeded, the WTRU may continue to use the first CG configuration to send the remaining PDUs associated with the PDU set.

[0026] The WTRU may be configured to update the resource grant type for sending a PDU set in the UL. The WTRU may be configured to indicate unused UL CG opportunities based on traffic characteristics. The WTRU may be configured to indicate unused UL CG opportunities based on HARQ feedback. The WTRU may be configured to receive HARQ feedback for XR data sent using CG resources. The WTRU may be configured to switch between using single and multiple CDRX configurations.

[0027] The features described herein may be associated with a CG configuration for enhanced power saving in XR. The WTRU may determine whether to use a CG configuration with high (e.g., higher) energy efficiency (e.g., low transmit power, low number of PRBs) based on the state of PDU set transmission (e.g., PDU set delay budget) and the WTRU power state.

[0028] The WTRU may be configured to perform the following operations. The WTRU may be configured to receive configuration information from the gNB, including a first CG configuration (e.g., default: high number of PRBs, high transmit power) and a second CG configuration (e.g., low power: low number of PRBs, low transmit power). The WTRU may receive a threshold for a NACK counter to enable switching to a low power CG configuration. The WTRU may be configured to receive a PDU associated with a PDU set and an indication of a PDU set delay budget from an application. The WTRU may be configured to select a first CG configuration for transmitting the PDU. The WTRU may maintain use of the first CG configuration. The WTRU may be configured to select one of the CG configurations (e.g., default or low power) for further transmission based on the PDU set delay budget and the NACK counter threshold.

[0029] If the number of NACKs received within a period of time is less than a NACK counter threshold, or if the WTRU is in a low battery state, an expected latency for sending the remaining PDUs in the PDU set using a second CG configuration may be determined (e.g., by the WTRU). If the expected latency is less than the PDU set delay budget, a second CG configuration may be selected (e.g., by the WTRU) for sending the remaining PDUs in the PDU set. The remaining PDUs in the PDU set may continue to be sent using the first CG configuration.

[0030] In an example, the CG configuration may include enhanced power savings in XR. The WTRU may determine whether to use a CG configuration with higher energy efficiency (e.g., low transmit power, low number of PRBs) based on the state of the PDU set transmission (e.g., PDU set delay budget) and the WTRU power state.

[0031] An example WTRU may be configured to perform the following operations. The WTRU may receive configuration information from a gNB, including a first CG configuration (e.g., default: high number of PRBs, high transmit power) and a second CG configuration (e.g., low power: low number of PRBs, low transmit power). The WTRU may also receive a threshold for a NACK counter to enable switching to a low power CG configuration. The WTRU may receive a PDU associated with a PDU set and an indication of a PDU set delay budget from an application. The WTRU may select a first CG configuration for transmitting the PDU. The WTRU may remain in use of the first CG configuration. The WTRU may select one or more CG configurations in the CG configuration (default or low power) for further transmission based on the PDU set delay budget and the NACK counter threshold. If the number of NACKs received over a period of time may be less than the NACK counter threshold, or the WTRU may be in a low battery state), the WTRU may determine the expected delay for sending the remaining PDUs in the PDU set using the second CG configuration. If the expected delay is less than the PDU set delay budget, the WTRU may select the second CG configuration for sending the remaining PDUs in the PDU set. The WTRU may continue to use the first CG configuration to send the remaining PDUs in the PDU set. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0034] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within the illustrated communication system.

[0035] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of another example RAN and another example CN for use within the illustrated communication system.

[0036] Figure 2 An example of determining a resource grant type for transmitting a set of one or more packet data units (PDUs) is illustrated.

[0037] Figure 3 An example message flow diagram for determining changes to an adjustable CG configuration based on variable PDU characteristics in a PDU set is illustrated. DETAILED DESCRIPTION

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

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

[0040] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is 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 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, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

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

[0043] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, 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 use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. 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).

[0044] 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) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro).

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

[0046] 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 together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0047] 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), and GSM EDGE (GERAN).

[0048] Figure 1A The base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. 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 a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0049] 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be 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 different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1AAlthough not shown in the figure, 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 utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0050] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides 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), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication 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.

[0051] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication 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 via different wireless links). Figure 1A The illustrated WTRU 102c 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.

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

[0053] 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 associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC) and state machine, etc. The processor 118 may perform signal decoding, 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. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0055] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, 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.

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

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

[0058] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control 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, etc.

[0059] 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 from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

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

[0061] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both 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 for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0062] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with 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.

[0063] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-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 evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0064] Each of the evolved Node 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, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0065] Figure 1C The illustrated CN 106 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 being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0066] The MME 162 may be connected to each of the evolved Node-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, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. 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.

[0067] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an 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 the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

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

[0069] 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 be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts 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 other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0070] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

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

[0072] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0073] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each 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.

[0074] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0075] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by sending STA. At the receiver of the receiving STA, the above-mentioned operation for 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

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

[0077] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

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

[0080] 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, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send 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, gNB 180a may transmit multiple component carriers to 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, 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).

[0081] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

[0082] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0083] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b and routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0084] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0085] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 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 mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

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

[0087] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the 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, and providing mobility anchoring, etc.

[0088] 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 acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b via the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0089] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b and / or any other device described herein. The simulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0091] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0092] The following acronyms and / or abbreviations may be used in this document:

[0093] 6DOF 6 Degrees of Freedom

[0094] ACK

[0095] AR Augmented Reality

[0096] AS Access Layer

[0097] BWP Bandwidth Part

[0098] BSR Buffer Status Report

[0099] CSI Channel State Information

[0100] CG Configuration Authorization

[0101] DL Downlink

[0102] DMRS Dedicated Demodulation Reference Signal

[0103] DCI Downlink Control Channel

[0104] FDD Frequency Division Duplex

[0105] FoV

[0106] gNB NR Node B

[0107] FPS Frames per second

[0108] HARQ Hybrid Automatic Repeat Request

[0109] iBLEr Initial Block Error Rate

[0110] LCP Logic Control Prioritization

[0111] LCH Logical Channel

[0112] MAC Media Access Control

[0113] MCS modulation and coding scheme

[0114] MTP Movement to Photons

[0115] NAS Non-Access Stratum

[0116] NACK Negative Acknowledgement

[0117] NW Network

[0118] PDB Packet Delay Budget

[0119] PDCCH Physical Downlink Control Channel

[0120] PDCP Packet Data Convergence Protocol

[0121] PDU Packet Data Unit

[0122] PER Packet Error Rate

[0123] PHY Physical Layer

[0124] PSG Power Saving Gain

[0125] PSR Grouping Power

[0126] PUCCH Physical Uplink Control Channel

[0127] PUSCH Physical Uplink Shared Channel

[0128] PDSCH Physical Downlink Shared Channel

[0129] RLC Radio Link Control

[0130] RTT Round Trip Time

[0131] SDAP Service Data Adaptation Protocol

[0132] SR Scheduling Request

[0133] STD Standard Deviation

[0134] TDD Time Division Duplex

[0135] UCI Uplink Control Channel

[0136] UE User Equipment

[0137] UL Uplink

[0138] VR Virtual Reality

[0139] XR

[0140] As used herein, the term "extended reality" (XR) may refer to any of several different types of immersive experiences, including virtual reality (VR), augmented reality (AR), and mixed reality (MR), and realities interpolated therein. Virtual reality (VR) is a rendered version of a delivered visual and audio scene. Such rendering may mimic the visual (e.g., stereoscopic 3D) and / or auditory sensory stimulation of the natural world to an observer or user as he or she navigates the boundaries defined by the VR application. Augmented reality (AR) is when a user is provided with supplementary information and / or artificially generated items and / or content, such as superimposed on the current natural environment. Mixed reality (MR) is an advanced form of AR in which one or more virtual elements are inserted into a natural scene (e.g., by visual overlay) so that one or more of these elements can be perceived as part of the natural scene. XR may include a natural and virtual combined environment, as well as human-computer interactions generated by computer technology and wearable devices.

[0141] The concept of "immersion" in the context of XR applications / services can refer to the feeling of being surrounded by a virtual environment, and / or the feeling of being physically and spatially located in a virtual environment. The level of virtuality can range from partial sensory input to fully immersive multi-sensory input, resulting in a virtual reality that is virtually indistinguishable from natural reality.

[0142] XR devices may be equipped with one or more of a variety of sensors. Such sensors may include cameras or camera arrays (e.g., monocular cameras and / or stereo cameras and / or depth cameras), radio beacons, GPS receivers, inertial sensors, and the like. Spatial tracking may be performed at different granularities, in some examples with 3 degrees of freedom (e.g., rotational motion along the X, Y, and Z axes), and in some examples with 6 degrees of freedom (e.g., rotational and / or translational motion along the X, Y, and Z axes). Such special tracking may provide users with an interface for interacting with virtual elements within an extended reality scene. For example, actions and / or interactions may involve movement, gestures, eye tracking, and the like. For another example, some form of head and / or motion tracking may determine that virtual visual and / or audio elements may be updated in response to the user's movement. Inaccurate and / or delayed spatial tracking may cause the user to feel uncomfortable and / or motion sickness.

[0143] In the examples described herein, a wireless transmit / receive unit (WTRU) may correspond to any XR device and / or node and may take any of a variety of form factors. Typical WTRUs may include, but are not limited to, the following: head-mounted displays (HMDs), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with position tracking and cameras, wearable devices, and the like. Based on the XR device functionality, additional types of XR WTRUs may be envisioned, such as devices that combine any one or more of the following: displays, cameras, sensors, sensor processing components, wireless connectivity components, XR / media processing units, and power supplies. Such envisioned XR WTRU types may be embodied in one or more devices, wearable devices, actuators, controllers, and / or accessories. In an example, one or more devices and / or nodes (e.g., WTRUs) may be grouped into a collaborative XR system for use in supporting various XR applications and / or experiences and / or services.

[0144] In an example communication network, quality of service (QoS) may be implemented at a per-flow granularity, where a QoS flow may be identified with a QoS flow identifier (QFI). The QFI may be associated with one or more QoS parameters, such as traffic type (e.g., non-guaranteed bit rate, guaranteed bit rate, or delay critical bit rate), data rate (e.g., guaranteed flow bit rate or maximum flow bit rate), packet delay budget, average window, maximum data burst capacity (MDBV), time to live, etc. Such QoS parameters may be applied to determine forwarding treatment during transmission of a packet data unit (PDU) in a data flow.

[0145] In XR services and / or applications (e.g., AR, VR, and configuration authorization), data traffic may include one or more PDUs, which may be associated with one or more PDU sets. One or more PDUs belonging to a PDU set may be associated with each other based on specific application logic (e.g., by the spatial positioning of the PDU in a frame). For example, one or more PDUs in a PDU set may carry data associated with the field of view (FoV) spatial positioning in a frame. Similarly, one or more PDUs in a PDU set may carry non-FoV spatial positioning in a frame. The various PDUs in a PDU set may contribute to various aspects of the user experience and may therefore be associated with different spatial and / or temporal significance values. Therefore, the various PDUs associated with a PDU set may be distinguished and therefore processed differently during QoS-aware scheduling. This distinction may not be associated with whether one or more PDUs in a PDU set are in one or more associated QoS flows during transmission.

[0146] QoS may be determined at the PDU set level (e.g., PDU set level delay bound, PDU set level reliability). During transmission in both UL and DL, in addition to achieving the absolute QoS requirements for individual PDUs, the relative QoS associated with the PDUs may also be determined (e.g., the maximum delay difference achievable for different PDUs in a PDU set). QoS requirements (e.g., latency and reliability) for a PDU set associated with an XR service may be achieved via scheduling during transmission. Information related to XR traffic patterns and PDU set characteristics may be provided to the gNB to enable adaptive scheduling.

[0147] Providing XR services and traffic features. As used herein, a "communication network" or "network" may include any of a base station (e.g., an NR Node B, a TRP, a radio access network node, or an access node), core network functions (e.g., access and mobility management functions), and application functions (e.g., an edge server function or a remote server function).

[0148] As described herein, a "data flow" may correspond to a QoS flow (e.g., one or more data flows including one or more PDUs or sets of PDUs that may be associated with one or more QoS parameters, such as latency, data rate, reliability, or round-trip time delay). Different flows (e.g., those originating from a common application / experience source, or those intended for a common destination WTRU or group of associated WTRUs) may be referred to as associated flows or related flows.

[0149] As described herein, a "forwarding configuration" may correspond to any of the following: a radio bearer (e.g., a data radio bearer (DRB) and / or a signaling radio bearer (SRB)), a logical channel (LCH), a logical channel group (LCG), configuration parameters corresponding to various layers within the access stratum (AS) protocol stack (e.g., service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control, medium access control, etc.), parameters associated with logical channel prioritization (LCP) (e.g., priority, policy-based routing, etc.), bandwidth part (BWP), carrier, radio link and / or interface (Uu link, SL) and radio resources (e.g., a collection of one or more frequency and / or time and / or space resources such as time slots, subcarriers or beams). A radio resource may be associated with a configuration grant (CG), a dynamic grant (DG) and / or any other resource grant or unlicensed resource.

[0150] As described herein, a "mapping configuration" may correspond to any of the following: parameters and / or configurations associated with a mapping from one or more application data flows, QoS flows to one or more radio bearers, SDAP, PDCP, LCH, carriers or components, BWP, and radio links and / or interfaces, which can be used to deliver PDUs in an upload direction or a download direction.

[0151] A description of XR-aware and / or application-aware data transmission and / or reception and XR-aware QoS processing and / or application-aware QoS processing is provided. For example, a PDU set (e.g., a media unit, a video frame) may include one or more PDUs. A PDU set may be associated with PDU set level QoS requirements (e.g., data rate, latency, error rate, reliability), which may apply to one or more PDUs associated with the PDU set. One or more PDUs in a PDU set may be associated with a single PDU level QoS requirement. Such associations and interdependencies may be visible to an AS layer (e.g., having an association ID) and / or processed in an AS layer with association awareness during data transmission in the UL and data reception in the DL.

[0152] In an example, one or more PDUs in a PDU set may be associated with an application and / or high-level importance and / or priority value. Such values ​​may correspond, for example, to spatial importance (e.g., spatial positioning of a video frame whose data is carried in whole or in part by one or more PDUs, wherein one or more PDUs carrying FoV spatial positioning may be associated with a higher spatial importance than those carrying non-FoV spatial positioning) or, for example, to temporal importance (e.g., temporal sequence of video frames whose data is carried by one or more PDUs, wherein one or more of such PDUs carrying basic video frames (such as I frames) may be associated with a higher temporal importance than one or more of such PDUs carrying differential video frames (such as P frames / B frames). In an example, such importance values ​​may be visible to the AS layer (e.g., by an associated ID, tag, or indication). In an example, such importance values ​​may be implemented by application awareness.

[0153] In an example, one or more PDUs in a PDU set may be encoded and delivered to the WTRU or to the network via one or more data flows. In such examples, one or more QoS flows carrying one or more PDUs and / or PDU sets associated with an XR application and / or experience may be visible to the AS layer (e.g., with an associated ID) and / or processed in the AS layer with association awareness during data transmission and reception.

[0154] As used herein, example characteristics of "PDU" and "PDU set" are provided. A PDU set may include one or more PDUs. PDUs within a PDU set may have varying payload sizes and / or varying priority values. PDUs within a PDU set may have dependencies on each other. PDUs in a PDU set may have joint QoS requirements (e.g., PDU set delay bounds, PDU set error rates, PDU set throughput). PDU sets may be characterized by intra-PDU set dependencies (e.g., varying importance between PDUs and / or the presence of redundant PDUs) and inter-PDU set dependencies (e.g., subsequent PDU sets may be similar to or different from previous PDU sets). PDUs and / or PDU sets may be characterized by jitter and / or non-integer periodicity values ​​(e.g., a PDU set generation rate may typically correspond to a video frame generation rate of, for example, 60 frames per second or 120 frames per second). PDUs and / or PDU sets may be characterized by variable periodicity values ​​(e.g., a video encoder may change the frame generation rate during runtime).

[0155] As used herein, example "WTRU actions" are provided (e.g., actions related to application actions, or actions related to AS layer actions such as those supporting differentiated QoS). For example, a WTRU action may involve determining metadata. Such a WTRU action may include determining metadata related to spatial perimeters (e.g., 2D / 3D size, border, spatial attributes, boundaries of the FoV) based on measurements of one or more spatial dimensions (e.g., longitude, latitude, altitude, depth, roll, pitch, yaw) in one or more coordinate systems (e.g., Cartesian coordinate system, spherical coordinate system). Another such WTRU action may include determining metadata associated with the quality of the FoV content, for example, whether the FoV content is of high quality (e.g., in the case of images, the quality may be determined by a measure such as the described image resolution, such as by the number of megapixels of density). Another such WTRU action may include determining metadata associated with the importance and / or priority of the FoV content. Such importance and / or priority may be associated with the spatial importance and / or temporal importance of the data. For illustration, the importance value may indicate an absolute or relative importance associated with the FoV content. Spatial importance may be associated with one or more segments, tiles, slices or locations of the FoV in the spatial dimension. Temporal importance may be associated with one or more frames and / or subframes of the FoV in the temporal dimension.

[0156] In an example, a WTRU action may involve determining or generating application content. Such a WTRU action may involve determining and / or capturing one or more 2D and / or 3D images and / or video frames associated with the FoV boundaries corresponding to the WTRU's FoV metadata for itself and / or on behalf of another WTRU. For example, FoV content mapping may involve the WTRU generating one or more images and / or video frames using a visual sensor (e.g., a 2D and / or 3D camera, a lidar), an RF sensor (e.g., an RF transceiver, a radar), an audio sensor (e.g., a sonar), etc. As described herein, FoV content mapping may also be referred to as sensing FoV content or capturing FoV content. Another such WTRU action may involve recording and / or capturing one or more audio frames as part of a physical environment or as part of an overlaid audio file (e.g., an audio file originating from a source other than the mapped physical environment).

[0157] In an example, a WTRU action may involve measurement and / or reporting. Such a WTRU action may involve measuring the pose (e.g., expressed as one or more descriptions of 6DoF orientation, position, or location) or the rate of motion of the WTRU and / or other objects (e.g., virtual or physical) with which the user may interact. Such a WTRU may, for example, periodically or when triggered, send such pose measurements to the network (e.g., by determining that the change in the pose measurement is above / below a threshold). Another such WTRU action may involve measuring one or more of a reference radio signal (e.g., a 5G NR synchronization and signal block or a 5G downlink positioning reference signal), a GPS signal, an ultra-wideband signal, a lidar signal, a visual signal, etc. Another such WTRU action may involve measuring a radio link interface associated with the WTRU (e.g., Uu link, SL). For example, the WTRU triggers the sending and / or measurement of a reference signal in one or more other WTRUs (e.g., via a Uu link and / or a side link). Another such WTRU action may include sending a report of the measurement to the network and / or another WTRU.

[0158] In an example, a WTRU action may involve processing and / or forwarding data (e.g., PDUs and PDU sets) and processing QoS corresponding to the PDUs and / or PDU sets. For such example WTRU actions, the data may include media, image or video frames, sensor data, or measurement data (e.g., posture measurements or link and / or channel measurements). Such data may support applications, services, and / or network requests associated with the WTRU. Such a WTRU action may involve the WTRU transmitting and / or receiving data to and / or from one or more destinations, including a RAN node (e.g., a gNB), a CN function and / or entity, an application function (e.g., hosted in the WTRU or in the network), etc. Another such WTRU action may involve the WTRU splitting and / or merging data (e.g., PDUs) in one or more QoS flows into one or more forwarding configurations during transmission and / or reception.

[0159] In an example, a WTRU action may involve the WTRU processing and / or forwarding information related to connectivity with a network and / or one or more other WTRUs. Such a WTRU action may involve sending capability information to the network, such information including one or more of capabilities for supporting one or more interfaces, capabilities for coordinating and / or interacting with other WTRUs that may or may not be co-located with the WTRU (e.g., via an SL interface). Another such WTRU action may involve receiving configuration information, such as receiving an RRC configuration from a gNB and / or receiving a NAS layer configuration from a CN. Another such WTRU action may involve transmitting and / or receiving from the network auxiliary data associated with traffic, QoS, scheduling, etc. (e.g., for supporting UL / DL transmissions). Another such WTRU action may involve transmitting a request for radio resources and / or resource grants (e.g., dynamic grants, semi-static grants, or configured grants).

[0160] A mapping configuration may be used to map PDUs and / or PDU sets received in one or more QoS flows to one or more forwarding configurations. Such forwarding configurations may be configured to target and / or implement various QoS parameters when sending PDUs and / or PDU sets. In an example, a mapping configuration (e.g., at an SDAP) may be used to map PDUs in a PDU set received in one or more QoS flows to one or more forwarding configurations (e.g., DRBs with a common or different PDCP entity). In an example, a forwarding configuration may be associated for targeting and / or ensuring PDU set level QoS. After mapping, such a configuration may be applied to a PDU and / or PDU set associated with the forwarding configuration.

[0161] In an example, it is possible that one or more PDUs in various PDU sets may be received in different QoS flows that may have different QoS parameters. Based on the determination of the expected QoS of the PDUs and / or PDU sets received or to be received in the QoS flows, the WTRU may apply certain mapping and buffer management mechanisms at one or more layers of the AS layer protocol stack (e.g., SDAP, PDCP, MAC) so that the QoS provided for the PDUs may be met during transmission and / or after reception at the network. A similar approach may be applied when the WTRU expects to receive a PDU / PDU set in the DL from the network.

[0162] In an example, various layers in the forwarding configuration may be configured with different configuration parameters for meeting QoS parameters for a PDU and / or a set of PDUs. For example, such configuration parameters may include support for AM / UM in RLC, LCP rules / restrictions at MAC and associated LCH parameters (e.g., PBR, BSD, priority), and the number of hybrid automatic repeat request (HARQ) transmissions. In some examples, meeting QoS parameters may require setting certain configuration parameters in the PDCP sublayer (e.g., sequence number size and ROCH parameters) or the SDAP sublayer (e.g., mapping of QFI and radio bearers).

[0163] As used herein, the term "expected QoS" may be used to refer to an expected margin (e.g., for QoS targeted and / or implemented on transmission) for a QoS metric (e.g., latency, data rate, reliability) before a PDU and / or PDU set arrives or when a PDU / PDU set is received at a WTRU. For example, the expected QoS may correspond to a duration available to the WTRU for forwarding the PDU on a Uu link. For example, the expected QoS may also correspond to a time-to-live (TTL) (e.g., a maximum time available for processing and delivery) for one or more PDUs in a single PDU or PDU set. In such a case, the expected QoS may be determined based on an indication / marker in one or more PDUs (e.g., a QFI in a PDU header, a timestamp, a PDU set ID, etc.) and / or based on the use of a timer that may be started when the PDU / PDU set is received and stopped when the configured duration expires. In an example, a similar mechanism may be applied to change between different mapping and / or forwarding configurations to ensure the expected QoS.

[0164] In an example, the expected QoS may be stricter or looser than the default QoS metric associated with the PDU and / or PDU set. For example, the PDU may arrive at the WTRU late (e.g., experiencing delay and / or jitter at the application layer), or the importance value of the PDU may be determined to be high (e.g., above a threshold). In such examples, the expected latency to be met by the PDU on the Uu link will be lower than the default PDB typically used to transmit such PDUs. In other examples, the PDU may arrive earlier or the importance value of the PDU may be determined to be low (e.g., below a threshold). In such examples, the expected latency on the Uu link may be considered to be looser than the PDB typically used to transmit such PDUs. As described, the expected QoS of a PDU and / or PDU set may vary dynamically based on the QoS experienced during reception from the application layer and / or higher layers and / or based on an importance / priority indication. Therefore, for a fixed QoS (e.g., PBR, PDB), an increase or decrease in the expected QoS before reception may be converted into a decrease or increase in the expected QoS on the Uu link.

[0165] Example techniques for supporting adaptive scheduling of one or more PDUs and / or PDU sets are provided. In some examples, when processing data transmission associated with a PDU set, the WTRU may support adaptive scheduling at one or more QoS granularity levels (e.g., flow level, PDU set level, or PDU level). In various examples, the WTRU may support adaptive scheduling and / or assist the network in supporting adaptive scheduling of a PDU set during data transmission based on one or more of the following: configuration, triggering events, conditions and / or criteria received from the network, and conditions and / or criteria received from an application. In an example, the WTRU may be configured with one or more conditions and / or configurations associated with the processing of PDUs associated with a PDU set to be sent to or received from the network. Such conditions and / or configurations may relate to or may reflect an expected QoS to be achieved by the PDU and / or PDU set during transmission to the network (in the UL) or reception at the WTRU (in the DL), or a change in such expected QoS.

[0166] In an example, the WTRU may be configured to use PDU aggregate traffic information from the application layer to determine an adaptive scheduling method (e.g., DG-based, CG-based, CG+DG-based, etc.) for performing UL transmissions in accordance with associated QoS requirements. In some example techniques, the WTRU may assist the network (e.g., base station) by providing information about XR traffic patterns and requirements (e.g., the importance of PDU or PDU aggregate delay budget) to support better utilization of radio resources, save energy, and achieve XR QoS requirements. In some example techniques, the WTRU may perform some actions (e.g., enhancing the reliability of XR data transmission) by triggering changes to LCH-associated SR resources or CG configurations based on some trigger conditions (e.g., urgency of the data, deadline, failure in previous transmission, etc.).

[0167] In an example, the WTRU may transmit information associated with supporting application awareness and / or QoS processing (e.g., association of PDUs to PDU sets) to the network. Such information may enable the network to be aware of the applications and / or traffic parameters supported by the WTRU. Information associated with application awareness and / or QoS may be transmitted by the WTRU to the network as, for example, auxiliary information, preferred configuration information (e.g., preferred mapping and / or forwarding configuration applied in UL / DL), status information (e.g., associated with the AS layer), measurements and / or status reports (e.g., WTRU posture information, channel and / or link measurements, buffer occupancy measurements, etc.), request and / or response messages, etc.

[0168] In an example, the WTRU may transmit such information periodically (e.g., using one or more configured periodicity values), dynamically (e.g., upon detection of a triggering event and / or condition as described herein), as an update message (e.g., upon detection of a change in previously transmitted information), or on a semi-persistent basis (e.g., transmitted at a periodicity value over a time span). In an example, the WTRU may switch between a first periodicity value and a second periodicity value for transmitting information, which may be based on the type of event detected (e.g., a change in a PDU set characteristic). In an example, the WTRU may switch between transmitting information periodically and dynamically based on whether a change and / or the amount of change is detected in the transmitted information.

[0169] In an example, the WTRU may transmit such information to the network via any of: RRC signaling and / or messages, control PDUs associated with the AS layer (e.g., SDAP control PDUs, PDCP control PDUs, etc.), UL MAC CEs (e.g., buffer status reports (BSRs), preemptive BSRs, flexible BSRs, etc.), uplink control channels (UCIs) (e.g., scheduling requests (SRs), ARQ / HARQ feedback, ACK / NACKs, CSIs), physical uplink control channels (PUCCHs), physical uplink shared channels (PUSCHs) (e.g., containing piggybacked UCIs or first / second phase UCIs), reference signals (e.g., DMRSs, CSI-RSs, SRSs, SRSs for positioning), non-AS (NAS) layer signaling (e.g., PDU session-related messages), and application layer signaling.

[0170] In an example, such information transmitted to the network may include an identifier (ID). For example, the WTRU may transmit any of the following: an ID associated with an application (e.g., an application ID, a service ID, a session ID, an application configuration ID, etc.); a group ID (e.g., associated with a group of QoS flows, a group of forwarding configurations, a group of WTRUs); an ID of one or more QoS flows, a mapping configuration, a forwarding configuration; a data type and / or message ID (e.g., a PDU set ID, a PDU ID, an ID associated with pose information, FoV information, media / video frame information, etc.); an association ID (e.g., an ID or sequence number indicating an association between one or more UL PDUs and / or PDU sets and one or more DLPDUs, PDU sets, and / or PDU flows).

[0171] In an example, such information transmitted to the network may include an indication of the priority of applications supported by the WTRU. For example, the WTRU may transmit the ID of the supported application and / or information about the relative / absolute priority values ​​associated with the supported application.

[0172] In an example, such information transmitted to the network may include data flows associated with applications. For example, the WTRU may transmit an ID associated with the QoS flows supported by each application. Similarly, the WTRU may transmit priority values ​​associated with the QoS flows of different applications supported.

[0173] In an example, such information transmitted to the network may include devices associated with the application. For example, the WTRU may transmit IDs associated with supported devices and / or associations of devices for each application.

[0174] In an example, such information transmitted to the network may include data and / or traffic types associated with data flows for each application. For example, the WTRU may transmit information about QoS flows associated with an application, where the data types may include video data (e.g., I-frame data, P-frame data, B-frame data), RGB-D data, 360-degree video data, tactile data, pose and / or positioning data, audio data, etc.

[0175] In an example, such information transmitted to the network may include traffic characteristics and / or parameters of traffic associated with the QoS flow of each application. For example, the WTRU may transmit information about traffic characteristics of the QoS flow associated with the application, including whether such data is periodic, aperiodic, semi-persistent, quasi-periodic, etc. Such quantity characteristics may include one or more periodicity values ​​of the flow. For example, the WTRU may transmit information related to the number of PDUs expected per PDU set in one or more flows of each application. Such information on the number of PDUs per PDU set may also include statistical information, such as an average, minimum, maximum, or standard deviation value. Similarly, in some examples, the WTRU may transmit information related to the PDU set, which may include the size of the PDU set (e.g., total payload, number of PDUs in the PDU set, etc.), an indication of the first and / or last PDU in the PDU set, and an indication of the association / dependency of the PDUs in the PDU set (e.g., ID of the PDU set, importance value, priority value). For example, the WTRU may transmit information related to jitter in the UL and / or in the DL. Such jitter information may be transmitted on a per-stream, per-PDU, or per-PDU set basis and may include, for example, descriptive statistics such as range, average, maximum, and minimum values. For example, the WTRU may transmit an indication when a change in UL and / or DL ​​traffic pattern is detected (e.g., a change in periodicity, a change in average payload size, a change in jitter range, etc.). For example, the WTRU may transmit information representing a prediction of traffic patterns in the UL and / or DL ​​of upcoming data (e.g., timing, size, importance of the data to be received, uncertainty and / or confidence level of the prediction, etc.). For example, the WTRU may transmit information indicating whether one or more PDUs and / or PDU sets sent in the UL may be followed by an ACK / NACK feedback indication, which the WTRU may expect to receive from an application layer (e.g., TCP, RTP) and / or lower layers (e.g., ARQ, HARQ) with or without an associated time window after the UL transmission. In a similar example, the WTRU may transmit information indicating whether one or more PDUs and / or PDU sets received in the DL may be followed by an ACK / NACK feedback indication, which the WTRU may expect to send to the application layer (e.g., TCP, RTP) and / or lower layers (e.g., ARQ, HARQ) with or without an associated time window after the DL reception.For example, the WTRU may transmit information related to the expected one or more PDU sets (e.g., the size of the PDU set, descriptive statistics about the PDU set such as the average, the maximum payload size, the minimum payload size, the count of PDUs in the set, the size of one or more PDUs in the PDU set, the importance of the PDUs in the set, etc.). For example, the WTRU may transmit information indicating the QoS requirements of the PDU set (e.g., the PDU set latency bound, the reliability configuration requirements, etc.). For example, the WTRU may transmit intermediate QoS status information (e.g., ACK / NACK reports of previous PDUs to indicate a change in the importance, urgency, or reliability of the transmission of the incoming PDU).

[0176] In an example, such information transmitted to the network may include buffering information at networking layers such as the application layer, the AS layer, and higher layers. For example, the WTRU may transmit information indicating the amount of data payload or the buffering level (e.g., relative to one or more configured thresholds) at the application. Such payload and / or buffering information may include an indication of data waiting to be delivered to the lower layer for UL transmission or data received in the DL that may be waiting to be consumed, exhausted, or otherwise processed. Such buffering information may be reported as, for example, an estimated or measured duration of data held in the buffer before being delivered to the lower layer or consumed by the application. Such buffering information may be reported, for example, based on a data rate delivered to the lower layer or a data consumption and / or exhaustion rate at the higher layer (e.g., determined as a ratio of payload size to duration). For example, the WTRU may transmit information corresponding to the amount of data payload or the buffering level (e.g., relative to one or more configured thresholds) at the higher layer (e.g., NAS layer) and / or AS layer (e.g., in SDAP, PDCP, RLC, MAC, LCH, LCG).

[0177] In an example, such information transmitted to the network may include QoS parameters or expected QoS associated with the data. For example, the WTRU may transmit QoS parameters or expected QoS for one or more flows associated with the application (including, for example, data rate, latency, reliability, absolute and / or relative priority values, etc.). In various examples, such QoS information may include descriptive statistics, such as mean, minimum, maximum, standard deviation, etc. For example, the WTRU may transmit an indication that such QoS requirements or expected QoS may be supported at different QoS granularities (such as per PDU, per PDU subgroup within a PDU set, per PDU set, per group of PDU sets, per flow, per session, etc.). In another example, the WTRU may transmit an indication of a time window (e.g., defined by a start time and duration, a start time and an end time, or otherwise) during which such QoS requirements or expected QoS may apply at different QoS granularities.

[0178] In an example, such information transmitted to the network may include information received from an application and / or higher layers. For example, the WTRU may transmit statistical information about PDU sets (e.g., average PDU set size and average number of PDUs per PDU set). For example, the WTRU may transmit information per PDU set (e.g., PDU set payload size, PDU set delay budget, etc.) and / or information per subset of one or more PDUs within a PDU set (e.g., PDU size, PDU importance, expected arrival time, etc.). For example, the WTRU may transmit an indication of a detected change in QoS expectations (e.g., reliability requirements or delay budget) due to a change occurring in the XR traffic.

[0179] In an example, such information transmitted to the network may include resource configuration information. For example, the WTRU may transmit information about a preferred resource configuration (e.g., the number of time slots of a CG cycle, period, or opportunity, a preference for one or more CG configurations in a set of candidate CG configurations, a start offset time slot of a CG cycle / configuration, etc.). For example, the WTRU may transmit a flag indicating whether the CG update request is a one-time change (e.g., for a single CG opportunity, period, or cycle) or a semi-persistent change (e.g., for multiple CG opportunities / periods). In an example, an indication that the CG update is a semi-persistent change may imply that subsequent consecutive PDU sets may have similar characteristics until further indications are triggered / transmitted.

[0180] In an example, such information transmitted to the network may include round-trip time (RTT) latency information. For example, the RTT latency information provided by the WTRU may include end-to-end latency (e.g., application on the WTRU to application on the server to application on the WTRU). In various examples, such RTT latency may include motion to photons (e.g., the delay between the movement of a user and the change of a display of a device reflecting the user's movement), motion to audio, and motion to tactile. In various examples, such RTT information may be provided by the WTRU at different granularities, including on a per-PDU basis, on a per-PDU set basis, on a per-stream basis, or on a per-session basis. For example, the RTT latency information provided by the WTRU may include latency components associated with over-the-air UL transmission and DL reception (e.g., over a Uu link) and / or latency in the network (e.g., upstream and downstream). In various examples, such RTT latency may or may not include latency at the application layer (e.g., processing, reproduction, encoding and / or decoding latency, etc.).

[0181] In an example, such information transmitted to the network may include stream synchronization information. For example, the WTRU may transmit information describing synchronization, including delay differences between one or more PDUs and / or PDU sets in one or more related streams of the same and / or different devices / users (e.g., visual-tactile synchronization delay, audio-tactile synchronization delay, etc.). For example, such synchronization delay difference may correspond to a delay between the arrival of a PDU in a PDU set in a first stream and the arrival of the last PDU in a PDU set in an associated second stream. For example, the WTRU may transmit information about synchronization, including delay differences between unicast streams and multicast streams (e.g., for one-to-many and many-to-many interactions).

[0182] In an example, such information transmitted to the network may include posture information (e.g., orientation, location, position, etc.). For example, the posture information provided by the WTRU may include one or more measurements in spatial dimensions (such as longitude, latitude, altitude, roll, pitch, yaw, etc.) in one or more coordinate systems (e.g., Cartesian coordinate systems, spherical coordinate systems). For example, the posture information provided by the WTRU may indicate the orientation and / or position of the WTRU. In an example, the WTRU may include information corresponding to the movement of the WTRU (e.g., movement rate based on linear movement and / or rotational movement).

[0183] In an example, such information transmitted to the network may include capability information associated with connectivity. For example, information about interfaces may include the number and / or types of interfaces supported by the WTRU (e.g., NR Uu, NR SL, WiLAN, Bluetooth). For example, capability information about interfaces that may be supported by the WTRU and / or required by the WTRU to support WTRU actions may include any of the following: bandwidth, BWP, number of carriers, number of transmit antennas, number of receive antennas, etc.

[0184] In an example, such information transmitted to the network may include capability information associated with the WTRU action. For example, capability information related to WTRU actions (including visual sensing) that may be supported by the WTRU (e.g., a sensor, a camera associated with the UE) and / or required by the WTRU may include any of the following: FoV resolution (e.g., megapixel count), rendering viewport (e.g., viewport ID), FoV size (e.g., 120 degrees), aperture size, shutter delay and start-up time, image quality (e.g., minimum / maximum range), zoom lens options, image stabilization, exposure settings, battery life, sound / audio, display calibration (e.g., corrections applied to distortion and chromatic aberration), and the ability to merge overlapping frames from different angles (e.g., stitching frames from independent captures together for a panoramic image / video).

[0185] In an example, such information transmitted to the network may include preferred configuration information. For example, the WTRU may transmit one or more preferred mapping configurations, forwarding configurations, and / or resource configurations (e.g., CG, DG) to the network, including in some examples specific parameters associated with the forwarding and / or resource configurations, for supporting actions of the WTRU, including those actions that may be performed by the WTRU and / or associated devices.

[0186] Further illustrating an example forwarding configuration, such forwarding configuration transmitted by a WTRU associated with a supported and / or requested UP / CP configuration (e.g., radio bearer, LCH, link) may include a delay requirement (for a PDU, for example, the delay requirement may be expressed in terms of a packet delay budget associated with an IP packet; for a PDU set, for example, the delay requirement may be expressed in terms of a PDU set delay bound or a frame delay budget associated with a PDU set for use with a media frame), a data rate requirement (for a PDU, for example, the data rate may be expressed in terms of a bit rate associated with one or more PDUs; similarly, for a PDU set, for example, the data rate may be expressed in terms of a bit rate associated with one or more PDU sets), a reliability requirement (for a PDU, for example, the reliability may be expressed as a packet rate error; for a PDU set, for example, the reliability may be expressed as a frame error rate or a PDU set error rate), an importance value (e.g., an absolute and / or relative importance and / or priority value associated with a UP / CP configuration including a radio bearer, a logical channel, a link, etc.), and one or more of an LCP configuration. In various examples, the WTRU may indicate which LCP rules / restrictions (e.g., restrictions associated with mapping from DRB / LCH to configured resource grants) may apply for a set of forwarding configurations and / or resource configurations (e.g., CGs), whether such LCP rules / restrictions may change temporarily over a period of time, which conditional LCP configurations apply when certain configured events are detected (e.g., a surge in the number of PDUs / data with high QoS requirements), and / or which default LCP configurations prevail.

[0187] Further illustrating a forwarding configuration example, when transmitting a request related to a preferred configuration, the WTRU may associate and / or indicate weight values ​​(e.g., probability values) to different forwarding configurations. In such examples, the weight values ​​may be determined based on the likelihood of the configuration to be applied during the transmission and other application or AS layer information. For example, the network may use such weight values ​​to determine and provide the WTRU with a combined configuration and / or activate or deactivate a configuration that may match the weight value indicated by the WTRU.

[0188] Returning to the example technique for supporting adaptive scheduling of one or more PDUs and / or PDU sets, the WTRU may transmit information to the network, such as an indication for activating and / or deactivating a configuration. For example, the WTRU may transmit an indication to the network to request activation and / or deactivation of a mapping, forwarding, or resource configuration and / or parameters associated with the configuration. In an example, such configuration and / or parameters may be pre-configured in the WTRU. In an example, when the request indication is transmitted, such indication may include an ID of the configuration and / or parameter. In an example, the request to activate and / or deactivate a configuration may be accompanied by information corresponding to a WTRU action (e.g., splitting or merging one or more PDUs, QoS flows, or PDU sets).

[0189] In an example, such information transmitted to the network may include measurements related to the application or AS layer. For example, the WTRU may transmit one or more of reference signal received power, reference signal received quality, and received signal strength indication measurements of signals, channels, radio links, carriers, etc. that may be associated with one or more WTRU actions. For example, the WTRU may transmit posture and / or positioning measurement results (e.g., location information, posture in 6DoF, rate of WTRU movement). For example, the WTRU may transmit measurements and / or estimates related to RTT / MTP, application buffer level, buffer exhaustion time, exhaustion rate, etc. For example, the WTRU may transmit QoS-related measurements, including one or more of those related to the number of PDUs and / or PDU sets received within a certain duration, changes in QoS (e.g., increase / decrease in data rate, latency, reliability, etc.), the survival time associated with the PDU and / or PDU set, and the remaining time for delivering the PDU and / or PDU set.

[0190] In an example, such information transmitted to the network may include uncertainty information. For example, for other information transmitted by the WTRU, including application layer information (e.g., posture information, QoS flow, MTP delay, etc.) and / or AS layer information (e.g., preferred forwarding configuration, RTT delay, etc.), the WTRU may also transmit uncertainty associated with the information. For illustration, in an example in which the WTRU may perform a prediction or estimation of a parameter (e.g., RTT delay), the WTRU may indicate to the network the uncertainty associated with the estimation.

[0191] In an example, a WTRU may receive information applicable to support adaptive scheduling. Such support information may be used by the WTRU to implement various techniques, mechanisms, rules, actions, etc. associated with adaptive scheduling during UL transmission and / or DL ​​reception of one or more PDUs and / or PDU sets in one or more data streams. The WTRU may receive such support information from the network periodically (e.g., with one or more configured periodicity values), dynamically (e.g., as a status indication, request message, etc.), and / or on a semi-persistent basis (e.g., transmitted as a periodic value over a duration). The WTRU may receive configuration / assistance information / indications via, for example, RRC signaling and / or messages (e.g., dedicated / unicast signaling, broadcast, etc.), control PDUs associated with one or more AS layers (e.g., SDAP control PDUs, PDCP control PDUs, etc.), DL MAC CEs, DCIs, PDCCHs, PDSCHs (e.g., including piggybacked DCIs or first / second phase DCIs), wake-up signals (WUS), reference signals (e.g., DMRS, PRS, CSI-RS), ARQ / HARQ feedback (e.g., ACK / NACK feedback), etc. Examples of such supporting information are provided.

[0192] In an example, the adaptive scheduling support information may include one or more mapping, forwarding and resource configurations and / or parameters. For example, the WTRU may receive one or more configurations and / or configuration parameter sets to apply to different layers of the AS protocol stack (e.g., RRC, SDAP, PDCP, RLC, MAC, PHY, etc.). Examples of such configuration parameters for various AS layers are provided.

[0193] For the SDAP / PDCP AS layer, such parameters may include 1-to-1, 1-to-M, or N-to-M mapping configurations; tags, indications, and / or IDs to be applied (e.g., associated with processing QoS flows, PDU sets, association information between UL and DL PDUs / PDU sets); ranges of values ​​associated with importance and / or priority information to be identified in one or more PDUs and / or PDU sets. SDAP / PDCP mapping configuration may refer to information associated with mapping packets at the SDAP layer to PDCP entities and / or sublayers. For the PDCP AS layer, such parameters may include IDs and sequence numbers to be applied, RoCH configurations, security / encryption parameters, and packet repetition configurations.

[0194] For the RLC AS layer, such parameters may include parameters associated with AM, UM and / or TM operations.

[0195] For the MAC AS layer, such parameters may include LCH parameters (e.g., priority, PBR, BSD for PDU and / or PDU set level), LCP configuration (e.g., rules, restrictions and / or policies for PDU and / or PDU set level processing, duration for changing between different LCP rules and / or policies), LCP restrictions (e.g., associations and / or restrictions between LCH and SR resources, associations and / or restrictions between CG configurations and / or resources), a set of possible SR resources and / or configurations and associated LCHs that can be applied when relaxations of some LCP restrictions are activated and / or deactivated, and / or configurations for multiplexing or assembling one or more PDUs / PDU sets.

[0196] For the PHY AS layer, such parameters may include MCS and / or HARQ configuration.

[0197] In an example, the adaptive scheduling support information may include resource configuration. Examples of such resource configurations are provided.

[0198] In an example, the resource configuration may include a configuration grant (CG) configuration for UL data transmission. Parameters associated with the CG configuration may include one or more values ​​indicating periodicity, start offset, duration, BWP, parameter set / SCS, number of PRBs per time slot, number of opportunities, number of PUSCH time slots per opportunity, maximum size of PUSCH, one or more MSC values ​​for grant, antenna ports, etc.

[0199] In an example, the resource configuration may include CG configuration update actions that the WTRU may allow (e.g., allowable changes in the CG configuration may include adding, reducing and / or skipping one or more time slots (such as PUSCH time slots), adding new / additional or canceling one or more CG opportunities, shifting some opportunities in time (e.g., such as by advancing or delaying an opportunity by multiple opportunities), shifting some opportunities in frequency (e.g., such as PRBs), modifying some parameters in one or more CG opportunities corresponding to the number of PRBs, MCS values, number of symbols, transmission configuration indication (TCI), quasi co-location (QCL), etc.).

[0200] In an example, the resource configuration may include options for allowing CG configuration update actions for the WTRU (e.g., fully flexible or limited changes to increase and / or decrease the number of PUSCH time slots per CG opportunity).

[0201] In an example, the resource configuration may include a semi-persistent scheduling (SPS) configuration for DL ​​data reception. Parameters associated with the SPS configuration may include one or more periodicity, start offset, duration, BWP, parameter set / SCS value, number of PRBs per time slot, number of opportunities, number of PDSCH time slots per opportunity, maximum size of PDSCH, one or more MCS values ​​for grant, antenna ports, etc.

[0202] In an example, the resource configuration may include SPS configuration update actions that the WTRU may allow (e.g., allowable changes in the SPS configuration may include adding, reducing, and / or skipping one or more time slots (such as PDSCH time slots), adding or canceling one or more SPS opportunities, shifting some opportunities in time (e.g., such as by advancing or delaying an opportunity by multiple opportunities), shifting some opportunities in frequency (e.g., such as by PRBs), modifying some parameters in one or more SPS opportunities corresponding to the number of PRBs, MCS values, number of symbols, TCI, QCL, etc.).

[0203] In an example, the resource configuration may include dynamic grant (DG) resources for UL data transmission (e.g., triggered by UCI, SR, BSR, MAC CE). Parameters associated with the DG are one or more values ​​indicating a start offset, duration, BWP, parameter set / SCS value, number of PRBs per time slot, number of PUSCH time slots per opportunity, maximum size of PUSCH, one or more MSC values ​​for grant, antenna ports, etc.

[0204] In an example, resource configuration may include dynamic scheduling / grant (DS / DG) resources for DL ​​data reception (e.g., triggered by DCI, PDCCH, MAC CE). Parameters associated with DS / DG are one or more values ​​indicating a start offset, duration, BWP, parameter set / SCS value, number of PRBs per time slot, number of PDSCH time slots per opportunity, maximum size of PDSCH, one or more MSC values ​​for grant, antenna ports, etc.

[0205] In an example, the resource configuration may include timing information / windows indicating when at least some of the CG, SPS, or DG configurations / parameters may be updated for the WTRU.

[0206] In an example, the adaptive scheduling support information may include at least one set of configuration parameters associated with a default configuration, which may be activated and / or used during a normal scenario for sending and / or receiving data. The WTRU may receive one or more additional sets of configuration parameters, which may be associated with abnormal operations (e.g., which may be activated and / or used when a triggering event and / or condition is detected).

[0207] In an example, the adaptive scheduling support information may include a default priority value associated with a resource configuration (e.g., a CG). For example, a first resource configuration may be associated with a first priority value, and a second resource configuration may be associated with a second priority value. For one or more PDUs and / or PDU sets that use the first resource configuration and the second resource configuration during transmission, such first resource configuration and the second resource configuration may be associated with the same application, and the first priority value set may be associated with achieving a default QoS performance (e.g., a default latency, a default data rate, etc.), and the second priority value set may be intended to achieve excellent QoS performance (e.g., a burst data rate, very low latency, etc.).

[0208] For example, in a case where the WTRU may be configured with multiple PUSCH slots per CG opportunity, multiple PDSCH slots per SPS opportunity, multiple PUSCH slots per DG resource, and / or multiple PDSCH slots per DG / DS resource, adaptive scheduling support information associated with one or more slots for various resource grants may be indicated or modified using a single DCI. A single DCI may include one or more DCI transmissions (e.g., in a PUCCH or PDCCH) at one or more occasions. In an example, the WTRU may be configured with multiple PUSCH slots in a CG opportunity. Multiple PUSCH slots may be used to send multiple TBs per opportunity. Multiple PUSCH slots may be configured in the WTRU by configuring and / or activating a single active CG configuration with multiple slots per opportunity or multiple active CG configurations with a single slot per opportunity (e.g., with different start offsets for the slots).

[0209] For example, for one or more CG configurations, in the case where the WTRU may be configured with multiple PUSCH time slots per opportunity, the WTRU may be indicated with a single DCI to indicate activation and / or deactivation, parameters and / or changes to CG configuration parameters (e.g., increase or decrease the number of time slots per opportunity, time shift by advancing or delaying some time slots in one or more opportunities, modify parameters such as MCS and PRB in one or more time slots per opportunity, etc.). Such a single DCI may indicate changes to a single opportunity or multiple opportunities associated with the CG configuration. In an example, the WTRU may be configured with multiple PDSCH time slots in an SPS opportunity. Multiple PDSCH time slots may be used to receive multiple TBs per opportunity (in the DL). Multiple PDSCH time slots may be configured in the WTRU by configuring and / or activating a single active SPS configuration with multiple time slots per opportunity or multiple active SPS configurations with a single time slot per opportunity (e.g., with different start offsets for the time slots).

[0210] For example, for one or more SPS configurations, in the case where the WTRU may be configured with multiple PDSCH time slots per opportunity, the WTRU may be indicated with a single DCI to indicate activation and / or deactivation, parameters and / or changes to SPS configuration parameters (e.g., increase or decrease the number of time slots per opportunity, time shift by advancing or delaying some time slots in one or more opportunities, modify parameters such as MCS and PRB in one or more time slots per opportunity, etc.). Such a single DCI may be used to indicate changes to a single opportunity or multiple opportunities associated with the SPS configuration. In an example, the WTRU may be configured with multiple PUSCH time slots per DG resource. Such multiple PUSCH time slots may be used to send multiple TBs per DG resource. Multiple PUSCH time slots may be configured in the WTRU by allocating a single DG resource with multiple time slots per DG resource or multiple DG resources with a single time slot per DG resource (e.g., with different start offsets for the time slots).

[0211] For example, in the case where the WTRU may be configured with multiple PUSCH slots per DG resource, the WTRU may be indicated with a single DCI for indicating parameters and / or changes to DG parameters (e.g., increasing or decreasing the number of slots per opportunity, time shifting by advancing or delaying some slots in one or more opportunities, modifying parameters such as MCS and PRB in one or more slots per opportunity, etc.). In an example, the WTRU may be configured with multiple PDSCH slots per DG / DS resource. Multiple PDSCH slots may be used to send and / or receive multiple TBs per DG / DS resource. Multiple PDSCH slots may be configured in the WTRU by allocating a single DG / DS resource with multiple slots per DG / DS resource or multiple DG / DS resources with a single slot per DG / DS resource (e.g., with different start offsets for the slots).

[0212] For example, in a case where the WTRU may be configured with multiple PDSCH time slots per DG / DS resource, the WTRU may be indicated with a single DCI for indicating parameters and / or changes to DG / DS parameters (e.g., increasing or decreasing the number of time slots per opportunity, time shifting by advancing or delaying some time slots in one or more opportunities, modifying parameters such as MCS and PRB in one or more time slots per opportunity, etc.).

[0213] In an example, the adaptive scheduling support information may include an identifier (ID). For example, the WTRU may receive information including one or more IDs to be applied during transmission and / or reception. Examples of such IDs are provided. In an example, the ID may include a WTRU ID, such as a C-RNTI, an I-RNTI, a NAS ID, a TMSI / IMSI, etc. In an example, the ID may include an ID associated with an application (such as one or more of an application ID, a service ID, a session ID, an application configuration ID, etc.). In an example, the ID may include a group ID (e.g., associated with a group of QoS flows, a group of forwarding configurations, a group of devices and / or WTRUs, etc.). In an example, the ID may include an ID for a single QoS flow, a mapping configuration, a forwarding configuration, etc. In an example, the ID may include a data type or a message ID (e.g., a PDU set ID, a PDU ID, etc.). In an example, the ID may include a resource configuration ID (e.g., a CG ID, an SPS ID, etc.).

[0214] In an example, the adaptive scheduling support information may include forwarding state and / or resource configuration. For example, when one or more such configurations are used, the WTRU may receive information about the achieved and / or achievable QoS (e.g., latency, error rate, etc.). In an example, when sending and / or receiving one or more PDUs or PDU sets, such information may be received by the WTRU in terms of achievable and / or achieved data rate, latency (e.g., expected or remaining latency, etc.), reliability (e.g., error rate), and / or priority. Similarly, the WTRU may receive statistical information associated with the achieved and / or achievable QoS in terms of descriptive statistics (such as mean, maximum, minimum, standard deviation, etc.).

[0215] In an example, the adaptive scheduling support information may include a flow control indication. For example, the WTRU may receive from the network an explicit or implicit flow control indication associated with, for example, starting, increasing, decreasing, pausing, or stopping the transmission of one or more PDUs or sets of PDUs. Such flow control indication may be associated with achieving an indicated transmission rate, latency, or error rate in one or more forwarding configurations.

[0216] In an example, the adaptive scheduling support information may include validity information. For example, the WTRU may receive validity information associated with a forwarding configuration and / or a resource configuration, the validity information indicating whether or when such a configuration may be considered valid or invalid based on one or more trigger conditions. The WTRU may also receive validity information indicating whether such a configuration is to be deactivated and / or released when determined to be invalid. In an example, the WTRU may receive information indicating that a configuration is to be considered valid based on the RRC state of the WTRU (e.g., connected, inactive, idle) and / or when transitioning between different RRC states.

[0217] In an example, the adaptive scheduling support information may include a threshold. Examples of such thresholds are provided.

[0218] In an example, the threshold may include one or more buffer occupancy thresholds. For example, a buffer occupancy threshold associated with a forwarding configuration may indicate a maximum and / or minimum amount (e.g., in terms of total payload capacity) of data, a PDU, or a set of PDUs that may be included in a buffer (e.g., an application layer buffer, an AS layer LCH buffer, etc.).

[0219] In an example, the threshold may include one or more payload size thresholds. For example, the payload size threshold may be associated with one or more upper and / or lower values ​​corresponding to the total size (e.g., in bits or bytes) of the payload of one or more PDUs or PDU sets. In an example, the payload size threshold may be associated with one or more upper and / or lower values ​​corresponding to the total number of PDUs in a PDU set.

[0220] In an example, the threshold may include one or more residual delay thresholds when processing a PDU set. For example, the WTRU may receive one or more thresholds (e.g., maximum and / or minimum values) associated with the residual delay for performing one or more actions during transmission and / or reception. For example, the residual delay may be related to the remaining PDUs in the transmitted PDU set. Similarly, the residual delay may refer to, for example, the difference between the total delay for transmitting the PDUs in the PDU set (e.g., PSDB) and the delay caused by the subset of one or more PDUs in the PDU set. The WTRU actions that may be performed based on the comparison of the residual delay for transmitting the PDU set relative to the residual delay threshold may include, for example, determining whether to trigger a request for new resources (e.g., triggering SR, BSR, etc.), determining a change to a resource configuration (e.g., CG, DG, CG+DG, etc.), determining whether to relax LCP restrictions on accessing and / or switching to resources from other LCHs (e.g., CG resources, SR resources from other restricted LCHs, etc.), etc.

[0221] In an example, the adaptive scheduling support information may include an expected threshold time (ETT) value. Examples of such expected threshold time values ​​are provided. For example, the WTRU may receive one of a plurality of ETT values ​​or expected time of arrival (ETA) thresholds corresponding to an expected time for receiving one or more PDUs and / or PDU sets in a data stream, where the PDU may be the first or last PDU associated with the PDU set, or a subsequent PDU after receiving an earlier PDU. In an example, the ETT threshold may be associated with an expected delay of a second PDU and / or PDU set after receiving and / or sending a first PDU and / or PDU set with a first delay value. In an example, the second PDU may correspond to the last PDU in the PDU set. In an example, after receiving and / or sending one or more PDUs and / or PDU sets in a first data stream with a first delay value, the ETT threshold may be associated with an expected delay of a PDU and / or PDU set in a second associated data / QoS stream. In an example, the ETT threshold may be associated with a duration or a timer value. In an example, the WTRU may start a timer at a time instance when a first PDU is received and / or sent, and stop the timer when the timer expires at a time instance corresponding to a threshold time value and / or when a second PDU is received and / or sent (e.g., the first PDU and the second PDU may be associated with the same PDU set).

[0222] In an example, the adaptive scheduling support information may include an expected data rate (EDR) threshold. Examples of such EDR values ​​are provided. For example, the WTRU may receive one or more EDR threshold (EDR) values ​​associated with a data rate expected for receiving and / or sending one or more PDUs and / or PDU sets in one or more data streams. The data rate may correspond to any of the following units: PDU / PDU set per second, number of frames per second, bits / bytes per second, etc. In an example, after receiving and / or sending a first PDU and / or PDU set having a first data rate value, the EDR threshold may be associated with an EDR for a second PDU and / or PDU set. In an example, after receiving and / or sending one or more PDUs and / or PDU sets in a first data stream having a first data rate value, the EDR threshold may be associated with an EDR for one or more PDUs and / or PDU sets in a second associated data stream.

[0223] In an example, the adaptive scheduling support information may include an expected reliability (EER) threshold. Examples of such EER values ​​are provided. For example, the WTRU may receive one or more EER values ​​associated with the expected reliability for receiving one or more PDUs and / or PDU sets in one or more data / QoS flows. The reliability value may correspond to any of the following units: packet error rate, frame / PDU set error rate, and / or error probability, etc. In an example, after receiving and / or sending a first PDU and / or PDU set with a first reliability value, the EER threshold may be associated with the expected reliability for a second PDU and / or PDU set. In an example, after receiving and / or sending one or more PDUs and / or PDU sets in a first data / QoS flow with a first reliability value, the EER threshold may be associated with the expected reliability for one or more PDUs and / or PDU sets in a second associated data / QoS flow.

[0224] In an example, the threshold may include one or more pose difference thresholds. For example, the pose difference threshold may correspond to a difference between a measurement of pose information at a first time instance and a second time instance, wherein the time instances may correspond to any of the following units: time slot, symbol duration, SFN, seconds, milliseconds, etc.

[0225] In an example, the threshold may include one or more WTRU mobility thresholds. For example, the WTRU mobility threshold may correspond to a difference between a position or rotation angle of the WTRU between a first time instance and a second time instance, where these time instances may correspond to any of the following units: time slots, symbol durations, SFNs, and seconds, milliseconds, etc.

[0226] In an example, the threshold may include one or more relevant time window values. For example, the relevant time window may correspond to the minimum time difference between two triggering events (e.g., posture information measurement, QoS event, etc.), where the two events may be considered to be related when they occur within the relevant time window. When two events occur at time instances outside the relevant time window, they may be considered to be independent. In an example, the WTRU may use the relevant time window to determine whether to transmit an indication to the network (e.g., indicating a change in the WTRU's location / movement or a change in QoS).

[0227] In an example, a WTRU may receive triggering events and / or conditions applicable to support adaptive scheduling. The WTRU may be configured with one or more triggering conditions related to triggering WTRU actions, such as transmitting auxiliary information and / or indications to the network, receiving configuration and / or auxiliary information from the network, transmitting indications and / or requests for changing resource configurations, transmitting indications and / or requests for changing forwarding configurations, etc. Such triggering events / conditions may be related to adaptive scheduling and / or used to meet QoS requirements (e.g., latency, reliability) when sending / receiving PDUs / PDU sets in one or more associated QoS flows. Such triggering events / conditions may determine whether the WTRU can perform an action and which actions can be performed. Such triggering events / conditions may determine when (at what moment) the WTRU can perform an action. For example, the WTRU may select a resource configuration (e.g., CG, SPS, DG, etc.) for achieving the expected QoS based on the detection of one or more triggering events and / or conditions. Examples of such triggering events and / or conditions are provided.

[0228] In an example, the triggering event and / or condition may include information from a network.

[0229] For example, the WTRU may receive an indication from the network (e.g., gNB, etc.) of the expected and / or achievable QoS for transmission and / or reception over the Uu link (in UL and / or DL). Such indication may be received semi-statically, during configuration, or dynamically. The WTRU may trigger WTRU actions (e.g., determining / selecting a mapping, forwarding, or resource configuration) based on the indication received from the network. In such an example, the expected and / or achievable QoS may be indicated per PDU, per PDU set, per QoS / data flow, per forwarding configuration, per resource configuration, etc.

[0230] In other such examples, the WTRU may implicitly receive information associated with expected and / or achievable QoS from the network (e.g., gNB, etc.) based on one or more of the following: the number of times HARQ feedback is received, the size and / or timing of resource grants used to allocate resources (configuration grants, dynamic grants, etc.), the allocation of retransmission grants corresponding to one or more forwarding configurations (e.g., LCH, DRB, BWP, etc.), de-prioritization of PUSCH of one or more LCHs due to prioritization within or between WTRUs, etc.

[0231] In other such examples, the WTRU receives an indication from the network (e.g., in an RRC, MAC CE, other control PDU or DCI, etc.) and may be triggered to perform one or more WTRU actions. In an example, such indication received by the WTRU may be related to a change in forwarding and / or resource configuration at the WTRU and / or an expected QoS associated with one or more PDU sets or QoS flows.

[0232] In an example, the triggering event and / or condition may include an indication and / or information from an application and / or higher layers. Examples of such indications and / or information from an application layer and / or higher layers are provided.

[0233] For example, upon receiving an indication from the application layer and / or higher layers, the WTRU may perform one or more WTRU actions. Such indications may include information about changes in traffic characteristics associated with the generation, processing, or reception of one or more PDUs and / or PDU sets in one or more data flows.

[0234] In an example, the application may indicate to the WTRU information regarding an expected number of QoS flows that may be associated with the application, an expected number of PDUs per PDU set, expected frames and / or PDU sets in one or more subsequent time instances (e.g., the next frame generation instance), an expected change in the priority distribution of one or more PDUs generated, an expected increase and / or decrease in latency (e.g., due to processing at the application), an expected increase and / or decrease in QoS (e.g., latency, error rate, etc.), jitter for delivering PDUs and / or PDU sets in the UL and / or DL, an expected change in the time to live associated with one or more PDUs and / or PDU sets, an expected change in WTRU mobility (e.g., an increase and / or decrease in motion rate), and the like.

[0235] In an example, the WTRU may receive an indication from an application layer and / or higher layers indicating the arrival of one or more PDUs and / or sets of PDUs (e.g., in batches) from an application in the WTRU (for UL) or from an application in the network (for DL). Such information regarding the arrival of the one or more PDUs and / or sets of PDUs may include an expected timing generated at the application (e.g., time slot, time frame, etc.) and / or an expected timing received at the WTRU. Such information may be indicated to the WTRU via a timestamp, sequence number, etc.

[0236] In an example, the WTRU may be triggered to perform one or more WTRU actions based on an indication of a priority for sending one or more PDUs and / or sets of PDUs. In an example, upon receiving an indication including a priority value above a threshold, the WTRU may trigger an action (e.g., change forwarding and / or resource configuration) to transmit a delayed PDU with compensation (e.g., low latency).

[0237] In an example, the triggering event and / or condition may include a buffer state and / or a load at a forwarding configuration (e.g., DRB / LCH). Such a buffer state may include at least one condition associated with one or more of the following: the amount of one or more PDUs and / or PDU sets in one or more buffers associated with the forwarding configuration over a period of time; the arrival and / or departure rate of one or more PDUs and / or PDU sets in one or more buffers associated with the forwarding configuration; the average, maximum, minimum capacity of one or more PDUs and / or PDU sets in the buffers associated with the forwarding configuration (e.g., the number of PDUs in the LCH buffer); a measure of the amount of time spent by one or more PDUs and / or PDU sets in the buffers associated with the forwarding configuration; the number of forwarding configurations that meet conditions and / or thresholds associated with data volume, arrival rate, PDU and / or PDU set size (e.g., total payload size), etc. Examples of such buffer states are provided.

[0238] In an example, if at least one PDU or a set of PDUs in the forwarding configuration (e.g., a UL LCH buffer waiting to be sent in the UL, a DL LCH buffer waiting to be processed, etc.) is in the buffer for a period of time exceeding a threshold time value, the WTRU may perform one or more actions (e.g., changing the forwarding configuration, changing the resource configuration, etc.).

[0239] In an example, if the buffer status of a forwarding configuration exceeds a threshold, the WTRU may perform one or more actions (e.g., transmit a report or status indication). In an example, the buffer status metrics that may be monitored to determine the expected QoS include the number of PDUs and / or PDU sets buffered in one or more associated forwarding configurations that exceed a configured threshold, or the rate at which PDUs or PDU sets arrive and / or depart in the buffer relative to a configured arrival / departure rate.

[0240] In an example, the WTRU may determine the number of PDUs and / or PDU sets received within a duration for use in evaluating whether the rate of PDUs received (e.g., received from higher layers for UL transmission, or received from the network for DL ​​reception) is within an expected range for QoS. In an example, such a duration may be used to evaluate whether one or more PDUs and / or PDU sets received from the network are received within a latency bound. If such PDUs and / or PDU sets are received outside the expected range for QoS, the WTRU may select a mapping configuration to adjust the expected QoS.

[0241] In an example, the triggering event and / or condition may be associated with a configuration change at the WTRU. An example of such a configuration change is provided.

[0242] In an example, when a change to a mapping configuration, forwarding configuration, and / or resource configuration is determined (including a change to a mapping configuration (e.g., mapping a QoS flow to a new forwarding configuration), at least one of the parameters at the DRB and / or LCH (e.g., priority, PDB, PBR, etc.), LCP configuration or restrictions, and / or resource configuration or parameters (e.g., CG, DG, SPS, etc.)), the WTRU may be triggered to perform an action (e.g., transmit an indication and / or report to the network).

[0243] In an example, when the CDRX or DRX configuration or associated parameters applied at the WTRU changes, the WTRU may be triggered to perform an action because such changes may affect the transmission and / or reception mode and / or QoS (e.g., RTT, etc.) that can be achieved during data transmission and / or reception.

[0244] In an example, the WTRU may be configured with one or more PDCCH monitoring behaviors, where different monitoring behaviors may include one or more of high-effort monitoring (e.g., high periodicity) and low-effort monitoring (e.g., low periodicity). In an example, the WTRU may change from high-effort monitoring to low-effort monitoring, or vice versa, based on detection and / or indication of a change in traffic pattern from high load (e.g., high number of TBs / timeslot) to low load (e.g., low number of TBs / timeslot).

[0245] In an example, a WTRU may be configured with PDCCH monitoring between a dense search space set group (SSSG) and a sparse SSSG. Such a WTRU may change from monitoring a dense SSSG to monitoring a sparse SSSG, or vice versa, based on detection and / or indication of a change in traffic pattern from high load (e.g., high number of TBs / timeslot) to low load (e.g., low number of TBs / timeslot).

[0246] In an example, the triggering event and / or condition may be associated with timing information, which may be further associated with the expected QoS. Such timing information may include one or more of the following: one or more timestamps, one or more sequence numbers, one or more tags, one or more PDUs, etc. Examples of such timing information are provided.

[0247] In an example, the WTRU may track timing information in one or more PDUs and / or PDU sets received in an earlier time window to determine latency or jitter. Such timing information may then be used to determine the expected QoS of an upcoming PDU or PDU set in a later time window (e.g., the next time window).

[0248] In an example, the timing information may be a restrictive deadline, a latency bound, or a time to live. Such restrictions may be defined on a per-PDU, per-PDU set, or per-QoS flow basis. Such timing information may be determined across one or more associated QoS flows (e.g., including associated UL flows, associated DL flows, and associated UL+DL flows). In an example, such timing information may also be determined on a count basis (e.g., a PDU or PDU set count). When determining whether the expected QoS can be achieved based on the timing information, the WTRU may trigger an action (e.g., determining a mapping and / or forwarding configuration). In an example, the WTRU may transmit information about the expected QoS based on measurements associated with the duration that one or more PDUs and / or PDU sets spend in the forwarding configuration (e.g., the time elapsed from receiving one or more PDUs and / or PDU sets from a higher layer to sending in the UL, the time elapsed from sending one or more PDUs and / or PDU sets in the UL to receiving in the DL, the time elapsed from receiving one or more PDUs and / or PDU sets in the DL to forwarding to a higher layer, etc.).

[0249] In an example, a WTRU may communicate timing information about latency (e.g., total latency, remaining latency, etc.) of one or more PDUs and / or PDU sets transmitted in the UL and received in the DL based on measurements at AS layer entities and / or sublayers (e.g., SDAP, PDCP, RLC, MAC, etc.). In an example, a PDCP entity used by a WTRU for UL transmission of a PDU set may start a timer (e.g., a discard timer, an RTT timer, etc.), possibly including a sequence number, and / or transmit the PDU set to a lower layer. Such a WTRU may measure the RTT latency at such a PDCP entity based on reception of an associated PDU set with a corresponding sequence number (e.g., a DL sequence number may be added by the gNB). In such a scenario, if the timer expires before receiving the PDU set in the DL, the WTRU may transmit an indication to the gNB to discard the PDU set, transmit a PDU set with a lower priority, or transmit a PDU set with a higher priority.

[0250] In an example, a WTRU may be configured with one or more discard timer values ​​associated with a QoS parameter (e.g., at a PDCP entity) associated with a set of PDUs forwarded using an associated DRB. For example, the one or more discard timer values ​​may be associated with a PDU set delay bound (PSDB) value. In an example where the WTRU is preconfigured with a set of one or more discard timer values ​​and / or the WTRU selects a discard timer value from a preconfigured set (e.g., based on monitoring and / or detection of a PSDB value for a set of PDUs), the WTRU may transmit an indication to the network indicating the selected discard timer value (e.g., in RRC signaling, MAC CE, or UCI, etc.). In an example, when a discard timer expires at a transmitting PDCP entity (e.g., at the WTRU), or when a status report indicating successful reception of a PDU associated with a set of PDUs is received from a receiving PDCP entity (e.g., a base station), the transmitting PDCP entity may discard any of the transmitted PDUs and / or the remaining untransmitted PDUs in the set of PDUs. In an example, the PDU discard mechanism applied may vary between the type of PDU set processed by the WTRU and / or the priority value of one or more PDUs within the PDU set. For example, in a case where a first subset of a PDU set (e.g., high priority) may have different QoS requirements than a second subset of a PDU set (e.g., low priority), some PDUs in the first subset of the PDU set (e.g., high priority) may not be discarded even when a discard timer associated with the PDU set expires. For example, when the discard timer expires, the PDUs associated with the second subset of the PDU set (e.g., low priority) may be discarded. In examples where the PDUs may have similar QoS requirements (e.g., similar priority levels), the remaining PDUs may be discarded when the discard timer associated with the PDU set expires.

[0251] In an example, the WTRU may transmit information to the network periodically or based on the expiration of a configured timer.

[0252] In an example, the WTRU may be configured to use any of the resource grants based on CG, DG, and / or CG+DG. For example, the WTRU may be configured with a timer associated with the transmission of one or more PDU sets. In an example, a WTRU configured to use a first resource configuration (e.g., a first CG configuration) may switch to using a second resource configuration (e.g., a second CG configuration or a DG configuration) upon expiration of the configured timer.

[0253] In an example, a WTRU may be configured with an adaptable CG configuration (e.g., allowing CG resources to be adapted based on L2 / L1 signaling (e.g., DCI)), which may be used as long as the configuration timer is running and valid. In an example, such a WTRU may switch from using the adaptable CG configuration to the default CG configuration after the configuration timer expires.

[0254] In an example, a WTRU may set a timer when certain SR resources from a restricted LCH are used during transmission of one or more PDUs and / or PDU sets. In an example, such a WTRU may use the SR resources as long as the timer is running (e.g., after some relaxation of LCP restrictions). Such a WTRU may fall back to using SR resources associated with a default LCH after the timer expires.

[0255] In an example, the triggering event and / or condition may include measurements based on one or more Uu links. Examples involving such Uu link measurements are provided.

[0256] In an example, the WTRU may use Uu link measurements corresponding to RSRP, RSSI, CQI, and / or CSI to determine the expected QoS. Channel and / or load measurements taken over a certain duration may indicate whether one or more PDUs and / or PDU sets can achieve the expected QoS during transmission and / or reception, or whether the QoS budget may be exceeded. The WTRU may trigger actions (e.g., determine a mapping configuration) based on such channel and / or load measurements.

[0257] In an example, the WTRU may determine the Uu link condition based on the number of ARQ / HARQ (ACK / NACK) feedback messages and / or ARQ / HARQ retransmissions performed on one or more HARQ processes associated with a forwarding configuration associated with transmitting one or more PDUs and / or PDU sets. The updated QoS expectations may be determined based on a mapping function between the Uu link conditions determined in the UL and / or DL ​​and the expected QoS. In an example, a ReTx (or retransmission) count above a threshold may indicate a poor Uu link condition and, therefore, result in a reduced updated QoS expectation. In an example, a change to a resource configuration (e.g., the number of PUSCH time slots for a CG and / or DG) may be determined based on a mapping function between the Uu link conditions determined in the UL and / or DL ​​and the resource configuration. In an example, a ReTx count exceeding a threshold or a number of NACK feedback receptions may be converted into an increase or decrease in the number of time slots allocated per CG opportunity or DG. In various examples, the WTRU may determine the Uu link condition based on a CSI report sent to and / or received from the network.

[0258] In an example, when the Uu link condition (based on, e.g., RSRP, RSSI, RSRQ, CQI, CSI) changes to exceed a configured threshold and / or remains above the threshold for a certain duration, the WTRU may be triggered to perform one or more actions (e.g., transmit an indication to the network).

[0259] In an example, when one or more QoS related measurements (e.g., latency measured for one or more PDUs / PDU sets in one or more forwarding configurations) exceed a certain threshold, the WTRU may be triggered to perform one or more actions.

[0260] In an example, the WTRU may trigger an action based on determining a duration or jitter, or a change in duration or jitter, between reception of consecutive PDUs associated with a PDU set and / or reception of one or more PDUs and / or PDU sets in one or more related streams in UL and / or DL. In an example, the WTRU may infer a change in jitter between consecutive PDUs to determine whether the processing load at the application layer or higher layers is high or low. To determine the duration or jitter, the WTRU may set a timer when a first PDU arrives and reset the timer when a second PDU associated with a PDU set associated with the first PDU arrives.

[0261] In an example, the triggering event and / or condition may include compensation based on the expected QoS. Examples involving such compensation are provided.

[0262] For example, the WTRU may be triggered to perform one or more actions based on a determination of an expected QoS for one or more PDUs and / or sets of PDUs, where the expected QoS may indicate that such PDUs may be delayed or may arrive early during UL transmission and / or DL ​​reception. In an example, the WTRU may trigger an action such that a delayed or advanced set of PDUs may be sent with a determined compensation amount by, for example, selecting an appropriate resource configuration (such as a CG or DG resource). In an example, if the WTRU determines that a PDU has been delayed, it may select a forwarding and / or resource configuration suitable to satisfy the compensation amount, where such compensation amount may be determined by subtracting the expected delay from the observed or actual delay. In an example, such an action may be triggered when a change in the expected QoS of a PDU / PDU is detected that exceeds a certain threshold.

[0263] In an example, the triggering event and / or condition may include one or more attributes associated with a link and / or channel associated with the forwarding configuration. Examples involving such attributes are provided.

[0264] For example, a WTRU may be configured with attributes specific to a forwarding configuration, link, and / or channel, such as a priority or one or more parameters that enable or disable actions per forwarding configuration, link, or channel. In an example, a link configured with a high priority attribute may allow the WTRU to change configuration (relative to an initial or default configuration). For example, such a WTRU may change parameters of a link associated with a high priority as long as such changes only affect other lower priority forwarding configurations.

[0265] In an example, the triggering event and / or condition may include detection of a QoS event, where the QoS event may include, for example, a surge in payload size or the arrival of high importance data. Examples involving such QoS events are provided.

[0266] For example, a QoS event may include a surge event indicating high importance associated with an increase in the number of PDUs and / or PDU sets or an increase in data capacity (e.g., within a time window). Example QoS events may include QoS reductions associated with a decrease in the number of PDUs and / or PDU sets or a decrease in payload capacity (e.g., within a time window). In an example, a QoS event may be detected when the WTRU detects poor or degraded radio conditions. Such poor or degraded radio conditions may be determined based on measurements, increased retransmissions, increased NACKs of uplink packets, etc.

[0267] For example, in some examples, based on the expected duration of the QoS events, when one or more QoS events are detected, the WTRU may be triggered to perform one or more actions. In an example, such a WTRU may perform one or more other actions, such as falling back to a default configuration. In an example, when a surge event (e.g., an increase in the total payload or number of PDU sets) is detected, the WTRU may trigger an action to change the resource configuration in the UL and / or DL ​​(e.g., a CG and / or SPS updated for the duration of the surge) so that the surge event can be accommodated within the latency bounds. In an example, upon determining a reduction in the surge event or the end of the surge event, such a WTRU may fall back to using the default resource configuration in the UL and / or DL ​​(e.g., a default CG and / or SPS).

[0268] In an example, the WTRU may determine a resource grant type (e.g., DG, CG, or CG+DG) for sending one or more PDU sets in the UL within an associated PDU set level latency bound based on information including one or more of a PDU set characteristic (e.g., a PDU set payload size), resource configuration information, and / or a payload size threshold. In an example, the WTRU may determine whether to use a default CG configuration or trigger a request for a DG allocation, for example, based on PDU set traffic information received from an application layer and / or higher layers. An example of a resource grant type for determining sending one or more PDU sets in the UL may be provided.

[0269] The WTRU may receive configuration information from a network (e.g., a gNB, etc.) including one or more default CG resource configurations (e.g., the default CG resource configuration may include one or more parameters such as the number of PUSCH time slots per opportunity, a periodicity value, and the number of opportunities) and minimum and maximum thresholds for the total PDU set payload size (e.g., per opportunity) that can be sent using the default CG resources.

[0270] Such a WTRU may receive, from an application layer and / or higher layers, a first PDU subset including one or more PDUs associated with a PDU set (and in some examples, traffic pattern information associated with the PDU set). In an example, such a first subset may include PDU set information (e.g., in one or more PDU headers) associated with the PDU set (e.g., total PDU set payload size, total number of PDUs in the PDU set, PDU set delay budget, etc.).

[0271] Such a WTRU can determine the resource authorization type (DG, CG or CG+DG) for sending the PDU set based on, for example, configuration information and PDU set information.

[0272] In examples where the total PDU aggregate payload size is less than the minimum PDU aggregate payload size threshold for the CG, such a WTRU may trigger an SR and / or a BSR to request DG resources. For example, the WTRU may provide explicit or implicit information about the PDU aggregate delay budget, requesting in some examples that a DG PUSCH slot be allocated prior to a PDU aggregate delay deadline. In examples, such a WTRU may save transmit power by transmitting a PDU aggregate on one or more DG PUSCH slots, which may be less than the number of PUSCH slots in a single CG opportunity, for example, by transmitting a request for a single DG.

[0273] In some examples, after receiving an indication (e.g., in a DCI) indicating an allocation of DG resources from a network (e.g., a gNB, etc.), such a WTRU may use such DG resources to send PDUs associated with a PDU set. In an example, such a WTRU may send an indication to the network indicating that at least a subset of the CG resources are not used to send the PDU set.

[0274] In examples where the total PDU set payload size is at least a minimum PDU set payload size threshold for the CG, such a WTRU can determine the expected delay for transmitting PDUs associated with the PDU set based on configuration information and in some examples based on minimum and / or maximum payload size thresholds.

[0275] In an example where the total PDU set payload size is no greater than the maximum PDU set payload size threshold of the CG and where the expected latency is less than the PDU set delay budget, such a WTRU may use the resources and / or timing provided in the CG resource configuration to send PDUs associated with the PDU set.

[0276] In an example where the total PDU set payload size is at least the maximum PDU set payload size threshold of the CG, such a WTRU determines the number of excess CG opportunities and / or the payload size of the PDUs associated with the PDU set that can be transmitted on the remaining CG opportunities based on the PDU set delay budget and configuration information. In the example, such a WTRU may trigger an SR and / or BSR to request DG resources for sending additional PDUs (e.g., PDUs that may not fit within the CG resources). For example, such a WTRU may transmit an explicit or implicit indication of the payload size and / or the remaining delay associated with the additional PDUs. In the example, such a WTRU may transmit to the network an indication of the number of excess CG opportunities that can be skipped (e.g., if the excess opportunities still exceed the expected delay for transmitting the PDUs associated with the PDU set). Such a WTRU may monitor the DCI to receive DG resource allocations. Such a WTRU may use CG resources and DG resources to send PDUs associated with the PDU set.

[0277] Figure 2 Illustrated is how a WTRU may determine a resource grant type (eg, DG, CG, or CG+DG) for sending one or more PDU sets in the UL within a PDU set level latency based on information including PDU set characteristics.

[0278] The WTRU may be configured to update the resource grant type for sending a set of PDUs in the UL.

[0279] In an example, a WTRU may be configured with a resource grant type (e.g., DG, CG, or CG+DG) for transmitting one or more PDU sets in the UL within a PDU set level delay bound (PSDB) based on information about PDU set characteristics (e.g., PDU set payload size, PDU set delay budget), resource configuration information, and a configured payload size threshold. The WTRU may use PDU set traffic information received from the application layer / higher layers to decide whether to use a default CG configuration, trigger a request for a DG allocation, and / or use a different CG configuration. Examples of resource grant types used by the WTRU to determine the type of resource grant to use during UL transmission of a PDU set may include the following.

[0280] The WTRU may receive configuration information from the gNB, including any of the following. The configuration information may include a default CG resource configuration (e.g., parameters of the default CG resource configuration may include a default number of PUSCH slots per opportunity, a default periodicity value, and a default number of opportunities). The configuration information may include a (e.g., second) CG configuration having a higher number of PUSCH opportunities per slot than the default CG. The configuration information may include a (e.g., third) CG configuration having a lower number of PUSCH slots per opportunity than the default CG.

[0281] The WTRU may receive a first subset consisting of one or more PDUs of a PDU set from an application layer / higher layer having traffic pattern information of the PDU / PDU set. The WTRU may determine the expected latency for transmitting the PDUs in the PDU set based on the configuration information received from the gNB regarding the CG resource configuration and the PDU set payload size.

[0282] The WTRU can determine the resource authorization type (e.g., default CG or CG+DG) for sending a PDU set based on the PDU set information received from the application layer / higher layers, the configuration information about CG resource configuration received from the network, and the minimum / maximum payload size thresholds.

[0283] If the total PDU aggregate payload size is greater than the maximum PDU aggregate payload size threshold of the CG, or if the expected PDU aggregate latency is greater than the PDU aggregate delay budget, the WTRU may trigger an SR and / or BSR to request DG resources for sending additional PDUs (e.g., PDUs that may not fit within the CG resources). The WTRU may communicate (e.g., explicitly or implicitly indicate) on the payload size and / or the remaining latency associated with the additional PDUs that cannot fit within the CG resources.

[0284] The WTRU may update a counter of the number of times the WTRU has used additional resources to (e.g., for) the default CG. If the additional DG request counter is greater than or equal to the maximum counter limit, the WTRU may indicate to the gNB that due to a continued surge in traffic, it is time to switch to a second CG configuration with more resources (e.g., than originally allocated). The WTRU may convey the indication via UCI piggybacked on the UL data or UCI on PUCCH, MAC CE, or RRC signaling.

[0285] If the total PDU set payload size is less than the maximum PDU set payload size threshold of the CG, and if the expected PDU set delay is less than or equal to the PDU set delay budget, the WTRU can determine the number of excess CG opportunities and / or the payload size of the PDUs in the PDU set that can be transmitted on the remaining CG opportunities based on the PDU set delay budget and configuration information.

[0286] When using the default CG, the WTRU may update a counter of the number of times it releases the CG. If the release CG occasion counter is greater than or equal to the maximum counter limit, the WTRU may indicate to the gNB to switch to a third CG configuration with fewer resources due to continued reduction in traffic. The WTRU may transmit the indication via UCI piggybacked on the UL data or UCI on PUCCH, MACCE, or RRC signaling.

[0287] The WTRU may reset the attach DG request counter and the release CG opportunity counter to zero within a period of time (e.g., based on a multiple of the CG opportunity) so that the counters may represent the most recent status of the amount of UL traffic.

[0288] In an example, a WTRU may determine adjustments to CG resources based on variable PDU characteristics associated within a PDU set. In such an example, the WTRU may determine one or more adjustments to the CG configuration based on PDU set information (e.g., PDU payload size), resource configuration information, and / or a configured payload size threshold for using the CG configuration during UL transmission. In an example, the parameters associated with the adjustable CG configuration may be similar to a default CG configuration, where the allocated periodic and semi-persistent radio resources may be available to such a WTRU for a specific duration. In an example, for example, in the case of an adjustable CG configuration, the PUSCH resources allocated in a time period may be adjusted by increasing or decreasing the number and / or number of resources (e.g., PUSCH slots, PRBs, MSC indexes, etc.) to match the variable PDUs and / or PDU sets sent by such a WTRU. Such a WTRU may determine to use the default CG configuration or request that more (or fewer) PUSCH slots be allocated to some CG opportunities based on PDU set traffic information (e.g., PDU set traffic information received from an application layer and / or higher layers). Examples are provided for determining adjustments to a CG configuration to be used during UL transmission of one or more PDU sets.

[0289] The WTRU may receive configuration information from a network (e.g., a gNB, etc.), the configuration information including one or more adjustable CG resource configurations (e.g., parameters of the adjustable CG resource configuration may include a default number of PUSCH time slots per opportunity, a default periodicity value, and a default number of CG opportunities) and a minimum and / or maximum threshold indicating a PDU set payload size per CG opportunity that can be sent using the default CG resources.

[0290] Such a WTRU may receive, from an application layer and / or higher layers, a first PDU subset including one or more PDUs associated with a PDU set (and in some examples, traffic pattern information associated with the PDU set). In an example, such a first subset may include PDU set information (e.g., in one or more PDU headers) associated with the PDU set (e.g., total PDU set payload size, total number of PDUs in the PDU set, PDU set delay budget, etc.).

[0291] Such a WTRU can use resources to send a PDU subset set in the next CG opportunity.

[0292] Such a WTRU can determine the CG resources that can be applied to send the second PDU based on, for example, configuration information and / or traffic pattern information.

[0293] In an example where the total payload size of the second PDU subset exceeds the maximum PDU payload size per CG occasion threshold, such a WTRU may determine the number of additional PUSCH slots per CG occasion available for sending the second PDU subset. Such a determination may be made, for example, by such a WTRU based on, for example, a difference between the total payload size of the second PDU subset and the maximum PDU payload size per occasion threshold.

[0294] For one or more subsequent CG occasions, such a WTRU may send a request indication to the network to increase the number of PUSCH slots, in some examples by a determined additional number of PUSCH slots. For example, such a request may be sent in a UCI (e.g., SR), a PUSCH (e.g., including a piggybacked UCI), an UL MAC CE (e.g., a BSR), an RRC signaling / message, or other suitable channel. In an example, such a request may be sent multiplexed with the first PDU subset using a CG occasion. In an example, such a request may be sent as a separate indication before or after sending the first PDU subset. In an example, such a WTRU may indicate whether the requested resource change (e.g., increase) is temporary (e.g., for the next CG occasion) or semi-permanent (e.g., for one or more CG occasions).

[0295] Such a WTRU may monitor for an indication of receiving a response to such a request (in some examples, within a time window).

[0296] Such a WTRU may receive a response indicating an increase in allocated PUSCH slots and / or resources for subsequent one or more CG occasions. For example, such an indication may be received in a DCI (e.g., PDCCH, flag), a PDSCH (e.g., including piggybacked DCI), HARQ feedback (e.g., previous transmission of a PDU for a PDU set), a WUS, a DL MAC CE, or an RRC signaling / message.

[0297] Such a WTRU may send a second PDU subset using the received allocation of adjustable CG resources (e.g., an increased PUSCH time slot) in the next CG opportunity after receiving the second PDU subset from the application layer and / or higher layers.

[0298] In an example where the total payload size of the second PDU subset is lower than the minimum PDU payload size per CG opportunity threshold, such a WTRU may determine a number of excess PUSCH time slots per CG opportunity that may not be used to send the second PDU subset based on, for example, the difference between the payload size of the second PDU subset and the minimum PDU payload size per CG opportunity threshold.

[0299] For one or more subsequent CG occasions, such a WTRU may send a request to reduce and / or skip the number of PUSCH slots (in some examples, to reduce and / or skip a determined excess number of PUSCH slots). For example, such a request may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), a UL MAC CE (e.g., BSR), an RRC signaling / message. In an example, such a request may be sent multiplexed with the first PDU subset using a CG occasion. In an example, such a request may be sent as a separate indication before or after sending the first PDU subset. In an example, such a WTRU may indicate whether the requested resource change (e.g., reduction / skipping) is temporary (e.g., for the next CG occasion) or semi-permanent (e.g., for one or more CG occasions).

[0300] Such a WTRU may receive an indication to reduce and / or skip some PUSCH resources for one or more subsequent CG occasions. For example, such an indication may be received in a DCI (e.g., PDCCH, flag), a PDSCH (e.g., including piggybacked DCI), a HARQ feedback (e.g., a previous transmission of a PDU for a PDU set), a WUS, a DL MAC CE, or an RRC signaling / message.

[0301] Such a WTRU can send a second PDU subset using available CG resources in the next CG opportunity after receiving the second PDU subset from the application layer and / or higher layers.

[0302] refer to Figure 3 , Figure 3 Illustrated is how an example WTRU (here a UE) may determine changes to an adjustable CG configuration (e.g., reducing and / or skipping or increasing CG resources at different times) based on variable PDU characteristics (e.g., variable PDU set payload size) in a PDU set during UL transmission. In some examples, the default CGH configuration may not allow such changes to CG resources.

[0303] In an example, a WTRU may determine to skip one or more of the assigned CG resources based on a variable PDU characteristic associated with a PDU set, resource configuration information, and a configured jitter threshold. If the expected arrival of a subset of incoming PDUs exceeds a configured jitter threshold (e.g., the jitter is greater than the length of multiple CG opportunities), such a WTRU may use PDU set traffic information received from an application layer and / or higher layers to decide whether to skip one or more of the assigned CG opportunities. An example is provided for determining to skip one or more assigned CG opportunities.

[0304] The WTRU may receive configuration information from the network (e.g., gNB) including one or more default CG resource configurations (e.g., parameters of an adjustable CG resource configuration may include an initial / default number of PUSCH slots per opportunity, an initial periodicity value, and an initial / default number of CG opportunities), a jitter threshold (e.g., a duration used to determine whether a PDU associated with a PDU set can be sent using a CG opportunity or can be skipped). Such a jitter threshold may be indicated, for example, based on the number of PUSCH slots and / or CG opportunities.

[0305] Such a WTRU may receive a first PDU subset associated with a PDU set (and in some examples, traffic pattern information for the PDU set) from an application layer and / or higher layers. For example, the first PDU subset may include information (e.g., in a PDU header) about an expected arrival time of a second PDU subset associated with the PDU set.

[0306] Such a WTRU can use resources to send the first PDU subset in the next CG opportunity.

[0307] Such a WTRU may determine the jitter associated with the second PDU subset (e.g., based on the number of PUSCH time slots and / or CG timing) based on, for example, traffic pattern information (e.g., expected arrival time of the PDU) and / or configuration information.

[0308] For example, in the event that the determined jitter associated with the second PDU subset set exceeds a jitter threshold, such a WTRU may send a request to the network to reduce and / or skip some PUSCH time slots or CG opportunities. In the example, such CG opportunities may correspond to the determined jitter for sending the second PDU subset. For example, such a request may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), an UL MAC CE (e.g., BSR), an RRC signaling / message. Such a request may be sent multiplexed with the first PDU subset using a CG opportunity, or may be sent as a separate request before or after sending the first PDU subset set. In the example, the WTRU may indicate whether the requested resource change (e.g., reduction and / or skipping) is temporary (e.g., for the next CG opportunity) or semi-permanent (e.g., for one or more CG opportunities).

[0309] In an example, such a WTRU may send a second PDU subset using available CG resources in the next CG opportunity after receiving the second PDU subset from the application layer and / or higher layers.

[0310] The WTRU may be configured to indicate unused (eg, skipped) UL CG opportunities based on traffic characteristics.

[0311] The WTRU may determine to skip one or more of the assigned CG resources based on information about PDU set characteristics (e.g., PDU payload size, PDU set delay budget) and resource configuration information. The CG resources that the WTRU may skip or not use may include at least one of the following: PUSCH opportunities, time slots, PRBs per PUSCH opportunity, and / or CG cycles / periods. If the WTRU is not expected to use one or more CH resources (e.g., PUSCH opportunities) to transmit UL data, the WTRU may use PDU set traffic information received from the application layer / higher layers to decide whether to skip one or more allocated CG resources. Example techniques applied by the WTRU to determine to skip CG opportunities may include the following.

[0312] The WTRU may receive configuration information from the gNB, including one or more of the following.

[0313] The configuration information may include one or more default or initial CG resource configurations. Parameters associated with the CG resource configurations that may be configured in the WTRU may be adjusted and may include at least one of the following: starting slot / symbol offset, number of PUSCH opportunities per slot, number of symbols per PUSCH opportunity, number of PUSCH opportunities per CG cycle / period, number of slots per CG cycle / period, number of CG cycles / periods per CG configuration, and CG periodicity value. The configuration information may include CG skip configuration information (e.g., resource difference thresholds associated with early and / or late skipping).

[0314] The configuration information may include a configuration associated with an early skip method that may be used by the WTRU by indicating to the gNB that unused CG resources (e.g., one or more PUSCH opportunities) are skipped during early opportunities / time slots associated with the CG cycle / period. For example, the WTRU may transmit an indication of unused CG resources associated with one or more PUSCH opportunities starting from the first PUSCH opportunity in a time slot. The indication may indicate unused PUSCH opportunities (e.g., from the second opportunity to the last opportunity). The indication may be transmitted by the WTRU on a per-time slot basis or on a per-group of time slot basis. The indication may be used to assist the gNB in ​​reallocating skipped or unused CG resources (e.g., PUSCH opportunities or PRBs) to other WTRUs.

[0315] The WTRU may send an availability indication to the gNB (e.g., a network node), and the availability indication may indicate the number of available PUSCH opportunities in the CG period. Available PUSCH opportunities may be available to be skipped (e.g., skipped PUSCH opportunities). Available PUSCH opportunities and skipped PUSCH opportunities may be used interchangeably as described herein.

[0316] The configuration information may include a configuration associated with a late skip method that may be used by the WTRU to indicate to the gNB to skip CG resources (e.g., one or more PUSCH opportunities) during a later opportunity / time slot associated with the CG cycle / period. For example, the WTRU may transmit an indication of unused CG resources associated with one or more PUSCH opportunities starting from the nth PUSCH opportunity in a time slot. The indication may indicate unused PUSCH opportunities from the n+1 opportunity to the last opportunity. The indication may be transmitted by the WTRU on a per-time slot basis or on a per-group of time slot basis. After determining that a PDU of a PDU set or subset is to be sent, the late skip indication may be transmitted together with the latest PDU of the PDU set or subset.

[0317] The WTRU may receive from the application layer / higher layer a first subset consisting of one or more PDUs of a PDU set and traffic information of the PDU / PDU set. In an example, the first subset consisting of one or more PDUs of a PDU set may include information about the expected / actual size of the PDU set (e.g., in a PDU header).

[0318] The information associated with the PDU set may include a total payload size of the PDU set and a delay bound. The WTRU may determine an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set based on the total payload size of the PDU and the delay bound.

[0319] The WTRU may use information about the CG configuration obtained from the gNB and the PDU set size information obtained from the application layer to determine the number of CG resources (e.g., PUSCH opportunities, CG slots / cycles / periods) used to transmit the PDU set.

[0320] The WTRU may receive configuration information from a network node indicating a delay threshold and a configuration grant (CG) configuration including a number of PUSCH opportunities in a CG period. The WTRU may receive a first PDU subset of a PDU set and information associated with the PDU set from an application layer (e.g., an application).

[0321] A PDU set may be associated with a CG period. The WTRU may determine an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set. The WTRU may determine a first set of CG PUSCH opportunities associated with a first PDU subset and a second set of CG PUSCH opportunities associated with a second PDU subset based on the payload size of the first PDU subset and the estimated payload size of the second PDU subset.

[0322] Under the condition that the difference between the estimated arrival time of the second PDU subset and the arrival time of the first PDU subset is greater than the delay threshold, the WTRU may determine the available CG PUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset. The WTRU may send information indicating at least the available CG PUSCH opportunities, the first group of CG PUSCH opportunities, and the second group of CG PUSCH opportunities to the network node.

[0323] The WTRU may determine to transmit an indication to skip unused CG resources (eg, PUSCH opportunities, CG slots / cycles / periods) that are not expected to be used (eg, will not be used). In an example, the WTRU may perform one or more of the following.

[0324] The WTRU may assign temporary or semi-persistent status to available CG PUSCH opportunities based on network traffic characteristics, and the temporary status may indicate applicability to the next PUSCH opportunity and the semi-persistent status may indicate applicability to one or more PUSCH opportunities.

[0325] If the number of allocated PUSCH opportunities minus the number of used PUSCH opportunities plus the number of expected retransmissions is greater than the difference threshold for early skipping, the WTRU may send an early CG skip indication to the gNB to skip PUSCH opportunities in one or more time slots. Early CG skipping may be used when the difference between the allocated PUSCH opportunities and the used PUSCH opportunities is large (e.g., above a threshold). The request indication may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), a UL MAC CE (e.g., a BSR), or an RRC signaling / message. The UCI may correspond to a CG-UCI or a new UCI (e.g., a UCI corresponding to a non-CG UCI). For example, the indication may be sent by multiplexing the indication with a first subset of a PDU set using CG resources, or the indication may be sent as a separate indication before / after sending the first subset of a PDU set. In an example, the WTRU may indicate whether the requested skipping of a resource / PUSCH opportunity is temporary (e.g., for the next PUSCH opportunity or CG slot / cycle / period) or semi-permanent (e.g., one or more PUSCH opportunities or CG slots / cycles / periods).

[0326] The WTRU may estimate the available CG resources based on the difference between the number of PUSCH opportunities in the CG period and the sum of the PUSCH opportunities used in the first set of CG PUSCH opportunities and the second set of CG PUSCH opportunities.

[0327] The WTRU may indicate CG skipping in a variety of formats. The WTRU may transmit an offset value to indicate to the gNB that the WTRU may skip PUSCH opportunities in time slots starting after the offset value. The WTRU may transmit a bitmap vector to indicate upcoming PUSCH opportunities or time slots that are skipped and / or used. A value of "1" in the bitmap may indicate a PUSCH opportunity or time slot that may not be used. The WTRU may transmit the number of PUSCH opportunities to be skipped. For example, the gNB may determine which opportunities to skip based on SRs from (e.g., other) WTRUs in the network. The WTRU may monitor the PDCCH after retransmission to receive a skip confirmation indication from the gNB. For example, the WTRU's receipt of an indication (e.g., in the PDCCH) may confirm the number of PUSCH opportunities that may be skipped. The WTRU may indicate n unused PUSCH opportunities (e.g., n=1) in an indication transmitted to the gNB (e.g., in a CG-UCI or a new UCI). The indication may be sent in the first PUSCH opportunity along with the data. In an example, the WTRU may indicate k unused PUSCH opportunities from the last PUSCH opportunity in a timeslot or CG cycle / period (e.g., in an indication transmitted to the gNB).

[0328] The WTRU may send the information in the WTRU indication multiplexed with the first subset of the PDU set or sent separately from the first subset of the PDU set.

[0329] The WTRU may use a bitmap vector or an offset value to encode information indicating available CG PUSCH opportunities. The bitmap vector may indicate the status of an upcoming PUSCH opportunity or timeslot, and the offset value may indicate a delay for the WTRU to skip a PUSCH opportunity.

[0330] If the number of allocated PUSCH opportunities minus the number of used PUSCH opportunities plus the number of expected retransmissions is greater than the difference threshold for late skipping, the WTRU may use PUSCH opportunities to transmit PDUs from a PDU set or subset until it receives an ACK for the last PDU to be sent during the allocated CG opportunity set.

[0331] The WTRU may send a late CG skip indication to the gNB to skip PUSCH opportunities in one or more slots. The request indication may be sent in UCI (e.g., SR), PUSCH (e.g., including piggybacked UCI), UL MAC CE (e.g., BSR), RRC signaling / message. For example, the indication may be sent by multiplexing the indication with the first subset of the PDU set using the CG resources, or may be sent as a separate indication before / after sending the first subset of the PDU set. The WTRU may indicate whether the requested skipping of the resource / PUSCH opportunity is temporary (e.g., for the next PUSCH opportunity or CG slot / cycle / period) or semi-persistent (e.g., for one or more PUSCH opportunities or CG slots / cycles / periods).

[0332] The WTRU may indicate the skipping of unused PUSCH opportunities in a (e.g., multiple) format. The WTRU may use a similar format for indicating an earlier skip. Depending on the CG configuration, the WTRU may transmit a flag to indicate that the upcoming one or more PUSCH opportunities or CG timeslots are skipped from the nth PUSCH opportunity in the timeslot onwards or from the nth PUSCH opportunity until the next PUSCH opportunity or CG timeslot set. The WTRU may indicate n unused PUSCH opportunities in an indication transmitted to the gNB (e.g., in the CG-UCI or new UCI). The indication may be sent with the data in the mth PUSCH opportunity (e.g., m=n-1) or the last PUSCH opportunity in the timeslot or CG period / cycle.

[0333] The WTRU may receive an availability confirmation from the network node. The availability confirmation may indicate the approved number of PUSCH opportunities available within the CG period.

[0334] The WTRU may decide to skip slots in the current or subsequent CG cycles / periods. The WTRU may determine that it does not (e.g., needs to) use (e.g., all) the allocated resources (e.g., slots) in a given CG slot / cycle / period. The WTRU may indicate to the gNB to partially skip (e.g., some) resources (e.g., PUSCH opportunities or PRBs) of one or more CG slots / cycles / periods by notifying the gNB of the number of resources (e.g., PUSCH opportunities) to be skipped and how many CG slots / cycles / periods to skip.

[0335] The WTRU may be configured to indicate unused UL CG opportunities based on HARQ feedback. The WTRU may determine whether to skip one or more of the assigned CG resources (e.g., PUSCH opportunities) based on the HARQ feedback. If the WTRU receives multiple NACKs in a previous CG slot / period / cycle, the WTRU may not indicate unused CG resources or PUSCH opportunities and / or may not indicate that the WTRU will not (e.g., needs to) use additional CG resources. These resources may be used for retransmissions. If the WTRU has a low number of NACKs in a previous transmission, it may indicate potentially unused CG resources or PUSCH opportunities to the gNB. Example techniques applied by the WTRU for determining to skip CG opportunities based on HARQ feedback may include the following.

[0336] The WTRU may receive configuration information from the gNB, including one or more default CG resource configurations (e.g., parameters of the adjustable CG resource configuration may include an initial / default number of PUSCH opportunities per time slot, an initial periodicity value, and an initial / default number of CG opportunities). The configuration may include CG skip configuration information (e.g., a maximum threshold number of NACKs for triggering CG skipping). The WTRU may update a NACK counter for a NACK it receives for a non-acknowledged PDU (or after an ACK timeout). The WTRU may determine to transmit an indication to skip CG resources (e.g., PUSCH opportunities) that are not expected to be used.

[0337] In an example, the WTRU may perform one or more of the following. If the number of allocated PUSCH opportunities is greater than the number of used PUSCH opportunities and the NACK counter is less than the maximum NACK number threshold, the WTRU may send a CG skip indication to the gNB to indicate unused PUSCH opportunities. The request indication may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), an UL MAC CE (e.g., a BSR), an RRC signaling / message. For example, the indication may be sent by multiplexing the indication with the first subset of the PDU set using CG resources, or the indication may be sent as a separate indication before / after sending the first subset of the PDU set. The WTRU may indicate whether the requested skipping of the resource / PUSCH opportunity is temporary (e.g., for the next PUSCH opportunity or CG slot / cycle / period) or semi-permanent (e.g., one or more PUSCH opportunities or CG slots / cycles / periods).

[0338] The WTRU may indicate a CG skip in multiple formats. First, the WTRU may transmit an offset value to indicate to the gNB that the WTRU may skip PUSCH opportunities starting after the offset value. Second, the WTRU may transmit a bitmap vector to indicate the skipped and used upcoming PUSCH opportunities. The WTRU may transmit the number of PUSCH opportunities to be skipped. For example, the gNB may determine which opportunities to skip based on an SR from a WTRU in the network (e.g., another) WTRU. In the latter case, the WTRU may need to monitor the PDCCH after the retransmission to receive a skip confirmation indication from the gNB. For example, the WTRU's receipt of an indication (e.g., in the PDCCH) may confirm the number of PUSCH opportunities that may be skipped.

[0339] The WTRU may be configured to receive HARQ feedback for XR data sent using CG resources. In an example, the WTRU may determine whether / when to monitor a DL indication (e.g., in the PDCCH) indicating HARQ feedback based on the HARQ configuration used when sending XR data in one or more PUSCH opportunities per time slot / period utilizing the CG. For example, when CG resources are configured for sending XR data in the UL, the WTRU may be configured to receive HARQ feedback. When HARQ is configured, the WTRU may assume that HARQ feedback (ACK / NACK) is received in a time instance after the XR data is sent using the CG resources. When XR data (e.g., a PDU set) is sent using one or more PUSCH opportunities in a CG configuration, HARQ feedback may be received in a time instance (e.g., opportunity, time slot, cycle / period) associated with one or more of the following.

[0340] An example may be associated with a timing or time slot after a PUSCH timing. For example, HARQ feedback associated with data transmitted in a PUSCH timing may be received in a kth DL timing or time slot (e.g., k=1) occurring after a PUSCH timing. For example, when data is sent in the first PUSCH timing in a time slot, associated HARQ feedback may be received in an nth DL timing (e.g., n=1, 2, 3, 4) after a UL PUSCH timing.

[0341] An instance may be associated with a time slot or time period after a PUSCH opportunity. For example, HARQ feedback associated with data transmitted in n PUSCH opportunities may be received in the first time slot or time slot occurring after n PUSCH opportunities (e.g., in DL). For example, when data is sent in a time slot including 4 PUSCH opportunities, the associated HARQ feedback may be received in the nth DL time slot (e.g., n=1, 2, 3, 4) after the UL time slot. An instance may be associated with a time slot or time period / cycle after n time slots. For example, HARQ feedback associated with data transmitted in n time slots (e.g., n=1) may be received in the kth DL time slot (e.g., k=1) occurring after n time slots. For example, when data is sent in n time slots over one or more time periods / cycles, where the time slots may include one or more PUSCH opportunities, and where the time period / cycle may include one or more time slots, associated HARQ feedback may be received in the nth DL time slot (e.g., n=1, 2, 3, 4) after the n UL time slots.

[0342] The WTRU may receive HARQ feedback based on the transmission of a transport block (TB), where such transmission may be associated with one or more HARQ processes (e.g., with a HARQ process ID). In an example, when XR data is transmitted in one or more TBs, where the TBs may be transmitted in one or more PUSCH opportunities or time slots, the WTRU may initiate one or more HARQ processes. The WTRU may select a HARQ process ID, for example, from a configured ID pool or a HARQ process ID preconfigured by the network, and indicate the selected HARQ process ID in control information associated with the PUSCH carrying the TB (e.g., in the PUCCH). For example, when receiving HARQ feedback, the WTRU may receive an indication of the HARQ process (ID) to which the feedback may relate. If the WTRU transmits one or more TBs using n PUSCH opportunities, where the PUSCH opportunities may be associated with one or n HARQ processes, the WTRU may receive feedback for the HARQ process (e.g., TB).

[0343] For example, the WTRU may receive HARQ feedback associated with XR data / TB sent in one or more PUSCH opportunities in any of the following: PDCCH in DCI, PDSCH, MAC CE, or RRC signaling. Such HARQ feedback may be received based on one or more of the following: per TB, per PUSCH basis, per UL time slot, per TB set, per PUSCH set, and UL time slot set. For example, such HARQ feedback may be received in a bitmap, where, for example, the bits in the bitmap may correspond to ACK / NACK feedback for TBs sent in PUSCH opportunities. For example, a bitmap with an 8-bit length may correspond to 8 PUSCHs carrying one or more TBs. Bit "1" may indicate ACK, and bit "0" may indicate NACK for a TB sent in an associated PUSCH opportunity. The HARQ feedback report may be received implicitly in the PDCCH. When the WTRU receives a PDCCH in a DL opportunity / timeslot associated with a PUSCH / HARQ process, where the PDCCH may contain a UL DG grant, the WTRU may assume a NACK indication for the associated TB. The UL grant may be used to resend the TB. For example, when the WTRU does not receive a PDCCH in the expected opportunity / timeslot, the WTRU may assume an ACK indication for the associated TB.

[0344] In an example, a WTRU may determine whether to use a CG configuration with higher reliability (e.g., low MCS, high number of PRBs per slot and / or opportunity, etc.) based on the status of previous PDU set transmissions. If the expected arrival of a subset of incoming PDUs exceeds a configured jitter threshold (e.g., the jitter is greater than the length of multiple CG opportunities), such a WTRU may use PDU set traffic information received from an application layer and / or higher layers to decide whether to skip one or more of the assigned CG opportunities. An example is provided for determining an adjustment to a CG configuration to be used during UL transmission of one or more PDU sets. In an example, using more reliable resources to send one or more PDUs in a PDU set (such as when link conditions are not conducive to using a default CG resource configuration (e.g., high MCS, low number of PRBs per slot / opportunity)) can improve resource usage efficiency and can achieve a delay bound associated with the PDU set. For example, such a WTRU may use PDU set traffic information received from an application layer and / or higher layers to decide whether to maintain use of the default CG configuration or trigger a request to use a CG configuration with higher reliability. An example is provided for determining whether to use a CG configuration with higher reliability.

[0345] The WTRU may receive configuration information including a first CG configuration (e.g., default CG configuration parameters may include one or more high MCS values / indexes (e.g., aggressive MCS) and a low number of PRBs per time slot / opportunity). For example, such first CG configuration parameters may be intended to improve resource usage efficiency during transmission.

[0346] Such configuration information may include second CG configuration information (e.g., high reliability CG configuration parameters may include one or more high MCS values / indexes and a high number of PRBs per time slot and / or opportunity). For example, such second CG configuration parameters may be intended to trade off resource usage efficiency to improve reliability during transmission.

[0347] Such configuration information may include a remaining latency threshold (e.g., corresponding to a latency value for sending the remaining PDUs associated with the PDU set). For example, the threshold may be used to determine whether to switch between using a first CG configuration and a second CG configuration.

[0348] Such configuration information may include a maximum retransmission threshold per PDU (e.g., for determining a maximum retransmission of PDUs associated with a set of PDUs used to switch between using a first CG configuration and a second CG configuration).

[0349] Such a WTRU may receive one or more PDUs associated with a PDU set (including, in some examples, a PDU set delay budget (e.g., in a header of one or more PDUs associated with the PDU set) from an application layer and / or higher layers.

[0350] Such a WTRU may use a first CG configuration to send in the UL at least some of the PDUs associated with a PDU set.

[0351] Such a WTRU may receive feedback (e.g., HARQ ACK / NACK feedback) indicating the status of the UL transmission of a PDU associated with a PDU set. For example, the feedback indication may be received at a granularity of per PDU, per PDU subset associated with a PDU set, and / or per PDU set.

[0352] Such a WTRU may continue to use the first CG configuration to retransmit one or more PDUs (e.g., when a NACK feedback indication is received), up to a maximum retransmission threshold.

[0353] In an example where the number of received NACKs exceeds a maximum retransmission threshold, such a WTRU may determine a remaining delay for transmitting one or more remaining PDUs associated with the PDU set based on the PDU set delay budget and the time incurred by transmission and / or retransmission of previously transmitted PDUs associated with the PDU set. In an example, such a WTRU may switch to using a second CG configuration based on a change in the importance of the PDUs (e.g., after receiving multiple NACKs, the importance of the remaining PDUs may increase and allow switching to a higher reliability CG configuration).

[0354] In an example where the determined remaining latency is lower than the remaining latency threshold, such a WTRU may select a second CG configuration for sending the remaining PDUs associated with the PDU set in the UL.

[0355] In an example, such a WTRU may transmit an indication of switching to a second CG configuration. For example, such an indication may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), a UL MAC CE (e.g., a BSR), or an RRC signaling / message.

[0356] In an example, such a WTRU may, possibly upon receiving an acknowledgment indication (e.g., from a gNB) (e.g., in a DCI, MAC CE), send the remaining PDUs associated with the PDU set using a second CG configuration.

[0357] In an example where an ACK feedback indication is received when or before the maximum retransmission threshold is reached, such a WTRU may continue to use the first CG configuration to send one or more remaining PDUs associated with the PDU set.

[0358] In an example, the WTRU may determine to use SR resources associated with different LCHs based on a change in the priority of the PDUs associated with the PDU set. In an example, when sending PDUs associated with the PDU set in the UL, a change in the priority of some PDUs (e.g., due to an approaching deadline) may cause the WTRU to select SR resources from one or more LCHs, which may be different from the LCHs mapped to the already transmitted PDUs associated with the PDU set. For example, SR resources of different LCHs may be accessed and / or triggered for sending a request for resource authorization (e.g., DG resources) for transmitting the remaining PDUs through the PDU set delay boundary. In an example, the LCP restrictions associated with one or more LCHs may be relaxed for a duration, for example, the LCP restrictions apply to high priority LCHs. For example, during the relaxed LCP restrictions, the WTRU may use low-latency SR resources associated with low-latency LCHs of other traffic (e.g., URLLC) to meet the deadline and / or delay boundary of the PDU set associated with the XR traffic. An example of determining to use SR resources associated with different LCHs according to a change in priority of a PDU is provided.

[0359] The WTRU may receive configuration information including a first LCH configuration (e.g., a default LCH configuration associated with XR traffic intended to support high throughput and / or medium latency), a second LCH configuration (e.g., a low latency LCH configuration associated with low latency traffic intended to support low throughput and / or ultra-low latency), one or more SR resources and / or configurations associated with the first LCH configuration and the second LCH configuration, and a remaining latency threshold (e.g., corresponding to a latency value for sending a PDU associated with a PDU set). In an example, the threshold may be used to determine whether to switch between using the first LCH configuration and the second LCH configuration to access the SR resources.

[0360] Such a WTRU may receive, from an application layer and / or higher layers, a first PDU subset comprising one or more PDUs associated with a PDU set (and in some examples also including traffic pattern information of the PDU set).

[0361] For example, a first PDU subset may include information about a second PDU subset (e.g., in a PDU header), where the second PDU subset includes one or more PDUs associated with a PDU set (such information includes, for example, the total PDU set payload size, the total number of PDUs in the PDU set, the PDU set delay budget, etc.).

[0362] In an example, a first PDU subset may be mapped to a first LCH configuration.

[0363] Such a WTRU may trigger an SR associated with the first LCH configuration. For example, such a WTRU may explicitly or implicitly indicate traffic information associated with a PDU set (e.g., PDU set delay budget, remaining delay for transmitting remaining PDUs in the PDU set, PDU set size, number of PDUs) in the SR and / or in the BSR after triggering the SR. For example, such an indication may be sent in UCI (e.g., SR), PUSCH (e.g., including piggybacked UCI), UL MAC CE (e.g., BSR, new BSR), RRC signaling / message.

[0364] Such a WTRU may use DG resource allocation to send the first PDU subset after triggering the SR / BSR.

[0365] Such a WTRU may receive, from an application layer and / or higher layers, a second PDU subset including one or more PDUs associated with a PDU set (and in some examples also including traffic pattern information for subsequent PDUs / PDU sets).

[0366] Such a WTRU may determine the remaining delay for sending the second PDU subset based on the PDU set delay budget and the time incurred by the transmission and / or retransmission of the first PDU subset.

[0367] In an example where the determined remaining latency is below the remaining latency threshold, the WTRU may trigger an SR associated with the second LCH configuration. For example, such a WTRU may explicitly or implicitly indicate the selection of SR resources in the second LCH and / or the reason for the selection (e.g., due to reaching the configured remaining latency threshold). In an example, such a WTRU may explicitly and / or implicitly indicate traffic information associated with the second PDU subset in the SR and / or in the BSR after triggering the SR (e.g., PDU set delay budget, remaining latency for transmitting the remaining PDUs, amount of PDU set size of the remaining PDUs, number of remaining PDUs). For example, such an indication may be sent in a UCI (e.g., SR), a PUSCH (e.g., including piggybacked UCI), an UL MAC CE (e.g., BSR, new BSR), an RRC signaling / message. Such a WTRU may send the second PDU subset using the received DG resource allocation (e.g., received from the gNB) (e.g., in the DCI).

[0368] In the example where the determined remaining latency exceeds the remaining latency threshold, the WTRU may trigger an SR associated with the first LCH configuration.Such a WTRU may send a second PDU subset using the received DG resource allocation.

[0369] The WTRU may be configured to support dynamic adaptation of SPS / CG parameters.

[0370] In an example, for DL ​​reception of periodic XR traffic (e.g., PDU sets / PDU set groups), the WTRU may be configured with an initial / default number of PDSCHs per SPS opportunity / timeslot. The initial number of PDSCHs may be determined by the WTRU and / or the network based on the XR traffic pattern (e.g., such as periodicity, the expected number of PDUs per PDU set, and the PDU set QoS (e.g., PSDB), etc.). For example, when a trigger condition as described herein is detected. The WTRU may transmit to the base station in a dynamic indication (e.g., in RRC signaling, MAC CE, or UCI) (e.g., requesting a change in the number of PDSCHs per SPS opportunity / timeslot (e.g., increase or decrease the number x)). For example, the WTRU may receive a dynamic indication (e.g., in RRC signaling, MAC CE, or DCI) from the base station indicating a change in the number of PDSCHs per SPS opportunity / timeslot (e.g., increase or decrease the number x). In an example, the WTRU may be configured (e.g., initially configured) with a high number of PDSCHs per SPS opportunity / timeslot. The WTRU may then receive an indication from the base station (eg, in a MAC CE, DCI, or non-scheduled DCI) indicating, for example, to skip one or more of the PDSCHs when receiving DL data.

[0371] In an example involving periodic UL transmissions, the WTRU may be configured with an initial / default number of PUSCHs (e.g., per CG opportunity / timeslot) for supporting periodic XR traffic in the UL. The TB size or number of TBs carrying the PDU / PDU set may be greater or less than the initial number of PUSCHs, and the WTRU may transmit an indication to the base station (e.g., in an RRC, MAC CE, UCI, or in the first PUSCH) and request a change in the number of PUSCHs per CG opportunity / timeslot. For example, the WTRU may transmit an indication to increase a specific number of PUSCHs when one or more of the following is true: the number of PUSCHs is insufficient or the PDU / PDU set may not be delayed until the next CG opportunity. For example, a PDU set may be sent using less than the initial number of PUSCHs, and the WTRU may transmit an indication to the base station (e.g., MAC CE, UCI) to skip one or more (e.g., some) of the PUSCHs. The WTRU may receive an indication from the base station indicating an increase / decrease in the number of PUSCHs per CG opportunity / timeslot.

[0372] In an example, the WTRU may be configured with one or more start time offset values ​​associated with an SPS and / or CG opportunity / time slot. For example, the start time offset value may be used to time shift (e.g., advance / delay multiple time slots) relative to the SPS and / or CG opportunity. For example, based on the arrival time of one or more PDUs / PDU sets detected / measured by the WTRU, the WTRU may transmit an indication to the base station (e.g., in an RRC, MAC CE, or UCI) indicating a change in the start time offset of any one of the CG or SPS opportunities. For example, the WTRU may receive an indication from the base station (e.g., in an RRC, MAC CE, DCI) indicating a change in the start time offset of any one of the CG or SPS opportunities (e.g., a time shift). In order to minimize overhead, the WTRU may use an indication to indicate to the base station to change the start time offsets of multiple CG and / or SPS opportunities / time slots. For example, the indication may indicate the number of CG and / or SPS opportunities to be time shifted and the value of the time shift. Similarly, the WTRU may receive an indication (e.g., a single indication) from a base station indicating a time shift to multiple CG and / or SPS opportunities / slots.

[0373] The WTRU may be configured to support and / or trigger dynamic activation / deactivation of multiple CG configurations. In an example, the WTRU may be configured with multiple active CG configurations corresponding to (e.g., different) traffic patterns of the streams supported by the WTRU. For example, when performing UL transmission of data associated with a stream with a small payload size (e.g., a first stream) and a stream with a larger payload size (e.g., a second stream), the WTRU may be configured to use at least two CG configurations, wherein the CG configurations may be configured with a low / high number of PUSCHs per opportunity / timeslot. In an example, the WTRU may be configured to use multiple active CG configurations, wherein the CG configurations may consist of (e.g., different) sets of parameters (e.g., different numbers of PUSCHs per CG opportunity / timeslot, different start time offsets per CG opportunity / timeslot). The WTRU may transmit an indication to the base station (e.g., in an RRC, MAC CE, or UCI) to request / indicate the dynamic activation / deactivation of one or more CG configurations (e.g., based on the arrival time and / or payload size of one or more PDUs / PDU sets in the UL).

[0374] In one example, a WTRU may be configured with multiple CG configurations (e.g., a first CG configuration and a second CG configuration) with different parameters (e.g., periodicity, number of PUSCHs per opportunity) for sending different types of PDU sets (e.g., I frames or P / B frames) in the UL. Data may be sent in the UL (e.g., a PDU set carrying I frame data) using an initial / first CG configuration with an initial / default number of CG opportunities, and a higher layer (e.g., a higher layer) in the WTRU may determine a traffic pattern of UL data in a next set of one or more CG opportunities (e.g., based on a GOP structure and a frame rate). Such information about traffic patterns may be used by the WTRU to identify (e.g., other / second) one or more CG configurations (e.g., with different periodicity or different number of 0PUSCHs per opportunity) that may match a traffic pattern of (e.g., the next) UL data (e.g., the next PDU set). The WTRU may transmit an indication (e.g., in an RRC, MAC CE, UCI) to a base station about an identified CG configuration (e.g., an ID of a CG configuration) that may be used to send the next UL data. The WTRU may receive an indication from a base station (e.g., in an RRC, MAC CE, or DCI) to (e.g., dynamically) activate / deactivate a CG configuration that the WTRU may use when performing UL transmissions.

[0375] The WTRU may be configured to support (e.g., dynamic) grants with multiple PUSCH allocations. In an example, the WTRU may be configured to receive dynamic resource grant allocations for (e.g., multiple) PUSCHs with (e.g., different) configurations (e.g., different MCSs and / or different numbers of PRBs per PUSCH) in one or more indications from a base station. For example, the indication may be received by the WTRU in RRC signaling, MAC CE, DCI, non-scheduled DCI, or in a PDSCH. The indication may indicate a (e.g., different) number of PUSCHs per allocation, a resource grant allocation pattern for repeated allocations (e.g., dynamic resource grant allocations over multiple time slots), and a duration for the resource grant allocation pattern.

[0376] The WTRU may transmit information about traffic patterns in the UL (e.g., for receiving an indication of dynamic resource grant allocation for multiple PUSCHs with different configurations / allocations). For example, such information may be transmitted by the WTRU in one or more of the RRC, MAC CE (e.g., new or enhanced BSR), UCI, or PUSCH. Such information about the traffic pattern transmitted by the WTRU may include any of the following: number of PDUs of a PDU set, payload size of a PDU set, number of PDU sets in a PDU set group (e.g., dependencies), expected arrival time of PDUs in one or more PDU sets, delay bounds / PSDB for one or more PDU sets, timing information (e.g., remaining time) for sending one or more PDUs / PDU sets, etc. For example, the WTRU may receive an indication from a base station (e.g., in an RRC, MAC CE, DCI) indicating one or more parameters, the one or more parameters including a (e.g., recurring dynamic) resource grant allocation pattern that may be aligned with time instances / time slots when a PDU / PDU set may be expected to arrive at the WTRU and be ready for UL transmission.

[0377] Techniques as described herein may support power savings when processing PDU sets. In an example, the WTRU may transmit to the network assistance / status information associated with processing XR traffic and PDU sets to enable adaptive scheduling with power savings. In an example, the WTRU may transmit to the network information associated with power savings in support of QoS requirements that comply with XR applications (e.g., to enable the network to be aware of XR applications in order to support more power savings for the UE). Information associated with application awareness and / or QoS may be transmitted by the WTRU to the network as one or more of the following message types: preferred configuration information (e.g., preferred CG configuration mode in UL); status information / indication (e.g., battery charge status); measurement / status reports (e.g., channel / link measurement results, buffer occupancy measurements); or request / response messages).

[0378] The WTRU may be configured to receive configuration / assistance information / indications from the network to support adaptive scheduling with power saving. The power saving related information that may be received by the WTRU from the network may include one or more of the following: CG configuration information (e.g., default CG and power saving CG mode configuration information), including one or more of periodicity, start offset, duration, BWP, parameter set / SCS value, number of PRBs per slot, number of opportunities / periods / cycles, number of PUSCH slots per opportunity, maximum number / duration / length of PUSCH, antenna ports, or transmit power; counter threshold (e.g., a threshold for the number of NACKs that enable the use of a power saving CG configuration); timer (e.g., a timer that starts counting NACKs before checking eligibility for switching to a power saving CG configuration); or threshold (e.g., a WTRU battery charge threshold associated with a measurement of energy stored in the WTRU battery, below which the WTRU may be triggered to take actions for power saving).

[0379] The WTRU may determine whether to use a CG configuration with low power based on the state of PDU set transmission and the WTRU power state. In an example, the WTRU may determine whether to use a CG resource configuration with low power (e.g., low number of PRBs per time slot / opportunity, low transmission power) to transmit a subset of one or more PDUs of a PDU set based on the transmission state of a previous subset of the PDU set (e.g., remaining delay, PDU set delay budget, number of NACK feedback received) and / or the WTRU power state (e.g., WTRU battery power). In this case, the WTRU may determine to use a power-saving CG configuration to improve energy efficiency while achieving a delay bound associated with the PDU set. For example, the WTRU may use PDU set traffic information received from the application layer / higher layers to decide whether to keep using the default CG configuration or trigger a request to use a CG configuration with lower power consumption.

[0380] In an example, the WTRU may monitor the performance of the UL transmission by counting the number of NACKs or monitoring the channel quality. The number of NACKs may be below a certain threshold and there may be an opportunity to meet the XR specific QoS requirements while using a low power CG configuration. Checking the eligibility for the low power CG configuration may be triggered by the WTRU battery charge status. The WTRU may determine whether a low power CG configuration may be used to meet the QoS requirements of the XR application (e.g., a PDU set delay budget) by determining the expected latency for the transmission of a PDU (or a set of PDUs). If the PDU (or a set of PDUs) can be transmitted within the PDU delay budget, the WTRU may request / select a low power CG configuration (e.g., a low number of PRBs or a low transmit power).

[0381] Examples of appropriate CG resource configurations applied by the WTRU to determine transmission of PDUs for a PDU set may include one or more of the following. The WTRU may receive configuration information (e.g., from a gNB) including: a first CG configuration (e.g., default CG configuration parameters may consist of a high number of PRBs and a high transmit power per time slot / opportunity, such configuration parameters may be intended for increased capacity), for example, a second CG configuration (e.g., low power CG configuration parameters may consist of a low number of PRBs and a low transmit power per time slot / opportunity, such configuration parameters may be intended for power saving), for example, or a number of NACK thresholds per PDU (e.g., used to determine a maximum number of retransmissions of PDUs in a PDU set for enabling a request to switch to a second CG configuration).

[0382] The WTRU may receive one or more PDUs (eg, of a PDU set) from an application layer / higher layer (eg, together with an indication of a delay budget for the PDU set (eg, in a header of one or more PDUs of the PDU set)).

[0383] The WTRU may use the first CG configuration to transmit in the UL. For example, the WTRU may use the first CG configuration to transmit at least some PDUs of the PDU set using the UL.

[0384] The WTRU may receive feedback indications (e.g., HARQ ACK / NACK feedback from a gNB) indicating the status of UL transmission of PDUs of a PDU set (e.g., the feedback indications may be received at a granularity of per PDU, per PDU subset in a PDU set, and / or per PDU set).

[0385] The WTRU may continue to send one or more PDUs using the first CG configuration (e.g., when a NACK feedback indication is received) until a timer expires (e.g., a duration elapses or passes) to check the number of NACKs received against a NACK number threshold (e.g., or the WTRU is in a low battery state). As used herein, a timer may be a duration, an amount of time that may elapse, etc.

[0386] If the number of received NACKs is less than the NACK number threshold, the WTRU may determine the remaining delay for sending one or more remaining PDUs of the PDU set based on the PDU set delay budget and the time caused by the transmission and / or retransmission of PDUs previously sent by the PDU set. In an example, the WTRU may select / switch to use the second CG configuration based on the opportunity to save power while meeting the QoS requirements of the XR application.

[0387] If the determined remaining delay is less than the PDU set delay budget. For example, the WTRU may select a second CG configuration for sending the remaining PDUs of the PDU set in the UL. The WTRU may transmit an indication (e.g., to the gNB) to indicate the selection / switching to the second CG configuration. For example, such an indication may be sent in one or more of UCI (e.g., SR), PUSCH (e.g., including piggybacked UCI), UL MAC CE (e.g., BSR), RRC signaling / message. The WTRU may use the second CG configuration to send the remaining PDUs in the PDU set, possibly after receiving a confirmation indication (e.g., from the gNB in ​​DCI, MAC CE). The WTRU may continue to use the first CG configuration to send one or more remaining PDUs in the PDU set.

[0388] The WTRU may be configured to support dynamic adaptation of connected mode discontinuous reception (CDRX) parameters. In an example, the WTRU may be configured to (e.g., dynamically) adjust the CDRX cycle length, the active / on duration in one or more CDRX cycles (including the current and next cycles). For example, the adjustment of the active / on time may be accomplished by the WTRU by increasing / decreasing the on duration, using multiple / additional / fewer on durations, or increasing / decreasing the inactivity timer for receiving PDUs in one or more PDU sets. For example, traffic arriving on the DL may have a high number of PDUs and a strict PSDB, and the length of the current on duration applied at the WTRU may be extended or an additional on duration may be triggered for receiving PDUs in a PDU set. A PDU set may have a low number of PDUs, which may be delivered using a shorter on / active time, and the current on duration at the WTRU may be shortened / reduced (e.g., possibly shortened / reduced by a preconfigured value).

[0389] In an example, a WTRU may be configured with one or more sets of CDRX cycle length values ​​including (e.g., different) CDRX cycles. For example, a first set may consist of 16ms, 16ms, and 17ms; a second set may consist of 16ms, 17ms, and 17ms; and a third set may consist of 8ms, 9ms, and 9ms. In an example, when configuring a CDRX configuration, the WTRU may be configured with different on-duration length values, different start offsets for fixed on-duration values, and / or inactive timer values. For example, when a mismatch between a traffic pattern and a configured CDRX parameter is detected, the WTRU may receive a dynamic indication (e.g., in a MAC CE or DCI) during the current active / on time. For example, when a dynamic indication is received from a base station, the WTRU may apply the indicated changes to the CDRX parameters (e.g., a new set of CDRX cycle lengths may be used, a new on-duration may be used, and / or multiple / additional on-durations may be activated). For example, a (e.g., single) indication (e.g., single MAC CE or DCI) may be used to adapt the length of the active / on-duration or trigger additional on-durations for multiple CDRX cycles, possibly to reduce signaling overhead. For example, when receiving a dynamic indication, the WTRU may adjust CDRX according to the indicated parameters for receiving a set of PDUs on one or more cycles.

[0390] In an example, the WTRU may adjust or assist in adjusting the start offset time of the CDRX activity / on duration to account for jitter in the DL / UL and / or to align with the XR traffic pattern (e.g., arrival of PDUs / PDU sets). In an example, the presence of jitter may cause the arrival of PDUs within a PDU set (e.g., intra-PDU set jitter) and across different PDU sets (e.g., inter-PDU set jitter) to be delayed / advanced when arriving at the WTRU in the UL and / or arriving at the base station in the DL. For example, for intra-PDU set jitter, the PDU set boundaries corresponding to the arrival times of the first and last PDUs in the PDU set may vary, rather than arriving periodically in bursts that are aligned with the frame generation periodicity. For example, for inter-PDU set jitter, the arrival times of different PDU sets may differ from each other, rather than following the frame generation periodicity.

[0391] In an example, the adjustment of the start offset time of the CDRX active time may include advancing or delaying the corresponding offset time slot. For the transmission of UL data, the WTRU may determine the adjustment of the start offset time (e.g., the number of time slots to be advanced or delayed) based on the arrival time of one or more PDUs or PDU sets. For example, the WTRU may transmit an indication to the base station (e.g., in RRC signaling, MAC CE, UCI, or PUSCH) on the adjustment value so that the base station can perceive the change in the active duration from the transmission DL signal / channel (e.g., PDCCH and / or PDSCH). For example, the adjustment indication transmitted by the WTRU may include any of the ID of the CDRX configuration, the number of time slots to be advanced / delayed, the index / ID of the start offset adjustment value (e.g., preconfigured in the UE), the number of CDRX opportunities to which the adjustment of the start offset can be applied, when the start cycle of the adjustment can be applied (e.g., the current CDRX cycle or the next CDRX cycle), etc. For example, the WTRU may receive an indication from the base station (e.g., in RRC, MAC CE, DCI, or PDSCH) indicating confirmation / rejection of the adjustment of the start offset. For example, for DL ​​transmissions, the WTRU may receive an indication from the base station indicating an adjustment of the start offset time to the CDRX Active / On Duration. Similar to the UL case, the indication received by the WTRU may indicate any of the following: an ID of the CDRX configuration, a number of slots to advance / delay, an index / ID of the start offset adjustment value (e.g., preconfigured in the UE), a number of CDRX opportunities to which the adjustment to the start offset may be applied, a start cycle when the adjustment may be applied (e.g., current CDRX cycle or next CDRX cycle), etc. For example, a dynamic indication received by the WTRU (e.g., in a DCI) during the Active / On Duration in the current CDRX cycle may indicate a preconfigured start offset value to be applied to the next CDRX cycle.

[0392] The WTRU may be configured with multiple CRDX configurations, and an indication (e.g., a single indication) may be transmitted by the WTRU (e.g., a single UL MAC CE or a single UCI) or received by the WTRU (e.g., a single UL MAC CE or a single DCI) to indicate the adjustment of the start offset times of the multiple CDRX configurations, which may minimize overhead. For example, the indication may contain an ID / index of one or more CDRX configurations (e.g., different CDRX configurations) or an ID / index of a CDRX configuration group consisting of one or more CDRX configurations.

[0393] In an example (e.g., which may correspond to a split rendering application (e.g., VR, AR)), the WTRU may send pose and / or video traffic in the UL and, in response, may receive pre-rendered video traffic in the DL. To assist in providing an adequate user experience, DL data may be received within a maximum RTT latency after the UL data is sent. The WTRU may be a source and destination for UL and DL traffic, and higher layers in the WTRU may determine the expected traffic pattern in the DL (e.g., payload size of a set of DL PDUs, arrival time of DL traffic), for example based on the traffic sent in the UL and knowledge of the RTT latency. When it is identified that the configured CDRX parameters (e.g., active / on duration, start offset) may not be suitable for handling the expected traffic pattern in the DL, the WTRU may transmit an indication to the base station (e.g., in RRC signaling, MAC CE, UCI) to request specific adaptation of the CDRX parameters configured at the UE. For example, the WTRU may transmit a request / indication (e.g., in RRC signaling, MAC CE, or UCI) for extending the active / on duration or adjusting the start offset time of the active / on duration in the next CDRX cycle (e.g., by advancing / delaying a number of slots) for receiving DL traffic within the RTT delay. For example, the WTRU may receive an indication (e.g., in RRC, MAC CE, DCI, or PDSCH) from the base station indicating confirmation / rejection of the adjustment of the CDRX parameters (e.g., active / on duration, start offset).

[0394] The WTRU may be configured to support and / or trigger dynamic activation / deactivation of multiple CDRX configurations / parameters. In an example, the WTRU may be configured to support a set of one or more active CDRX configurations that may be used simultaneously for receiving DL traffic and / or for sending UL traffic. For example, a CDRX configuration may be associated with one or more traffic flows supported by the WTRU during DL reception and / or UL transmission. For example, when processing flows with small payload sizes and flows with large payload sizes, dedicated CDRX configurations with short / long on-durations per cycle may be used instead of a single CDRX configuration with high periodicity and / or long on-duration to support multiple flows.

[0395] In an example, the WTRU may transmit a request (e.g., in RRC signaling, MAC CE, or UCI) to a base station to (e.g., dynamically) activate / deactivate one or more CDRX configurations based on the detection of one or more triggering events / conditions (described in another section of the present disclosure). For example, the WTRU may transmit an indication to trigger or assist in the dynamic activation / deactivation of multiple CDRX configurations at one time for matching UL and / or DL ​​traffic patterns of different flows and reducing overhead. The WTRU may receive an indication (e.g., in RRC signaling, MAC CE, or DCI) indicating the activation / deactivation of one or more CDRX configurations from a base station. The indication or bitmap received by the WTRU from the base station may include, for example, an ID / index of a CDRX configuration that may be activated / deactivated. The WTRU may be configured with a CDRX configuration group including one or more CDRX configurations and a CDRX configuration group ID / index. For example, the indication received by the WTRU may include a CDRX configuration group ID.

[0396] In an example, the WTRU may activate a first CDRX configuration and may transmit a request to activate a second CDRX configuration, a third CDRX configuration, and a fourth CDRX configuration, and deactivate the first CDRX configuration when (e.g., some) triggering conditions are detected. For example, the WTRU may receive an indication from a base station indicating activation of the second CDRX configuration and the third CDRX configuration and deactivation of the first CDRX configuration.

[0397] In an example, a WTRU may be configured with one or more CDRX configurations having different parameters (e.g., periodicity, on-duration, start offset) associated with processing different types of PDU sets (e.g., I-frames or P / B-frames). When receiving DL data with a first CDRX configuration (e.g., a PDU set carrying I-frame data), the WTRU may determine a traffic pattern of DL data in the next cycle (e.g., based on a GOP structure and a frame rate). The WTRU may then identify one or more CDRX configurations that may match the traffic pattern of DL data in the next cycle based on the determined traffic pattern. The WTRU may transmit an indication (e.g., in RRC signaling, MAC CE, or UCI) to a base station on the identified CDRX configuration (e.g., an ID / index of a CDRX configuration or an ID / index of a CDRX configuration group), which may be used to receive DL data in the next cycle. The WTRU may receive an indication from a base station for dynamically activating / deactivating one or more CDRX configurations (e.g., IDs) or CDRX configuration groups (e.g., group IDs) in the WTRU for receiving DL traffic.

[0398] In an example, the WTRU may be configured with a multi-level CDRX configuration, which may consist of one or more parameter sets (e.g., cycle duration, periodicity, on / active duration, start offset) that may be used to receive / send XR traffic (e.g., PDU set, PDU set group). For example, the WTRU may be configured with a first-level CDRX including a first-level parameter set (e.g., a first cycle duration, a first on duration, and a first periodicity) and a second-level CDRX including a second-level parameter set (e.g., a first cycle duration, a first on duration, and a first periodicity). For example, a multi-level CDRX may be configured, and a second-level CDRX and / or a second-level parameter set may be applied within the on / active duration of the first-level CDRX. In an example, when a multi-level CDRX configuration is used, the WTRU may receive one or more DL signals (e.g., PDCCH, PDSCH) and / or perform UL transmissions (e.g., PUCCH, PUSCH) in a time slot of the on / active duration associated with the second-level CDRX (e.g., which may be configured to be active / aligned within the on / active duration of the first-level CDRX). In an example, the WTRU may receive DL signals (e.g., PDCCH, PDSCH) and / or perform UL transmissions (e.g., PUCCH, PUSCH) in a time slot of the on / active duration associated with the second level CDRX (e.g., which may be configured to be outside the on / active duration of the first level CDRX, possibly overlapping with one or more time slots of the sleep duration associated with the first level CDRX).

[0399] In an example, the WTRU may be configured with a first level CDRX configuration and a second level CDRX configuration and / or a first level parameter set and a second level parameter set (e.g., in RRC signaling). For example, when receiving the configuration information, the first level CDRX and / or the first level parameter set may be activated by default. For example, when one or more trigger conditions are detected (e.g., jitter is detected when the set of transmitted PDUs is above / below a threshold), the WTRU may transmit a request / indication to activate the second level CDRX and / or the second level parameter set (ID / index) to the base station (e.g., in RRC signaling, MAC CE, or UCI). For example, the WTRU may receive an indication from the base station indicating activation / deactivation of the second level CDRX and / or the second level parameter set (e.g., in RRC signaling, MAC CE, or DCI). For example, the WTRU may receive an activation / deactivation indication from the base station indicating activation / deactivation of the second level CDRX and / or the second level parameter set (e.g., possibly due to jitter detected in the DL).

[0400] The WTRU may be configured to support dynamic adaptation of PDCCH monitoring. In an example, the WTRU may be configured to support dynamic adaptation of PDCCH monitoring behavior when handling variable XR traffic patterns and jitter. For example, when the last PDU of a PDU set or PDU set group (e.g., a data burst) is received, the WTRU may receive an indication from the base station (e.g., in a MAC CE, DCI) indicating a PDCCH skip duration until the next PDU set / PDU set group arrives. When handling a traffic pattern with a low number of PDUs / PDU sets or a low duration for DL ​​reception, an example of this situation may be applied, where the WTRU may be transitioned to sleep mode for a long (e.g., longer) duration until the next PDU set / PDU set group arrives. In an example, the WTRU may be configured with one or more PDCCH monitoring skip durations (e.g., IDs / indexes), which may be aligned with XR traffic pattern parameters (e.g., periodicity, frames per second, number of streams, jitter range). For example, when receiving DL traffic, the WTRU may (eg, dynamically) receive one or more indications indicating a PDCCH monitoring skip duration (eg, ID / index) to apply.

[0401] A WTRU initiated PDCCH monitoring behavior adaptation may be provided. The WTRU may transmit an indication (e.g., in RRC signaling, MAC CE, UCI) to a base station indicating a PDCCH monitoring skip duration that the WTRU may intend to use to receive one or more DL transmissions. The indication may contain one or more PDCCH monitoring skip durations (e.g., IDs / indexes), and multiple cycles of the skip durations may be applied. For example, such parameters associated with the PDCCH monitoring skip duration (e.g., skip duration value, ID / index) may be preconfigured in the WTRU.

[0402] For example, the WTRU may determine a PDCCH monitoring skip duration to indicate to the base station based on RTT latency and knowledge of the association between UL and DL traffic available at the WTRU from higher layers. Jitter in the network may affect the arrival of DL traffic, and the WTRU may take into account the jitter range when determining the PDCCH monitoring skip duration (e.g., possibly based on a jitter range configured in the WTRU (e.g., a standard deviation relative to the periodic timing at which traffic may be expected to arrive)). In an example, the WTRU may take into account jitter by initiating PDCCH monitoring in a sparse search space set group (SSSG) (e.g., possibly before transmitting a PDCCH monitoring skip duration indication to the base station), and switching to a dense SSSG at the end of the PDCCH monitoring skip duration.

[0403] In an example, in the case where the WTRU can support HARQ retransmissions in the UL after receiving an indication from the base station to skip PDCCH monitoring, the WTRU may begin skipping PCDDH monitoring from the next timeslot onward. This may result in a reduction in the PDCCH monitoring skip duration and / or a shorter time available for the WTRU to operate in sleep / low power operation. For example, in order to minimize the possibility of receiving retransmissions and / or extend the sleep duration at the WTRU, the WTRU may be configured to receive the last PDU of a PDU set / PDU set group with one or more robust MCS (e.g., QPSK, 16-QAM) schemes before receiving an indication for PDCCH monitoring skipping. When it is determined from the PDCCH / DCI that the transport block (TB) carrying the last PDU of the PDU set / PDU set group can be sent using a (e.g., robust) MCS and / or when a PDCCH monitoring skip indication is received, the WTRU may be configured to enter sleep mode directly. Alternatively, the WTRU may be configured to receive a PDCCH monitoring skip indication in an indication different from the DCI, so that the WTRU may not monitor the PDCCH associated with the retransmission and may enter sleep mode shortly after receiving the last PDU of a PDU set / burst. For example, the WTRU may be configured to receive an indication for PDCCH monitoring skip in the PDSCH (e.g., together with the data or last PDU), MAC CE, or non-scheduled DCI.

[0404] In an example, the WTRU may be configured to support dynamic adaptation of PDCCH monitoring behavior when handling variable XR traffic patterns and jitter. For example, the WTRU may receive an indication from a base station when the last PDU of a PDU set or a PDU set group (e.g., a data burst) is received.

[0405] The WTRU may be configured to switch between using single and multiple CDRX configurations.

[0406] In an example, the WTRU may be configured to switch between using one or more active CDRX configurations when receiving DL traffic and / or sending UL traffic based on known or predicted traffic arrival rates, payload sizes, and delay budgets for multiple traffic flows. When processing multiple traffic flows with strict delay budgets, the WTRU may be configured to support multiple CDRX configurations for different traffic flows simultaneously. If one or more traffic flows have relaxed delay requirements, they may have tolerance to wait until the turn-on time of the next CDRX cycle. The WTRU may support a single CDRX configuration by aggregating data from multiple traffic flows.

[0407] In an example, the WTRU may be configured to activate or deactivate two CDRX configurations for two DL traffic flows. The first traffic flow may have a large payload size, a strict delay budget, and a low arrival rate (eg, video with a low frame rate).

[0408] The first traffic flow may be associated with a CDRX configuration having a long CDRX cycle length and a long on time sufficient to receive DL data within a strict delay budget. The second traffic flow may have a small payload size, a high arrival rate, and a strict delay budget. The WTRU may be configured to activate a second CDRX configuration that matches the traffic flow of the second traffic flow, for example, with a short on time and frequent (e.g., more frequent) cycles.

[0409] The second traffic flow may have a small payload size, a high arrival rate, and a relaxed delay budget.The WTRU may receive data of the combined first and second traffic flows during the on-time of the first CDRX cycle.

[0410] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to such scenarios and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to such scenarios and is also applicable to other wireless systems.

[0411] The processes described above 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 (sent via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, built-in hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disk (CD)-ROM disks and / or digital versatile disks (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A wireless transmit receive unit (WTRU), comprising: The processor is configured to: receiving configuration information from a network node, the configuration information indicating a delay threshold and a configuration grant (CG) configuration, the configuration grant (CG) configuration including a number of PUSCH opportunities in a CG period; receiving, from an application, a first subset of a set of protocol data units (PDUs) and information associated with the set of PDUs, wherein the set of PDUs is associated with the CG period; determining an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set; determining a first set of CG PUSCH opportunities associated with the first PDU subset and a second set of CG PUSCH opportunities associated with the second PDU subset based on a payload size of the first PDU subset and the estimated payload size of the second PDU subset; determining, under the condition that a difference between the estimated arrival time of the second PDU subset and the arrival time of the first PDU subset is greater than the delay threshold, available CG PUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset; and Information indicating at least the available CG PUSCH opportunities, the first group of CG PUSCH opportunities, and the second group of CG PUSCH opportunities is sent to a network node.

2. The WTRU of claim 1 , wherein the information associated with the PDU set comprises a total payload size and a delay bound for the PDU set, and wherein the processor is further configured to: The estimated payload size of the second PDU subset of the PDU set and the estimated arrival time of the second PDU subset of the PDU set are determined based on the total payload size of the PDU and the delay bound.

3. A WTRU according to claim 1, wherein the processor is further configured to estimate available CG resources based on the difference between the number of PUSCH opportunities in the CG period and the sum of the PUSCH opportunities used in the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities.

4. The WTRU of claim 1 , wherein the processor is further configured to send information in a WTRU indication multiplexed with the first subset of the PDU set or sent separately from the first subset of the PDU set.

5. The WTRU of claim 1 , wherein the processor is further configured to: The available CG PUSCH opportunities are assigned a temporary or semi-persistent status based on network traffic characteristics, wherein the temporary status indicates applicability to a next PUSCH opportunity, and wherein the semi-persistent status indicates applicability to one or more PUSCH opportunities.

6. The WTRU of claim 1 , wherein the processor is further configured to: The information indicating the available CG PUSCH opportunities is encoded using a bitmap vector or an offset value, wherein the bitmap vector indicates a status of an upcoming PUSCH opportunity or time slot, and wherein the offset value indicates a delay for the WTRU to skip a PUSCH opportunity.

7. The WTRU of claim 1 , wherein the processor is further configured to: An availability confirmation is received from the network node, wherein the availability confirmation indicates an approved number of PUSCH opportunities available within the CG period.

8. The WTRU of claim 1 , wherein the processor is further configured to: An availability indication is sent to the network node, wherein the availability indication indicates the number of available PUSCH opportunities in the CG period.

9. A method for a wireless transmit receive unit (WTRU), wherein the method further comprises: receiving configuration information from a network node, the configuration information indicating a delay threshold and a configuration grant (CG) configuration, the configuration grant (CG) configuration including a number of PUSCH opportunities in a CG period; receiving, from an application, a first subset of a set of protocol data units (PDUs) and information associated with the set of PDUs, wherein the set of PDUs is associated with the CG period; determining an estimated payload size of a second PDU subset of the PDU set and an estimated arrival time of the second PDU subset of the PDU set; determining a first set of CG PUSCH opportunities associated with the first PDU subset and a second set of CG PUSCH opportunities associated with the second PDU subset based on a payload size of the first PDU subset and the estimated payload size of the second PDU subset; determining, under the condition that a difference between the estimated arrival time of the second PDU subset and the arrival time of the first PDU subset is greater than the delay threshold, available CG PUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset; and Information indicating at least the available CG PUSCH opportunities, the first group of CG PUSCH opportunities, and the second group of CG PUSCH opportunities is sent to a network node.

10. The method of claim 9, wherein the information associated with the PDU set comprises a total payload size and a delay bound of the PDU set, and wherein the method further comprises: The estimated payload size of the second PDU subset of the PDU set and the estimated arrival time of the second PDU subset of the PDU set are determined based on the total payload size of the PDU and the delay bound.

11. The method according to claim 9, wherein the method further comprises: Available CG resources are estimated based on the difference between the number of PUSCH opportunities in the CG period and the sum of PUSCH opportunities used in the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities.

12. The method according to claim 9, wherein the method further comprises: Information in the sending WTRU indication is multiplexed with the first subset of the PDU set or sent separately from the first subset of the PDU set.

13. The method according to claim 9, wherein the method further comprises: The available CG PUSCH opportunities are assigned a temporary or semi-persistent status based on network traffic characteristics, wherein the temporary status indicates applicability to a next PUSCH opportunity, and wherein the semi-persistent status indicates applicability to one or more PUSCH opportunities.

14. The method according to claim 9, wherein the method further comprises: The information indicating the available CG PUSCH opportunities is encoded using a bitmap vector or an offset value, wherein the bitmap vector indicates a status of an upcoming PUSCH opportunity or time slot, and wherein the offset value indicates a delay for the WTRU to skip a PUSCH opportunity.

15. The method according to claim 9, wherein the method further comprises: An availability confirmation is received from the network node, wherein the availability confirmation indicates an approved number of PUSCH opportunities available within the CG period.

16. The method according to claim 9, wherein the method further comprises: An availability indication is sent to the network node, wherein the availability indication indicates the number of available PUSCH opportunities in the CG period.

17. A wireless transmit receive unit (WTRU), comprising: The processor is configured to: receiving configuration information indicating a delay threshold and a configuration grant (CG) configuration; determining a first set of CG PUSCH opportunities associated with the first PDU subset and a second set of CG PUSCH opportunities associated with the second PDU subset based on a payload size of the first PDU subset and an estimated payload size of the second PDU subset, wherein the first set of CG PUSCH opportunities and the second set of CG PUSCH opportunities are in a CG period from the CG configuration, wherein the first PDU subset and the second PDU subset include a set of PDUs associated with the CG period; determining, under the condition that a difference between an estimated arrival time of the second PDU subset and an arrival time of the first PDU subset is greater than the delay threshold, available CGPUSCH opportunities between the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities based on the arrival time of the first PDU subset and the estimated arrival time of the second PDU subset; and Information indicating at least the available CG PUSCH opportunities, the first group of CG PUSCH opportunities, and the second group of CG PUSCH opportunities is sent to a network node.

18. The WTRU of claim 17, wherein the information associated with the PDU set includes a total payload size and a delay bound for the PDU set, and wherein the processor is further configured to: The estimated payload size of the second PDU subset of the PDU set and the estimated arrival time of the second PDU subset of the PDU set are determined based on the total payload size of the PDU and the delay bound.

19. A WTRU according to claim 17, wherein the processor is further configured to estimate available CG resources based on the difference between the number of PUSCH opportunities in the CG period and the sum of the PUSCH opportunities used in the first group of CG PUSCH opportunities and the second group of CG PUSCH opportunities.

20. The WTRU of claim 17 wherein the processor is further configured to: An availability confirmation is received from the network node, wherein the availability confirmation indicates an approved number of PUSCH opportunities available within the CG period.

Images