Delay reporting associated with multi-modal traffic

Abstract

Systems, methods, and instrumentalities are described for delay reporting in multi-modal traffic. A wireless transmit / receive unit (WTRU) may receive, from a network node, configuration information indicating a remaining time threshold value. The WTRU may receive, from an application, a first and a second protocol data unit (PDU) set. The WTRU may determine remaining time values for each of the first and the second PDU set and determine whether one or both are less than the threshold. The WTRU may identify a portion of data and a buffer size of the portion. Information related to the portion of data may be included in a delay status report (DSR), along with the buffer size and one or both remaining time values. The WTRU may transmit the information in the DSR.

Description

DELAY REPORTING ASSOCIATED WITH MULTI-MODAL TRAFFICCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 572,485, filed April 1 , 2024, the contents of which is incorporated by reference herein.BACKGROUND

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

[0003] Systems, methods, and instrumentalities are described herein related to delay reporting associated with multi-modal traffic. A wireless transmit / receive unit (WTRU) may be configured to perform one or more of the following. A WTRU may receive, from a network node, configuration information that indicates a remaining time threshold value. The WTRU may receive, from an application, a first protocol data unit (PDU) set and a second PDU set. The WTRU may determine a remaining time value for the first PDU set and a remaining time value for the second PDU set. The WTRU may determine that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than a remaining time threshold value. Based on the determination that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value, the WTRU may determine a portion of data and a buffer size of the portion of data. Information associated with the determined portion of data may be included in a delay status report (DSR) based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set. The WTRU may transmit an indication, in the DSR, that indicates the buffer size of the portion of data and one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set. The indication may indicate a respective buffer size for a respective portion of data and a respective remaining time value associated with the respective portion of data.

[0004] The first PDU set may be associated with a first data flow and the second PDU set is associated with a second data flow. The remaining time value for the first PDU set may be based on an arrival timeassociated with the first PDU set and a discard timer value associated with the first PDU set. The remaining time value for the second PDU set may be based on an arrival time associated with the second PDU set and a discard timer value associated with the second PDU set.

[0005] The buffer size may be based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set being below the remaining time threshold value. The portion of data may include a first portion of data and a second portion of data. The first portion of data may be grouped based on a first remaining time value. The second portion of data may be grouped based on a second remaining time value. The first remaining time value may be the remaining time value for the first PDU set. The second remaining time value may be the remaining time value for the second PDU set.

[0006] The WTRU may include the first PDU set in a first octet and the second PDU set in a second octet. The first octet may be associated with a first remaining time threshold value, and the second octet may be associated with a second remaining time threshold value. The WTRU may include the first octet and the second octet in the DSR.

[0007] Systems, methods, and instrumentalities are described herein related to delay reporting for multimodal traffic. A wireless transmit / receive unit (WTRU) may be configured to report a delay status, such as on a per logical channel (LCH) basis or on a per packet data unit (PDU) set basis. A WTRU may be configured to report more than one remaining time value and associated data volume in a (e.g., one) Delay Status Report (DSR). A WTRU may be configured to report a second DSR (e.g., new DSR) for dependent data, for example, if a synchronization condition is not met between (e.g., two) dependent data units. A WTRU may be configured with one or more conditions for the WTRU to report on a delay. A WTRU may be configured with DSR cancellation conditions.

[0008] Delay information of a data unit (e.g., one data unit) may be reported as a function of another dependent data unit, for example, if / when the synchronization time window between the two dependent data units is exceeded or within a threshold of being exceeded.

[0009] A device (e.g., a WTRU) may perform (e.g., may be configured to perform) one or more of the following. A WTRU may receive configuration information associated with delay status report. The configuration information may indicate a remaining time threshold and / or a remaining synchronization delay threshold. The configuration information may be received from a network (NW) (e.g., from a network entity, such as a base station). The WTRU may receive, e.g., from an application, PDUs of PDU set 1. The WTRU may determine the remaining time of PDU set 1 , for example, based on the arrival time of PDUs of PDU set 1 and the PDU set delay budget (PSDB) of PDU set 1 . The WTRU may determine a remaining synchronization delay of PDU set 2. For example, the WTRU may determine the remaining synchronizationdelay of PDU set 2 based on the arrival time of PDU set 1 and a synchronization requirement / threshold. The synchronization requirement / threshold may be received from the application.

[0010] In some examples, a WTRU may transmit a DSR with information on the remaining time and associated volume of PDU set 1 and PDU set 2, for example, if the remaining time of PDU set 1 is less than the remaining time threshold, if PDU set 2 is received before triggering the DSR, and if the remaining synchronization delay of PDU set 2 is higher than the remaining synchronization delay threshold. In some examples, the data volume of PDU set 1 and PDU set 2 may be reported in different octets in the same DSR.

[0011] In some examples, a WTRU may transmit a first DSR with information on the remaining time and / or associated volume of PDU set 1 and / or the WTRU may transmit a second DSR with information on PDU set 2 (e.g., one or more of: expected remaining time of PDU set 2, expected remaining synchronization delay, expected data volume of PDU set 2), for example, if the remaining time of PDU set1 is less than the remaining time threshold, If PDU set 2 is not received before triggering DSR, and if the remaining sync delay of PDU set 2 is less than the remaining sync delay threshold. The second DSR may be a regular DSR or a DSR that carries delay information for PDU sets that may not have arrived in the WTRU buffer yet. In some examples, the DSR for PDU set 1 (e.g., regular DSR) and the DSR for PDU set2 (e.g., a regular DSR or DSR as described) may be sent in the same medium access control (MAC) control element (CE) or different MAC CEs.

[0012] An example device (e.g., WTRU) may include a processor, where the WTRU may perform (e.g., be configured to perform) one or more of the following.

[0013] A WTRU may receive configuration information associated with delay status report. The configuration information may indicate a remaining time threshold and / or a remaining synchronization delay threshold. The configuration information may be received from a network (NW) (e.g., from a network entity, such as a base station).

[0014] The WTRU may determine that a remaining time associated with PDU set 1 (e.g., a first PDU set) is less than the remaining time threshold. The WTRU may send one or more DSRs based on the remaining time associated with PDU set 1 being less than the remaining time threshold and one or more other conditions. The one or more other conditions may comprise whether PDU set 2 (e.g., a second PDU set which may have some association and / or dependencies with PDU set 1 ) is received before a DSR (e.g., with information on PDU set 1) is triggered (e.g., whereby the triggering condition may be whether the remaining time of PDU set 1 is less than the remaining time threshold for example) and / or whether the remaining synchronization delay associated with PDU set 2 is lower or higher than the remaining synchronization delay threshold.

[0015] In examples, PDU set 2 is received before a DSR is triggered and the remaining synchronization delay associated with the second PDU set is higher than the remaining synchronization delay threshold. In such a case, the WTRU may send a DSR with information about PDU set 1 and PDU set 2. The DSR may indicate a first remaining time associated with PDU set 1 , a first volume associated with PDU set 1 , a second remaining time associated with PDU set 2, and a second volume associated with PDU set 2. The first volume associated with PDU set 1 may be indicated in a first octet of the DSR and the second volume associated with PDU set 2 may be indicated in a second octet of the DSR.

[0016] In examples, PDU set 2 is not received before the DSR is triggered and the remaining synchronization delay associated with PDU set 2 is lower than the remaining synchronization delay threshold. In such a case, the WTRU may send a first DSR and a second DSR. The first DSR may indicate a first remaining time associated with PDU set 1 and a first volume associated with PDU set 1. The first DSR may not indicate information associated with PDU set 2. The WTRU may send a second DSR, wherein the second DSR indicates a second remaining time associated with PDU set 2, and a second volume associated with PDU set 2.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0021] FIG. 2 illustrates an example of determining the remaining sync delay.

[0022] FIG. 3 illustrates an example of a delay status report with more than one delay information reported per LCG.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0045] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and / or Augmented Reality (VR / AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0062] WLAN systems, which may support multiple channels, and channel bandwidths, such as802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

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

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

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

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

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

[0068] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0069] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

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

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

[0075] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and / or may performing testing using over-the-air wireless communications.

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

[0077] Systems, methods, and instrumentalities are described herein related to delay reporting for multimodal traffic. A WTRU may be configured to report a delay status on a higher granularity, such as on a per logical channel (LCH) basis or on a per packet data unit (PDU) set basis. A WTRU may be configured to report more than one remaining time value and associated data volume in a (e.g., one) Delay Status Report (DSR). A WTRU may be configured to report a new DSR for a dependent data, for example, if a synchronization condition is not met between (e.g., two) dependent data units. A WTRU may be configured with one or more conditions for the WTRU to report on a delay. A WTRU may be configured with DSR cancellation conditions.

[0078] The term extended Reality (XR) is an umbrella term for different types of immersive experiences, including Virtual Reality (VR), Augmented Reality (AR), Mixed Reality (MR), and the realities interpolated among them. Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual (e.g., stereoscopic 3D) and audio sensory stimuli of the real world as naturally as possible to an observer or user as they move within the limits defined by the application. Augmented Reality (AR) refers to providing a user with additional information or artificially generated objects / items or content overlaid upon their current environment. Mixed Reality (MR) is an advanced form of AR where some virtual elements may be inserted into the physical scene, e.g., to provide the illusion that the elements are part of the real scene. XR may include all real-and-virtual combined environments and human-machine interactions generated by computer technology and wearables.

[0079] The notion of immersion in the context of XR applications / services refers to a sense of being surrounded by the virtual environment as well as providing a feeling of being physically and spatially located in the virtual environment. The levels of virtuality may range from partial sensory inputs to fully immersive multi-sensory inputs leading to a virtual reality, which may be practically indiscernible from actual reality.

[0080] A WTRU may correspond to any XR device / node, which may come in variety of form factors. A WTRU (e.g., XR WTRU) may include, but is not limited to, the following examples: Head Mounted Displays (HMD), optical see-through glasses and camera see-through HMDs for AR and MR, mobile devices with positional tracking and camera, wearables, haptic gloves, haptic body suit, haptic shoes, etc. There are different types of XR WTRUs based on XR device functions, such as, for example, display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing and power supply, which may be provided by one or more devices, wearables, actuators, controllers, and / or accessories. One or more device / nodes / WTRUs may be grouped into a collaborative XR group for supporting one or more (e.g., any) XR applications / experience / services.

[0081] In XR services and applications, traffic may include data / PDUs, which may be associated with an application data unit (ADU), PDU set, or data burst. In some examples, PDUs belonging to a PDU set may be associated with different segments or components of a video frame or a video slice. A data burst may include one or more PDU sets that may be transmitted / received over a time window. For example, a number of PDUs in an PDU set or data burst transmitted in UL and / or received in DL may be dependent on the type of the media frame (e.g., 3D video frame, audio frame).

[0082] In some XR applications, a WTRU transmits XR traffic that may include one or more PDUs / PDU sets in uplink (UL) (e.g., pose, gesture, video data) and / or receives XR traffic in downlink (DL) (e.g., video, audio, haptics). Traffic may be transmitted and / or received periodically or aperiodically in one or more data flows (e.g., quality of service (QoS) flows). During UL transmissions, XR traffic may arrive from the application layer at the WTRU and / or from different devices / terminals / WTRUs (e.g., via sidelink) at different time instances. XR traffic may be characterized by different attributes, such as variable payload sizes per PDU set, variable number of PDUs per PDU set, variable per-PDU / PDU set level importance, and / or different levels of inter-dependencies between PDUs / PDUs sets. XR traffic (e.g., PDU / PDU sets) received by the WTRU may (e.g., also) experience different delays, jitter, data rate, and / or loss rate. High QoS and high user experience (e.g., quality of experience (QoE)) may be maintained by performing data transmission / reception and other associated functions (e.g., prioritization, multiplexing, scheduling) on timely basis with XR awareness (e.g., awareness of PDU set attributes).

[0083] A WTRU may determine that there are multiple PDUs in the WTRU’s buffer that may be available for transmission. The plurality of PDUs may be related to each other e.g., through an association as a set (e.g., “a PDU set”) and / or through an association between multiple sets of one or more PDUs (e.g., including “PDUs of a same service and / or multi-modality application and / or data traffic”). An association may be a configuration part of the WTRU. An association may be related to a delay requirement of the data to be received (e.g., over the air interface) and / or by the application. An association may be related to a synchronization aspect of the data, for example, from a rendering and / or application experience perspective (e.g., QoE metric).

