Burst traffic handling

Abstract

Burst traffic may be communicated e.g., for extended reality (XR) data communications. A wireless transmit / receive unit (WTRU) may be configured to perform (or perform) one or more of the following. The WTRU may receive configuration information from a network. The configuration information may indicate a burst traffic condition. The WTRU may receive an indication of burst traffic. The WTRU may determine a parameter associated with the burst traffic. The WTRU may determine that the burst traffic condition is satisfied based on the parameter. The WTRU may, based on the determination that the burst traffic condition is satisfied, send burst traffic information to the network associated with the burst traffic.

Description

BURST TRAFFIC HANDLINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The application claims priority to U.S. Application No. 63 / 679,274 filed August 5, 2024, the contents of which are incorporated by reference in their entirety.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] Disclosed herein are systems, methods, and instrumentalities that may be associated with the use of burst traffic handling, e.g., for extended reality (XR) data communications. A wireless transmit / receive unit (WTRU) may be configured to perform (or perform) one or more of the following.

[0004] The WTRU may receive configuration information from a network. The configuration information may indicate a burst traffic condition. The WTRU may receive an indication of burst traffic. The WTRU may determine a parameter associated with the burst traffic. The WTRU may determine that the burst traffic condition is satisfied based on the parameter. The WTRU may, based on the determination that the burst traffic condition is satisfied, send burst traffic information to the network associated with the burst traffic.

[0005] In examples, the burst traffic condition may be a burst traffic latency threshold. The determination that the burst traffic condition is satisfied may include a determination that a latency indicated by the parameter satisfies the burst traffic latency threshold.

[0006] In examples, the burst traffic condition may be a burst traffic volume threshold. The determination that the burst traffic condition is satisfied may include a determination that a burst traffic amount indicated by the parameter satisfies the burst traffic volume threshold.

[0007] In examples, the burst traffic condition is a configured resource threshold. The determination that the burst traffic condition is satisfied may include a determination that a difference between an amount of a required resource and a scheduled resource indicated by the parameter satisfies the configured resource threshold.

[0008] In examples, the burst traffic condition may be a configured quality threshold. The determination that the burst traffic condition is satisfied may include a determination that a difference between an actual quality of service and a reported quality of service indicated by the parameter satisfies the configured quality threshold.

[0009] In examples, the burst traffic information may indicate at least one of an amount associated with the burst traffic, an error bound associated with the burst traffic, or a quality of service class associated with the burst traffic. In examples, the burst traffic may be an available burst traffic, a predicted burst traffic, or an updated burst traffic.

[0010] In examples, the WTRU may determine a change in the burst traffic. The WTRU may receive a transmission resource indication from the network. The transmission resource indication may indicate a transmission resource. The WTRU may send, based on the determination of the change in the burst traffic, updated burst traffic information to the network via the transmission resource.

[0011] Systems, methods, and instrumentalities are described herein that may be related to burst traffic handling, e.g., for extended reality (XR) data communications. A device may include a processor. A device may be configured to perform (or perform) one or more of the following.

[0012] The device may receive configuration information from a network indicative of conditions for device reporting of predicted burst traffic to the network. The device may determine whether burst traffic for transmission to the network satisfies the conditions in the received configuration information and may notify the network, prior to transmission of the burst traffic, based on whether the burst traffic for transmission to the network satisfies the conditions in the received configuration information. For example, the conditions for device reporting of predicted burst traffic to the network may include a latency requirement of the burst traffic being less than a configured latency threshold, an amount of burst traffic being greater than a configured volume threshold, an expected arrival time of the burst traffic being within a configured range, a difference between an amount of a required resource and a scheduled resource being larger than a configured resource threshold, a difference between an actual quality of service and a reported quality of service parameter being larger than a configured quality threshold, and / or the like. Determining whether burst traffic for transmission to the network satisfies the conditions in the received configuration information may include the device being configured to determine an indication from an application layer to report predicted burst traffic information.

[0013] The device may be further configured notify the network of burst traffic in addition to performing dynamic scheduling with buffer status reporting.BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0016] FIG. 1C 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.

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

[0018] FIG. 2 illustrates an example of a dynamic scheduling procedure according to an embodiment.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

[0029] 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 orfemtocell. 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.

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

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

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

[0033] 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 peripherals138, 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0046] 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 are 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.

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

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

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

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

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

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

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

[0054] 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 afixed 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.

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

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

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

[0058] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by aSTA, 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.

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

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

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

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

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

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

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

[0066] 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, differentnetwork 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.

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

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

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

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

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

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

[0073] Disclosed herein are systems, methods, and instrumentalities associated with the use of burst traffic handling, e.g., for extended reality (XR) data communications. A WTRU may be configured to perform (or perform) one or more of the following.

[0074] The WTRU may receive configuration information from a network. The configuration information may indicate a burst traffic condition. The WTRU may receive an indication of burst traffic. The WTRU may determine a parameter associated with the burst traffic. The WTRU may determine that the burst traffic condition is satisfied based on the parameter. The WTRU may, based on the determination that the burst traffic condition is satisfied, send burst traffic information to the network associated with the burst traffic.

[0075] In examples, the burst traffic condition may be a burst traffic latency threshold. The determination that the burst traffic condition is satisfied may include a determination that a latency indicated by the parameter satisfies the burst traffic latency threshold.

[0076] In examples, the burst traffic condition may be a burst traffic volume threshold. The determination that the burst traffic condition is satisfied may include a determination that a burst traffic amount indicated by the parameter satisfies the burst traffic volume threshold.

[0077] In examples, the burst traffic condition is a configured resource threshold. The determination that the burst traffic condition is satisfied may include a determination that a difference between an amount of a required resource and a scheduled resource indicated by the parameter satisfies the configured resource threshold.

[0078] In examples, the burst traffic condition may be a configured quality threshold. The determination that the burst traffic condition is satisfied may include a determination that a difference between an actual quality of service and a reported quality of service indicated by the parameter satisfies the configured quality threshold.

[0079] In examples, the burst traffic information may indicate at least one of an amount associated with the burst traffic, an error bound associated with the burst traffic, or a quality of service class associated with the burst traffic. In examples, the burst traffic may be an available burst traffic, a predicted burst traffic, or an updated burst traffic.

[0080] In examples, the WTRU may determine a change in the burst traffic. The WTRU may receive a transmission resource indication from the network. The transmission resource indication may indicate a transmission resource. The WTRU may send, based on the determination of the change in the burst traffic, updated burst traffic information to the network via the transmission resource.

[0081] Systems, methods, and instrumentalities are described herein related to burst traffic handling, e.g., for extended reality (XR). A wireless transmit / receive unit (WTRU)) may be configured with differentiated handling for a burst traffic. The WTRU may report burst traffic information. The WTRU may determine the message to report the burst traffic information. The WTRU may determine whether to trigger a medium access control-control element (MAC CE) or radio resource control (RRC) to report burst traffic information. The WTRU may receive an indication from the network to perform differentiated handling of the burst traffic. The WTRU may receive uplink transmission resources to transmit the burst traffic. The WTRU may perform prioritization for treatment of the burst traffic. The WTRU may assign a quality of service (QoS) class and / or QoS treatment profile to the burst traffic. The WTRU may select the transmission resources for the burst traffic. The WTRU may allocate bits to an uplink grant (e.g., logical control prioritization (LCP) procedure) considering the availability of the burst traffic. The WTRU may report the updated burst traffic information to the network (e.g., error case). The WTRU may be configured with a condition to report updated burst traffic information. The WTRU may determine the information to convey in the updated burst traffic reporting. The WTRU may determine the messages to report the updated burst traffic information.

[0082] A dynamic scheduling procedure (e.g., in 5G new radio (NR)) may involve multiple (e.g., two) rounds of signaling before uplink transmission of data in the buffer. An example of a dynamic scheduling procedure is shown in FIG. 2. As shown in FIG. 2, a MAC-CE (e.g., buffer status report (BSR)) may be triggered. There may not be an uplink grant within a latency duration. The WTRU may trigger a scheduling request (SR) to indicate to the network that the WTRU has uplink data to transmit. The WTRU may receive downlink control information (DCI) for uplink (UL) scheduling. The WTRU may (e.g., normally) receive asmall uplink grant to transmit the MAC CE (e.g., BSR), for example, because the network may not be aware of the amount of data available for uplink transmission at the WTRU. The WTRU may perform the UL transmission, which may include the MAC CE (e.g., BSR) in the scheduled grant. The WTRU may receive the UL grant via DCI for further uplink data transmission. The gNB may be (e.g., fully) aware of the amount of data in the buffer of the WTRU, allowing the gNB to schedule the uplink grants properly so that the WTRU can transmit (e.g., all) the necessary data reported in the buffer. The WTRU may transmit uplink data in one or more scheduled uplink grants.

[0083] FIG. 2 illustrates an example of a dynamic scheduling procedure.

[0084] The dynamic scheduling procedure (SR / BSR) may be inflexible. The WTRU may perform Buffer Status Reporting (BSR), for example, (e.g., only) if the data is available at the RLC buffer. The WTRU may report BSR, for example, (e.g., only) if data with higher priority is available at the WTRU’s buffer. Even as an excessive amount of data in the same DRB arrives at the buffer, BSR reporting may not be triggered. As a consequence, the gNB may not aware of the updated buffer situation at the WTRU. The WTRU may be unable to timely provide buffer information to the network for scheduling, e.g., especially in a scenario where the WTRU may transmit a large amount of data (e.g., burst data) within a short delay requirement. The multiple rounds of signaling exchanged between the WTRU and the network before the WTRU transmits the uplink data may negatively impact QoS.

[0085] For example, in an XR application, e.g., in many scenarios, it may take time for the application layer to generate data, process (e.g., encode, add header, encrypt, etc.), and forward to the access stratum (AS) layer, e.g., especially when a large amount of data may be processed. However, the application layer at the WTRU may be fully aware of the processing time and the amount of generated data. The information (e.g., known by the WTRU) may be conveyed to the radio access network (RAN). Advance awareness of an impending burst may be beneficial to the network.

[0086] In some scenarios, the application layer may be aware in advance that the WTRU may (e.g., need to) generate data to convey to the server. The application layer may process sensory information and may be aware of the triggering conditions to generate data. For example, due to change in the position, Field of View (FoV), and / or detection of an object in sensing, the application layer may be aware that the WTRU may (e.g., need to) convey the information to reflect the detected change in the environment. The application may be aware of the amount of data to be generated. The information may be beneficial for the network to (e.g., properly) schedule the WTRU.

[0087] An adaptive uplink data treatment procedure, which may include, for example, traffic reporting, data treatment, and transmission, may facilitate the WTRU in transmission of burst traffic with stringent QoS (e.g., low latency, high reliability).

[0088] A WTRU may be configured to perform (or perform) one or more of the following.

[0089] A WTRU may trigger reporting, to a network, of predicted burst traffic information. The report may include (e.g., indicate to the network) the amount and / or expected arrival time of the burst traffic, for example, if (e.g., when) a configured reporting condition is satisfied. The WTRU may (e.g., further) report updated burst traffic information to the network, for example, if arrived burst traffic satisfies an updated reporting condition.

[0090] A WTRU may receive a configuration (e.g., configuration information) from the network with the condition(s) to report (e.g., predicted) burst traffic information (e.g., the WTRU may send a report associated with the predicted burst traffic information if the condition(s) are satisfied). The configuration may include other condition(s) to report updated burst traffic information (e.g., the WTRU may report updated burst traffic information if the other condition(s) are satisfied).

[0091] The condition(s) to report burst traffic information may include, for example, one or more of the following: the latency requirement of the burst traffic is smaller than a configured threshold; the amount of predicted burst traffic is greater than a configured threshold; and / or the expected arrival time of the predicted burst traffic is within a configured range.

[0092] The condition(s) to report updated burst traffic information may include, for example, one or more of the following: the difference between the amount of the required resource(s) and the scheduled resource(s) is larger than a configured threshold; and / or the difference between an actual and a reported QoS parameter is larger than a configured threshold.

[0093] The WTRU may receive an indication (e.g., from the application layer) to report a predicted and / or expected burst traffic information. The WTRU may report the burst traffic to the network, for example, if the configured burst traffic reporting condition(s) is satisfied. The burst traffic reporting information may include, for example, one or more of the following: the expected amount of the burst traffic, the error bound of the burst traffic, and / or the associated QoS class; the expected arrival time and / or error bound; and / or an indication about an upcoming burst arrival from one or more configured data flows. The WTRU may receive one or more resources from the network (e.g., an indication of one or more resources) to perform uplink transmissions (e.g., for the reported burst traffic). The WTRU may report updated burst traffic information to the network, for example, if the configured reporting condition for updated burst traffic is satisfied. The updated burst traffic reporting information may include, for example, the number and / or set(s) of unused resources and / or the amount of additional resource(s) to transmit the burst traffic.

[0094] Burst traffic handling as described herein, in some examples, may provide one or more of the following. For example, burst traffic handling may enable the WTRU to provide the network with advance notice of the arrival of burst traffic with stringent QoS requirements (e.g., low latency, high reliability), whichmay help the network perform early scheduling of the transmission resources to meet the QoS requirement of the burst traffic. For example, burst traffic handling may provide a mechanism to update the reported burst traffic information, which may enable the network to efficiently utilize the scheduling resources to support (e.g., guarantee) the QoS of burst traffic with stringent QoS requirements.

[0095] The WTRU may be configured with information, with a functional capability, and / or the like. Such configuration may be preconfigured. For example, the WTRU may receive a configuration from the network. The WTRU may receive a network configuration, for example, via a system information block (SIB), a dedicated RRC message, a MAC CE, and / or downlink control information (DCI). For example, the WTRU being configured with a threshold may be equivalent to the WTRU being preconfigured with the threshold (e.g., where the WTRU may store the configuration) or the WTRU receiving the threshold (e.g., from the network, such as via SIB, RRC, MAC CE, and / or DCI).

[0096] A WTRU may generate and / or communicate (e.g., transmit and / or receive) burst traffic. A data burst may refer to the data produced by an application (e.g., executed by the WTRU) in a short period of time, comprising packet data units (PDUs) from one or more PDU Sets. The attributes, associations, and / or inter-dependencies (e.g., intra-PDU set and / or inter-PDU set), for example, including the start and / or end indication of a PDU set and / or data burst (e.g., via sequence number, start / end indication, or timestamp), start and / or end time, duration, payload sizes, periodicity, importance and / or priority, and / or QoS (e.g., PDU set delay budget (PSDB)), may be visible to the RAN layers (e.g., with associated IDs) and / or may be handled at the RAN layers with the awareness of the association during data transmission in uplink (UL) and reception in downlink (DL). As described herein, data (e.g., all data) from the WTRU may be considered as a burst traffic with a different type of burst. For example, the burst traffic may have small, medium, and / or high volume. The burst traffic may be associated with different types of data, etc.

[0097] A burst of data may be identified by, for example, at least one of the following: a number of PDUs; a data volume; time; and / or data rate.

[0098] A burst of data may be identified by a number of PDUs. For example, a burst may include one or a plurality of data units (e.g., Internet protocol (IP) packets, L3 and / or RRC signalling, sensing data, artificial intelligence (Al) and / or machine learning (ML) data, and / or system data).

[0099] A burst of data may be identified by data volume. For example, a burst may correspond to an amount of data (e.g., in octet(s)). A burst may be quantized and / or categorized, for example, by (e.g., several) configured data volume ranges. For example, burst type 1 may correspond to data volume 0 to x; burst type 2 may correspond to data volume x to 2x (or y), etc.

[0100] A burst of data may be identified by time and / or rate. For example, a burst may correspond to a period (e.g., in time domain), which may correspond to the burst’s transmission delay and / or latencyrequirement for the associated volume and / or PDUs. A burst may be categorized by the latency bound associated with the data.

[0101] A WTRU may report a burst using a characterization (e.g., any characterization), which may include, for example, a combination of the associated number of PDUs, data volume, and / or latency requirement, e.g., including if (e.g., when) reported as one or more of the following: rate and period, volume and period, number of PDUs (e.g., assuming average size), as data volume (e.g., assuming a fixed latency requirement), and / or the like.

[0102] In examples, a device may include a processor configured to receive configuration information from a network indicative of conditions for device reporting of predicted burst traffic to the network. The processor may determine whether burst traffic for transmission to the network satisfies the conditions in the received configuration information and may notify the network, prior to transmission of the burst traffic, based on whether the burst traffic for transmission to the network satisfies the conditions in the received configuration information. For example, the conditions for device reporting of predicted burst traffic to the network may include a latency requirement of the burst traffic being less than a configured latency threshold, an amount of burst traffic being greater than a configured volume threshold, an expected arrival time of the burst traffic being within a configured range, a difference between an amount of a required resource and a scheduled resource being larger than a configured resource threshold, a difference between an actual quality of service and a reported quality of service parameter being larger than a configured quality threshold, and / or the like. Determining whether burst traffic for transmission to the network satisfies the conditions in the received configuration information may include the processor being configured to determine an indication (e.g., from an application layer) to report predicted burst traffic information.

[0103] The processor may be further configured to notify the network of burst traffic in addition to performing dynamic scheduling with buffer status reporting.

[0104] Burst traffic and burst data may be used interchangeably herein.

[0105] Quality of service (QoS) and / or quality of experience (QoE) may be associated with a burst traffic. QoS and / or QoE associated with a burst traffic may be used to indicate and / or describe, for example, one or more of the following: one or more parameters (e.g., QoS and / or QoE parameters) of a PDU associated with the burst traffic; one or more parameters of a PDU Set (e.g., QoS and / or QoE parameters) associated with the burst traffic; one or more parameters of the burst traffic; and / or one or more redundancy parameters (e.g., Application Layer Forward Error Correction ratio (AL-FEC ratio) associated with the burst traffic.

[0106] QoS and / or QoE associated with a burst traffic may be used to indicate and / or describe one or more parameters (e.g., QoS and / or QoE parameters) of a PDU associated with the burst traffic. The parameters of a PDU may include, for example, one or more of the following: PDU Importance; priority associated with the PDU; latency requirement of the PDU and / or PDU-segment; synchronization window; remaining synchronization window and / or the remaining time to serve (e.g., to transmit and / or receive) the PDU; reliability requirement of the PDU (e.g., Packet Error Rate (PER)); maximum Data Burst Volume (MDBV); traffic type of PDU and / or PDU-segment (e.g., periodic vs. aperiodic); periodicity of the PDU and / or PDU-segment; and / or size of the PDU and / or PDU-segment.

[0107] The parameter(s) of a PDU may include PDU Importance, which may be used to indicate the Importance of the PDU set associated with the PDU, the relative Importance of the PDU in the PDU set, the relative Importance of the PDU in a Data Burst, and / or the relative Importance of the PDU in the QoS flow.

[0108] The parameter(s) of a PDU may include the priority associated with the PDU.

[0109] The parameter(s) of a PDU may include the latency requirement of the PDU and / or PDU- segment, which may include, for example, one or more of the following: a packet delay budget (PDB); and / or a remaining PDB.

[0110] The parameter(s) of a PDU may include the synchronization window, which may be used to describe the synchronization requirement between two or more interdependent PDUs. One more PDUs may be associated with the burst traffic. One or more interdependent PDUs may or may not be associated with the burst traffic. For example (e.g., to satisfy the QoE requirement of an XR service), the WTRU may (e.g., may need to) deliver (e.g., two) interdependent PDUs within the synchronization window. Based on transmission and / or reception of the first PDU, the WTRU may (e.g., may need to) transmit and / or receive the second inter-dependent PDU within the synchronization window. The second PDU may be associated with the considered burst traffic. The first PDU may or may not be associated with the first burst traffic.

[0111] The parameter(s) of a PDU may include the remaining synchronization window and / or the remaining time to serve (e.g., to transmit and / or receive) the PDU, which may be used to describe the remaining time to serve a second PDU upon transmission and / or reception of a first inter-dependent PDU (e.g., due to a synchronization requirement between the PDU and another inter-dependent PDU). For example, the WTRU may transmit and / or receive the first PDU. The WTRU may (e.g., need to) transmit and / or receive another inter-dependent PDU. The WTRU may (e.g., then) initialize a timer (e.g., sync- Timer) to track the synchronization between the (e.g., two) PDUs. The current value of a timer (e.g., sync- Timer) may be used to indicate the remaining synchronization window and / or the remaining time to transmit and / or receive the PDU.

[0112] The parameter(s) of a PDU may include the reliability requirement of the PDU (e.g., Packet Error Rate (PER)).

[0113] The parameter(s) of a PDU may include the maximum Data Burst Volume (MDBV).

[0114] The parameter(s) of a PDU may include the traffic type of PDU and / or PDU-segment (e.g., periodic vs. aperiodic).

[0115] The parameter(s) of a PDU may include the periodicity of the PDU and / or PDU-segment.

[0116] The parameter(s) of a PDU may include the size of the PDU and / or PDU-segment.

[0117] QoS and / or QoE associated with a burst traffic may be used to indicate and / or describe one or more parameters of a PDU Set (e.g., QoS and / or QoE parameters) associated with the burst traffic. The parameters of a PDU set may include, for example, one or more of the following: PDU Set Importance (e.g., PSI); PDU set Priority; synchronization window; remaining synchronization window and / or the remaining time to serve (e.g., to transmit and / or receive) the PDU set; latency requirement associated with the PDU set; PDU Set Integrated Handling Indication (PSIHI); type of the PDU set; reliability requirement of a PDU Set, such as PDU Set Error Rate (PSER); volume of the PDU set; Type of PDU set (e.g., periodic vs. aperiodic); and / or periodicity of the PDU set.

[0118] The parameter(s) of a PDU set may include PDU Set Importance (e.g., PSI), which may be used to indicate the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0119] The parameter(s) of a PDU set may include PDU set Priority.