[0084] A WTRU supporting an XR experience may receive data units (e.g., PDU segment(s), PDUs, PDU sets, data bursts, bitstreams) from higher layers or different devices, such as AR glasses and / or haptics gloves (e.g., via sidelink (SL)). Data units, which may have variable payload sizes, different periodicity, jitter, and / or inter-dependencies, may be further processed and transmitted by the WTRU in the UL.

[0085] There may be multiple Configured Grant (CG) physical uplink shared channel (PUSCH) transmission occasions in a period of a single CG PUSCH configuration. There may be a dynamicindication of unused CG PUSCH occasions based on Uplink Control Information (UCI) by the WTRU. A buffer status report (BSR) may include one or more BSR Tables. Delay reporting may be provided for buffered data in uplink. There may be a discard operation of PDU Sets for DL and UL. Discontinuous reception (DRX) support may be provided for XR frame rates corresponding to non-integer periodicities (e.g., through at least semi-static mechanisms, such as RRC signaling). Signaling may be provided (e.g., by the core network (CN)) for semi-static information per QoS flow for DL traffic (e.g., PDU set QoS parameters). Signaling may be provided (e.g., by the CN) for dynamic information per PDU set (PDU Set information and Identification) and / or for an End of Data Burst indication for DL traffic. A WTRU may provision XR traffic assistance information, e.g., periodicity and / or UL traffic arrival information for UL traffic.

[0086] A WTRU may perform delay reporting by reporting remaining time (e.g., with respect to the PDU set delay budget (PSDB) per logical channel group (LCG)). The remaining time may be based on the discardTimer at the packet data convergence protocol (PDCP).

[0087] A scheduler may be provided with more granular delay information of the traffic in the WTRU buffer. A Delay Status Report (DSR) may be provided. A DSR may report (e.g., per LCG) the shortest remaining time and the data volume associated with the shortest remaining time. There may be more than one PDU set with a small remaining time. A network (NW) and WTRUs may benefit from knowing about the multiple PDU sets with small remaining time, for example, to provide better provisioning of resources. For example, the NW may provide a larger grant to accommodate more than one PDU set if the NW knows that more than one PDU set has a small remaining time. Remaining time may be reported for multi-modal traffic.

[0088] Delay information of a (e.g., one) data unit may be reported as a function of another dependent data unit, for example, e.g., if / when the synchronization time window between the (e.g., two) dependent data units is exceeded or is within a threshold of being exceeded.