[0120] The parameter(s) of a PDU set may include the synchronization window, which may be used to describe the synchronization requirement between two or more inter-dependent PDU sets or the synchronization requirement between one PDU set and one or more other PDUs. For example, e.g., to satisfy the QoE requirement of an XR service, the WTRU may (e.g., need to) deliver (e.g., two) interdependent PDU sets within the synchronization window. Upon transmission and / or reception of the first PDU set, the WTRU may (e.g., need to) transmit and / or receive the second inter-dependent PDU set within the synchronization window.

[0121] The parameter(s) of a PDU set may include the remaining synchronization window and / or the remaining time to serve (e.g., to transmit and / or receive) the PDU set, which may be used to describe the remaining time to serve a second PDU set upon transmission and / or reception of a first inter-dependent PDU set (e.g., due to a synchronization requirement between the PDU set and another inter-dependent PDU set). For example, the WTRU may transmit and / or receive the first PDU set. The WTRU may (e.g., need to) transmit and / or receive another inter-dependent PDU set. The WTRU may (e.g., then) initialize a timer (e.g., syncTimer) to track the synchronization between the (e.g., two) PDU sets. The current value oftimer (e.g., syncTimer) may be used to indicate the remaining synchronization window and / or the remaining time to transmit and / or receive the second PDU set.

[0122] The parameters of a PDU set may include a latency requirement associated with the PDU set, which may include, for example, one or more of the following: PDU Set Delay Budget (PSDB); remaining PSDB; nominal PSDB associated with the PDU set; and / or PDU Set Delivery Deadline (PSDD). PDU Set Delay Budget (PSDB) may be used to indicate the maximum time between reception of the first PDU (e.g., at the UPF in DL, at the WTRU in UL) and the successful delivery of the last arrived PDU of a PDU Set (e.g., at the WTRU in DL, at the user plane function (UPF) in UL). PSDB may be an optional parameter. PSDB (e.g., when provided) may supersede the PDB. The PDU Set Delivery Deadline (PSDD) may be the absolute deadline, e.g., where the last PDU of a PDU set may (need to) be received at the application so that the application can make use of the PDU set.

[0123] The parameter(s) of a PDU set may include the PDU Set Integrated Handling Indication (PSI HI), which may indicate whether (e.g., all) PDUs of the PDU Set are needed for usage of the PDU Set by the application layer.

[0124] The parameter(s) of a PDU set may include the type of the PDU set, which may include, for example, one or more of the following: a first type of PDU set, which may require reliable delivery of all PDUs in the set; a second type of PDU set, in which the transmission of a PDU set may be unsuccessful if (e.g., when) at least one (e.g., specific) PDU fails transmission; and / or a third type of PDU set, in which the transmission of a PDU set may be successful if (e.g., when) X PDUs of the PDU set of Y PDUs may be received. The third type of PDU set may be indicated, for example, if (e.g., when) Forward Error Correction (FEC) is used and / or if (e.g., when) additional layered encoding is used and assigned to the same PDU set.

[0125] The parameter(s) of a PDU set may include the reliability requirement of a PDU Set, such as PDU Set Error Rate (PSER), which may be used to indicate, for example, one or any combination of the following: an upper bound for the rate of PDU Sets that may have been processed by the sender of a link layer protocol (e.g., RLC in RAN of a 3GPP access) but that may not be successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP in RAN of a 3GPP access); an upper bound for the rate of PDUs per PDU set that may have been processed by the sender of a link layer protocol (e.g., RLC in RAN of a 3GPP access) but that may not be successfully delivered by the corresponding receiver to the upper layer (e.g., PDCP in RAN of a 3GPP access); and / or an upper bound for the rate of PDUs per PDU set that may not be successfully received by the receiver of the upper layer (e.g., PDCP in RAN of a 3GPP access).

[0126] The parameter(s) of a PDU set may include the volume of the PDU set, which may include, for example, one or more of the following: the size of each PDU; and / or the number of PDUs in the PDU set.

[0127] The parameter(s) of a PDU set may include the Type of PDU set (e.g., periodic vs. aperiodic).

[0128] The parameter(s) of a PDU set may include the periodicity of the PDU set.

[0129] QoS and / or QoE associated with a burst traffic may be used to indicate and / or describe one or more parameters of the burst traffic, which may include the volume of the Data Burst. The volume of the data burst may include, for example, one or more of the following: the size of each PDU in the Data Burst; the number of PDU sets in the Data Burst; and / or the volume of each PDU set in the Data Burst.

[0130] QoS and / or QoE associated with a burst traffic may be used to indicate and / or describe one or more redundancy parameters (e.g., Application Layer Forward Error Correction ratio (AL-FEC ratio) associated with the burst traffic, which may be used to indicate the number of required PDUs to decode the PDU set. In some examples, a burst data may be a PDU set, in which the receiver may (e.g., need to) successfully receive at least K out of N PDUs in the PDU set to successfully decode the PDU set (e.g., successfully decode a video frame at the Application layer). K or the ratio between K and N (e.g., K and / or N) may be used as one of the QoS and / or QoE parameters for the PDU set to represent the redundancy parameter for the PDU set. In some examples, a burst data may be a PDU set, which may include multiple subsets of the PDU set. The WTRU may (e.g., be required to) successfully transmit a ratio or a certain number of PDUs of each subset of the PDU set to satisfy a (e.g., certain) QoS and / or QoE requirement. The ratio of each PDU may be used as one or more QoS and / or QoE parameters for the PDU set to represent the redundancy parameters for the PDU set.

[0131] “Network” may be used to describe the base station serving the WTRU, which may include, for example, one or more of the following: a gNB, a 6G gNB, a transmission and / or reception point (TRP), a network entity such as a location management function (LMF), a coordinator device (e.g., a relay WTRU, another WTRU, a group coordinator), etc.

[0132] A WTRU may (e.g., be configured to) perform differentiated handling for burst traffic.

[0133] A WTRU may be configured with differentiated handling for a burst traffic. In some examples, the WTRU may have burst traffic available or predicted and / or expected to be available at a buffer. The WTRU may perform differentiated handling for the burst traffic, which may include, for example, one or more of the following procedures: reporting the burst traffic information to the network; and / or performing (e.g., exclusive) treatment for the burst traffic. The WTRU may perform treatment (e.g., exclusive treatment) for the whole burst traffic, part of the burst traffic, and / or selected (e.g., certain) data in the burst traffic, for example, to satisfy a configured condition (e.g., the data associated with one configured type of data, and / or the data with a QoS and / or QoE parameter being higher or lower than a configured threshold). The treatment (e.g., exclusive treatment) for the burst traffic may include, for example, one or more of the following procedures: performing prioritization for treatment of the burst traffic; assigning QoS class and / orQoS treatment profile to the burst traffic; selecting the transmission resources for the burst traffic; and / or allocating bits to an uplink grant (e.g., logical channel prioritization (LCP) procedure) considering the availability of the burst traffic.

[0134] The WTRU may receive a configuration from the network with one or more condition(s) to perform differentiated handling for a burst traffic. The WTRU may satisfy the configured condition(s). The WTRU may (e.g., then) perform differentiated handling for the burst traffic. The WTRU may be configured with a set of one or more conditions for each possible differentiated handling for a burst traffic. For example, the WTRU may be configured with a set of one or more conditions to report the burst traffic information to the network. For example, the WTRU may be configured with another set of one or more conditions to perform prioritization for treatment of a burst traffic.

[0135] The condition(s) to perform differentiated handling for the burst traffic (e.g., reporting the burst traffic information to the network, performing prioritization for treatment of the burst traffic, assigning QoS class and / or QoS treatment profile to the burst traffic, selecting the transmission resources for the burst traffic, and / or allocating bits to an uplink grant (e.g., LCP procedure) considering the availability of the burst traffic) may be based on, for example, one or more of the following: one or more QoS and / or QoE parameters associated with the burst traffic; the type of data associated with the burst traffic; the QoS class and / or the QoS treatment profile associated with the burst traffic; the amount of data associated with the burst traffic; the amount of resource requested and / or required for the burst traffic; the type of already available resources; the data rate associated with the burst traffic; the burst traffic arrival information; reception of an indication from the network; whether the anticipated data belongs to one or more configured data flows; indication from higher layer (e.g., application layer); the arrival of another dependent flow and / or successful transmission of a dependent flow; an indication from another node (e.g., a wearable device); and / or a configured time duration has elapsed.

[0136] The condition(s) to perform differentiated handling for the burst traffic may be based on one or more QoS and / or QoE parameters associated with the burst traffic. The WTRU may be configured with a threshold for a QoS parameter (e.g., priority, latency, reliability, PSDB, PSDD, PSI). The WTRU may perform differentiated handling for the burst traffic, for example, if the QoS parameter associated with the burst traffic is higher or lower than the configured threshold.

[0137] In some examples, the WTRU may be configured with a priority threshold. The WTRU may (e.g., then) perform differentiated handling for the burst traffic, for example, if the burst traffic has priority higher or lower than the configured threshold. For example, the WTRU may report the burst traffic information if the burst traffic has priority higher or lower than the configured priority threshold. For example, the WTRUmay perform treatment (e.g., exclusive treatment) for the burst traffic if the priority associated with the burst traffic is higher or lower than the configured threshold.

[0138] In some examples, the WTRU may be configured with an importance threshold. The WTRU may (e.g., then) report the burst traffic information, for example, if the burst traffic has importance higher or lower than the configured threshold.

[0139] In some examples, the WTRU may be configured with a delay threshold. The WTRU may (e.g., then) perform differentiated handling for the burst traffic, for example, if the delay associated with the burst traffic is smaller or larger than the configured threshold.

[0140] The condition(s) to perform differentiated handling for the burst traffic may be based on the type of data associated with the burst traffic. The WTRU may be configured with a (e.g., one) type of data to trigger differentiated handling for the burst traffic. The WTRU (e.g., then) perform differentiated handling for the burst traffic, for example, if the burst traffic includes the configured type of data. Otherwise, the WTRU may perform other (e.g., default) handling for the burst traffic. The data type may include, for example, one or more of the following: system data, control data, data from a configured data flow, dependent data on another data flow, sensory data, and / or intelligence collection data (e.g., from an artificial intelligence (Al) and / or machine learning (ML) process).

[0141] The condition(s) to perform differentiated handling for the burst traffic may be based on the QoS class and / or the QoS treatment profile associated with the burst traffic. For example, the WTRU may be configured with one or more QoS class and / or QoS treatment profiles allowing differentiated handling. The WTRU may (e.g., then) perform differentiated handling for the burst traffic, for example, if the burst traffic is associated with the QoS class and / or QoS treatment profile allowing differentiated handling.

[0142] The condition(s) to perform differentiated handling for the burst traffic may be based on the amount of data associated with the burst traffic. The WTRU may perform differentiated handling for the burst traffic, for example, if the amount of the burst traffic is larger or smaller than a configured threshold. The WTRU may be (e.g., further) configured with (e.g., additional) thresholds, such as the amount of burst traffic associated with a certain QoS classes, QoS treatment profiles, and / or QoS parameter. The WTRU may (e.g., then) trigger differentiated handling for the burst traffic, for example, if the amount of burst traffic associated with the configured QoS classes, QoS treatment profiles, and / or QoS parameter is larger or smaller than the configured threshold. For example, the WTRU may apply a first differentiated handling for the burst traffic if the data volume falls within a first configured data volume range. The WTRU may apply a second differentiated handling for the burst traffic, for example, if the data volume falls within a second range.

[0143] The condition(s) to perform differentiated handling for the burst traffic may be based on the amount of resource requested and / or required for the burst traffic. The WTRU may trigger differentiated handling for the burst traffic, for example, if the amount of requested and / or required resource (e.g., the bandwidth of the request resource and / or the number of transmission resources) is larger or smaller than a configured threshold.

[0144] The condition(s) to perform differentiated handling for the burst traffic may be based on the type of already available resources. For example, the WTRU may trigger a differentiated handling for the burst traffic if available uplink resources are not suitable to meet the QoS requirement for the expected data (based on reliability level, latency etc.).

[0145] The condition(s) to perform differentiated handling for the burst traffic may be based on the data rate associated with the burst traffic. The WTRU may trigger differentiated handling for the burst traffic, for example, if the preferred and / or expected data rate associated with the burst traffic is higher or lower than a configured threshold. For example, the WTRU may trigger reporting the burst traffic information to the network if a preferred and / or expected data rate associated with the burst traffic is higher or lower than a configured threshold.

[0146] The condition(s) to perform differentiated handling for the burst traffic may be based on the burst traffic arrival information. The WTRU may be configured with a traffic arrival time threshold to perform differentiated handling for a burst traffic. The WTRU may (e.g., then) perform differentiated handling for the burst traffic, for example, if the arrival time of the burst traffic is later or sooner than the configured arrival time threshold. In some examples, the WTRU may perform treatment (e.g., exclusive treatment) for the burst traffic if the burst traffic arrives after a configured arrival time threshold, which may accelerate transmission of the late arrival burst traffic. In some examples, the WTRU may report the burst traffic information to the network regrading a predictive burst traffic if the predicted arrival time of the burst traffic is within a configured range. The WTRU may report the burst traffic information to the network, for example, if the predictive earliest, latest, and / or expected arrival time of the traffic is later than a configured arrival time threshold and / or sooner than another configured arrival time threshold. The arrival time of a burst traffic may be described as the gap between the burst traffic information reporting time to the earliest, latest, and / or expected arrival time of the burst traffic.

[0147] The condition(s) to perform differentiated handling for the burst traffic may be based on reception of an indication from the network. For example, the WTRU may receive an implicit and / or explicit indication from the network to perform treatment (e.g., exclusive treatment) for a burst traffic. The WTRU (e.g., upon reception of the indication from the network) may (e.g., then) perform the treatment (e.g., exclusive treatment) for the burst traffic.

[0148] The condition(s) to perform differentiated handling for the burst traffic may be based on whether the anticipated data belongs to one or more configured data flows.

[0149] The condition(s) to perform differentiated handling for the burst traffic may be based on an indication from a higher layer (e.g., application layer). The WTRU may have an application to RAN interface (App API) residing within the application to indicate one or more events to the RAN. An event may be used to indicate an expected arrival of a burst traffic. The WTRU (e.g., upon reception from the app API) may (e.g., then) report the burst traffic information to the network. The burst traffic information reporting may be triggered, for example, based on one or more of the following: the WTRU detects a change in its position; the WTRU detects one or more object (e.g., due to sensing); and / or a sensing event has occurred.

[0150] Burst traffic information reporting may be triggered based on detection of a change in WTRU position. For example, the WTRU may detect a change in its position. The WTRU may (e.g., need to) convey the position and sensing information to the network. The WTRU may (e.g., then) trigger burst traffic reporting to the network.

[0151] Burst traffic information reporting may be triggered based on detection of one or more objects, e.g., due to sensing.

[0152] Burst traffic information reporting may be triggered based on the occurrence of a sensing event. For example, the WTRU may trigger burst traffic reporting if the WTRU detects one or more sensing events, such as a detection of one or more sensing objects, detection of a change in WTRU environment (e.g., Field of View (FoV)), etc.

[0153] The condition(s) to perform differentiated handling for the burst traffic may be based on the arrival of a (e.g., another) dependent flow and / or successful transmission of a dependent flow. For example, the WTRU may be configured with (e.g., two) dependent RAN flows. The (e.g., two) flows may be (e.g., required to be) synchronous within a synchronization window. The WTRU (e.g., upon the arrival and / or departure of a dependent flow) may trigger performing burst traffic information reporting to the network to indicate a predicted and / or expected arrival of a burst traffic. The WTRU may (e.g., then) indicate a latency requirement of the predicted and / or expected burst traffic as a function of, for example, a synchronization requirement between the (e.g., two) flows.

[0154] The condition(s) to perform differentiated handling for the burst traffic may be based on an indication from another node (e.g., a wearable device). For example, the WTRU may receive an information regarding uplink traffic, which may be originated from a wearable device. The WTRU may (e.g., then) report the burst traffic information to the network, for example, if the generated traffic from the wearable device satisfied the burst traffic reporting condition(s).

[0155] The condition(s) to perform differentiated handling for the burst traffic may be based on a configured time duration has elapsed. The WTRU may trigger performing a burst traffic information reporting to the network, for example, if a configured time duration from the previous burst traffic reporting has elapsed. For example, the WTRU may be configured with a prohibit timer, which may be used to control the frequency of burst traffic information reporting. The WTRU may report the burst traffic information, for example, if the prohibit timer has expired or is not running, the WTRU may not report the burst traffic information, for example, if the prohibit timer is running. The WTRU may (re)start the prohibit timer, for example, after a (e.g., each) burst traffic information reporting.

[0156] A WTRU may report burst traffic information. In some examples, the WTRU may report burst traffic information to the network, which may help the network in scheduling transmission resources for the WTRU and / or to be aware of the burst traffic information of the WTRU. The WTRU may indicate and / or report, for example, one or any combination of the following information to the network: whether the burst traffic is available and / or predicted and / or expected to be available; the data type associated with the burst traffic; a value, range of values, and / or set of values (e.g., the minimum value, the maximum value, and / or an exact value) of one or more QoS and / or QoE parameters (e.g., priority, latency, reliability) associated with the burst traffic; the QoS class and / or the QoS treatment profile associated with the burst traffic; the amount of data associated with the burst traffic; the amount of resources requested for the burst traffic; the burst traffic arrival information; the preferred and / or expected data rate associated with the burst traffic; the periodicity associated with the burst traffic; the number of transmission periods; the data flows associated with the anticipated data arrival; and / or the delay and / or latency bound associated with the anticipated data arrival.

[0157] The WTRU may indicate and / or report to the network whether the burst traffic is available and / or predicted and / or expected to be available. In some examples, the WTRU may indicate to the network whether the WTRU has available burst traffic and / or whether the WTRU has burst traffic predicted and / or expected to be available later in the WTRU’s buffer.

[0158] In some examples, the WTRU may be configured to indicate the burst traffic information to the network if the WTRU has the burst traffic available at a buffer. The WTRU (e.g., upon the availability of the burst traffic) may (e.g., then) indicate the burst traffic information to the network.

[0159] In some examples, the WTRU may be configured to indicate the burst traffic information to the network if the burst traffic is predicted and / or expected to be available at a WTRU buffer.

[0160] In some examples, the WTRU may be configured to indicate the burst traffic information to the network for either the burst traffic at the WTRU buffer and and / or or the burst traffic predicted and / or expected to be available at the WTRU’s buffer. The WTRU may (e.g., then) indicate the burst trafficinformation to the network if the WTRU has burst traffic available and / or predicted and / or expected to be available at the WTRU’s buffer.

[0161] The WTRU may indicate and / or report to the network the data type associated with the burst traffic. The WTRU may be configured with multiple types of data (e.g., Al and / or ML, XR, sensing, and / or volumetric data). The WTRU may (e.g., then) indicate the data type associated with the burst traffic.

[0162] The WTRU may indicate and / or report to the network a value, range of values, and / or set of values (e.g., the minimum value, the maximum value, and / or an exact value) of one or more QoS and / or QoE parameters (e.g., priority, latency, and / or reliability) associated with the burst traffic. In some examples, the WTRU may report the priority associated with the burst data. The WTRU may (e.g., alternatively) report the expected set of priority (e.g., 1 -3) for a burst traffic. In some examples, the WTRU may report a latency requirement associated with the burst data. The WTRU may (e.g., alternatively) report a range of latency requirement associated with the burst data.

[0163] The WTRU may indicate and / or report to the network the QoS class and / or the QoS treatment profile associated with the burst traffic. For example, the WTRU may be configured with multiple QoS classes and / or a QoS treatment profile for a burst traffic for uplink transmission. The WTRU may (e.g., then) indicate the QoS class and / or the QoS treatment profile associated with the burst traffic. The WTRU may (e.g., alternatively) indicate the set of QoS classes and / or QoS treatment profiles associated with the burst traffic.

[0164] The WTRU may indicate and / or report to the network the amount of data associated with the burst traffic. The WTRU may indicate the predicted and / or expected burst volume associated with the burst traffic. The WTRU may (e.g., alternatively) indicate the burst volume (e.g., amount of data) in the WTRU’s buffer. The WTRU may (e.g., alternatively) indicate the available burst volume and the predicted and / or expected burst volume in the WTRU’s buffer. The WTRU may indicate the potential range of burst volume (e.g., the minimum and / or the maximum amount of data), e.g., for the predicted burst volume in the buffer. The WTRU may indicate the predicted burst volume and the error bound.

[0165] In some examples, the WTRU may indicate the amount of burst traffic and the associated QoS class and / or QoS treatment profile, in which the amount of burst traffic may be available and / or predicted and / or expected to be available at the WTRU’s buffer.

[0166] In some examples, the WTRU may have burst traffic associated with multiple QoS classes. The WTRU may report (e.g., separately) each amount of burst traffic and the associated QoS class.

[0167] In some examples, the WTRU may report a burst size type based on the data volume within a configured range or below and / or above a configured threshold.

[0168] The WTRU may indicate and / or report to the network the amount of resources requested for the burst traffic. The WTRU may indicate the amount of resources (e.g., the bandwidth of each transmission resource and / or the number of transmission resources) for an uplink transmission of the burst traffic.

[0169] The WTRU may indicate and / or report to the network the burst traffic arrival information. In some examples, the WTRU may report burst traffic arrival information associated with the arrived burst traffic in the WTRU’s buffer. In some examples, the WTRU may report the arrival time associated with the burst traffic. In some examples, the WTRU may report the remaining time to serve the burst traffic. In some examples, the WTRU may report the traffic arrival information associated with a predictive burst traffic, which may arrive at the WTRU’s buffer in the future. The WTRU may indicate the earliest, latest, and / or expected arrival time of the predicted burst traffic. The WTRU may (e.g., alternatively) indicate the expected and error bound of the burst traffic arrival time. The WTRU may (e.g., alternatively) indicate the potential range of arrival times of the burst traffic. In some examples, the WTRU may report the traffic arrival information associated with predictive burst traffic and / or the available burst traffic.

[0170] The WTRU may indicate and / or report to the network the preferred and / or expected data rate associated with the burst traffic.

[0171] The WTRU may indicate and / or report to the network the periodicity associated with the burst traffic. In some examples, the WTRU may expect the burst traffic to be periodic. The WTRU may (e.g., then) indicate the (e.g., expected) periodicity of the burst traffic.

[0172] The WTRU may indicate and / or report to the network the number of transmission periods. In some examples, the WTRU may expect the burst traffic to happen in multiple periods. The WTRU may (e.g., then) indicate the (e.g., expected) number of transmission periods for the WTRU’s burst traffic. In some examples, multiple transmission periods may be used to transmit a (e.g., one) burst traffic. In some examples, each transmission period may be used to transmit a burst traffic.

[0173] The WTRU may indicate and / or report to the network the data flows associated with the anticipated data arrival.

[0174] The WTRU may indicate and / or report to the network the delay and / or latency bound associated with the anticipated data arrival.

[0175] In some examples, the WTRU may report the burst traffic information associated with a predicted burst traffic. In the report, the WTRU may include, for example, the predictive range of arrival time (e.g., the possible earliest and / or latest arrival time) of the burst traffic, the QoS class and / or QoS treatment profile associated with the predictive burst traffic, the latency requirement associated with the burst traffic, and / or the expected amount of data associated with the burst traffic.

[0176] A WTRU may determine the message to report the burst traffic information. Messages may be conveyed in shared and / or control channels (e.g., physical uplink control channel (PUCCH), physical uplink shared channel (PUSCH)). The WTRU may use one or more of the following to provide messages to report the burst traffic information to the network: uplink control information (UCI); MAC CE; and / or RRC.

[0177] The WTRU may use UCI (e.g., SR) to provide messages to report the burst traffic information to the network. Specifically, the WTRU may use UCI (e.g., SR) to report the availability of the burst traffic information. For example (e.g., if (e.g., when) one or more triggering condition to report the burst traffic information is satisfied), the WTRU may trigger sending UCI (e.g., SR) to indicate the availability of the burst traffic satisfying the configured burst traffic reporting conditions. In some examples, the WTRU may trigger sending UCI (e.g., SR) if the WTRU does not have an uplink grant within a duration. In some examples, the WTRU may trigger sending UCI (e.g., SR) regardless of the availability of the uplink grant, e.g., since a UCI (e.g., SR) transmission may (e.g., explicitly) indicate the availability of burst traffic to handle the WTRU.

[0178] The WTRU may use MAC CE (e.g., BSR, DSR, a MAC CE defined for reporting burst traffic information) to provide messages to report the burst traffic information to the network.

[0179] The WTRU may use RRC (e.g., WTRU assistance information (UAI)) to provide messages to report the burst traffic information to the network.

[0180] The WTRU may signal availability of data associated with a data burst, for example, according to at least one of the following: the WTRU may transmit a signal on a dedicated PUCCH resource; the WTRU may transmit a preamble on PRACH as a dedicated resource; and / or the WTRU may transmit a MAC BSR CE and / or a MAC DSR CE.

[0181] The WTRU may signal availability of data associated with a data burst, for example, by transmitting a signal on a dedicated PUCCH resource e.g., a Data-Scheduling Request (D-SR) request. For example, the WTRU may be configured with channel selection on PUCCH, e.g., with a plurality of D- SR resources, where one of the configured D-SR resources may be associated with a burst of a specific size and / or period. The WTRU may select a first D-SR resource for a (e.g., normal) scheduling request not related to a burst indication and the WTRU may select a second D-SR resource to indicate availability and / or uplink data arrival of bursty data.

[0182] The WTRU may signal availability of data associated with a data burst, for example, by transmitting a signal on a dedicated PUCCH resource, such as a (e.g., specific) codepoint (e.g., if the WTRU is configured with a multi-bit D-SR resource, where one of the configured D-SR codepoints may be associated with a burst of a (specific) size and / or period). For example, the WTRU may select a first D-SRcodepoint for a (e.g., normal) scheduling request not related to a burst indication and may select a second D-SR codepoint to indicate availability and / or uplink data arrival of bursty data.

[0183] The WTRU may signal availability of data associated with a data burst, for example, by transmitting a preamble on PRACH as a dedicated resource e.g., an RA-SR request. For example, the WTRU may be configured with channel selection between a physical random access channel (PRACH) (e.g., using a dedicated preamble) or PUCCH (e.g., with a plurality of SR resources), where one of the configured preambles for RA-SR resources may be associated with a burst associated with a (e.g., specific) size and / or period. The WTRU may select a first D-SR resource (e.g., on PUCCH) for a (e.g., normal) scheduling request not related to a burst indication and may select a second RA-SR resource to indicate availability and / or uplink data arrival of bursty data.

[0184] The WTRU may signal availability of data associated with a data burst, for example, by transmitting a MAC BSR CE and / or a MAC DSR CE, which may include a field for the purpose of reporting a burst of data.

[0185] A WTRU may determine whether to trigger MAC CE or RRC to report burst traffic information. The WTRU may be configured with (e.g., at least) two messages (e.g., MAC CE vs. RRC) to report the burst traffic information. The WTRU may (e.g., then) determine whether to trigger sending MAC CE (e.g., a MAC CE defined for reporting burst traffic information) and / or RRC (e.g., UAI). The determination may be based on, for example, one or any combination of the following: whether the burst traffic is periodic or aperiodic; and / or the arrival time associated with the burst traffic.

[0186] The WTRU may determine whether to trigger sending MAC CE and / or RRC based on whether the burst traffic is periodic or aperiodic. For example, the WTRU may trigger sending RRC (e.g., UAI) if the burst traffic is periodic. The WTRU may trigger sending MAC CE to report burst traffic information, for example, if the burst traffic is aperiodic.

[0187] The WTRU may determine whether to trigger sending MAC CE and / or RRC based on the arrival time associated with the burst traffic. For example, the WTRU may use RRC message if the predicted and / or expected arrival time associated with the burst traffic is later than a configured arrival time threshold. The WTRU may use MAC CE to report the burst traffic information if the predicted and / or expected arrival time associated with the burst traffic is earlier than a configured arrival time threshold.

[0188] The WTRU may receive an indication from the network to perform differentiated handling of the burst traffic. The WTRU may receive indication from the network to perform differentiated handling (e.g., perform (exclusive) treatment) of the burst traffic. The indication may be used to validate the reception of the burst traffic information reporting. The WTRU may receive an indication of which burst traffic information reporting is validated. The indication may be received, for example, after the WTRU transmitsthe burst traffic information reporting to the network. The indication may be conveyed to the WTRU, for example, via DCI, MAC CE, and / or RRC.

[0189] The WTRU may receive uplink transmission resources to transmit the burst traffic. The WTRU may be scheduled with one or more uplink transmission resources, which may be used to transmit the burst traffic with differentiated handling. The WTRU may receive a grant from the network (e.g., a dynamic grant, a configured grant), which may be used to schedule uplink transmission resources for the WTRU. In some examples, the network may (e.g., explicitly) indicate (e.g., via DCI scheduling the dynamic grant, via DCI activating a type 2 configured grant, and / or via RRC configuring the type-1 configured grant) that the scheduled resources may be used to perform exclusive treatment of the burst traffic. The WTRU may receive the indication of which burst traffic (e.g., burst traffic ID) to perform treatment (e.g., exclusive treatment). The WTRU (e.g., upon reception of the (explicit) indication) may (e.g., then) perform treatment (e.g., exclusive treatment) of the burst traffic to transmit in the scheduled grant. For example, the WTRU may (e.g., then) prioritize the reported burst traffic in the scheduled grant.

[0190] In some examples, the WTRU may receive a scheduling of one or more uplink resources. The WTRU may determine (e.g., assume) that the scheduled grant received after reporting the burst traffic information may be used to validate the reception of the burst traffic information and / or to activate the treatment (e.g., exclusive treatment) of the reported burst traffic. The WTRU may (e.g., then) perform treatment (e.g., exclusive treatment) of the burst traffic to transmit in the scheduled grant. For example, the WTRU may (e.g., then) prioritize the reported burst traffic in the scheduled grant.

[0191] The WTRU may multiplex and / or provide an (e.g., a further) indication about the anticipated data arrival, for example, if the grant is received and the data has not yet arrived at the WTRU buffer. For example, the WTRU may provide a delta indication indicating the difference between what was already reported and the updated assumption at the time of grant transmission.

[0192] The WTRU may multiplex and / or provide an (e.g., a further) indication about the anticipated data arrival (e.g., instead of a BSR), for example, if the grant is received and some or all of the reported and / or anticipated data has been received. The WTRU may (e.g., alternatively) multiplex a BSR that may reflect data already arrived, e.g., in addition to the anticipated data arrival report. The WTRU may avoid multiplexing a BSR, for example, if the WTRU has already provided an indication of a number of bursts arriving, a periodic burst arrival, and / or if the WTRU multiplexes an indication that further data from the same burst may be anticipated.

[0193] The WTRU may perform prioritization for treatment of the burst traffic. I n some examples, the WTRU may be configured with multiple (e.g., two) configurations for uplink transmission and / or downlink reception activity. The downlink reception activity may include, for example, PDCCH monitoring, downlinkreference signal measurement (e.g., sensing and / or positioning reference signal measurement, radio resource management (RRM) reference signal measurement), and / or discontinuous reception (DRX). The uplink transmission activity may include, for example, data transmission, reference-signal transmission (e.g., sensing / positioning reference signal transmission, and / or sounding reference signal (SRS) transmission). The WTRU may (e.g., initially) use the first configuration (e.g., the default configuration) for uplink transmission and / or downlink reception activity. The WTRU may (e.g., then) apply the second configuration, for example, if the WTRU has a burst traffic available or predicted and / or expected to be available at the WTRU’s buffer satisfying the conditions to perform differentiated handling. The WTRU may apply the second configuration of the uplink transmission and / or downlink reception activity, for example, based on the transmission of the burst traffic report. The WTRU may apply the second configuration of the uplink transmission and / or downlink reception activity, for example, upon transmission of the burst traffic reporting. The WTRU may (e.g., alternatively) apply the second configuration of the uplink transmission and / or downlink reception activity, for example, based on the predicted and / or expected arrival time of the burst traffic, which may be reported to the network in the burst traffic information report.

[0194] In some examples, the WTRU may (e.g., first) use a first control resource set (CORESET), search-space and / or PDCCH monitoring configuration. The WTRU may (e.g., then) trigger reporting of a burst traffic information (e.g., based on the available and / or predicted and / or expected to be available of the burst traffic). The WTRU may (e.g., then) apply the second CORESET, search-space and / or PDCCH monitoring configuration (e.g., the configuration requiring the WTRU to monitor PDCCH more frequently) upon transmission of the burst traffic information reporting. This approach may support the network to reach the WTRU to schedule transmission resources for the burst traffic.

[0195] In some examples, the WTRU may (e.g., first) use the first DRX configuration. The WTRU may (e.g., then) apply the second DRX configuration, for example, after reporting the burst traffic information to the network. The second DRX may enable the WTRU to be active to transmit the burst traffic. The second DRX may enable the WTRU to be active after reporting the burst traffic information and during the predicted and / or expected burst traffic arrival time. The WTRU may (e.g., alternatively) determine to override the first DRX configuration and remain active after reporting the burst traffic and during a window of the predicted and / or expected arrival time of the burst traffic.

[0196] In some examples, the WTRU may (e.g., first) prioritize measurement of a reference signal (e.g., prioritize the measurement gap) and / or transmission of a reference signal over other uplink transmission and / or downlink monitoring. The WTRU may (e.g., then) modify the priority associated with uplink transmission and / or downlink monitoring related to burst traffic, for example, based on (e.g., upon) triggering of a differentiated handling of a burst traffic and / or reporting of burst traffic information. TheWTRU may (e.g., then) prioritize the uplink transmission and / or downlink monitoring related to the reported burst traffic over measurement of reference signal (e.g., a measurement gap) and / or transmission of the reference signal. For example, the WTRU may skip a measurement gap to perform PDCCH monitoring after reporting the burst traffic information. For example, the WTRU may prioritize transmission of the burst traffic over reference signal transmission (e.g., sensing and / or positioning reference signal (SRS)).

[0197] The WTRU may assign a QoS class and / or a QoS treatment profile to the burst traffic. In some examples, the WTRU may be configured with multiple (e.g., two) configurations of QoS classification for a burst traffic, which may be used to determine the QoS class and / or QoS treatment profile of the data in the burst traffic. The first configuration (e.g., the default configuration) may be used for the burst traffic, for example, if the differentiated handling condition is not satisfied. The WTRU may use the second configuration to assign data in the burst traffic to a QoS class and / or QoS treatment profile, for example, if the differentiated handling condition is satisfied.

[0198] In some examples, the WTRU may be configured with multiple (e.g., two) QoS classes and / or QoS treatment profiles for a burst traffic. The WTRU (e.g., then) assign the burst data to the first QoS class and / or QoS treatment profile, for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may assign the second QoS class and / or QoS treatment profile, for example, if the burst traffic satisfies the differentiated handling condition. In some examples, the WTRU may be configured with multiple (e.g., two) QoS classes and / or QoS treatment profiles for the high importance data in a data burst (e.g., the data having importance greater than a configured threshold). The WTRU may (e.g., then) map the high importance data in the data burst to the first QoS class and / or QoS treatment profile (e.g., the default QoS class assignment), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may map the high importance data in the data burst to the second QoS class and / or QoS treatment profile, for example, if the burst traffic satisfies the differentiated handling condition. The WTRU may not change the mapping of the remaining data (e.g., data with low importance or data having importance smaller than the configured threshold) of the burst traffic.

[0199] The WTRU may select the transmission resources for the burst traffic. In some examples, the WTRU may be configured with multiple (e.g., two) sets of resources, which may include a default set of resources that may be used for normal traffic, e.g., including the burst traffic not satisfying the differentiated handling condition, and at least one other (e.g., another) set of resources that may be used for the burst traffic satisfying the differentiated handling condition. The WTRU may (e.g., then) use the second set of resources for the burst traffic associated with differentiated handling. A configured set of resources for a burst traffic may include, for example, one or any combination of the following: the allowed configured grant(CG) types; the list of allowed CGs; the list of allowed PHY priorities; the RLC mode; the set of allowed serving cells from the cell group; the set of allowed carriers; the set of cells / TRPs; the set of allowed subcarrier spacings (SCSs); the minimum and / or maximum grant size; the modulation and coding scheme (MCS) and / or MCS table; the maximum and / or minimum PUSCH duration; the number of repetitions associated with the grant; and / or the channel access priority class (CAPC).

[0200] A configured set of resources for a burst traffic may include the allowed CG types (e.g., Type 1 CG, Type 2 CG, multi-PUSCH CG). For example, the WTRU may be configured with multiple (e.g., two) lists of CG types for a burst traffic. The WTRU may use the first list of CGs type (e.g., default list of CG types), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second list of CG types, for example, if the burst traffic satisfies the differentiated handling condition.

[0201] A configured set of resources for a burst traffic may include the list of allowed CGs. For example, the WTRU may be configured with multiple (e.g., two) lists of CGs for a burst traffic. The WTRU may use the first list of CGs (e.g., default list of CGs), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second list of CGs, for example, if the burst traffic satisfies the differentiated handling condition. The second list of CGs may be the superset of the first list of CGs. The WTRU may override the restriction of one or more CGs in the second list of CGs, for example, to enable the WTRU to transmit the burst traffic if (e.g., when) the differentiated handling condition is satisfied.

[0202] A configured set of resources for a burst traffic may include the list of allowed PHY priorities. For example, the WTRU may be configured with multiple (e.g., two) allowed PHY priorities for a burst traffic. The WTRU may use the first list of the allowed PHY priorities (e.g., default list), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second list of the allowed PHY priorities, for example, if the burst traffic satisfies the differentiated handling condition. For example, the first list of allowed PHY priorities may include (e.g., only) the low priority(ies). The second list of allowed PHY priorities may include low and high PHY priority(ies).

[0203] A configured set of resources for a burst traffic may include the RLC mode (e.g., acknowledged mode (AM), unacknowledged mode (UM), transparent mode (TM)). For example, the WTRU may be configured with multiple RLC modes for a burst traffic. The WTRU may use a first RLC Mode (e.g., AM mode), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use a second RLC Mode (e.g., UM mode), for example, if the burst traffic satisfies the differentiated handling condition.

[0204] A configured set of resources for a burst traffic may include the set of allowed serving cells from the cell group. For example, the WTRU may be configured with multiple (e.g., two) set of serving cells for a burst traffic. The WTRU may use the first list of the allowed PHY priorities (e.g., default list), for example, if the burst traffic does not satisfy the differentiated handling condition, the WTRU may use the second list of the allowed PHY priorities, for example, if the burst traffic satisfies the differentiated handling condition. For example, the first list of allowed PHY priority include (e.g., only) the low priority(ies). The second list of allowed PHY priorities may include low and high PHY priority(ies).

[0205] A configured set of resources for a burst traffic may include the set of allowed carriers. For example, the WTRU may be configured with multiple (e.g., two) sets of carriers for a burst traffic. The WTRU may use the first set of carriers (e.g., default list of CGs), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of carries to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0206] A configured set of resources for a burst traffic may include the set of cells and / or TRPs. For example, the WTRU may be configured with multiple (e.g., two) set of cells and / or TRP for a burst traffic. The WTRU may use the first set of cells and / or TRPs (e.g., default set of cells and / or TRPs), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of cells and / or TRPs to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0207] A configured set of resources for a burst traffic may include the set of allowed SCSs. For example, the WTRU may be configured with multiple (e.g., two) sets of SCSs for a burst traffic. The WTRU may use the first set of SCSs (e.g., default set of SCSs), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of SCSs to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0208] A configured set of resources for a burst traffic may include the minimum and / or maximum grant size. For example, the WTRU may be configured with multiple (e.g., two) sets of grant sizes for a burst traffic. The WTRU may use the first set of grant sizes (e.g., default set of grant sizes), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of grant sizes to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0209] A configured set of resources for a burst traffic may include the MCS and / or MCS-table. For example, the WTRU may be configured with multiple (e.g., two) sets of MCSs and / or MCS-tables for a burst traffic. The WTRU may use the first set of MCSs and / or MCS-tables (e.g., default set of MCSs and / or MCS-tables), for example, if the burst traffic does not satisfy the differentiated handling condition. TheWTRU may use the second set of MCSs and / or MCS-tables to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0210] A configured set of resources for a burst traffic may include the maximum and / or minimum PUSCH duration. For example, the WTRU may be configured with multiple (e.g., two) sets of PUSCH duration for a burst traffic. The WTRU may use the first set of PUSCH duration (e.g., default set of PUSCH duration), for example, if the burst traffic does not satisfy the differentiated handling condition, the WTRU may use the second set of PUSCH duration to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0211] A configured set of resources for a burst traffic may include the number of repetitions associated with the grant. For example, the WTRU may be configured with multiple (e.g., two) set of cells and / or TRP for a burst traffic. The WTRU may use the first set of number of repetitions associated with the grant (e.g., default set of the number of repetitions), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of the number of repetitions to transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0212] A configured set of resources for a burst traffic may include the channel access priority class (CAPC). For example, the WTRU may be configured with multiple (e.g., two) set CAPCs for a burst traffic. The WTRU may use the first set of CAPCs (e.g., default set of CAPCs), for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second set of CAPCs to access the channel and transmit the burst traffic, for example, if the burst traffic satisfies the differentiated handling condition.