[0089] A WTRU may be configured to perform or participate in one or more operations or actions. A WTRU may receive configuration information from the NW (e.g., in a DSR), including (e.g., that indicates): a remaining time threshold (e.g., a remaining time threshold value); and / or a remaining synchronization delay threshold. A WTRU may receive, e.g., from an application, PDUs of PDU set 1 (e.g., as described herein, the WTRU may receive a first PDU set (PDU set 1) and a second PDU set (PDU set 2). A WTRU may determine the remaining time of PDU set 1 , for example, based on the arrival time of PDUs of PDU set 1 and the PSDB (e.g., discard timer as described herein) of PDU set 1 . A WTRU may determine the remaining synchronization delay of PDU set 2, for example, based on the arrival time of PDU set 1 and the synchronization requirement / threshold from the application.

[0090] A WTRU may transmit (e.g., in an indication) a DSR with information on the remaining time and associated volume (e.g., including, as described herein, a portion of data and a buffer size (e.g., the indication may indicate a respective buffer size for a respective portion of data and a respective remaining time value associated with the respective portion of data) of PDU set 1 and PDU set 2, for example, if the remaining time of PDU set 1 is less than the remaining time threshold, if PDU set 2 is received before triggering the DSR, and if the remaining synchronization delay of PDU set 2 is higher than the remaining synchronization delay threshold. In some examples, the data volume of PDU set 1 and PDU set 2 may be reported in different octets (e.g., one or more of octet 2 or octet 4, as described herein) in the same DSR.

[0091] A WTRU may transmit a DSR with information on the remaining time and associated volume of PDU set 1 and / or the WTRU may transmit a DSR with information on PDU set 2 (e.g., expected remaining time of PDU set 2, expected remaining synchronization delay, expected data volume of PDU set 2), for example, if the remaining time of PDU set 1 is less than the remaining time threshold, if PDU set 2 is not received before triggering DSR, and if the remaining sync delay of PDU set 2 is less than the remaining sync delay threshold (e.g., the portion of data (e.g., information associated with the portion of data) may be included in the DSR based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set. In some examples, the DSR may be a regular DSR or a new DSR that carries delay information for PDU sets that may not have arrived in the WTRU buffer yet. In some examples, the DSR for PDU set 1 (e.g., regular DSR) and the DSR for PDU set 2 (e.g., a regular or new DSR) may be sent in the same medium access control (MAC) control element (CE) or different MAC CEs.

[0092] A benefit of reporting delay information of a data unit as a function of another data unit may be network awareness of small remaining times for more than one PDU set and provision of a larger grant to the WTRU to accommodate the more than one delay-critical PDU set. Network awareness of a dependent PDU set having a small remaining time and provisioning a larger grant to the WTRU to accommodate the dependent PDU sets may ensure successful decoding of the dependent PDU sets.

[0093] A PDU Set Delay Budget (PSDB) indicates a time between reception of the first PDU (e.g., at the user plane function (UPF) in DL, at the WTRU in UL) and the (e.g., successful) delivery of the last arrived PDU of a PDU Set (e.g., at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter. PSDB (e.g., when provided) may supersede the packet delay budget (PDB).

[0094] PDU set 1 may refer to a PDU set from one flow (e.g., application data flow, QoS flow, etc.). PDU set 1 may refer to a single PDU set or several PDU sets with similar requirements and / or characteristics (e.g., a group of PDU sets). A “group of PDU sets” may be referred to as “PDU set 1 .”

[0095] Similarly, PDU set 2 may refer to a PDU set different from PDU set 1 . PDU set 2 may refer to a single PDU set or several PDU sets with similar requirements and / or characteristics (e.g., a group of PDU sets). A “group of PDU sets” may be referred to as “PDU set 2.”

[0096] The difference between PDU set 1 and PDU set 2 may include one or more of the following characteristics / requirements: have different QoS requirements (e.g., PDU set 1 may have PSDB1 while PDU set 2 may have PSDB2, PDU set 1 may have PSER1 while PDU set 2 may have PSER2, PDU set 1 may be from a flow with the PDU Set Integral Handling Indication (PSI HI), while PDU set 2 may be from a flow without the PSIHI indicator); and / or belong to and / or be tagged to different QoS flows, different application data flows (e.g., PDU set 1 is associated with a first data flow and PDU set 2 is associated with a second data flow), different data radio bearers (DRBs), different logical channels (LCHs), and / or different logical groups (LCGs).

[0097] In some examples, PDU set 1 and PDU set 2 may refer to two different PDU sets in the same flow. In some examples, PDU set 1 and PDU set 2 may refer to two different PDU sets in two different flows (e.g., QoS flows, application data flows, etc.).

[0098] The term “flow” may refer to, for example, one or more (e.g., any) of the following: QoS flows; application data flows; and / or any stream of data flowing through the protocol stack. “Flows” may correspond to any of the following: QoS flows or data flows, such as a flow of data including one or more PDUs, PDU sets, or data bursts, which may be inter-dependent with one another and / or associated with one or more QoS requirements (e.g., latency, data rate, reliability, RTT latency). Different flows, which may originate from a common application / experience source and / or intended for a common destination device / WTRU or group of associated devices / WTRU, may be referred to associated flows or correlated flows.

[0099] “Protocol stack” may refer, for example, to the layer 2 protocol stack, which may include all or a subset of the following sublayers: service data adaptation protocol (SDAP), packet data convergence protocol (PDCP), radio link control (RLC), MAC, physical layer (PHY), and / or a protocol sublayer (e.g., placed before the MAC sublayer).

[0100] A “network” may include, for example, one or more (e.g., any) of the following: a base station (e.g., gNB, transmit-receive point (TRP), RAN node, access node); a core network function (e.g., access and mobility function (AMF), session management function (SMF), policy control function (PCF), network exposure function (NEF)); and / or an application function (e.g., edge server function, remote server function).

[0101] A “forwarding configuration” may correspond, for example, to one or more (e.g., any) of the following: radio bearers (e.g., data radio bearer (DRB), signaling radio bearers (SRB), transport radiobearer, PDU set bearer); logical channels (LCHs), logical channel groups (LCGs); configuration parameters in the individual layers within the AS protocol stack (e.g., SDAP, PDCP, RLC, MAC, PHY, other new protocol layers); parameters associated with logical channel prioritization (LCP) (e.g., priority, prioritized bitrate (PBR), bucket size duration (BSD)), bandwidth parts (BWPs), carriers, radio links / interfaces (Uu links, sidelinks (SLs)); radio resources (e.g., set of one or more frequency / time / spatial resources, such as symbols, slots, subcarriers, resource elements or beams). For example, radio resources may be associated with configured grants (CGs), dynamic grants (DGs), and / or any other resource grants or grant free resources.

[0102] PDU Set 1 may refer to one or more PDU sets with similar PDU Set level QoS requirements (e.g., same or similar PSDB1, PDU Set Error Rate (PSER1), PSII indication, etc.). Similarly, PDU Set 2 may refer to one or more PDU sets with similar PDU Set level QoS requirements (e.g., same or similar PSDB2, PSER2, PSII indication, etc.). In other words, PDU set 1 may not necessarily refer to a si ngle / singular PDU set. Similarly for PDU set 2, PDU set 3, etc. PDU Set 1 may be a PDU Set type I or a PDU Set type II. Similarly for PDU Set 2, PDU Set 3, PDU Set A, PDU Set B, etc. which may be a PDU Set type I or a PDU Set type II. Type I PDU sets, for example, may not tolerate a (e.g., any) loss / delay of a (e.g., any) PDU within the PDU set, e.g., loss / delay outside of the bounds of the PSDB for a (e.g., any) PDU of the PDU set, which may render the remaining PDUs of the PDU set useless since the application may need (e.g., all) the PDUs of the PDU set to successfully decode the PDU set. Type II PDU sets may tolerate some loss / delay of PDUs within the PDU set.

[0103] A “data unit” may refer, for example, to one or more (e.g., any) of the following: one or more frames (e.g., media / video / audio frame or slice / segment), PDUs, PDU sets, data bursts, group of frames / PDUs / PDU-sets / data bursts, bitstreams. Data units, which may be transmitted or received by the WTRU sequentially (e.g., one after the other) or in parallel (e.g., over different channels / li nks / resources), may or may not be inter-dependent with each other.

[0104] PDU sets and the associated c h aracteristics / properti es / attri b utes may refer, for example, to one or more (e.g., any) of the following.

[0105] A PDU set may comprise of one or more data units (e.g., PDUs) associated with a media unit, or a video frame / slice. Data units within a PDU set or data burst may be inter-dependent with each other at the application layer and / or lower layers (e.g., AS-layers).

[0106] Attri b utes / p roperties of a PDU set may be different from each other in terms of, for example, one or more of the following: the number of PDUs in a PDU set, payload sizes, intra-PDU set correlation, importance / priority of the data units, status of transmission (e.g., percentage of PDUs of one or more dataunits transmitted / received successfully), and / or effective data rate and / or effective reliability associated with transmission.

[0107] In some examples, attributes associated with PDU sets may be visible at one or more lower layers (e.g., at SDAP, PDCP, RLC, MAC, PHY, or other sub-layers / layers). Attribute visibility may support additional actions (e.g., prioritizing, mapping to an LCH, multiplexing into one or more TBs, scheduling) based on, for example, one or more (e.g., any) of the following: markings in the data units; reception of an indication; mapping of the data units from a higher layer to a configuration associated with a lower layer; tracking of the attributes of the PDUs at a (e.g., any) buffer associated with sublayer, radio bearer logical channel, and / or HARQ processes; restrictions associated with the sublayer, radio bearer, logical channel, and / or HARQ process to which the data units of PDU sets may be mapped to.

[0108] Attribute visibility may support additional actions based on markings in the data units. For example, markings may include sequence numbers, IDs, indexes, timestamps, and / or time offset values (e.g., with respect to a reference time) in the header of data units. Markings may be made, for example, by higher layers, a (e.g., any) preceding sub-layer / layer, or another device / WTRU.

[0109] Attribute visibility may support additional actions based on reception of an indication, such as a control PDU (e.g., application / higher / NAS layer indication, PDCP control PDU, RLC control PDU, MAC CE, DCI / UCI). An indication may be received by a WTRU, for example, from a higher / preceding layer, from another device / WTRU (e.g., over SL), and / or from a network.

[0110] Attribute visibility may support additional actions based on mapping of the data units from a higher layer to a configuration associated with a lower layer. For example, a WTRU may have visibility of higher layer attribute(s) at a lower layer when mapping the PDUs to one or more radio bearers, logical channels (LCHs), TBs or HARQ processes that may be configured to provide similar forwarding treatment.

[0111] Attribute visibility may support additional actions based on tracking of the attributes of the PDUs at a (e.g., any) buffer associated with sublayer, radio bearer logical channel, and / or HARQ processes. For example, a WTRU may track the attributes associated with a PDU set based on one or more (e.g., any) of the following: the time elapsed since the reception of a first PDU of a PDU set, the remaining time for the PDUs of a PDU set for meeting PSDB, jitter between the arrival one or more PDUs within / across PDU sets, and / or the percentage / payload size of remaining PDUs of a PDU set expected to be received.

[0112] Attribute visibility may support additional actions based on restrictions associated with the sublayer, radio bearer, logical channel, and / or HARQ process to which the data units of PDU sets may be mapped to. For example, a WTRU may have visibility of the data units and / or determine the corresponding actions (e.g., perform prioritization per LCP, perform mapping to restricted CG configurations, TBs, HPIs),for example, based on the configured restrictions associated with the one or more sublayers, radio bearers, and / or LCHs to which the data units may be mapped to.

[0113] A data burst may refer to the data produced by the application in a short period of time. Data may comprise PDUs from one or more PDU Sets. The attributes, associations, and inter-dependencies (e.g., intra-PDU set and / or inter-PDU set), which may include, for example, the start / end indication of a PDU set / data burst (e.g., via sequence number, start / end indication, timestamp), start / end time, duration, payload size(s), periodicity, and / or importance / priority and QoS (e.g., PSDB), may be visible to the AS- layers (e.g., with associated IDs) and / or may be handled at the AS layers with the awareness of the association during data transmission in UL and reception in DL.

[0114] PDU sets and the associated characteristics / properties / attributes may refer to application / high layer importance / priority. The different PDUs in a PDU set or (e.g., all) PDUs in a PDU set may be associated with different importance / priority values. An importance value may correspond to spatial importance (e.g., spatial position of the video frame whose data is carried by the PDU / PDU set, where PDUs / PDU set carrying field of view (FoV) spatial positions may be associated with higher spatial importance than non-FoV spatial positions) or temporal importance (e.g., time sequence of the video / application frame whose data is carried by the PDU / PDU set, where PDUs / PDU sets carrying base video frames such as l-frame may be associated with higher temporal importance than differential video frames such as P-frame / B-frame). Importance values may be visible to the AS layers during data transmission and reception.

[0115] PDU sets and the associated c h aracteristics / properti es / attri b utes may refer to QoS / data flow. The PDUs / PDU sets of an application may be encoded and delivered by the application to a WTRU (e.g., in UL) or by a network (e.g., in DL) via one or more QoS / data flows. The different QoS flows carrying the PDUs / PDU sets associated with an XR application / experience may be visible to the AS-layers and / or may be handled at the AS layers with the awareness of the association during data transmission and reception.

[0116] The following definitions of traffic characteristics and PDU set-level QoS requirements may be applicable.

[0117] A PDU Set Delay Budget (PSDB) may be a time between reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the (e.g., successful) delivery of the last arrived PDU of a PDU Set (e.g., at the WTRU in DL, at the UPF in UL). PSDB may be an optional parameter. PSDB (e.g., when provided) supersedes the PDB.

[0118] A PDU Set Integrated Handling Indication (PSI HI) may indicate whether (e.g., all) PDUs of the PDU Set may be needed for the usage of a PDU Set by an application layer.

[0119] A PDU Set Error Rate (PSER) may define an upper bound for a rate of non-congestion related PDU Set losses between the RAN and the WTRU.

[0120] Jitter may refer to variation with respect to an expected time instance during which one or more data units may be received or transmitted. For example, for a set of data units that may be expected to be received periodically at different periodic time instances, jitter may refer to the variation with respect to the periodic time instances (e.g., for a data unit that may be received T1 ms in advance or T2 ms later than an expected time instance at T, the jitter range is T2 - T1 ). Jitter may refer to an instantaneous value or a statistical value (e.g., average, variance, standard deviation, maximum / minimum).

[0121] Remaining delay may refer to the time duration remaining for receiving or transmitting one or more PDUs of a PDU set before the PSDB. Remaining delay may (e.g., also) be referred to as the time to live (TTL) associated with a PDU set.

[0122] A PDU set may refer to a PDU set in its integrity and / or the PDUs that make up the PDU set. A PDU set may include one or more PDUs that make up the PDU set. At the application, a PDU set (e.g., (all) PDUs making up the PDU set) may be considered as one frame. One PDU set may include one or more PDUs. Some PDU sets may be of the PDU Set Integrated Handling Indication (PSI HI) type, where, for example, (all) PDUs of the PDU set may be needed at the application by the PSDB and / or PSDD for the application to be able to decode the PDU set. Other PDU sets may not be of the PSIHI type, where, for example, the application may still be able to decode the PDU set if one or more (e.g., some) PDUs of the PDU set are lost and / or delayed beyond the PSDB and / or PDU set delay deadline (PSDD). In some examples, successful reception of, for example, 80% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application. In some examples, successful reception of, for example, 70% of the PDUs of the PDU set may be sufficient for the successful decoding of the PDU set at the application.

[0123] “Time to serve a PDU set,” “remaining time to serve a PDU set,” “time to serve PDUs of a PDU set,” “remaining time to serve PDUs of a PDU set,” and “remaining time” may refer to the time to process and / or do one or more (e.g., some) operations on a PDU set, PDUs of a PDU set, and / or remaining PDUs of a PDU set in the protocol stack. One or more operations may include, for example, routing the PDU set and / or PDUs of the PDU set to a logical channel and / or multiplexing the PDU set and / or PDUs of the PDU set from one or more logical channel(s) into a transport block, discarding of PDUs and / or PDU sets at PDCP, etc. A “remaining time to serve a PDU set” may be determined by the WTRU based on, for example, the elapsed time since the arrival of a reference PDU (e.g., first, nth, last PDU of the PDU set) and PSDD / PSDB.

[0124] PDU set characteristics / attributes / properties may refer to, for example, one or more of the following: PSDB; PSER; PDU set important (PSI); PSI HI type or not; PDU set size; number of PDUs in a PDU set; size of PDU set (e.g., in bytes, kilobytes, bits, etc.); last PDU of a PDU set; end PDU of PDU set; first PDU of PDU set; time (e.g., remaining time) to serve a PDU set (e.g., time to transmit the PDU set before the PSDB is exceeded or is within a threshold of being exceeded, such as if 90% of PSDB is reached; or time to multiplex the PDU set into a transport block before the PSDB is exceeded or is within a threshold of being exceeded, such as if 90% of PSDB is reached); PDB of PDU within PDU set; PER of PDU within PDU set; importance of PDU within PDU set; size of PDU within PDU set; or remaining time to serve PDU within PDU set (e.g., time to transmit the PDU before the PDB is exceeded or is within a threshold of being exceeded, such as if 90% of PDB is reached; or time to multiplex the PDU into a transport block before the PDB is exceeded or is within a threshold of being exceeded, such as if 90% of PDB is reached).

[0125] A “drift” may be said to occur, for example, if / when the time window / duration between the last PDU of one PDU set and last PDU of another PDU set (e.g., dependent PDU set) is larger than what the synchronization (sync) requirement (e.g., from the application) may stipulate. The (e.g., two) PDU sets may be in the same or different flows.

[0126] A “drift size” may be the amount by which the time window between (e.g., two) dependent PDU sets exceeds the maximum (max) sync requirement from the application.

[0127] A “drift duration” may be the time period the drift lasts and / or may be expected to last.

[0128] “Drift” may refer to drift size and / or duration.

[0129] A WTRU may receive information from the network. A WTRU may receive from the NW one or more configuration information and / or parameters. The configuration information and / or parameters may be received (e.g., at least in part) in a broadcast transmission (e.g., MIB, SIB) and / or in dedicated RRC signaling (e.g., in RRCReconfiguration message) during CONNECTED mode and / or in I NACTI VE / I DLE mode (e.g., RRCRelease message, when transitioning from CONNECTED mode to INACTIVE mode). The configuration information and / or parameters may (e.g., alternatively) be received by the WTRU, at least in part, in one or more (e.g., dynamic) signaling indications, which may include, for example, in MAC CE, DCI (e.g., WTRU-specific or group common DCI), and / or PDSCH. A WTRU may receive from the NW one or more of the following configuration information and / or parameters: remaining time threshold, tRT; Remaining sync delay threshold, IRSD; and / or one or more DSR MAC CE formats.

[0130] A WTRU may receive from the NW a remaining time threshold, tRT A WTRU may receive one or more remaining time thresholds corresponding to one or more remaining times. In some examples, the thresholds may correspond to absolute values, e.g., 15ms, 50ms, 100ms. In some examples, thethresholds may be defined relative to the PSDB and / or PSDD, e.g., 50% of PSDB, 75% of PSDB, 90% of PSDD, etc.

[0131] In some examples (e.g., if / when the WTRU determines that the remaining time of a PDU set with respect to the PSDB falls below the remaining time threshold), the WTRU may send a DSR to the NW with information on the remaining time (e.g., one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set) and / or the data volume (e.g., the portion of data and the buffer size of the portion of data) associated with the remaining time. For example, for a remaining time threshold of 15ms, when the remaining time of a PDU set with respect to its PSDB falls below 15ms, the WTRU may send a DSR report to the network with the remaining time of the PDU set (e.g., 14ms) and the size of the data unit (e.g., size of the PDU set whose remaining time triggered the DSR).

[0132] In some examples, a WTRU may send a DSR report for a (e.g., any) PDU set whose remaining time value falls below (e.g., any of) the remaining time thresholds configured by the NW.

[0133] In some examples (e.g., if a WTRU is configured with multiple remaining time thresholds), the WTRU may prioritize sending a DSR for the PDU set that crosses the most stringent of the time thresholds. For example, if the WTRU is configured with remaining time thresholds of 15ms and 50ms and if PDU set A has a remaining time of Ums while PDU set B has a remaining time of 48ms, the WTRU may transmit a DSR to the network carrying information on PDU set A. e.g., remaining time for PDU set A with respect to a time deadline (e.g., PSDB and / or PSDD), buffer size of PDU set A, etc.

[0134] In some examples, a WTRU may receive from the network different remaining time thresholds corresponding, for example, to a different PDU set or type thereof; a different LCH or type thereof; a different LCG or type thereof; a different Radio bearer or type thereof; and / or a different Flow or type thereof.

[0135] A WTRU may receive from the network different remaining time thresholds corresponding to a different PDU set or type thereof. For example, “type thereof’ may correspond to one or more (e.g., any) attributes of a PDU set, e.g., as described herein. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply to PDU sets belonging to one flow and a different remaining time threshold to apply to PDU sets belonging to another flow. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply to PDU sets of PSI level 10 and above and a different remaining time threshold to apply to PDU sets of level 9 and below. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply to PDU sets of PSDB 50ms and above and a different remaining time threshold to apply to PDU sets of PSDB 49ms below.

[0136] A WTRU may receive from the network different remaining time thresholds corresponding to a different LCH or type thereof. For example, the WTRU may receive a (e.g., one) remaining time thresholdto apply for LCHs with a certain Prioritized Bitrate (PBR) and a different remaining time threshold to apply for LCHs with a different Prioritized Bitrate (PBR). For example, the WTRU may receive one remaining time threshold to apply for LCHs with a certain priority and a different remaining time threshold to apply for LCHs with a different priority. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply for LCHs of a certain type and a different remaining time threshold to apply for LCHs of a different type. A type may include control channel versus traffic channel, for example. Type may include the type of control channel, e.g., Broadcast Control Channel (BCCH), Paging Control Channel (PCCH), Common Control Channel (CCCH), and / or Dedicated Control Channel (DCCH). A BCCH may be a channel for broadcasting system control information. A PCCH may be a channel that transfers paging information and system information change notifications. This channel may be used for paging when the network does not know the location cell of the WTRU. A CCCH may be a channel for transmitting control information between WTRUs and network. A CCCH may be used for WTRUs without an RRC connection with the network. A DCCH may be a point-to-point bi-directional channel that transmits dedicated control information between a WTRU and the network. A DCCH may be used by WTRUs with an RRC connection.

[0137] A WTRU may receive from the network different remaining time thresholds corresponding to a different LCG or type thereof. For example, the WTRU may receive one remaining time threshold to apply for an (e.g., one) LCG and a different remaining time threshold to apply for another LCG. The WTRU may apply the same remaining time threshold to multiple (e.g., all) the logical channels forming part of an LCG. In some examples, an LCG may be based on a group of logical channels whose buffer status is being reported at once (e.g., in a BSR and / or DSR). In some examples, the WTRU may be configured with rules on how to group logical channels, e.g., based on the value of the remaining time threshold. For example, the WTRU may group logical channels with a small remaining time threshold into one LCG. The WTRU may (e.g., then) apply the most stringent of the remaining time thresholds for the individual logical channels forming part of the LCG to the LCG.

[0138] A WTRU may receive from the network different remaining time thresholds corresponding to a different radio bearer or type thereof. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply for a (e.g., one) radio bearer and a different remaining time threshold to apply for another radio bearer, e.g., a default radio bearer versus a dedicated radio bearer or a signaling radio bearer versus a data radio bearer, etc.

[0139] A WTRU may receive from the network different remaining time thresholds corresponding to a different Flow or type thereof. For example, the WTRU may receive a (e.g., one) remaining time threshold to apply for a (e.g., one) flow and a different remaining time threshold to apply for another flow.

[0140] A WTRU may receive from the NW a remaining sync delay threshold, tRSD. In some examples, the WTRU may receive one or more remaining sync delay thresholds from the network. In some examples, the purpose of the remaining sync delay threshold may be to ensure that the synchronization requirement between (e.g., two) dependent data units is met. e.g., sync requirements between PDU set 1 and PDU set 2. In some examples, the WTRU may report when the sync delay (e.g., as defined herein) exceeds the remaining sync delay threshold.

[0141] A WTRU may receive from the NW one or more DSR MAC CE formats.

[0142] In some examples, a DSR MAC CE may accommodate reporting, per LCG, of a (e.g., one) remaining time and one data volume.

[0143] In some examples, a DSR MAC CE may accommodate reporting, per LCH, of a (e.g., one) remaining time and a (e.g., one) data volume.

[0144] In some examples, a DSR MAC CE may accommodate reporting, per PDU set, of a (e.g., one) remaining time and a (e.g., one) data volume.

[0145] In some examples, a DSR MAC CE may accommodate reporting, per LCG, of more than a (e.g., one) remaining time and more than a (e.g., one) data volume.

[0146] In some examples, a DSR MAC CE may accommodate reporting, per LCH, of more than a (e.g., one) remaining time and more than a (e.g., one) data volume.

[0147] In some examples, a pre-emptive DSR MAC CE may (e.g., serve to) report the (expected) delay status of a data unit that may not have been received at the WTRU yet, but which the WTRU may expect to receive within a (e.g., short) period of time. For example, a WTRU may know (e.g., based on the periodicity of the traffic) when to expect a data unit, before its arrival in the WTRU buffer. For example, the WTRU may expect PDU set B2 from the application in the WTRU in 15ms based on the periodicity of the UL traffic. The WTRU may determine (e.g., know) that it has 20ms to serve PDU set B2 (e.g., since the WTRU may have 20ms to serve all PDU sets of flow B, for example). The WTRU may determine that in 35 ms (e.g., 15ms + 20ms), the WTRU may have to transmit PDU set B2. the WTRU may transmit a pre-emptive DSR to the NW with information on PDU set B2, for example, if a (e.g., one) remaining time thresholds is set at 40ms, e.g., since the time to serve PDU set B2 is less than 40ms. A pre-emptive DSR may be referred to as a “new DSR.”

[0148] In some examples, a pre-emptive DSR MAC CE may (e.g., serve to) report the (e.g., expected) delay status of a data unit that may not have been received at the WTRU yet, but which the WTRU may expect to receive within a (e.g., short) period of time. The data unit may have one or more (e.g., some) dependencies with another data unit (e.g., a data unit that is currently sitting in the WTRU buffer). For example, the WTRU may determine or may receive information (e.g., from the application) on the existenceof dependencies between PDU set 1 and PDU set 2. The WTRU may (e.g., also) receive information on the sync requirements between the (e.g., two) dependent PDU sets from the NW and / or the application (e.g., in terms of max tolerable delay between the (e.g., two) PDU sets and / or the remaining sync delay threshold. For example, the WTRU may have received PDU set 1 but may not have received PDU set 2 in its buffer to be transmitted in the UL. For example, based on the periodicity of the traffic, the WTRU may determine (e.g., know) when to expect a data unit, e.g., PDU set 2, before its arrival in the WTRU buffer. The WTRU (e.g., in this case) may send a pre-emptive DSR with information on PDU set 2 (e.g., expected remaining time of PDU set 2, expected remaining sync delay between PDU set 1 and PDU set 2, and / or expected data volume of PDU set 2). A pre-emptive DSR may be referred to as a “new DSR.”

[0149] In some examples, a DSR MAC CE format may include information on data units in the WTRU buffer and / or data units expected in the WTRU buffer.

[0150] For example, the DSR MAC CE may carry a (e.g., one) remaining time information for the data in the WTRU buffer and a (e.g., one) remaining time info for the data expected in the WTRU buffer. For example, the DSR MAC CE may carry a (e.g., one) data volume information for the data in the WTRU buffer and a (e.g., one) data volume information for the data expected in the WTRU buffer.

[0151] For example, the DSR MAC CE may carry s (e.g., only one) data volume information for the data in the WTRU buffer and the data expected in the WTRU buffer, which may (e.g., essentially) combine / add the data volume in the WTRU buffer and the expected data in the WTRU buffer.

[0152] For example, the WTRU may report (e.g., only) a (e.g., one) remaining time information, e.g., the more stringent remaining time information. The WTRU may report (e.g., only) the smaller remaining time, e.g., of the data in the WTRU buffer, for example, if the data in the WTRU buffer has the smaller remaining time information compared to the data expected in the WTRU buffer.

[0153] For example, the WTRU may expect PDU set 2 from the application in the WTRU in 15ms based on the periodicity of the UL traffic of Flow 2. The WTRU may determine (e.g., know) that to maintain the dependencies between PDU set 1 and PDU set 2, PDU set 2 may (e.g., have to) be transmitted within 20ms of transmitting PDU set 1 . The WTRU may send a DSR to the NW on PDU set 2, for example, even though the WTRU has not yet received PDU set 2. The DSR may include, for example, one or more of the following: a data volume of PDU set 2; a remaining time of PDU set 2; and / or a time to serve / transmit PDU set 2 to maintain a sync requirement with PDU set 1 .

[0154] In some examples, a Pre-emptive DSR MAC CE may serve to report the (e.g., expected) delay status of a data unit that may not have been received at the WTRU yet. The data unit may be a data unit that the WTRU expects to receive within a (e.g., short) period of time and / or may have one or more (e.g., some) dependencies with a data unit that may have (e.g., just) been transmitted in the UL by the WTRU.

[0155] A WTRU may receive data, synchronization requirements, thresholds, and / or attributes. The WTRU may receive data, synchronization requirements, thresholds, and / or attributes from the application. A WTRU may receive data, such as PDU sets.

[0156] A WTRU may receive synchronization requirements and / or thresholds. A sync requirement may provide the WTRU with the maximum tolerable delay to maintain synchronization between (e.g., two) dependent data units (e.g., PDU set 1 and PDU set 2). The WTRU may start a timer corresponding to the length of the maximum tolerable delay upon reception of the first dependent data unit (e.g., PDU set 1). The WTRU may keep / maintain the timer running until reception of the last dependent data unit (e.g., PDU set 2, last PDU of PDU set 2, end PDU of PDU set 2, first PDU of PDU set 2, and / or all PDUs of PDU set 2). A WTRU may receive attributes of PDU sets, which may include, for example, one or more (e.g., any) of the following: PSDB; PSER; PDU set priority and / or PDU set importance; PDU set type; type of frame that the PDU set corresponds to; importance and / or priority of the PDUs of the PDU set; number of PDUs in the PDU set; remaining number of PDUs in a PDU set; size of PDU set; size of remaining PDUs of PDU set; dependencies or indications of dependencies between different data units; first PDU of PDU set indicator; end PDU of PDU set indicator; and / or end of data burst indicator.

[0157] A PDU set type attribute may be or indicate, for example, whether a PDU set corresponds to a PDU Set Integral Handling indicator (PSIHI) type. A PSIHI type PDU set may be a PDU set where (e.g., all) the PDUs of the PDU set are needed by the application for the successful decoding of the PDU set. A non-PSIHI type PDU set may not require all PDUs of the PDU set for the successful decoding of the PDU set. Another type of PDU set may utilize (e.g., need only) a subset of PDUs of the PDU set for the successful decoding of the PDU set at the application. A subset may correspond to, for example, 90%, 50%, 40%... etc. of PDUs of the PDU set for the successful decoding of the PDU set (e.g., by an application).

[0158] The type of frame that a PDU set corresponds to may indicate, for example, whether the PDU set corresponds to an l-frame, P-frame, B-frame, or any other type of frame according to the application, whether the frame is a primary or secondary or tertiary frame, whether the frame is a first frame or a differential frame, etc.

[0159] A PDU set attribute may indicate the importance and / or priority of the PDUs of the PDU set. Different PDUs of a PDU set may have different importance and / or priority values (e.g., levels), which may be set by the application. For example, different PDUs within a PDU set may correspond to different parts of the “frame” or “picture,” such as, for example, the primary part versus the differential part, which may have different importance and / or priority values.

[0160] A PDU set attribute may include the number of PDUs in the PDU set (e.g., total number of PDUs in the PDU set).

[0161] A PDU set attribute may indicate the remaining number of PDUs in the PDU set. The attribute may indicate, for example, the remaining number of PDUs in the PDU set that have not been received yet by the WTRU. The attribute may indicate, for example, the remaining number of PDUs in the PDU set in the WTRU buffer that have not been transmitted yet by the WTRU in the UL. The attribute may indicate, for example, the remaining number of PDUs in the PDU set in the WTRU buffer that have not been multiplexed yet by the WTRU into a MAC PDU. The WTRU may determine the remaining number of PDUs in the PDU set, for example, by subtracting the number of PDUs that have been multiplexed into a MAC PDU from the total number of PDUs in the PDU set. The WTRU may determine the remaining number of PDUs in the PDU set, for example, by subtracting the number of PDUs that have been transmitted by the WTRU in the UL from the total number of PDUs in the PDU set.

[0162] A PDU set attribute may indicate the size of a PDU set, e.g., in bytes, kB, MB, etc. The size of the PDU set may indicate, for example, if the size of the PDU set is larger than a preconfigured threshold.

[0163] A PDU set attribute may indicate the size of remaining PDUs of a PDU set, e.g., in bytes, kB, MB, etc.

[0164] A PDU set attribute may provide (e.g., indication(s) of) dependencies between different data units, such as, for example, one or more of the following: dependencies between PDUs of a PDU set; dependencies between different PDU sets; and / or dependencies between different data bursts.

[0165] A WTRU may perform transmissions to the network. In some examples, the WTRU may transmit to the network delay information (e.g., in a DSR, for example via a DSR MAC CE used as an example) for a (e.g., one) flow. Delay information may be transmitted by a WTRU, for example, in RRC signaling (e.g., in WTRU assistance info), UL MAC CE, UCI (e.g., in PUCCH or in PUSCH as UTO-UCI), and / or PUSCH.

[0166] Information transmitted by a WTRU may include one or more remaining time information and / or one or more associated data volume information. The WTRU may include in the indication information on the BSR table that was used, e.g., in case the WTRU may be configured with more than one BSR table. The WTRU may determine the BSR table to use based on the data volume that the WTRU is reporting, e.g., the BSR table that carries the entry that most closely matches the data volume that the WTRU needs to be reported in the delay status report may become the selected BSR table. The WTRU may be configured with different indices, for example, to identify the different BSR tables, e.g., ‘00’ - BSR table 1, ‘01 ’ - BSR table 2, ‘10’ - BSR table 3, ‘11 ’ BSR table 4 or ‘0’ for BSR table 1 , ‘1 ’ for BSR table 2.

[0167] In some examples, the WTRU may transmit to the network delay information (e.g., in a DSR via a DSR MAC CE) for more than one flow via separate delay status reports (e.g., in different DSR MAC CEs).

[0168] In some examples, the WTRU may transmit a DSR with information on the remaining time and the associated data volume (e.g., portion of data) of PDU set 1 (e.g., a first portion of data may be grouped based on a first remaining time (e.g., the remaining time value for the first PDU set)) and PDU set 2 (e.g., a second portion of data may be grouped based on a second remaining time (e.g., the remaining time value for the second PDU set)), for example, if the WTRU determines that the remaining time of a data unit (e.g., PDU set 1) is less than the remaining time threshold, if a dependent data unit (e.g., PDU set 2) is received before the WTRU sends the delay status for PDU set 1 , and if the remaining sync delay of the dependent data unit (PDU set 2) is higher than the remaining sync delay threshold. For example, the data volume of PDU set 1 and PDU set 2 may be reported in different octets in the same DSR.

[0169] In some examples, the WTRU may transmit delay information associated with PDU set 1, e.g., information on the remaining time and associated volume of PDU set 1 , for example, if the WTRU determines that the remaining time of a data unit (e.g., PDU set 1) is less than the remaining time threshold, if a dependent data unit (e.g., PDU set 2) is not received before the WTRU sends the delay status for PDU set 1 , and if the remaining sync delay of the dependent data unit (PDU set 2) is higher than the remaining sync delay threshold. The WTRU may (e.g., also) transmit delay information associated with PDU set 2, e.g., remaining time of PDU set 2, remaining sync delay, data volume of PDU set 2. The delay information for PDU set 2 may be transmitted in a separate DSR MAC CE or in the same DSR MAC CE as the delay information for PDU set 1 . For example, a “regular” DSR and a “pre-emptive” DSR (e.g., carrying expected delay information, as described herein) may be sent in the same MAC CE or different MAC CEs.

[0170] A WTRU may perform one or more operations / actions. For example, a WTRU may determine the remaining time of a PDU set.

[0171] A WTRU may make a determination of reception of a PDU set. Reception of PDU set may refer to the reception of the PDUs of the PDU set in the L2 protocol stack, e.g., at one or more (any) of the L2 sublayers, such as SDAP, PDCP, MAC, etc.

[0172] The WTRU may determine when a PDU set is received (e.g., the time instance of reception) based on, for example, one or more (e.g., any) of the following: arrival (time) of (e.g., all) PDUs of the PDU set (e.g., following the arrival of (all) PDUs belonging to the PDU set and / or based on the arrival times / timestamps of (all) PDUs belonging to the PDU set); arrival (time) of first PDU of PDU set; arrival time of last / end PDU of PDU set; reception of indicator indicating last PDU of PDU set; reception of indicator indicating last PDU of data burst (e.g., end of Data Burst (EoDB) indicator); information included in first PDU of PDU set; attributes of a PDU set that may be included in the first PDU of PDU set or any other PDU of a PDU set or sent separately (e.g., in a control PDU). Examples of attributes of a PDU set include,for example, one or more of the following: number of PDUs of PDU set; size of PDU set; PSDB of PDU set; and / or PSDD of PDU set.

[0173] A WTRU may make a determination of remaining time of PDU set. The remaining time of the PDU set may refer to the remaining time to serve the PDU set, e.g., the remaining time to perform any one or more of the operations in the protocol stack (e.g., multiplexing, discarding, segmentation, segregation, addition of security, etc.) before the PDU set is (e.g., has to be) transmitted in the UL, or the remaining time to perform any one or more of the operations in the protocol stack if / when the PDU set is received in the downlink before it is sent to the higher / application layer(s).

[0174] The WTRU may determine the remaining time of a PDU set based on, for example, any one or more of the following: the arrival time of PDUs of the PDU set; the arrival time of the first PDU of the PDU set; the arrival time of the last PDU of the PDU set; PDU Set Delay Budget (PSDB) and / or another delay budget that may be a function of the PSDB; PDU Set Delay Deadline (PSDD) and / or another delay deadline that may be a function of the PSDD; and / or the remaining time threshold.

[0175] The WTRU may determine the remaining time of a PDU set based on a PDU Set Delay Budget (PSDB) and / or another delay budget that may be a function of the PSDB (e.g., 90% of PSDB, 80% of PSDB, etc.). For example, the WTRU may start a timer whose length corresponds to the PSDB at the time it receives the first PDU of the PDU set. The WTRU may compute the “time to receive the PDU set,” for example, by computing the difference between the time the first PDU of the PDU set is received and the time the last PDU of the PDU set is received. The WTRU may compute the remaining time of the PDU set, for example, by subtracting the “time to receive the PDU set” from the PSDB.

[0176] The WTRU may determine the remaining time of a PDU set based on PDU Set Delay Deadline (PSDD) and / or another delay deadline that may be a function of the PSDD (e.g., 90% of PSDD, 80% of PSDD, etc.). For example, the WTRU may start a timer whose length corresponds to the PSDD at the time it receives the first PDU of the PDU set. The WTRU may compute the “time to receive the PDU set,” for example, by computing the difference between the time the first PDU of the PDU set is received and the time the last PDU of the PDU set is received. The WTRU may compute the remaining time of the PDU set, for example, by subtracting the “time to receive the PDU set” from the PSDD.

[0177] A WTRU may determine the remaining sync delay. A synchronization (sync) requirement and / or threshold may refer to a maximum time (e.g., measured in ms) and / or distance (e.g., measured in number of slots) between (e.g., two) dependent PDU sets (e.g., between last PDU of one PDU set and last PDU of a dependent PDU set) that can be tolerated by the application. The WTRU may receive the sync requirement and / or threshold from the application, for example.

[0178] A sync delay may refer to the time window between a PDU (e.g., last PDU, reference PDU) of a (e.g., one) PDU set and a PDU (e.g., last PDU, reference PDU) of another dependent PDU set. A sync delay may be measured, for example, in terms of time (e.g., measured in ms) and / or distance (e.g., measured in number of symbols / slots) between (e.g., two) dependent PDU sets. The (e.g., two) PDU sets may be in the same or different flows.

[0179] The remaining sync delay may refer to the time remaining in the sync delay window. FIG. 2 illustrates an example of determining the remaining sync delay. For example, as shown in FIG. 2, the WTRU may start a timer of length T ms upon receiving PDU set 1 (e.g., all PDUs of PDU set 1 or last PDU of PDU set 1 or first PDU of PDU set 1) if the maximum tolerable delay between PDU set 1 and PDU set 2 is a time window of length T ms. PDU set 1 may be received at time 0 ms. At time ti, PDU set 1 may have been received ti ms ago (e.g., PDU set 1 has been sitting in the WTRU buffer for the last ti ms). The remaining sync delay for PDU set 2 to be received (e.g., all PDUs of PDU set) to maintain the sync requirement may be equal to (T - ti) ms.

[0180] The remaining sync delay of one data unit (e.g., PDU set 2) may be determined with respect to another PDU set (e.g., PDU set 1) on which the data unit may be dependent on. Dependencies between data units may signify that (e.g., both) data units may (e.g., must) be received within a time window of one another for successful decoding at the application.

[0181] A WTRU may determine the remaining sync delay. A WTRU may determine the remaining sync delay of PDU set 2, for example, based on the arrival time of PDU set 1 and the remaining sync delay threshold.

[0182] A WTRU may determine the remaining sync delay of a data unit (e.g., PDU set 2) based on, for example, any one or more of the following: information on (e.g., arrival time) of a dependent data unit (e.g., PDU set 1); amount of time a PDU set (e.g., PDU set 1) has spent in the WTRU buffer; remaining sync delay threshold; remaining time threshold; and / or a sync requirement / threshold (e.g., from application).

[0183] Information on (e.g., arrival time) of a dependent data unit (e.g., PDU set 1) may include, for example, one or more of the following: arrival time of first PDU of PDU set; arrival time of last PDU of PDU set; arrival time of end PDU of PDU set; arrival time of (e.g., all) PDUs of PDU set (e.g., average arrival time of PDUs of PDU set); expected arrival time of PDUs of PDU set (e.g., expected nominal arrival time of PDUs of PDU set); statistics on arrival time of PDUs of PDU set (e.g., mean / median / average of arrival times of PDUs of one or more PDU sets); dependencies information between (e.g., two) data units.

[0184] The amount of time a PDU set (e.g., PDU set 1) has spent in the WTRU buffer may refer to, for example, any L2 buffer, which may include, for example, one or more of the following: a PDCP buffer, a MAC buffer, an RLC buffer, etc.

[0185] A sync requirement / threshold (e.g., from application) may provide a WTRU with the max tolerable delay to maintain sync between PDU set 1 and PDU set 2. The WTRU may start a timer corresponding to the max tolerable delay length, for example, upon reception of PDU set 1 . The WTRU may determine the remaining sync delay of PDU set 2, for example, based on the sync requirement / threshold and the amount of time the dependent data unit (e.g., PDU set 1) has spent in the WTRU buffer (e.g., PDCP buffer, MAC buffer, etc.).

[0186] There may be dependencies in XR traffic. In some examples, a WTRU may receive information (e.g., from the application) on dependencies in XR traffic. The WTRU may send to the NW information to assist the NW in determining that there are dependencies in UL data. For example, the WTRU may receive information from the application on dependencies between (e.g., two) flows in the uplink. The WTRU may send the dependencies information to the network. In some examples, the WTRU may determine that there are dependencies in the UL data. For example, the WTRU may determine that PDUs received together and / or within a (e.g., short) period of time of one another may be dependent on each other. The WTRU may transmit the dependency information to the NW.

[0187] In some examples, the WTRU may mark PDUs received together and / or within a (e.g., short) period of time of one another as being part of a PDU set, e.g., by adding markings / sequence numbers to the PDUs of the PDU set. The markings / sequence numbers may be added to the header of the PDU set (e.g., PDCP header). In some examples (e.g., instead of in-band marking of the PDUs / PDU sets), the WTRU may send via separate signaling (e.g., MAC CE, UCI) as an indication to the NW for the NW to determine the dependencies between the PDUs / PDU sets. For example, an indication such as (1 , 2, 3) may correspond to PDU 3 of PDU set 2 of Flow 1 .

[0188] In some examples, the WTRU may have determined and / or received information from the application on the dependency between (e.g., two) flows. For example, there may be a dependency between flow A and flow B. In some examples, the WTRU may have determined and / or received information from the application on the dependency of PDU sets within flows. For example, there may be a dependency between PDU Set A1 of flow A and PDU Set B1 of flow B. For example, there may be a dependency between PDU Set A1 and PDU set A2 of flow A and PDU Set B1 of flow B. For example, there may be a dependency between PDU Set A1 of flow A and PDU Sets B1, B2, B3 of flow B.

[0189] In some examples, a WTRU may determine dependency between PDU set 1 and PDU set 2 and / or the WTRU may receive information on dependencies (e.g., from an application) between PDU set 1 and PDU set 2. For example, there may be dependency between PDU set 1 from Flow 1 and PDU set 2 from Flow 2. The WTRU may receive information (e.g., from the application) on there being a dependency between Flow 1 and Flow 2.

[0190] In some examples, a (e.g., one) PDU set may reference another PDU set. For example, a P- frame may reference a dependent l-frame, e.g., in the header of the P-frame. For example, the header of PDU set a may have some information on PDU set 2 that may be dependent on PDU set 1 .

[0191] In some examples, the WTRU may receive an indication (e.g., from the application) of the sync delay (e.g., in terms of delay size / duration) between (e.g., two) dependent data units and / or flows. In some examples, the sync delay, measurement, and / or reporting of the measurement may happen at the WTRU and / or NW, for example, according to one or more of the following: detection and measurement at the WTRU; detection and measurement at the NW; detection at the WTRU (e.g., indicated to the NW) and measurement at the NW (e.g., with the value reported back to the WTRU); or detection at the NW (e.g., indicated to the WTRU) and measurement at the WTRU (e.g., with the value reported back to the NW).

[0192] In some examples (e.g., for DL traffic), the WTRU may receive an indication of the sync delay from the NW and / or application server. In some examples, the WTRU may measure the sync delay, e.g., based on reception of the data in the DL. For example, the WTRU may receive an indication from the NW / application on the periodicity of flow A. The WTRU (e.g., based on the periodicity knowledge) may expect arrival of PDU sets from flow A at certain time instants. The WTRU may determine that there may be a sync delay (e.g., and may measure the sync delay), for example, if the WTRU does not receive PDU sets from flow A at the expected arrival time instants. The time difference between when the WTRU expects to receive the PDU sets from flow A (e.g., based on knowledge of periodicity of flow A) and when the WTRU actually receives the PDU sets from flow A may represent the size / duration of the sync delay, for example.

[0193] There may be drift between dependent data units. A WTRU may measure the drift size / duration for UL traffic, for example, based on one or more of the following: time synchronization requirements; time difference between the periodicity of a flow and actual arrival time of dependent data; one or more of time synchronization requirements, information of periodicity of data / flow, and / or the actual arrival time of the dependent PDU set; one or more measurements; N past PDU sets of a flow with respect to the corresponding dependent PDU sets of another flow; and / or buffer overflow.

[0194] A WTRU may measure the drift size / duration for UL traffic based on time synchronization requirements (e.g., that the WTRU received from the application in (executed by) the WTRU) and the actual arrival time of the dependent PDU set. For example, the WTRU may have received information from the application on the sync requirements between flow A and flow B. the WTRU may determine that there is a drift and also estimate the drift size, for example, based on the sync requirements and the actual arrival time of a dependent PDU set. For example, the WTRU may have received information from the application on a sync requirement between flow A (e.g., with PDU sets A1, A2, A3, and so on) and flow B (e.g., withPDU sets B1, B2, B3, and so on). There may be a one-to-one correspondence for the dependency, e.g., PS A1 or flow A may be dependent on PS B1 of flow B. The WTRU may start a timer T (e.g., the length of the timer may correspond to or be a function of the sync requirements), for example, if / when the WTRU receives PS A1 (e.g., from the XR application in the WTRU). The WTRU may determine that there is a drift, for example, if the WTRU has not yet received PS B1 (e.g., from the XR application in the WTRU) at the expiry of T. The time difference between the expiry of timer T and the time at which the WTRU actually receives PS B1 may constitute the size of the drift. The WTRU may perform the measurement (e.g., spot check) for (e.g., all) instances of dependency (e.g., start timer T on reception of PDU set A2 and check if PDU set B2 is received within the time sync requirements, start timer T on reception of PDU set A3 to check that B3 is received on time, and so forth...). In some examples, the WTRU may be configured to do the spot check periodically, for example, every 40ms, 100ms, etc. and / or every n number of slots. In some examples, the WTRU may do the spot check on reception of an indication from the NW.

[0195] A WTRU may measure the drift size / duration for UL traffic based on the time difference between periodicity of a flow and actual arrival time of dependent data. For example, the WTRU may have received information from the application on the periodicity of flow B (e.g., in terms of bitrate, number of PDUs and / or PDU sets per second). The WTRU may (e.g., based on the received information) start a timer T (e.g., the length of the timer may correspond to or be a function of the interval between (two) respective PDU sets from the periodicity knowledge). For example, the WTRU may start timer T on reception of PDU set A1 (e.g., from an application in / executed by the WTRU). The WTRU may expect to receive A2 before expiry of timer T. The WTRU may determine that there is a drift, for example, if the WTRU has not received A2 (e.g., from the application in / executed by the WTRU) by the expiry of T. The time difference between the expiry of timer T and the time at which the WTRU actually receives PS A2 may constitute the size of the drift.

[0196] A WTRU may measure the drift size / duration for UL traffic based on any one or more of the following: time synchronization requirements, information of periodicity of data / flow, and / or the actual arrival time of the dependent PDU set.

[0197] In some examples, the WTRU may do perform a measurement (e.g., spot check) for (e.g., all) instances of dependency (e.g., start timer T on reception of PDU set A1 and check if PDU set A2 is received within the time sync requirements, start timer T on reception of PDU set A2 to check that A3 is received on time, and so forth...). In some examples, the WTRU may be configured to perform a spot check periodically, for example, every 40ms, 100ms, etc. and / or every n number of slots. In some examples, the WTRU may perform a spot check on reception of an indication from the NW.

[0198] A WTRU may measure the drift size / duration for UL traffic based on one or more measurements. In some examples, the WTRU may determine that there is a drift and measure the size of the drift based on one measurement (e.g., based on time difference between arrival of PS A1 and PS A2 from the application in the WTRU). In some examples, the WTRU may determine that there is a drift and measure the size of the drift based on more than one measurement. For example, the WTRU may measure the time difference between arrival of PS A1 and PS A2, the time difference between arrival of PS A2 and PS A3, the time difference between arrival of PS A3 and PS A4 from the application, and so on. The WTRU may determine an average over (e.g., all) the measurements to determine whether there is a drift. In a similar way, the determination of the size of the drift may be taken / averaged over multiple (e.g., several) measurements.

[0199] In some examples, the WTRU may determine that there is a drift and measure the size of the drift based on one measurement. The WTRU may, (e.g., only) in the event that there is a drift, make another measurement to confirm the existence of the drift. For example, PS A2 may arrive late with respect to PS A1 . The WTRU may determine there is a drift (e.g., only) after measuring the arrival time of PS A3 with respect to PS A2. For example, PS A2 may arrive late with respect to PS A1 . The WTRU may determine there is a drift (e.g., only) after measuring the arrival time of PS A3 with respect to PS A2, and PS A4 with respect to PS A3, and so on.

[0200] Phrases such as “WTRU receives PDU sets,” “Reception of PDU sets at WTRU,” “Arrival of PDU sets” used in the context of UL traffic may refer to the WTRU receiving the PDU sets from the application (e.g., in the WTRU or in a tethered UD). Likewise when “PDU sets” in such phrases are replaced with “PDUs” and / or “data.”

[0201] In some examples, the WTRU may determine that there is a drift and determine the size of the drift based on N past PDU sets of one flow with respect to the corresponding dependent PDU sets of another flow.

[0202] In some examples, the WTRU may determine that there is a drift based on buffer overflow. For example, LCH 1 may have data from flow A and LCH 2 may have data from flow B. The WTRU may know about dependencies between flow A and flow B and / or LCH 1 and LCH 2. The WTRU may determine that there is a drift, for example, in the event that there is buffer overflow for LCH 2.

[0203] The network (NW) may perform drift detection and / or measurement in UL / DL. The NW may detect / measure drift for DL traffic, for example, based on indications from the application server. In some examples, the WTRU may send indications to the NW on a drift / drift size, which the WTRU may detect / measure based on late arrival of PDUs / PDU sets in the DL.

[0204] The WTRU may receive information on a drift for UL traffic from the application. The WTRU may send an indication on the drift to the NW.

[0205] In some examples, the WTRU may send information to the NW to enable / allow the NW to determine that there is a drift and the drift size for UL traffic, for example, by adding markings / sequence numbers to the PDUs of the PDU set. The markings / sequence numbers may be added to the header of the PDU set (e.g., PDCP header), for example. In some examples (e.g., instead of doing in-band marking of the PDUs / PDU sets), the WTRU may send via separate signaling (e.g., MAC CE, UCI) as an indication to the NW for the NW to determine that there is a drift between dependent PDU sets.

[0206] In some examples (e.g., where the drift may be detected / measured at the NW), the WTRU may receive feedback / assistance information from the NW following the drift detection / measurement.Feedback / assistance information may include, for example, information on the size of the drift and / or the duration of the drift. In some examples, the NW may receive information from the application server on the drift size and / or duration. In some examples, the NW may determine the drift size based on delayed arrival of data. The NW may estimate the drift duration based on, for example, knowledge of past traffic.

[0207] The NW may (e.g., if the NW detects and / or measures the drift) send to the WTRU information on the drift, e.g., drift size and / or (e.g., expected) duration and / or the resulting action to take.

[0208] A WTRU may report a delay based on one or more conditions. The WTRU may report delay for a data unit and / or trigger a DSR (e.g., new DSR), for example, based on any one or more of the following: if / when the remaining time for the data unit (e.g., remaining time with respect to the PSDB and / or PSDD for PDU set, remaining time with respect to the PDB for PDU) falls below the remaining time threshold, tRT (e.g., the WTRU may determine the remaining time at the time of DSR triggering and / or at the time of multiplexing a DSR MAC CE); if / when the remaining time for a dependent data unit (e.g., remaining time with respect to the PSDB and / or PSDD for a dependent PDU set, remaining time with respect to the PDB for a dependent PDU) falls below the remaining time threshold, tRT (e.g., the WTRU may determine the remaining time at the time of DSR triggering and / or at the time of multiplexing a DSR MAC CE); if / when the remaining sync delay (e.g., maximum tolerable delay between (two) dependent data units (e.g., PDU sets) to maintain the synchronization requirement between them) exceeds the remaining sync delay threshold, tRSD; if / when requested by the network to report on the delay; a notification from higher layers (e.g., from PDCP, RLC, SDAP, or application layer) has been received by the WTRU; a timer has expired or is about to expire (e.g., within x ms of expiry), where the time may be maintained per LCG, LCH, PDU set, data burst, DRB, or an application (e.g., the timer, such as a discard timer, may be started upon transmission of a PDU, or delivering a PDU for transmission to lower layers, from the same PDU set or from an associated PDU set); new data has arrived in the WTRU buffer; the priority of the data is the same and / or higher and / or lower than the priority of LCGs for which a BSR has already been triggered; and / or the priority of thenew data that has arrived is the same and / or higher and / or lower than the data of LCGs for which a BSR has already been triggered.

[0209] A WTRU may trigger a new DSR for the same LCG that has been reported in a DSR (e.g., even if the DSR has not been cancelled yet and / or the newly arrived data is of the same priority), for example, if one or more of the following conditions is met: the remaining time for a data unit falls below the remaining time threshold; data from another PDU set has arrived and the data is mapped to the same LCG that has been reported (or for which the ongoing DSR has been triggered); newly arrived data is larger than a size threshold, newly arrived data is from a different LCH (e.g., within the same LCG for which there is a pending DSR); newly arrived data is of a higher priority than the previous data that triggered DSR; newly arrived data is of a higher importance than the previous data that triggered DSR; newly arrived data has a smaller PSDB, smaller PSDD, smaller remaining time with respect to its PSDB, and / or smaller remaining time with respect to its PSDD. The WTRU may perform methods (e.g., as described herein) for DSR triggering.

[0210] The WTRU may trigger a new SR (e.g., for a triggered DSR), for example, if the available uplink resource does not meet the delay to transmit the DSR MAC CE and / or the delay associated with data that triggered DSR. The WTRU may determine the delay from the remaining time for a data unit that triggered DSR. For example, the WTRU may trigger a new SR if the remaining time for the data unit that triggered DSR is greater than the time required to transmit PUSCH (e.g., from available UL grants). The WTRU may determine that the time required to transmit PUSCH as K2 (e.g., delay until the start of the PUSCH resource), PUSCH duration, and / or a combination of the two. In some examples, the WTRU may trigger a new SR if the available grants do not meet the LCP restrictions configured for (e.g., all) LCHs for which buffered data with remaining time is less than the remaining time threshold, or for LCHs in the LCG that triggered DSR. The WTRU may (e.g., therefore) trigger multiple SRs for the same LCH and / or LCG.

[0211] An enhanced and / or new DSR MAC CE may have a format. The remaining time may be computed at an (e.g., any) L2 sublayer (e.g., at PDCP based on the PDCP discardTimer). The associated data volume may be computed in a similar way as the data volume calculation may be done by the PDCP, RLC, and / or MAC sublayers.

[0212] The WTRU may be configured with multiple formats for the DSR MAC CE. The WTRU may determine the DSR MAC CE format to use based on, for example, the type of information and / or amount of information (e.g., one instance of remaining time or multiple instances of remaining time reported in one MAC CE) to be reported in the DSR MAC CE.

[0213] The DSR MAC CE and / or pre-emptive DSR MAC CE for a (e.g., one) data unit (e.g., for PDU set1) may include any one or more of the following information: remaining time for PDU set 1 ; an indication ofthe relevant BSR table (BT) used; A data volume information associated with PDU set 1 ; identity of the LCG (e.g., LCG 0, LCG 1, LCG 2, etc.) to which the data unit (e.g., PDU set 1) belongs; identity of the LCH (e.g., logical channel ID) to which the data unit (e.g., PDU set 1) belongs (e.g., the WTRU may also include the LCG the LCH belongs to); identity of the DRB to which the data unit (e.g., PDU set 1) belongs; identity of the flow to which the data unit (e.g., PDU set 1) belongs; dependency information between PDU set 1 and a dependent data unit (e.g., PDU set 2); an indication of the relevant BSR table (BT) used; information on the data volume associated with the dependent data unit (e.g., PDU set 2); identity of the LCG (e.g., LCG 0, LCG 1 , LCG 2, etc.) to which the dependent data unit (e.g., PDU set 2) belongs; identity of the LCH (e.g., logical channel ID) to which the dependent data unit (e.g., PDU set 2) belongs (e.g., the WTRU may also include the LCG the LCH belongs to); identity of the DRB to which the dependent data unit (e.g., PDU set 2) belongs; and / or identity of the flow to which the dependent data unit (e.g., PDU set 2) belongs.

[0214] The remaining time for PDU set 1 may include, for example, one or more of the following: remaining time with respect to the PSDB of PDU set 1 ; remaining time with respect to the PSDD of PDU set 1 ; remaining time with respect to a time threshold that may be a function of the PSDB and / or PSDD; remaining time with respect to a time threshold that may be a function of the time needed to serve PDU set 1 (e.g., perform an (any of the) L2 operations, such as multiplexing, discard, etc., before transmitting PDU set 1 in the uplink); and / or identity of PDU set 1 (e.g., via the SN of PDU set 1 and / or SN of PDUs of PDU set 1).

[0215] An indication of the relevant BSR table (BT) used may be, for example, a BT index used to transmit information on the data volume associated with PDU set 1 .

[0216] Data volume (e.g., a portion of data) information associated with PDU set 1 (e.g., in a buffer size field) may include, for example, one or more of the following: size of PDU set 1 (e.g., measured in kB, MB, etc.); number of PDUs in PDU set 1 ; an index corresponding to an entry in a BSR table that most closely matches the data volume information associated with PDU set 1 ; size of segment / portion (e.g., as described herein a buffer size, for example, of the portion of data) of PDU set 1 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU; number of PDUs of PDU set 1 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU; and / or an index corresponding to an entry in a BSR table that most closely matches the size of the segment / portion of PDU set 1 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU.

[0217] Dependency information between PDU set 1 and a dependent data unit (e.g., PDU set 2) may include, for example, any one or more of the following: an indication (e.g., a simple indication) of dependency; identity of PDU set 2 (e.g., via the SN of PDU set 2 and / or SN of PDUs of PDU set 2); identity of flow, DRB, LCH, and / or LCG to which PDU set 2 belongs to / is mapped to; remaining time and / orexpected remaining time with respect to the PSDB of PDU set 2; remaining time and / or expected remaining time with respect to the PSDD of PDU set 2; remaining time and / or expected remaining time with respect to a time threshold that may be a function of the PSDB and / or PSDD of PDU set 2; remaining time and / or expected remaining time with respect to a time threshold that may be a function of the time needed to serve PDU set 2 (e.g., perform a (any) of the L2 operations, such as multiplexing, discard, etc., before transmitting PDU set 2 in the uplink); sync delay of PDU set 2 with respect to PDU set 1 ; remaining sync delay of PDU set 2 with respect to PDU set 1 ; and / or maximum tolerable delay between PDU set 1 and PDU set 2.

[0218] An indication (e.g., a simple indication) of dependency may include, for example, a flag / one bit indication that there is a dependent data unit. For example, presence of a one bit indicator / flag may serve to indicate whether subsequent octets (e.g., following the first N octets) in the DSR MAC CE may be used to accommodate information on the dependent data unit.

[0219] An indication of the relevant BSR table (BT) used may include, for example, a BT index used to transmit information on the data volume associated with PDU set 2.

[0220] Information on the data volume associated with the dependent data unit (e.g., PDU set 2), e.g., in a buffer size field, may include, for example, one or more of the following: size of PDU set 2 (e.g., measured in kB, MB, etc.); number of PDUs in PDU set 2; an index corresponding to an entry in a BSR table that most closely matches the data volume information associated with PDU set 2; size of segment / portion of PDU set 2 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU; number of PDUs of PDU set 2 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU; and / or an index corresponding to an entry in a BSR table that most closely matches the size of the segment / portion of PDU set 2 that has not yet been transmitted in the UL and / or multiplexed in a MAC PDU.

[0221] In some examples, a WTRU may include delay information on multiple (e.g., two) data units in multiple (e.g., two) separate DSR MAC CEs. There may be dependencies between the multiple (e.g., two) data units. In some examples, the data units may be independent of each other. The multiple (e.g., two) data units may belong to the same or to different LCG(s). The multiple (e.g., two) data units may belong to the same or to different LCH(s). The multiple (e.g., two) data units may belong to the same or to different flow(s). The multiple (e.g., two) data units may belong to the same or to different DRB(s).

[0222] In some examples, the WTRU may include delay information on multiple (e.g., two) independent data units in the same DSR MAC CE. There may be dependencies between the multiple (e.g., two) data units. In some examples, the data units may be independent of each other. The multiple (e.g., two) data units may belong to the same or to different LCG(s). The multiple (e.g., two) data units may belong to thesame or to different LCH(s). The multiple (e.g., two) data units may belong to the same or to different flow(s). The multiple (e.g., two) data units may belong to the same or to different DRB(s).

[0223] In some examples (e.g., if DSR is triggered per LCG), the first octet in the DSR MAC CE may include the different LCG IDs (e.g., LCG 0, LCG 1 ,..., LCG 7). In the second octet, for example, six (6) bits may be used for the remaining time for the first LCG (e.g., LCG 0), with one (1) bit to indicate the BSR table for the data volume for LCG 0 (e.g., whether a default BSR table is used or the XR BSR table for example), and one (1) bit may be used to indicate whether only one or more than one remaining time and data volume is reported for LCG 0 (e.g., the first PDU set may be included in the second octet, and the first octet may be associated with a first remaining time threshold value). Octet 3 may be used for the buffer size of the data volume in LCG 0. In case there is more than one remaining time and buffer size to report for LCG 0, octet 4 may be used to report the second remaining time and the BSR table for the second data volume associated with LCG 0 (e.g., the second PDU set may be included in octet 4, and octet 4 may be associated with the second remaining time threshold value) . Octet 5 may be used to report the second buffer size.

[0224] In the case only one remaining time and data volume is reported per LCG, for example, octets 2 and 3 may be for LCG 0, octets 4 and 5 may be for LCG 1, octets 4 and 7 may be for LCG 2, and so forth, the WTRU may simply omit the relevant octets, for example, if there is no delay information to report.

[0225] The LCH carrying the data unit that triggered delay reporting may (e.g., also) be included, for example, if more than one delay information is reported per LCG. FIG. 3 illustrates an example of a delay status report with more than one delay information reported per LCG. For example, the first two octets in the DSR MAC CE may be as shown in FIG. 3. The second octet may correspond to the (e.g., two) logical channels per LCG with the (e.g., two) smallest remaining times.

[0226] In some examples (e.g., if DSR is reported per LCH), the first octet in the DSR MAC CE may correspond to the logical channel ID. Optionally, the second octet may carry information on the LCG it belongs to.

[0227] In some examples, DSR may be reported per PDU set. For example (e.g., for each PDU set), the remaining time information and / or the associated data volume information (e.g., segment / portion of PDU set associated to remaining time) may be reported in a DSR MAC CE.

[0228] Similar to the BSR MAC CE, there may be a truncated DSR MAC CE and / or a padded DSR MAC CE.

[0229] In some examples (e.g., if one LCG triggered the DSR, but more than one LCGs are below the threshold), the WTRU may report LCG delay and buffer size for each LCG with delay < threshold. The WTRU may compute the reported buffer size and / or reporting delay / remaining timer, for example, at time oftrigger or at time of multiplexing the DSR MAC CE. For example, LCG1 may have triggered a DSR. LCG1 may be the only LCG with data less than the remaining time threshold. At the time of multiplexing the pending DSR, LCG1 and LCG2 may both have data with remaining time less than the remaining time threshold. The WTRU may report delay and buffer status for both LCGs in the DSR MAC CE.

[0230] In some examples, the WTRU may determine the DSR MAC CE format to use based on the available resources.

[0231] DSR cancellation conditions may be configured. The DSR may include information similar to the BSR (Buffer Status Report), e.g., information on the buffer status / data volume per LCG. Overhead reduction may be beneficial. For example, DSR and BSR may be multiplexed in the same transport block. New cancellation conditions may be applied to avoid the same information on the data volume being reported in both the DSR and BSR. New cancellation conditions for BSR may indicate, for example, that BSR is cancelled if the same information on data volume is reported in DSR. In some examples, an SR triggered by BSR may be cancelled based on DSR multiplexing. In some examples, an SR triggered by BSR may be cancelled based on the WTRU adding a truncated DSR in the grant.

[0232] A triggered DSR may be considered pending until it is cancelled., the WTRU may multiplex DSR MAC CEs for transmission on PUSCH, for example, as long as a DSR is pending. Remaining time for a LCG / LCH may be determined as, for example, one or more of the following: the lowest remaining time for a buffered data unit belonging to LCG / LCH, the delay since arrival at WTRU buffer, and / or the anticipated delay to the transmission occasion.

[0233] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if at least one of the following conditions are met: remaining time associated with (e.g., all) LCGs / LCHs is larger than the configured threshold for triggering DSR; (e.g., all) PDU sets in the LCG are reported; (e.g., all) SDUs with remaining time < threshold are reported; upon discard of a data unit associated with a PDU set / LCG / LCH that triggered DSR; upon satisfying one or more QoS requirement of the PDU set is satisfied; no buffered data with remaining time less than the threshold (e.g., for LCG that triggered DSR or any LCG); and / or BSR is reported with the same information / content as DSR.

[0234] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if remaining time associated with (e.g., all) LCGs / LCHs is larger than the configured threshold for triggering DSR, e.g., at any time, such as at the time of multiplexing DSR. The WTRU may cancel the pending DSR, for example, if remaining time associated with any LCG or the LCG that triggered DSR is larger than the threshold. The WTRU may not cancel a pending DSR, for example, if the remaining time associated with the LCH / LCG that triggered the DSR is < threshold and / or number of buffered bits > x bits.

[0235] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if (e.g., all) PDU sets in the LCG are reported, e.g., separately, for example, with buffer size and / or remaining time reported separately for each LCG.

[0236] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if (e.g., all) SDUs with remaining time < threshold are reported. The delay may be computed, for example, at time of trigger or at time of multiplexing.

[0237] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, based on (e.g., upon) discard of a data unit associated with a PDU set / LCG / LCH that triggered DSR. The WTRU may inform the network that it has discarded associated PDUs upon a cancellation event, e.g., by providing an uplink discard indication for a given PDU set and / or a last BSR or DSR with the amount of buffer size reported.

[0238] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, based on (e.g., upon) satisfying one or more QoS requirement of the PDU set. The WTRU may cancel the DSR / BSR, for example, if the PDU set is determined (e.g., considered) to be (e.g., overall) successfully decoded (e.g., from decoding a subset of PDUs). The WTRU may cancel the DSR / BSR, for example, if an application layer metric (e.g., survival time, application-level timer are stopped or restarted) is met.

[0239] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if there is no buffered data with a remaining time less than the threshold (e.g., for LCG that triggered DSR or any LCG). The WTRU may cancel a pending DSR, for exampleif (e.g., all) LCGs that had a remaining time less than a threshold at the time that the DSR was triggered no longer have buffered data, and / or if the amount of buffered data is less than a threshold.

[0240] The WTRU may (e.g., be predefined and / or configured to) cancel a pending DSR or BSR, for example, if BSR is reported with the same information / content as DSR. In some examples (e.g., if DSR and BSR are multiplexed in the same TB), the WTRU may cancel the BSR and / or the DSR (e.g., prior or after multiplexing MAC CEs) if the same buffer status is reported in (e.g., both) MAC CEs for all LCGs. The WTRU may omit the BS octet in the DSR MAC CE, for example, in the event of cancellation. In some examples (e.g., if the DSR MAC CE is not multiplexed and the BSR was reported, or visa-versa), the WTRU may cancel the BSR (e.g., or the DSR in the other case) if the BSR includes the same buffer size octet as was already transmitted in the DSR MAC CE (e.g., or the BSR in the other case) and / or if no new data has arrived in between (e.g., after the multiplexing of one MAC CE type to the time when the other MAC CE type is considered for multiplexing). This type of cancellation may happen, for example, (e.g., only) at the time of multiplexing the other type of MAC CE or after the transmission of one MAC CE type.The WTRU may consider other (e.g., additional) conditions, such as whether (e.g., all of) the buffered data reported part of the DSR is the same as the one to be reported in the BSR, or visa-versa, e.g., which may indicate whether (e.g., all) the buffered data for a reported LCG may have a remaining time less than the configured threshold for DSR. The WTRU may consider other (e.g., additional) conditions, such as whether (e.g., all of) the buffered data reported part of the DSR is the same as the one to be reported in the BSR, or visa-versa, which may indicate whether (e.g., all) the buffered data for a reported LCG has a remaining time less than the configured threshold for DSR. In some examples, the WTRU may cancel BSR if DSR was reported for (e.g., all) LCGs with data units of remaining time less than the configured threshold. In some examples, the BSR may include (e.g., only) the delta buffer size in relation to what was reported in the DSR, or visa=versa. In some examples (e.g., if BSR was reported), the WTRU may cancel DSR if BS for LCGs that triggered the DSR has been reported in the BSR or if (e.g., all) LCGs with remaining time less than threshold has been reported in the BSR.

[0241] In some examples, the WTRU may cancel a pending SR triggered by DSR or BSR if the pending SR and / or BSR have been cancelled.

[0242] In some examples, the DSR may be used to include (e.g., only) the delta information that is not reported in a BSR. For example, a data volume may not be included in a DSR if the data volume is already reported in a BSR.

[0243] In some examples, the DSR may be used to include (e.g., only) the delta information that is not reported in another DSR. For example, a data volume that is already reported in a first DSR may not be included in a second DSR. In some examples, a second DSR may not be transmitted. In some examples, (e.g., only) the remaining time may be reported in the second DSR (e.g., the second DSR may reference the first DSR).

[0244] In some examples, a second DSR may be triggered for a data volume after a first DSR is triggered for the same data volume. While the data volume may be the same, the remaining time in the second DSR may be less than the remaining time reported in the first DSR.

[0245] Delay reporting may be provided for dependent data units. A WTRU may be configured to perform or participate in one or more operations or actions. A WTRU may receive configuration information from the NW (e.g., in a DSR), including (e.g., that indicates): a remaining time threshold (e.g., a remaining time threshold value); and / or a remaining synchronization delay threshold. A WTRU may receive, e.g., from an application, PDUs of PDU set 1 (e.g., as described herein, the WTRU may receive a first PDU set (PDU set 1) and a second PDU set (PDU set 2). A WTRU may determine the remaining time of PDU set 1 , for example, based on the arrival time of PDUs of PDU set 1 and the PSDB (e.g., discard timer as described herein) of PDU set 1 . A WTRU may determine the remaining synchronization delay of PDU set2, for example, based on the arrival time of PDU set 1 and the synchronization requirement / threshold from the application.

[0246] A WTRU may transmit a DSR with information on the remaining time and associated volume (e.g., including, as described herein, a portion of data and a buffer size) of PDU set 1 and PDU set 2, for example, if the remaining time of PDU set 1 is less than the remaining time threshold, if PDU set 2 is received before triggering the DSR, and if the remaining synchronization delay of PDU set 2 is higher than the remaining synchronization delay threshold. In some examples, the data volume of PDU set 1 and PDU set 2 may be reported in different octets (e.g., one or more of octet 2 or octet 4, as described herein) in the same DSR.

[0247] A WTRU may transmit a DSR with information on the remaining time and associated volume of PDU set 1 and / or the WTRU may transmit a DSR with information on PDU set 2 (e.g., expected remaining time of PDU set 2, expected remaining synchronization delay, expected data volume of PDU set 2), for example, if the remaining time of PDU set 1 is less than the remaining time threshold, if PDU set 2 is not received before triggering DSR, and if the remaining sync delay of PDU set 2 is less than the remaining sync delay threshold (e.g., the portion of data may be included in the DSR based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set. In some examples, the DSR may be a regular DSR or a new DSR that carries delay information for PDU sets that may not have arrived in the WTRU buffer yet. In some examples, the DSR for PDU set 1 (e.g., regular DSR) and the DSR for PDU set 2 (e.g., a regular or new DSR) may be sent in the same medium access control (MAC) control element (CE) or different MAC CEs.

[0248] An example device (e.g., WTRU) may include a processor, where the WTRU may perform (e.g., be configured to perform) one or more of the following.

[0249] Systems, methods, and instrumentalities are described herein related to delay reporting associated with multi-modal traffic. A wireless transmit / receive unit (WTRU) may be configured to perform one or more of the following. A WTRU may receive, from a network node, configuration information that indicates a remaining time threshold value. The WTRU may receive, from an application, a first protocol data unit (PDU) set and a second PDU set. The WTRU may determine a remaining time value for the first PDU set and a remaining time value for the second PDU set. The WTRU may determine that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than a remaining time threshold value. Based on the determination that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value, the WTRU may determine a portion of data and a buffer size of the portion of data. The portion of data (e.g., information associated with the portion of data) may be included in a delay statusreport (DSR) based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set. The WTRU may transmit an indication, in the DSR, information that indicates the buffer size (e.g., of the portion of data) and one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set.

[0250] The first PDU set may be associated with a first data flow and the second PDU set is associated with a second data flow. The remaining time value for the first PDU set may be based on an arrival time associated with the first PDU set and a discard timer value associated with the first PDU set. The remaining time value for the second PDU set may be based on an arrival time associated with the second PDU set and a discard timer value associated with the second PDU set.

[0251] The buffer size may be based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set being below the remaining time threshold value. The portion of data may include a first portion of data and a second portion of data. The first portion of data may be grouped based on a first remaining time (e.g., the remaining time value for the first PDU set). The second portion of data may be grouped based on a second remaining time (e.g., the remaining time value for the second PDU set). The indication may indicate a respective buffer size for a respective portion of data and a respective remaining time value associated with the respective portion of data.

[0252] The WTRU may include the first PDU set in a first octet and the second PDU set in a second octet. The first octet may be associated with a first remaining time threshold value, and the second octet may be associated with a second remaining time threshold value. The WTRU may include the first octet and the second octet in the DSR.

[0253] A WTRU may receive configuration information associated with delay status report. The configuration information may indicate a remaining time threshold and / or a remaining synchronization delay threshold. The configuration information may be received from a network (NW) (e.g., from a network entity, such as a base station).

[0254] The WTRU may determine that a remaining time associated with PDU set 1 (e.g., a first PDU set) is less than the remaining time threshold. The WTRU may send one or more DSRs based on the remaining time associated with PDU set 1 being less than the remaining time threshold and one or more other conditions. The one or more other conditions may comprise whether PDU set 2 (e.g., a second PDU set which may have some association and / or dependencies with PDU set 1) is received before a DSR (e.g., with information on PDU set 1) is triggered (e.g., whereby the triggering condition may be whether the remaining time of PDU set 1 is less than the remaining time threshold for example) and whether the remaining synchronization delay associated with PDU set 2 is lower or higher than the remaining synchronization delay threshold.

[0255] In examples, PDU set 2 is received before a DSR is triggered and the remaining synchronization delay associated with the second PDU set is higher than the remaining synchronization delay threshold. In such a case, the WTRU may send a DSR with information about PDU set 1 and PDU set 2. The DSR may indicate a first remaining time associated with PDU set 1 , a first volume associated with PDU set 1 , a second remaining time associated with PDU set 2, and a second volume associated with PDU set 2. The first volume associated with PDU set 1 may be indicated in a first octet of the DSR and the second volume associated with PDU set 2 may be indicated in a second octet of the DSR.

[0256] In examples, PDU set 2 is not received before the DSR is triggered and the remaining synchronization delay associated with PDU set 2 is lower than the remaining synchronization delay threshold. In such a case, the WTRU may send a first DSR and a second DSR. The first DSR may indicate a first remaining time associated with PDU set 1 and a first volume associated with PDU set 1 . The first DSR may not indicate information associated with PDU set 2. The WTRU may send a second DSR, wherein the second DSR indicates a second remaining time associated with PDU set 2, and a second volume associated with PDU set 2.

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

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

[0259] 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 (transmitted over wired and / or wireless connections) and / or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM disks, and / or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

CLAIMSWhat Is Claimed Is:1 . A wireless transmit / receive unit (WTRU) comprising: a processor configured to: receive, from a network node, configuration information that indicates a remaining time threshold value; receive, from an application, a first protocol data unit (PDU) set and a second PDU set; determine a remaining time value for the first PDU set and a remaining time value for the second PDU set; determine that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value; based on the determination that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value, determine a portion of data and a buffer size of the portion of data, wherein information associated with the determined portion of data is included in a delay status report (DSR) based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set; and transmit an indication, in the DSR, that indicates the buffer size of the portion of data and one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set.

2. The WTRU of claim 1 , wherein the indication indicates a respective buffer size for a respective portion of data and a respective remaining time value associated with the respective portion of data.

3. The WTRU of claim 1 , wherein the first PDU set is associated with a first data flow and the second PDU set is associated with a second data flow.

4. The WTRU of claim 1 , wherein the remaining time value for the first PDU set is based on an arrival time associated with the first PDU set and a discard timer value associated with the first PDU set, and wherein the remaining time value for the second PDU set is based on an arrival time associated with the second PDU set and a discard timer value associated with the second PDU set.

5. The WTRU of claim 1 , wherein the buffer size is based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set being below the remaining time threshold value.

6. The WTRU of claim 1 , wherein the portion of data comprises a first portion of data and a second portion of data, and wherein the first portion of data is grouped based on a first remaining time value, and wherein the second portion of data is grouped based on a second remaining time value.

7. The WTRU of claim 6, wherein the first remaining time value is the remaining time value for the first PDU set, and wherein the second remaining time value is the remaining time value for the second PDU set.

8. The WTRU of claim 1 , wherein the processor is further configured to: include the first PDU set in a first octet and the second PDU set in a second octet, wherein the first octet is associated with a first remaining time threshold value and the second octet is associated with a second remaining time threshold value; and include the first octet and the second octet in the DSR.

9. A method for a wireless transmit / receive unit (WTRU), the method comprising: receiving, from a network node, configuration information that indicates a remaining time threshold value; receiving, from an application, a first protocol data unit (PDU) set and a second PDU set; determining a remaining time value for the first PDU set and a remaining time value for the second PDU set; determining that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value; based on the determination that one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set is less than the remaining time threshold value, determining a portion of data and a buffer size of the portion of data, wherein information associated with the determined portion of data is included in a delay status report (DSR) based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set; and transmitting an indication, in the DSR, that indicates the buffer size of the portion of data and one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set.

10. The method of claim 9, wherein the first PDU set is associated with a first data flow and the second PDU set is associated with a second data flow.11 . The method of claim 9, wherein the remaining time value for the first PDU set is based on an arrival time associated with the first PDU set and a discard timer value associated with the first PDU set, and wherein the remaining time value for the second PDU set is based on an arrival time associated with the second PDU set and a discard timer value associated with the second PDU set.

12. The method of claim 9, wherein the buffer size is based on one or more of the remaining time value for the first PDU set or the remaining time value for the second PDU set being below the remaining time threshold value.

13. The method of claim 9, wherein the portion of data comprises a first portion of data and a second portion of data, and wherein the first portion of data is grouped based on a first remaining time value, and wherein the second portion of data is grouped based on a second remaining time value.

14. The method of claim 13, wherein the first remaining time value is the remaining time value for the first PDU set, and wherein the second remaining time value is the remaining time value for the second PDU set.

15. The method of claim 9, wherein the method further comprises: including the first PDU set in a first octet and the second PDU set in a second octet, wherein the first octet is associated with a first remaining time threshold value and the second octet is associated with a second remaining time threshold value; and including the first octet and the second octet in the DSR.

Images