[0213] In some examples, the WTRU may be configured with multiple configured grants. A configured grant (e.g., a multi-PUSCH CG) may be used and / or configured to transmit a periodic burst traffic. The WTRU may be allowed to use a configured grant for the periodic burst traffic, for example, if the burst traffic arrives before the first resource of the CG. The WTRU may be allowed to use (e.g., all) other CGs, for example, if the traffic arrives after the first resource of the CG.

[0214] The WTRU may allocate bits to an uplink grant (e.g., LCP procedure), for example, by considering the availability of the burst traffic. In some examples, the WTRU may allocate bits to an uplink grant (e.g., LCP procedure). The WTRU may be configured with multiple (e.g., two) traffic shaping policies. The WTRU may use the first traffic shaping policy (e.g., the default traffic shaping policy) for the burst traffic, for example, if the burst traffic does not satisfy the differentiated handling condition. The WTRU may use the second traffic shaping policy, for example, if the burst traffic satisfies the differentiated handling condition. A (e.g., each) traffic shaping policy may include, for example, a set of traffic shaping parameters and / or a shaping algorithm. The set of traffic shaping parameters may include, for example, the initialvalue of the bucket (b), the prioritized bit rate (PBR), the bucket side duration (BSD), and / or the number of applicable buckets. The shaping algorithm may describe how the WTRU select the bits to an uplink grant. For example, a default shaping algorithm may prioritize the bits to allocate to an uplink grant based on the priority associated with the QoS class. A second shaping algorithm may prioritize the bits to allocate to an uplink grant based on the volume associated with the QoS class. The second traffic shaping algorithm may (e.g., alternatively) prioritize the QoS class based on the delay requirement of the bits in the QoS class. The second traffic shaping algorithm may prioritize the burst traffic and / or the QoS class associated with the burst traffic regardless of the water level (Bj) associated with the QoS class while the first traffic shaping algorithm may prioritize the burst traffic and / or the QoS class associated with the burst traffic if the water level (Bj) is positive. The water level (Bj) may be used to monitor how PBR associated with a QoS class and / or a LCH is enforced. A negative water level (Bj) may indicate that the PBR associated with the QoS class and / or the LCH is satisfied. Otherwise, a positive water level (Bj) may indicate that the PBR associate with the QoS class and / or the LCH needs has not been satisfied.

[0215] In some examples, the WTRU may (e.g., then) use the second set of traffic shaping parameters and associated values (e.g., non-default set), for example, if the burst traffic satisfies the configured condition. For example, the WTRU may use a second PBR (e.g., higher PBR) for differentiated handling of the burst traffic. The second PBR may be infinitive, e.g., the WTRU may not limit the amount of burst traffic to allocate in an uplink grant.

[0216] A WTRU may report updated burst traffic information, for example, using one or more features described herein.

[0217] The WTRU may report the updated burst traffic information to the network (e.g., error case). In some examples, the WTRU may (e.g., first) report, to the network, the burst traffic information. The WTRU may report the burst traffic information of a predicted and / or expected burst traffic, which may be predicted and / or expected to arrive at the buffer of the WTRU within a period. In some scenarios, the burst traffic may arrive as expected, which may result in the property(ies) of the arrived burst traffic (e.g., burst traffic arrival time, amount of data, and / or QoS requirement) may be aligned with the information (e.g., previously) reported to the network. In some scenarios, the reported burst traffic may not arrive as predicted and / or expected, which may result in the property(ies) of the arrived burst traffic may be different from the information (e.g., previously) reported to the network. The WTRU may (e.g., then) report the updated burst traffic information to the network, which may be used to provide the updated burst traffic information to the network.

[0218] The WTRU may be configured with a condition to report updated burst traffic information. In some examples, the WTRU may be configured with one or more conditions to report the updated bursttraffic information to the network. The WTRU may (e.g., then) report the updated burst traffic information to the network, for example, if the configured condition(s) for the reporting is(are) satisfied. The triggering condition(s) to report the updated burst traffic information may be associated with, for example, one or more of the following: the availability of the reported burst traffic; the burst traffic arrival information; one or more QoS and / or QoE parameters associated with the burst traffic; the type of data associated with the burst traffic; the QoS class and / or the QoS treatment profile associated with the burst traffic; the amount of data associated with the reported burst traffic; and / or the amount of resource requested and / or required for the burst traffic.

[0219] Triggering condition(s) to report the updated burst traffic information may include the availability of the reported burst traffic. The WTRU may trigger reporting the updated burst traffic information to the network based on the availability of the reported burst traffic. The WTRU may indicate that the reported burst traffic is not available, for example, if the burst data is not available at the buffer within the indicated and / or reported time.

[0220] Triggering condition(s) to report the updated burst traffic information may include the burst traffic arrival information. The WTRU may report the updated burst traffic information to the network, for example, if the gap between the actual and reported arrival time of the burst traffic is larger than a configured threshold.

[0221] Triggering condition(s) to report the updated burst traffic information may include one or more QoS and / or QoE parameters associated with the burst traffic. The WTRU may report the updated burst traffic information to the network, for example, if the difference between one actual and reported QoS parameter is larger than a configured threshold.

[0222] Triggering condition(s) to report the updated burst traffic information may include the type of data associated with the burst traffic. The WTRU may report the updated burst traffic information to the network, for example, if the WTRU receives a different type of data compared to the type of data reported to the network.

[0223] Triggering condition(s) to report the updated burst traffic information may include the QoS class and / or the QoS treatment profile associated with the burst traffic. The WTRU may report the updated burst traffic information to the network, for example, if the reported QoS class is different from the arrived QoS class.

[0224] Triggering condition(s) to report the updated burst traffic information may include the amount of data associated with the reported burst traffic. The WTRU may report the updated burst traffic information to the network, for example, if the difference between the amount of arrived data and reported data is larger than a configured threshold.

[0225] Triggering condition(s) to report the updated burst traffic information may include the amount of resource requested and / or required for the burst traffic. The WTRU may report the updated burst traffic information to the network, for example, if the difference between the amount of the required resource and the requested and / or scheduled resources is larger than a configured threshold. The amount of the required resource may be based on the actual amount of burst traffic at the buffer of the WTRU and the amount of the requested resource value indicated in the reported burst traffic information.

[0226] The WTRU may determine the information to convey in the updated burst traffic reporting. In some examples, the WTRU may convey the similar parameters in the updated burst traffic reporting compared to a burst traffic reporting. The updated parameter values may reflect the updated burst traffic information. In some examples, the WTRU may perform delta reporting, which may indicate the difference between the reported burst traffic and the updated burst traffic.

[0227] The WTRU may determine the messages to report the updated burst traffic information. The WTRU may (e.g., then) report the updated burst traffic information to the network, for example, if the triggering condition to report updated burst traffic information is satisfied. Reporting the updated burst traffic information may help the network in utilizing the resource more efficiently and to react to the updated traffic information of the WTRU. The WTRU may use, for example, one or any combination of the following to transmit a message with the updated burst traffic information: the same message(s) used to report burst traffic information to report updated burst traffic information; a UCI (e.g., UCI-Update) used to update the burst traffic information; a MAC CE (e.g., MAC CE-Update) used to update burst traffic information; and / or an RRC used to update burst traffic information.

[0228] The WTRU may use the same message(s) used to report burst traffic information to report updated burst traffic information. The WTRU may use UCI (e.g., SR), MAC CE (e.g., BSR, DSR, a MAC CE defined for reporting the (updated) burst traffic information), and / or an RRC to report the updated burst traffic information. The WTRU may transmit UCI (e.g., SR) to indicate the availability of an updated burst traffic information report. The WTRU may (e.g., then) use MAC CE (e.g., BSR, DSR, a MAC CE defined for burst traffic information reporting) to provide more detailed information about the updated burst traffic.

[0229] In some examples, the WTRU may be scheduled with a (e.g., dedicated) resource to indicate the updated traffic information using UCI (e.g., SR). The UCI (e.g., SR) may be transmitted, for example, using a PUCCH channel. The dedicated resource may be scheduled using DCI. The DCI may indicate multiple resources, e.g., a first resource that may be used to transmit UCI using a PUCCH channel and one or more other (e.g., subsequent) resources that may be used to transmit data of the burst traffic using PUSCH. The WTRU may transmit UCI to transmit in the scheduled resource, for example, to indicate whether the updated burst traffic information is triggered or not. The WTRU may transmit in sequence, for example, ifthe updated burst traffic information is triggered. Otherwise, e.g., if the updated burst traffic information reporting is not triggered, the WTRU may transmit another sequence or may not transmit in the scheduled resource, for example, to implicitly and / or explicitly indicate that the updated burst traffic information reporting is not triggered.

[0230] In some examples, the WTRU may be scheduled with a dedicated resource to indicate the updated traffic information using MAC CE (e.g., BSR, DSR, a new MAC CE defined for reporting burst traffic information and / or updated burst traffic information). The MAC CE may be transmitted using the PUSCH channel. The dedicated resource may be scheduled using DCI. The DCI may indicate multiple resources, e.g., where one of the resources (e.g., the first resource) may be used to transmit MAC CE using PUSCH channel and one or more other (e.g., subsequent) resources may be used to transmit data of the burst traffic using PUSCH. The WTRU may (e.g., then), for example, include (e.g., only) MAC CE in the resource dedicated for updated burst traffic reporting while the remaining resource may be padded.

[0231] The WTRU may use a UCI (e.g., UCI-Update) to update the burst traffic information. For example, the WTRU may transmit in the set of the scheduled resources (e.g., the first resource, each scheduled resource, and / or one per configured N resources) a UCI-Update to indicate a plan to use the scheduled resources for burst traffic information. The WTRU may piggyback the UCI-Update with the PUSCH. For example, the UCI-Update may indicate the number of resources that may be used by the burst traffic. The UCI-Update may (e.g., alternatively) use a bitmap to indicate whether a (e.g., each) scheduled resource may be used for the burst traffic transmission. The UCI-Update may (e.g., alternatively and / or additionally) indicate whether more resources may be requested and / or required for the burst traffic transmission.

[0232] The WTRU may use a MAC CE (e.g., MAC CE-Update) to update burst traffic information. For example, the WTRU may trigger sending MAC CE if the WTRU needs less or more resources to transmit the burst traffic. In some examples, the MAC CE may indicate the amount of burst data in a buffer. In some examples, the new MAC CE may indicate how many more resources may be needed to transmit the burst traffic and / or how many scheduled resources may not be needed for transmission of the burst traffic. In some examples, the WTRU may use MAC CE, for example, if the WTRU needs more resources. The WTRU may use the UCI-Update, for example, if the WTRU does not need (e.g., all) the scheduled resources.

[0233] The WTRU may use an RRC used to update burst traffic information.

[0234] In some examples, the WTRU may (e.g., first) perform burst traffic information reporting to the network to indicate the information of a predictive burst traffic. The WTRU may (e.g., then) receive uplink resources to transmit the predictive burst traffic. The uplink resources may be aligned with the reportedpredictive burst traffic. The uplink resources may include multiple transmission opportunities. If the burst traffic arrived as reported to the network, the WTRU may use the scheduled resources to transmit the burst traffic. If the burst traffic does not arrive as it reported to the network, the WTRU may perform an updated burst reporting procedure. The WTRU may trigger transmission of a MAC CE (e.g., MAC CE-Update), for example, if the WTRU may need more resource to transmit the burst traffic. The WTRU may use UCI- Update, for example, to indicate the number of scheduled resources that the WTRU may use or the number of resources the WTRU may not use for the burst traffic transmission.

[0235] The WTRU may trigger reporting of predicted burst traffic information, which report may include the amount and expected arrival time of the burst traffic, to the network, for example, if (e.g., when) a configured reporting condition is satisfied. The WTRU may (e.g., further) report the updated burst traffic information to the network, for example, if the arrived burst traffic satisfies an updated reporting condition.

[0236] The WTRU may receive a configuration from the network with the condition(s) to report (e.g., predicted) burst traffic information. The configuration may include other condition(s) to report updated burst traffic information.

[0237] The condition(s) to report burst traffic information may include, for example, one or more of the following: the latency requirement of the burst traffic is smaller than a configured threshold; the amount of predicted burst traffic is greater than a configured threshold; and / or the expected arrival time of the burst traffic is within a configured range.

[0238] The condition(s) to report updated burst traffic information may include, for example, one or more of the following: the difference between the amount of the required resource(s) and the scheduled resource(s) is larger than a configured threshold; and / or the difference between an actual and a reported QoS parameter is larger than a configured threshold.

[0239] The WTRU may receive an indication from the application layer to report a predicted and / or expected burst traffic information. The WTRU may report the burst traffic to the network, for example, if the configured burst traffic reporting condition(s) is satisfied. The burst traffic reporting information may include, for example, one or more of the following: the expected amount of the burst traffic, its error bound, and / or the associated QoS class; the expected arrival time and error bound; and / or an indication about an upcoming burst arrival from one or more configured data flows. The WTRU may receive the one or more resources from the network to perform uplink transmissions (e.g., for the reported burst traffic). The WTRU may report the updated burst traffic information to the network, for example, if the configured reporting condition is satisfied. The updated burst traffic reporting information may include, for example, the number of unused resources and / or the amount of additional resource to transmit the burst traffic.

[0240] Burst traffic handling may provide one or more benefits and / or advantages. For example, burst traffic handling may enable a WTRU to provide the network with advance notice of the arrival of burst traffic with stringent QoS requirements (e.g., low latency, high reliability), which may help the network perform early scheduling of the transmission resources to meet the QoS requirement of the burst traffic. Burst traffic handling provides a mechanism to update the reported burst traffic information, which may enable the network to efficiently utilize the scheduling resources to support (e.g., guarantee) the QoS of burst traffic with stringent QoS requirements.

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

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

[0243] 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

Claims1 . A wireless transmit / receive unit (WTRU), comprising: a processor configured to: receive configuration information from a network, wherein the configuration information indicates a burst traffic condition; receive an indication of burst traffic; determine a parameter associated with the burst traffic; determine that the burst traffic condition is satisfied based on the parameter; and based on the determination that the burst traffic condition is satisfied, send burst traffic information to the network associated with the burst traffic.

2. The WTRU of claim 1 , wherein the burst traffic condition is a burst traffic latency threshold, and wherein the determination that the burst traffic condition is satisfied comprises a determination that a latency indicated by the parameter satisfies the burst traffic latency threshold.

3. The WTRU of claim 1 , wherein the burst traffic condition is a burst traffic volume threshold, and wherein the determination that the burst traffic condition is satisfied comprises a determination that a burst traffic amount indicated by the parameter satisfies the burst traffic volume threshold.

4. The WTRU of claim 1 , wherein the burst traffic condition is a configured resource threshold, wherein the determination that the burst traffic condition is satisfied comprises a determination that a difference between an amount of a required resource and a scheduled resource indicated by the parameter satisfies the configured resource threshold.

5. The WTRU of claim 1 , wherein the burst traffic condition is a configured quality threshold, wherein the determination that the burst traffic condition is satisfied comprises a determination that a difference between an actual quality of service and a reported quality of service indicated by the parameter satisfies the configured quality threshold.

6. The WTRU of claim 1 , wherein the burst traffic information indicates at least one of an amount associated with the burst traffic, an error bound associated with the burst traffic, or a quality of service class associated with the burst traffic.

7. The WTRU of claim 1 , wherein the burst traffic is an available burst traffic, a predicted burst traffic, or an updated burst traffic.

8. The WTRU of claim 1 , wherein the processor is further configured to: determine a change in the burst traffic; receive a transmission resource indication from the network, wherein the transmission resource indication indicates a transmission resource; and send, based on the determination of the change in the burst traffic, updated burst traffic information to the network via the transmission resource.

9. A method associated with a wireless transmit / receive unit (WTRU), the method comprising: receiving configuration information from a network, wherein the configuration information indicates a burst traffic condition; receiving an indication of burst traffic; determining a parameter associated with the burst traffic; determining that the burst traffic condition is satisfied based on the parameter; and based on the determination that the burst traffic condition is satisfied, sending burst traffic information to the network associated with the burst traffic.

10. The method of claim 9, wherein the burst traffic condition is a burst traffic latency threshold, and wherein the determination that the burst traffic condition is satisfied comprises a determination that a latency indicated by the parameter satisfies the burst traffic latency threshold.11 . The method of claim 9, wherein the burst traffic condition is a burst traffic volume threshold, and wherein the determination that the burst traffic condition is satisfied comprises a determination that a burst traffic amount indicated by the parameter satisfies the burst traffic volume threshold.

12. The method of claim 9, wherein the burst traffic condition is a configured resource threshold, wherein the determination that the burst traffic condition is satisfied comprises a determination that a difference between an amount of a required resource and a scheduled resource indicated by the parameter satisfies the configured resource threshold.

13. The method of claim 9, wherein the burst traffic condition is a configured quality threshold, wherein the determination that the burst traffic condition is satisfied comprises a determination that a difference between an actual quality of service and a reported quality of service indicated by the parameter satisfies the configured quality threshold.

14. The method of claim 9, wherein the burst traffic information indicates at least one of an amount associated with the burst traffic, an error bound associated with the burst traffic, or a quality of service class associated with the burst traffic.

15. The method of claim 9, wherein the burst traffic is an available burst traffic, a predicted burst traffic, or an updated burst traffic.

16. The method of claim 9, further comprising: determining a change in the burst traffic; receiving a transmission resource indication from the network, wherein the transmission resource indication indicates a transmission resource; and sending, based on the determination of the change in the burst traffic, updated burst traffic information to the network via the transmission resource.

Images