Detection and indication of end of burst by user plane function

Abstract

A method performed by a network node. A network node may receive configuration information indicating a condition indicating an end of a burst of a packet data unit (PDU) set. A network node may receive a burst of a set of PDUs. The burst of the set of PDUs may include PDUs. The network node may detect an end of a burst of the set of PDUs based on the PDUs satisfying a condition. The network node may send an indication to the base station of the end of the detected burst of the PDU set.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 454209, filed March 23, 2023, the contents of which are hereby incorporated by reference. Background Technology

[0002] Mobile communications using wireless communication continue to evolve. The fifth-generation mobile radio access technology (RAT) can be referred to as 5G New Radio (NR). Previous-generation (traditional) mobile communication RATs could be, for example, fourth-generation (4G) Long Term Evolution (LTE). Summary of the Invention

[0003] This disclosure describes devices and methods for detecting and indicating the end of a burst via user plane functions (e.g., via network nodes).

[0004] A network node can receive configuration information indicating the conditions for the end of a burst of Packet Data Units (PDUs). The network node can receive bursts of PDUs, wherein the burst of a PDU set includes PDUs. The network node can detect the end of a PDU burst based on the PDUs meeting the conditions. The network node can send an indication of the end of a PDU burst to the base station.

[0005] Configuration information may include an Information Element (IE) indicating the start of the second burst of the PDU set. The network node can receive the second burst of the PDU set. The network node can detect the end of the first burst of the PDU set by determining the number of PDU sets in the second burst based on the start of the second burst. The network node can determine the burst pattern based on the number of PDU sets in the second burst. The network node can determine whether the PDUs meet the condition based on the burst pattern.

[0006] A network node can determine a first timestamp associated with a first set of PDUs in a burst of PDU sets. A network node can determine a second timestamp associated with a second set of PDUs. The second timestamp may differ from the first timestamp. A network node can determine that a PDU satisfies a condition based on the second timestamp, which is different from the first timestamp.

[0007] Network nodes can identify the message headers of PDUs within a burst of PDU sets. These message headers can indicate the end of the burst of PDU sets. Network nodes can determine whether a PDU meets this condition based on the indication in the message headers.

[0008] The network node can determine that the PDU set is received during the first time duration. The burst of PDU sets can include the PDU set. The network node can determine a second time duration based on the determination that the PDU set is received during the first time duration. The network node can determine that the PDU satisfies the condition on a condition that the second time duration has elapsed.

[0009] The network node can determine a number of PDU sets in the burst of PDU sets. The network node can determine the PDU set based on the determined number of PDU sets. The network node can determine an expected byte size value for the determined PDU set. The network node can determine a received byte size value. The received byte size value can indicate a calculated byte size of the determined PDU set. The network node can determine that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

[0010] The network node can determine an expected byte size value for the burst of PDU sets. The network node can determine a received byte size value based on the burst of PDU sets. The network node can determine that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

[0011] The network node can determine a number of PDU sets associated with the burst of PDU sets. The network node can determine an expected byte size value for the number of PDU sets. The network node can determine a received byte size value based on the number of PDU sets. The network node can determine that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

[0012] The configuration information can include an information element (IE) indicating a PDU set identifier (ID). The network node can determine a burst pattern based on the PDU set identifier. The network node can determine a number of PDU sets based on the burst pattern. The number of PDU sets can be associated with the burst of PDU sets. The network node can determine that the PDU satisfies the condition based on the determined number of PDU sets. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented.

[0014] Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system Figure 1A illustrated in FIG. 1 can be used.

[0015] Figure 1C is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system Figure 1ASystem diagram of an example radio access network (RAN) and an example core network (CN) for use within a communication system shown in FIG. 1.

[0016] Figure 1D is a diagram illustrating an example of a user plane function (UPF) configured with burst information, in accordance with one embodiment. Figure 1A System diagram of another example RAN and another example CN for use within a communication system shown in FIG. 1.

[0017] Figure 2 An example data burst and burst periodicity are shown.

[0018] Figure 3 An example of a user plane function (UPF) detecting the end of a burst is shown.

[0019] Figure 4 An example of a UPF configured with burst information is shown.

[0020] Figure 5 An example RTP header extension using a single byte header format is shown.

[0021] Figure 6 An example RTP header extension using a double byte header format is shown.

[0022] Figure 7 An example RTP header format is shown.

[0023] Figure 8 An example of a UPF indicating the end of a detected burst is shown. DETAILED DESCRIPTION

[0024] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the

[0025] As Figure 1AAs shown in FIG. 1, the communications system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104 / 113, a CN 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 can 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 can be referred to as a “station” and / or a “STA”, can be configured to transmit and / or receive wireless signals, and can 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 (IoT) 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 or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0026] The communications system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can 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 can 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 can include any number of interconnected base stations and / or network elements.

[0027] The base stations 114a can be part of the RAN 104 / 113, which can 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 stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which can be referred to as a cell (not shown). The frequencies can be in licensed or unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell can provide coverage for a particular geographic area, which can be relatively fixed or can vary in time. The cell can also be divided into cell sectors (not shown). For example, the cell associated with a base station 114a can be divided into three sectors. Thus, in one embodiment, the base station 114a can include three transceivers, one for each sector of the cell. In another embodiment, the base station 114a can utilize MIMO technology and can utilize multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0028] The base stations 114a, 114b can communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over the air interface 116, which can 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 can be established using any suitable radio access technology (RAT).

[0029] More specifically, as noted above, the communications system 100 can be a multiple access system and can 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 can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 115 / 116 / 117 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

[0033] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can 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 IX, 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.

[0034] Figure 1AThe base station 114b in such embodiments can be, for example, a wireless router, Home Node B, Home eNode B, or access point, and can utilize any suitable RAT for facilitating wireless connectivity access 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 can 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 can 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 1C, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. Figure 1A

[0035] The RAN 104 / 113 can be in communication with the CN 106 / 115, which can 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 can 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 can 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 can 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 can be utilizing a NR radio technology, the CN 106 / 115 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology. Figure 1A

[0036] ​​The CN 106 / 115 can 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 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony, facsimile, and / or other

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

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

[0039] ​The processor 118 can 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 Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but can be integrated together in an electronic package or chip.

[0040] The transmit / receive element 122 can 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 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can 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 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

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

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

[0043] The processor 118 of the WTRU 102 can be coupled to, and can 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 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can 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 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can 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).

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

[0045] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0046] The processor 118 can further be coupled to other peripherals 138 that can 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 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs 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, an electronic game player module, an Internet browser, a virtual reality and / or an augmented reality (VR / A R) device, an activity tracker, and the like. The peripherals 138 can include one or more sensors, which can 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 posture sensor, a biometric sensor, and / or a humidity sensor.

[0047] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or eliminate self-interference and / or cross- interference that can occur during concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals can be concurrent but not simultaneous. In one embodiment, the WTRU 102 can include a full duplex radio and a half duplex radio. In one embodiment, the WTRU 102 can include multiple full duplex and / or half duplex radios.

[0048] Figure 1C is a system diagram of the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116 and can include the eNode-Bs 160a, 160b, 160c, and the like. The RAN 104 can also be in communication with the CN 106.

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

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

[0051] Figure 1C The CN 106 shown in FIG. 10 can 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 can be owned and / or operated by an entity other than the CN operator.

[0052] The MME 162 can be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and can serve as a control node. For example, the MME 162 can 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 can 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.

[0053] ​The SGW 164 can be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 can generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 can 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.

[0054] The SGW 164 can be connected to the PGW 166, which can 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.

[0055] The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide

[0056] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such terminals can (e.g., temporarily or permanently) use a wired communication interface to the communication network.

[0057] In representative embodiments, the other network 112 can be a WLAN.

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

[0059] When using an 802.11 ac infrastructure mode of operation or similar modes of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, such as in 802.11 systems, carrier sense multiple access with collision avoidance (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs, including the AP (e.g., each of the STAs) can sense the primary channel. If the primary channel is sensed / detected as busy and / or determined to be busy, a particular STA can back off. Only one STA can transmit at any given time in a given BSS.

[0060] High Throughput (HT) STAs can use 40 MHz wide channels 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.

[0061] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels - this can be referred to as the 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed into two streams by a segment parser. The inverse fast Fourier transform (IFFT) and time domain processing can be done on each stream separately. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations can be reversed for the 80+80 configuration, and the combined data can be sent to the medium access control (MAC).

[0062] 802.11 af and 802.11 ah support sub-1 GHz modes of operation. The channel operating bandwidth and carriers are reduced in 802.11 af and 802.11 ah relative to those used in 802.11η and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11 ah 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 can support metering type control / machine type communication, such as MTC devices in a macro coverage area. The MTC devices can have certain capabilities (e.g., limited capabilities) including support (e.g., only support) for certain and / or limited bandwidths. The MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0063] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11η, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) 1 MHz mode, the primary channel can be 1 MHz wide, even if other STAs in the AP and 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 can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (which only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy, even if most of the frequency band remains idle and can be available.

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

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

[0066] The RAN 113 can include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 113 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can 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 can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can 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 can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers (not shown) to the WTRU 102a. A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

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

[0068] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use signals

[0069] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can 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 functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown in FIG. 1C, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D As shown in FIG. 1C, the gNBs 180a, 180b, 180c can also be configured to communicate with a location management function (LMF) 183 over an N4 interface. The LMF 183 can be configured to receive location services requests from the WTRUs 102a, 102b, 102c, handle the requests, and provide appropriate location services to the WTRUs 102a, 102b, 102c.

[0070] Figure 1DThe CN 115, as shown in FIG. 10B, can 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 can be owned and / or operated by an entity other than the CN operator.

[0071] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling 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. The AMF 162 can provide CN support for session and service continuity across 3GPP and non-3GPP access networks. The AMF 162 can also participate in the setup of alert notifications for services that require

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

[0073] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which can 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 can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering of downlink packets, providing mobility anchoring, and the like.

[0074] The CN 115 can facilitate communications with other networks. For example, the CN 115 can include, or can 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 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can 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 can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0075] In view of Figures 1A-1D and Figures 1A-1D corresponding description, one or more or all of the functions described herein in relation to one or more of the WTRUs 102a-d, the base stations 114a-b, the eNode-Bs 160a-c, the MME 162, the SGW 164, the PGW 166, the gNBs 180a-c, the AMF 182a-b, the UPF 184a-b, the SMF 183a-b, the DN 185a-b, and / or any other device(s) described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or to simulate a network and / or WTRU functionality.

[0076] A simulation device can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more, or all, of the functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices can perform one or more, or all, of the functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device can test other devices either directly coupled to the simulation device and / or can perform tests using over-the-air, wireless communication.

[0077] One or more simulation devices can perform one or more functions, including all functions, but not be implemented / deployed as part of a wired and / or wireless communication network. For example, a simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to enable testing of one or more components. The one or more simulation devices can be test equipment. The simulation device can transmit and / or receive data using direct RF coupling via RF circuitry (e.g., which can include one or more antennas) and / or wireless communication.

[0078] A timer referred to herein can refer to a time, a time period, a time tracking, a time period tracking, a combination thereof, and / or the like. An expiration of a timer referred to herein can refer to a determination that a time has come or a time period has expired.

[0079] Devices and methods for detecting an end of burst are provided herein. For example, the disclosure describes devices and methods for detecting an end of burst (EOB) in extended reality (XR) traffic and configuring such detection. The EOB detection can be performed by a user plane function (UPF) or a radio access network (RAN). If the UPF performs the detection, the UPF can signal an EOB indication to the RAN. The RAN can use the EOB detection and / or indication to set a WTRU in a low power state.

[0080] Features associated with UPF-based EOB detection and indication are provided herein. A UPF can receive configuration information for detecting an EOB of a set of packet data units (PDUs). The UPF can detect the EOB. The UPF can send an indication of the EOB to a RAN.

[0081] Features associated with RAN-based EOB detection and use are provided herein. A RAN can receive configuration information for detecting an EOB of a set of PDUs. The RAN can detect the EOB. The RAN can control a sleep state of a WTRU based on the detection.

[0082] The following acronyms are used herein: AF application function AS application server DRX discontinuous reception EOB end of burst (e.g., end of a burst) EOBI end of burst indication GTP-U GPRS tunneling protocol user plane protocol HE header extension MOQ media over QUIC protocol NG-RAN next generation radio access network PCC policy and charging control PCF policy control function PDU packet data unit RTP real-time protocol SMF session management function SRTP secure real-time protocol UE user equipment UPF user plane function WTRU wireless transmit / receive unit XR extended reality

[0083] The terms “server,” “application server,” and “application function” can be used interchangeably herein.

[0084] Features are provided herein associated with UPF-based EOB detection and indication.

[0085] A network function (e.g., UPF) can receive configuration information for detecting an EOB of a PDU set. The configuration information can indicate conditions that indicate an EOB of a burst of PDU sets. For example, a network exposure function (NEF) application programming interface (API) can define a trigger information element (IE) to identify a start and / or end of a burst and / or inter-PDU timeout within a burst.

[0086] A network node (e.g., UPF) can receive a PDU set (e.g., over an N6 interface, e.g., via RTP / SRTP). For example, the network node can receive a burst of PDU sets. The burst of PDU sets can include at least one PDU.

[0087] The UPF can detect an EOB of the burst of PDU sets. The UPF can detect the EOB of the burst of PDU sets based on a PDU in the burst of PDUs satisfying a condition. For example, the UPF can detect the EOB of the PDU sets based on a timestamp change, a specific field in an RTP / SRTP header / extension / payload, a timeout, a number of PDU sets, a traffic pattern, and / or the like.

[0088] The UPF can signal the EOB to a RAN (e.g., NG-RAN), or can provide information to the RAN that the RAN can use to detect the EOB. For example, the UPF can send an EOB indication (EOBI) and / or information (e.g., size information, etc.) to the RAN in a GTP-U message. For example, the UPF can send an indication of the EOB of the PDU set to a base station.

[0089] Features are provided herein associated with RAN-based detection and use of EOBs.

[0090] A RAN (e.g., NG-RAN) can receive configuration information (e.g., in a QoS profile). The RAN can use the configuration information to detect an EOB of a burst of PDU sets. For example, the configuration information can indicate conditions that indicate an EOB of a burst of PDU sets. The RAN can use the EOB to control a sleep state of a WTRU.

[0091] The RAN can receive PDUs of a service data flow (SDF) corresponding to XR traffic.

[0092] The RAN can detect the EOB (e.g., of a PDU set). The RAN can not be able to see the contents of the header, but can be able to detect the EOB using a timer-based approach.

[0093] The RAN can control the sleep state (e.g., low power state) of the WTRU.

[0094] Provided herein are feature(s) associated with a data burst.

[0095] A data burst can be a set of one or more PDUs generated and transmitted by an application in a short period of time. A data burst can be (e.g., typically) associated with a burst periodicity. The burst periodicity can be configured in the control plane for an XR flow or set of flows. A data burst can include one or more PDU sets. For example, a data burst can carry an application data unit such as a frame or a set of pictures. For example, a data burst (e.g., the same data burst) can carry different PDU sets including media types corresponding to the same frame displayed to a user. The terms “data burst,” “burst,” and “burst transmission” can be used interchangeably herein.

[0096] Figure 2 Example data bursts and burst periodicities are shown. Bursts that take too long to transmit (e.g., take longer than the burst periodicity to transmit) can be merged with subsequent periodic transmissions to form a single continuous burst.

[0097] Data bursts can occur in traffic associated with an XR service. XR traffic can be transmitted in bursts. For example, an AS can transmit burst data to a WTRU. The data burst can represent audio information, video information, and / or the like. After a data burst is transmitted to the WTRU, a period of time can elapse before another data burst is transmitted by the AS to the WTRU.

[0098] XR traffic can be conveyed over an RTP / SRTP session or other protocol (e.g., MOQ over QUIC or RTP).

[0099] Provided herein are feature(s) associated with an EOB indication.

[0100] A core network (e.g., UPF) can send an “end of data burst” indication (EOBI) to a RAN (e.g., NG-RAN). The RAN can use the indication to configure a WTRU power saving management scheme (e.g., connected mode DRX).

[0101] The PCF can determine a protocol description for the flow. The protocol description can be based on local policy or information provided by the AF. An example of a protocol description can include traffic with an RTP payload. For example, the protocol description can include traffic with a Versatile Video Coding (e.g., VVC, H.265, H.266, MPEG, and / or the like) payload.

[0102] The PCF can provide the protocol description within the PCC rules (e.g., which can be sent to the SMF).

[0103] The SMF can configure the UPF to detect the last PDU of a data burst. The UPF configuration can be based on the protocol description from the PCC rules. The protocol description can indicate the type of header and / or payload found in the traffic. The UPF can use the protocol description to detect the end of a data burst.

[0104] If the UPF detects the end of a data burst, the UPF can provide an end of burst indication (EOBI) to the RAN. The EOBI can be sent in a GTP-U messaging from the UPF to the RAN.

[0105] If the RAN receives the EOBI in the GTP-U header of a message carrying a PDU, the RAN can assume that the PDU is the last PDU of a given data burst and can place the WTRU in a sleep state.

[0106] Provided herein are feature(s) associated with an RTP header extension for PDU set marking.

[0107] Provided herein are examples of an RTP header extension. The header extension can include fields that can be used to derive information such as a PDU set sequence number, an indication of an end PDU of a PDU set, a PDU sequence number within a PDU set, a PDU set size (e.g., in bytes), and a PDU set importance. The header can not address how to use the information in the RTP header extension to detect the end of a burst of PDU sets.

[0108] An example header extension can include a field carrying an extension element identifier, a flag indicating that a PDU is the first PDU of a PDU set, an end flag indicating that a PDU is the last PDU of a PDU set, a flag indicating that a PDU can be discarded without significant impact on reconstructing the media, a field indicating a priority, a sequence number of a PDU set, a number of PDUs in a PDU set, a sequence number of a PDU, and / or a PDU set size (e.g., indicating a size in bytes) of one or more (e.g., all) PDUs of a PDU set.

[0109] Provided herein are feature(s) associated with the GTP-U protocol.

[0110] A G-PDU can be an example GTP-U message type. A user payload can be transported in a G-PDU packet. An example G-PDU can be a packet that includes a GTP-U header and a user data packet (also referred to as a T-PDU). A G-PDU can include an extension header.

[0111] Provided herein are feature(s) associated with configuring a UPF to detect an end of a burst of PDUs. The UPF can detect the end of the burst of PDUs using techniques that can depend on the application layer protocol(s) used to encode downlink traffic (e.g., the format of the downlink traffic).

[0112] Provided herein are feature(s) associated with indicating in a GTP-U header to an NG-RAN an end of a burst of PDUs.

[0113] To detect (e.g., and signal) an end of a burst of PDUs, a system can consider that the PDUs can be received out of order by the UPF and / or the RAN (e.g., NG-RAN).

[0114] Provided herein are feature(s) associated with configuring a RAN (e.g., NG-RAN) to detect an end of a burst of PDUs.

[0115] A UPF can receive configuration information from a SMF. The UPF can use the configuration information to detect an end of a burst of a set of PDUs in downlink traffic of a WTRU. The UPF can send an indication or information to a RAN so that the RAN can detect the end of the burst of the set of PDUs. The RAN can use the indication or information to determine whether to put the WTRU in a sleep state or a low power state (e.g., to conserve WTRU power and increase battery life of the WTRU).

[0116] Figure 3 An example is shown in which a UPF detects an EOB.

[0117] Provided herein are feature(s) associated with configuring and UPF behavior.

[0118] Provided herein are feature(s) associated with configuring a UPF to detect an end of a burst. A SMF can send configuration information to a UPF (e.g., over an N4 interface).

[0119] Burst identification information (BII) (sometimes also referred to herein as burst information) can include a set of IE(s). The set of IE(s) can be used to identify / handle bursts and burst transitions. Different BII can be used to tailor EOB detection depending on the context (e.g., such as media transport protocol, media type, and / or application). BII can be associated with a SDF (e.g., in a PCC rule including a traffic filter identifying the flow), or associated with a QoS flow. BII can include one or more of the following: one or more trigger IE ID and associated burst start value and / or burst end value; protocol ID; burst periodicity; burst size (e.g., sum of PDU size in bytes, or sum of RTP payload in bytes, etc.); and / or inter-burst PDU timeout (e.g., this can be the maximum time between PDUs within a burst).

[0120] A trigger IE ID can include an ID identifying an IE field in a message (e.g., media transport, protocol message, and / or the like). For example, ID = 1 can identify an IE holding a presentation timestamp, and ID = 2 can identify an IE holding a layer ID. A protocol ID can be used to identify an IE. For example, an RTP protocol ID and a trigger IE ID "presentation timestamp" can (e.g., together) identify a presentation timestamp IE present in an RTP protocol header. A trigger IE ID can be an ID of a virtual IE field. A virtual IE field can correspond to (e.g., depending on which media transport protocol is used) a different IE or different combination of IEs in a media transport protocol. An example of such a trigger IE ID can be a PDU set ID. A PDU set ID can be a virtual trigger IE (e.g., if there is no explicit PDU set ID IE present in a PDU set).

[0121] A trigger IE can be an IE present in a PDU (e.g., a field in a header in an RTP packet). A trigger IE can be an IE present in a PDU set (e.g., a field in a header in a MOQ data stream). Examples of trigger IEs include: presentation timestamp; sending timestamp; sequence number; marker (e.g., frame boundary marker); payload type; frame start indication; frame end indication; independent frame indication; discardable frame indication; base layer synchronization (e.g., an indicator that a frame within a layer depends only on a base temporal layer); time ID (e.g., temporal layer ID); layer ID (e.g., spatial layer ID); time layer 0 picture index (e.g., a cyclic counter labeling base layer frames); PDU set ID; PDU set end indication; PDU set sequence number; PDU set significance (e.g., PDU set significance indicator); PDU set size; burst ID (e.g., as defined herein); and / or last PDU set indication of a burst of a PDU set.

[0122] The burst start value can comprise a tuple associated with the trigger IE ID. The burst start value can comprise: a value type (e.g., selected from {transition to different value, invalid value, fixed valid value, transition to higher value}), a new PDU set indication, and / or a fixed value.

[0123] For some value types (e.g., which include transition and invalid types), a fixed value (e.g., which can be 0) can not be used. The new PDU set indication can be used to indicate that the start of a burst can (e.g., only can) be detected on the first PDU received for a PDU set. In some systems, the new PDU set indication can be implicit (e.g., and thus can not be needed) for one or more burst start values. The burst start value can be used to determine a transition between one burst and the next burst.

[0124] The burst end value can be defined as a tuple associated with the trigger IE ID. The burst end value can comprise: a value type (e.g., selected from {detected transition pattern, number of transitions to different value}), a PDU set end indication, and / or a fixed value.

[0125] For a detected transition pattern, the fixed value can represent the number of consecutive observations of the pattern before the end of the burst is detected using the pattern. For a detected transition pattern, the fixed value can be set to 0 (e.g., thus allowing the UPF to determine a suitable number of repetitions based on other configuration or logic). For a number of transitions to different value, the fixed value can represent the number of transitions.

[0126] The PDU set end indication can be used to indicate that the EOB can (e.g., only can) be detected when the PDU set is complete (e.g., one or more PDUs of the set are received, or are received or deemed lost after a timeout elapses, for example). In some systems, “PDU set end” can be implicit (e.g., and thus can not be needed) for one or more burst end values. The burst end value can be used to determine when a burst is complete (e.g., the burst is completely received, or any missing PDUs in the burst are determined to be lost).

[0127] Provided herein are feature(s) associated with configuration and behavior of a UPF using a trigger IE ID. An AF can configure burst information for a given QoS flow and / or SDF. The burst information can include burst periodicity and BII in the PCF (e.g., by the NEF). The burst information can be configured in the PCF (e.g., in a PCC rule), communicated by the PCF to the SMF (e.g., in a PCC rule), and communicated by the SMF to the UPF (e.g., in an N4 message).

[0128] Figure 4An example of configuring a UPF with burst information is shown.

[0129] At 1a, the AF can invoke an API (e.g., Nnef_AFsessionWithQoS) to provide burst information to the network. At 1b, the NEF can respond to the API invocation.

[0130] At 2a, the NEF can invoke an API (e.g., Npcf_PolicyAuthorization) to provide burst information to the PCF. The PCF can use the burst information to construct PCC rules. The PCC rules can include all burst information or partial burst information. At 2b, the PCF can respond to the API invocation.

[0131] At 3, the PCF can send PCC rules to the SMF. The PCF can send PCC rules to the SMF (e.g., in case the SMF invokes an API such as Npcf_SMPolicyControl). For example, the SMF can invoke Npcf_SMPolicyControl during PDU session establishment. If the PDU session has (e.g., has been) established when the PCF creates the PCC rules, the PCF can use the notification operation of the Npcf_SMPolicyControl API to forward the PCC rules to the SMF. For example, sending PCC rules to the SMF can be initiated by the PCF or the SMF.

[0132] At 4, the SMF can send burst information to the UPF (e.g., in N4 messages).

[0133] Provided herein are feature(s) associated with detecting and using EOB.

[0134] Provided herein are feature(s) associated with burst processing initialization state and stable state. For example, at the beginning of a flow, the UPF can start in burst processing initialization state and use a burst start value to detect the start of a burst. For example, the UPF can detect the first PDU of a set of PDUs corresponding to a transition in the trigger IE. The UPF can (e.g., in response to detecting the first PDU of the set of PDUs) start a timer with a burst periodicity to estimate the start of the next burst. If the UPF determines that a new burst starts, the UPF can compare the actual inter-burst interval time with the expected burst periodicity. If the difference (e.g., based on network operator’s configuration) is always within an acceptable jitter range, the UPF can reach a burst processing stable state. The burst processing stable state can indicate a match between the burst periodicity and the actual behavior of the media traffic. As described herein, the UPF can start detecting and using EOB.

[0135] If the RAN performs EOB detection, the RAN can reach a similar burst handling steady state. In an example, the burst periodicity can not be configured, and the UPF / RAN can use burst start detection to estimate the burst periodicity. Based on the estimation, the UPF / RAN can measure the jitter and enter the burst handling steady state. If an error occurs during the burst handling steady state operation, the UPF can transition back to the burst handling initialization state. For example, the UPF can stop EOB detection until the UPF can re-enter the burst handling steady state. The burst handling initialization state and steady state can be used to enable the EOB detection mechanisms described herein.

[0136] Features associated with detecting EOB on multiple data streams are provided herein. For example, multiple data streams (e.g., video, audio, haptics) can make up the XR traffic sent to the WTRU. In some examples, the data streams (e.g., flows) can be multiplexed. If the data streams are multiplexed, a burst can be made up of the combination of data streams and can be detected and handled as described herein. The multiple data streams can be sent in different streams (e.g., different SDFs and / or QoS flows). In this case, EOB can be detected separately for each stream. The UPF / RAN can (e.g., determine) to wait for EOB (e.g., all EOB) to be detected on each relevant stream (e.g., all streams towards the same WTRU associated with PDU set based QoS handling) before using EOB (e.g., EOBIs sent to the RAN for the UPF; and / or controlling WTRU sleep state for the RAN). The UPF can send each EOB I to the RAN independently. The RAN can wait to receive (e.g., all) relevant EOB I before using the EOB I (e.g., to control WTRU sleep state).

[0137] Features associated with using EOB for non-XR traffic are provided herein. If non-XR traffic is sent to the WTRU, the RAN can consider the non-XR traffic when deciding whether to use EOB / EOBI to control the WTRU’s sleep state. For example, in determining EOB, the RAN can wait until one or more (e.g., all) queued PDUs to the WTRU are transmitted. The RAN can (e.g., then can) calculate the minimum of the PSDBs on all other QoS flows to the WTRU. The RAN can calculate the time until the next burst start. The RAN can set the WTRU sleep time to the time until the next burst start. In this case, the RAN can ensure that new PDUs can still be transmitted within the appropriate PSDB (e.g., even if a new PDU is received immediately after placing the WTRU in sleep mode).

[0138] Provided herein are feature(s) associated with detecting EOB using specific header extensions.

[0139] Provided herein are feature(s) associated with detecting EOB when RTP traffic uses specific header extensions. If EOB is detected, the UPF can trigger an indication to the RAN (e.g., NG-RAN) to indicate EOB.

[0140] Provided herein are feature(s) associated with detecting EOB based on specific header extensions.

[0141] As described herein (and as shown in Figure 4 The UPF can be configured by the SMF with information indicating what type of traffic (e.g., what type of header) can be present in the traffic of the flow. The UPF can use the traffic type information to detect information (e.g., headers) in the downlink traffic and use the detected information to detect the end of a data burst.

[0142] The RTP header extension can include a flag indicating that the PDU is the last PDU of a burst of PDU sets. The UPF can determine that the end of the burst is detected (e.g., when the UPF has received the entire PDU set). The UPF can determine that the entire PDU set has been received if the number of bytes of the PDU set matches the PDU set size. The UPF can determine that the entire PDU set has been received if one PDU of the PDU set is received and the end flag of the PDU is set in the header.

[0143] If the UPF counts the number of bytes of the received PDU set to determine EOB, the UPF can detect the end of the PDU set even if the UPF receives the packets in an order different from the order in which the packets are sent.

[0144] If the UPF uses the end flag to detect the end of the PDU set, the UPF can not (e.g., can not need to) count the number of packets that have been received so far from the PDU set (e.g., requiring less memory to maintain state associated with the PDU set).

[0145] The RTP header extension can include a time at which the next PDU set on the service data flow is expected to arrive. Based on this information and / or the BII, the UPF can determine which PDU set can be the last PDU set in the burst. If the UPF has received all of the PDUs of the last PDU set in the burst, the UPF can determine that the end of the burst is detected.

[0146] The end of burst indication can be signaled in the PDU set information header extension. The burst identifier can be signaled in the PDU set information header extension.

[0147] Figure 5 and Figure 6 An example syntax and semantics showing the end of a data burst (e.g., length of 2 bits) and / or burst ID (e.g., length of 8 bits) in the PDU set information header extension is shown. Figure 5 An example RTP header extension using a one-byte header format is shown. Figure 6 An example RTP header extension using a two-byte header format is shown.

[0148] For the last PDU of a data burst, the EOB flag (e.g., length of 2 bits) can be set to 0x01. If the current PDU is not the last PDU of a data burst, the EOB flag can be set to 0x00. If there is no indication of the end of a burst indication in the PDU set information RTP header extension, the EOB flag can be set to 0x10. If the PDU is part of the last PDU set of a data burst, the EOB flag can be set to 0x11.

[0149] The burst ID (e.g., length of 8 bits) can have a value set to the identifier of the burst. For example, PDUs intended to be sent in a single burst (e.g., which correspond to the same display time) can have the same burst ID.

[0150] The end of a burst in a media data stream can be identified by setting the RTP header extension EOB field of the last PDU of a reference frame to 0x01. The size of a reference frame in a media data stream can be larger. A reference frame can use (e.g., require) several PDUs and PDU sets to transmit encoded frame data.

[0151] The end of a burst can be indicated for the last PDU of an encoded picture (e.g., each encoded picture) or the last PDU of an encoded group of pictures (GOP). In video encoding, a GOP structure can indicate the order in which intra- and inter- coded frames are arranged. A GOP can include a set of consecutive pictures within an encoded video data stream. An encoded video data stream (e.g., each encoded video data stream) can include consecutive GOPs from which the visual frames are generated.

[0152] The end of a burst can be indicated (e.g., using the RTP header extension EOB field value 0x11) for the PDUs (e.g., all PDUs) in the last PDU set of a reference frame or GOP. In this case, the UPF / RAN can detect the EOB when the UPF / RAN has completely received the PDUs of the PDU set (e.g., by comparing the number of bytes received for the PDU set to the PDU set size information element (IE)).

[0153] The burst identifier can be derived from a media timestamp (e.g., a media decoding timestamp or a media display timestamp). The burst identifier can be a subset of bits in the timestamp (e.g., this can enable consecutive bursts to have different identifiers). Generating the burst identifier based on bits of the timestamp can enable multiple decoders (e.g., for different media types) in the same session to obtain the same burst identifier without coordination between the decoders.

[0154] The burst identifier can be a sequence number (e.g., set by the sender when starting a new independent frame). In this case, PDUs carrying different media types can have different burst IDs (e.g., even if they carry data that will be displayed at one time, the same time, or similar times), unless the different decoders cooperate to synchronize the sequence numbers. In this case, the UPF can (e.g., individually) detect the start and end of bursts for different flows / media types.

[0155] Using a burst identifier can enable the UPF to detect the start and end of a burst (e.g., with limited processing requirements). For example, the UPF can use a change in the burst ID to determine that a burst has merged with the next burst. The UPF can count the set of PDUs that belong to (e.g., a single) burst, or can count the number of bytes in (e.g., a single) burst. The UPF can (e.g., then can) use one of the techniques described herein to detect the EOB.

[0156] Provided herein are feature(s) associated with detecting EOB using existing RTP / SRTP headers, header extensions, and payloads.

[0157] Provided herein are feature(s) associated with detecting EOB where RTP traffic uses existing RTP / SRTP headers, header extensions, and payloads. If EOB is detected, the UPF can trigger an indication to the RAN (e.g., NG-RAN) to indicate the EOB.

[0158] Provided herein are feature(s) associated with detecting EOB based on changes in timestamps.

[0159] As described herein (and as shown in Figure 4 The UPF can be configured by the SMF with rules that can be used to detect information (e.g., headers) in the downlink traffic. The UPF can use the detected information to detect the end of a burst of data.

[0160] The UPF can be configured with (e.g., a single) trigger IE ID RTP timestamp. The trigger can indicate to the UPF (e.g., using an associated burst of start IE) that a new burst can be detected when the RTP timestamp transitions to a higher value. The UPF can determine a pattern. For example, within a burst (e.g., between two consecutive "burst of start" PDUs), the burst can include seven PDU sets. A PDU set (e.g., each PDU set) can include PDUs with the same RTP timestamp. To determine which pattern to look for, the UPF can use a "burst of end" IE. For example, the "burst of end" IE can describe a burst pattern based on PDU set ID. If the UPF observes several consecutive occurrences of the pattern, the UPF can enter a stable state (e.g., where the UPF expects the number of measurements to be stable). The UPF can remain in the stable state if (e.g., as long as) the UPF continues to observe the number of measurements regularly. In the stable state, if seven PDU sets are complete, the UPF can report the end of the burst on the last PDU of the last PDU set of seven PDU sets after the start of the burst. The UPF can detect whether a PDU set is complete (e.g., based on one or more of PDU set size, PDU set end indication, and / or PDU sequence number within a PDU set). To enable detection of the end of the burst, if some PDU sets are not complete, the UPF can reset a timer after each received PDU on a given burst (e.g., using an intra-burst timeout from the BII) and trigger a timeout if the timer expires before detecting the end of the burst. If the UPF triggers a timeout, the UPF can send a GTP-U message (including an end of burst indication for the QoS flow / SDF).

[0161] The UPF can be configured with a trigger IE ID (e.g., that includes {RTP timestamp, layer ID}). If the payload matches the indicated layer (e.g., the layer ID indicates a base layer in a multi-layer media coding scheme) and the RTP timestamp transitions to a different value, an associated burst of start IE can indicate that a start of burst is detected. The UPF can detect a new burst even if a video player jumps to an earlier position in the data stream.

[0162] Provided herein are feature(s) associated with detecting EOB based on RTP timestamp.

[0163] Figure 7 An example RTP header format is shown. If the timestamp value of the media changes in the RTP header, an EOB can be detected (e.g., as Figure 7Media data belonging to a particular time can be sent as a burst. For example, the PDUs (e.g., all PDUs) associated with a burst can have the same timestamp. If a new timestamp is detected in the RTP packet header of the RTP stream, the end of burst notification can be signaled in the PDU set information RTP header extension, or the UPF can send a GTP-U message (e.g., that includes an end of burst indication). Comparing (e.g., directly comparing) the RTP timestamps from different media can not be valid for the end of burst indication. For one type (e.g., each different type) of media, the RTP timestamp can be related to a sampling instant by pairing the RTP timestamp with a timestamp from a reference clock (e.g., a wall clock) that represents the time at which the data corresponding to the RTP timestamp was sampled. For example, to determine whether two or more media streams are part of the same burst, the timestamps in the RTP packet header can not be directly compared. The timestamps in the RTP packet header can be compared to the reference clock to determine whether the timestamps are contemporaneous transmissions.

[0164] Provided herein are feature(s) associated with detecting EOB based on a marker bit in the RTP header.

[0165] If a marker (M) bit in the RTP header is set, EOB can be detected. The marker bit can allow to mark significant events (e.g., such as frame boundaries) in the RTP packet data stream. If the marker bit is set, the marker bit can indicate that a frame boundary has been reached. In this case, the corresponding PDU can be marked with an end of burst notification in the RTP header extension, or the UPF can send a GTP-U message that includes an end of burst indication.

[0166] Provided herein are feature(s) associated with detecting EOB based on traffic patterns.

[0167] If EOB is detected at the time a PDU is received by the UPF, the UPF can transmit the PDU to the RAN with an EOB indication set in the GTP-U header that encapsulates the PDU sent to the RAN. If EOB is detected after a timeout by the UPF, the UPF can send a dummy PDU (e.g., a PDU of size 0, associated with a QoS flow / SDF) to the RAN. The dummy PDU can be associated with an EOB indication set in the GTP-U header.

[0168] Provided herein are feature(s) associated with detecting EOB based on inter-PDU timeout.

[0169] EOB detection can be based on inter-PDU timeout (e.g., based on a configuration including a BII with a burst-intra inter-PDU timeout IE). The UPF can use (e.g., initially) a burst start value to detect the start of a burst. If the start of a burst is detected, the UPF can start (e.g., begin) a timer for the inter-PDU timeout and reset the timer value each time a PDU of that service data flow is received. If the timer expires, the UPF can determine that the end of a burst is detected. The UPF can signal the EOB I to the RAN (e.g., the UPF can send an empty GTP-U packet including the EOB I for that SDF or QoS flow).

[0170] The UPF can determine that a PDU set is the last PDU set of a burst (e.g., in cases where there is a single PDU set per burst, or when the UPF knows / learns the number of PDU sets per burst). For example, the UPF can determine that a PDU is the last PDU of a PDU set by comparing the number of bytes received in the PDU set to the PDU set size IE value. In this case, the UPF can not (e.g., can not need to) wait for a timeout and can send an empty GTP-U packet (which includes the EOB I). The UPF can signal the EOB I in the GTP-U packet sent by the UPF to the RAN. The EOB I can indicate the last received PDU in the PDU set.

[0171] Provided herein are feature(s) associated with detecting EOB based on a number of PDU sets or a burst size.

[0172] Provided herein are feature(s) associated with detecting EOB based on counting PDU sets in a burst. For example, EOB can be detected based on a configuration including a BII with a trigger IE “PDU set ID” associated with an end of burst IE with a “number of transitions to a different value” and a fixed value indicating the number of transitions of the PDU set ID. The UPF can learn the number of PDU sets in a burst by analyzing traffic (e.g., rather than obtaining a fixed number of PDU sets from the BII) (e.g., during a burst processing initialization state).

[0173] If the start of a burst is detected, the UPF can count PDU sets after the start of the burst. If the number of received PDU sets completed corresponds to the configured / learned number of PDU sets per burst, the UPF can determine that the end of a burst is detected. The UPF can determine that a PDU set is complete if all PDUs in the set are received or if (e.g., after a timeout elapses) all PDUs in the set are received or determined to have been lost.

[0174] The UPF can count the received bytes and compare the number of received bytes to the burst size configured with the BII. The UPF can detect the EOB if the received size (e.g., the number of received bytes) reaches the configured burst size and if, at the same time, no start of other burst is determined.

[0175] Features are provided herein associated with detecting EOB based on other traffic patterns.

[0176] EOB can be detected based on traffic patterns (e.g., based on a configuration including a BII with a trigger IE “PDU Set ID” associated with an end IE of a burst with a “detected transition pattern”). The UPF can use a burst start value to detect the start of a burst. For example, the UPF can measure the jitter at the start of consecutive bursts. The UPF can use the trigger IE ID to identify a pattern in the burst. If one pattern repeats n times in a row (e.g., n is a value based on a protocol ID, a configuration, or an internal algorithm), the UPF can use the pattern to detect the end of a burst.

[0177] Features are provided herein associated with indicating EOB to a RAN (e.g., NG-RAN).

[0178] The UPF can indicate (e.g., to the NG-RAN) that the end of a burst has been detected. The indication can be sent in a GTP-U message. The RAN (e.g., NG-RAN) can use the indication to put the WTRU in a sleep (e.g., low power) state. Figure 8 An example of a UPF indicating a detected EOB is shown.

[0179] In Figure 8 , at 1, the AS can transmit DL PDUs to the WTRU. The DL PDUs can enter the 5G system at the UPF. The order of reception of the DL PDUs can be different from the order in which the AS transmitted them.

[0180] At 2, the UPF can use configuration information (e.g., received burst information, as shown in Figure 4 , to detect the end of a PDU set burst. The UPF can send the end of burst information to the RAN. Features are described herein associated with sending EOB information to the RAN.

[0181] At 3, the RAN can use the EOB information to determine whether and / or when to put the WTRU in a sleep (e.g., low power) state (e.g., by configuring a WTRU power saving management scheme such as connected mode DRX).

[0182] The EOB indication can be sent to the RAN in a G-PDU GTP-U message. The header extension of the G-PDU packet can include the EOB I. The UPF can determine whether and / or when to include the EOB I.

[0183] The UPF can receive another PDU that is part of the same PDU set burst associated with the EOB I (e.g., after the UPF sends the EOB I to the NG-RAN). For example, the UPF can receive another PDU from the same PDU set burst if the order in which the UPF receives packets (e.g., PDUs) can be different from the order in which the AS transmits the packets. To reduce the likelihood that the EOB I can trigger the RAN to put the WTRU in a sleep state before the additional PDU(s) of the burst are received, the UPF can send a wait time to the RAN with the EOB I. The wait time can be included in the header extension. The wait time can be an indication to the RAN that the end of the burst can not be assumed until after the wait time has expired and the EOB I has been received.

[0184] The UPF can be configured by the SMF with the wait time (e.g., as shown in Figure 4 The UPF can determine the wait time based on the contents of the burst identification information (e.g., the protocol ID). The wait time can be sent to the RAN as part of the QoS profile.

[0185] If the UPF detects that the UPF has received the first PDU of the burst, the UPF can send a GTP-U message (e.g., a new GTP-U message) to the RAN node (e.g., the NG-RAN node). The new GTP-U message can identify the burst and indicate the size of the burst. The RAN can (e.g., then can) use this information to detect the end of the burst. For example, the RAN can determine that the burst has ended if the amount of data received matches the indicated size of the burst. The burst can be identified by a QoS flow identifier. The QoS flow identifier can be used to identify the burst if the QoS flow is not expected to carry data not associated with the burst (e.g., the QoS flow is expected to only carry data associated with the burst during the transmission of the burst). The burst can be identified by one or more PDU set identifiers. The one or more PDU set identifiers can include an indication to the RAN that data that is part of (e.g., only data that is part of) the identified PDU set is part of the burst. The burst can be identified by the one or more PDU set identifiers if the QoS flow is expected to carry (e.g., also carry) data not associated with the burst.

[0186] A new GTP-U message can indicate a time value for the RAN to use to configure a timer. When the timer expires, the RAN can determine (e.g., assume) that the burst is over. For example, if the timer expires, the RAN can determine (e.g., assume) that the burst is over even if the amount of data received does not match the indicated size. The UPF can trigger sending a new GTP-U message when it receives the first PDU of a burst. However, the first PDU detected by the UPF can not be the first PDU transmitted by the AS (e.g., because the order in which packets are received can be different than the order in which packets are transmitted). The UPF can send a new GTP-U message to the RAN to indicate the start of a burst and provide information about the burst (e.g., so that the NG-RAN can detect the end of the burst). This technique can be more accurate than some other techniques (e.g., such as a method in which the UPF detects the end of a data burst by checking for an indication in an application traffic header). For example, this technique can be more accurate because PDU(s) from a burst can be received even after the UPF detects an indication (e.g., in an application layer header) of the end of the burst (e.g., because packets can be received in a different order than the order in which the packets were transmitted).

[0187] Features are provided herein associated with RAN-based EOB detection.

[0188] Features are provided herein associated with configuration and behavior of the RAN.

[0189] The RAN can be configured to detect the end of a burst. Configuration information can be sent to the RAN by the SMF (e.g., in a QoS profile IE).

[0190] The QoS profile can include a BII IE.

[0191] The BII sent to the RAN can include a trigger IE ID. The trigger IE ID can identify an IE present in a GTP-U message encapsulating a PDU. For example, the trigger IE ID can identify a PDU set IE, such as a PDU set ID, a PDU set size, a PDU set start indication, a PDU set end indication, a PDU set importance, a PDU sequence number within the set, a PSII, PDU set dependency information, a burst size, a burst time length, and / or an EOB I.

[0192] The start of a burst can be identified (e.g., in a BII) as the first received PDU of a PDU set (e.g., any independent PDU set that is marked as not dependent for decoding on any other PDU set).

[0193] If the RAN receives more than N PDUs consecutively or in quick succession (e.g., with a time gap shorter than a configured inter-PDU timeout within a burst), the start of a burst can be identified (e.g., in the BII). The value of N can be configured (e.g., in the burst start value in the BII).

[0194] If an inter-PDU timeout occurs, the end of a burst can be identified (e.g., in the BII).

[0195] If a set of N PDUs is completely received (e.g., where all PDUs are received or determined to be missing, e.g., based on a timeout), the end of a burst can be identified (e.g., in the BII). The value of N can be configured (e.g., in the burst start value in the BII).

[0196] If a PDU with an EOB set is received from the UPF (e.g., in a GTP-U header), the end of a burst can be identified (e.g., in the BII). More than one EOB detection technique (e.g., RAN-based EOB detection and UPF-based EOB detection) can be active at the same time. In this case, the BII used to configure the RAN can describe two ends of a burst (e.g., one end of a burst for detecting EOB using EOBIs, and another end of a burst for detecting EOB using another technique, as described herein).

[0197] An example BII can include information identifying the start of a burst using a timestamp change. An example BII can include information identifying the end of a burst (e.g., using an inter-PDU timeout based or trigger IE based technique). The UPF can obtain a timestamp (or a value derived from a timestamp, e.g., a subset of the bits used to encode the timestamp) in order to use a timestamp change based technique, and the UPF can provide the timestamp to the RAN (e.g., in a GTP-U header field).

[0198] If the size of received PDUs reaches an expected size of a burst (e.g., as configured in a BII and / or as sent by the UPF to the RAN, e.g., using a GTP-U message containing a burst size, as described herein), the UPF or RAN can identify an EOB.

[0199] Features are provided herein associated with a RAN that detects EOBs based on traffic patterns.

[0200] The feature(s) described herein related to UPF-based EOB detection (e.g., using inter-PDU timeout, number of PDU sets, and other traffic patterns) can be similarly performed by the RAN (e.g., based on configured BII). The RAN can use the indication or information to help determine whether and / or whether / when to place the WTRU in a sleep (low power) state (e.g., to thereby save WTRU power and increase the WTRU’s battery life).

[0201] The present disclosure describes apparatuses and methods for detecting and indicating an end of a burst by a user plane function (e.g., by a network node).

[0202] A network node can receive configuration information for detecting an end of a burst of packet data units (PDUs). The network node can receive the burst of PDU sets. The network node can detect the end of the burst of PDU sets based on the configuration information. The network node can transmit an indication of the detected end of the burst of PDU sets to a base station.

[0203] The configuration information can include an IE indicating a time value at which a start of the burst of PDU sets can be received. Detecting the end of the burst of PDU sets can involve using the time value to determine a number of PDU sets. The network node can use the number of PDU sets to determine a PDU pattern. The network node can use the PDU pattern to determine the end of the burst of PDU sets. The number of PDU sets can be associated with the burst of PDU sets. The time value can include a timestamp value.

[0204] Detecting the end of the burst of PDU sets can involve determining a first timestamp associated with a first PDU set and the burst of PDU sets, determining a second timestamp associated with a second PDU set, and using the first timestamp and the second timestamp to determine the end of the burst of PDU sets. The second timestamp can be different than the first timestamp. The burst of PDU sets can include the first PDU set.

[0205] Detecting the end of the burst of PDU sets can involve identifying (e.g., determining) a message header (e.g., of a PDU in the burst) indicating the end of the burst of PDU sets, and using the message header to determine the end of the burst of PDU sets. The network node can determine that the PDU satisfies an EOB condition based on the indication in the message header. The indication can be transmitted to the base station when the message header is used to determine the end of the burst of PDU sets.

[0206] Detecting an end of a burst of PDU sets can involve determining that a PDU set is received during a first time duration. The network node can determine a second time duration based on the determination that the PDU set is received during the first time duration. The network node can determine the end of the burst of PDU sets when the second time duration has elapsed. The burst of PDU sets can include the PDU set.

[0207] Detecting an end of a burst of PDU sets can involve determining a number of PDU sets associated with the burst of PDU sets. The network node can determine the PDU set using the determined number of PDU sets. The network node can determine an expected byte size value for the determined PDU set. The network node can determine a received byte size value that indicates a calculated byte size of the determined PDU set. The network node can determine the end of the burst of PDU sets when the received byte size value is similar to the expected byte size value.

[0208] Detecting an end of a burst of PDU sets can involve determining an expected byte size value for the burst of PDU sets. The network node can determine a received byte size value using the burst of PDU sets. The network node can determine the end of the burst of PDU sets when the received byte size value is within an acceptable range of the expected byte size value (e.g., similar to the expected byte size value).

[0209] Detecting an end of a burst of PDU sets can involve determining a number of PDU sets associated with the burst of PDU sets. The network node can determine an expected byte size value for the number of PDU sets. The network node can determine a received byte size value using the number of PDU sets. The network node can determine the end of the burst of PDU sets when the received byte size value is within an acceptable range of the expected byte size value (e.g., similar to the expected byte size value).

[0210] The configuration information can include an information element (IE) that indicates a PDU set identifier (ID). Detecting an end of a burst of PDU sets can involve determining a PDU pattern using the PDU set identifier. The network node can determine a number of PDU sets associated with the burst of PDU sets using the PDU pattern. The network node can determine the end of the burst of PDU sets using the determined number of PDU sets.

[0211] The present disclosure describes apparatuses and methods for detecting and indicating an end of a burst by a radio access network (e.g., by a base station).

[0212] A base station can receive configuration information for detecting an end of a burst of packet data units (PDUs) sets. The base station can receive the burst of PDU sets. The base station can detect the end of the burst of PDU sets based on the configuration information. The base station can transmit a message to change a configuration of a device (e.g., a wireless transmission / reception unit (WTRU)) based on the detected end of the burst of PDU sets. The configuration of the device can indicate a time for the device to enter a sleep state. The base station can determine that the burst of PDUs is associated with extended reality (XR) traffic.

[0213] The configuration information can include an information element (IE) indicating a start of the burst of PDU sets (e.g., a time value associated with the start of the burst of PDU sets can be received). The network node can determine a number of PDU sets in the burst of PDU sets based on the start of the burst. For example, detecting the end of the burst of PDU sets can involve using the time value to determine the number of PDU sets associated with the burst of PDU sets. The network node can use the number of PDU sets in the burst of PDU sets to determine a burst pattern. The network node can use the PDU pattern to determine the end of the burst of PDU sets. For example, the network node can determine that the PDU satisfies the condition based on the burst pattern. The time value can include a timestamp value.

[0214] Detecting the EOB of the PDU sets can involve determining a first timestamp associated with a first PDU set in the burst of PDU sets. The network node can determine a second timestamp associated with a second PDU set in the burst of PDU sets. The network node can use the first timestamp and the second timestamp to determine the EOB of the PDU sets. For example, the network node can determine that the PDU satisfies the condition based on the second timestamp being different from the first timestamp. The second timestamp can be different from the first timestamp. The burst of PDU sets can include the first PDU set.

[0215] Detecting the end of the burst of PDU sets can involve determining that a PDU set (e.g., in the burst of PDU sets) is received during a first duration of time. The network node can determine a second duration of time based on the determination that the PDU set is received during the first duration of time. If the second duration of time has elapsed, the network node can determine that the PDU satisfies the condition (e.g., the end of the burst of PDU sets can be detected). The burst of PDU sets can include the PDU set.

[0216] Detecting the end of the burst of PDU sets can involve determining a number of PDU sets associated with the burst of PDU sets. The network node can determine the PDU sets using the determined number of PDU sets. The network node can determine an expected byte size value for the determined PDU sets. The network node can determine a received byte size value that indicates a calculated byte size of the determined PDU sets. If / when the received byte size value is within an acceptable range of the expected byte size value (e.g., similar to the expected byte size value), the network node can determine the end of the burst of PDU sets.

[0217] Detecting the end of the burst of PDU sets can involve determining an expected byte size value for the burst of PDU sets. The network node can determine a received byte size value using the burst of PDU sets. If / when the received byte size value is within an acceptable range of the expected byte size value (e.g., similar to the expected byte size value), the network node can determine the end of the burst of PDU sets. Detecting the end of the burst of PDU sets can involve determining a number of PDU sets associated with the burst of PDU sets. The network node can determine an expected byte size value for the number of PDU sets. The network node can determine a received byte size value using the number of PDU sets. If / when the received byte size value is within an acceptable range of the expected byte size value (e.g., similar to the expected byte size value), the network node can determine the end of the burst of PDU sets.

[0218] The configuration information can include an information element (IE) that indicates a PDU set identifier (ID). Detecting the end of the burst of PDU sets can involve determining a PDU pattern using the PDU set identifier. The network node can determine a number of PDU sets associated with the burst of PDU sets using the PDU pattern. The network node can determine the end of the burst of PDU sets using the determined number of PDU sets.

[0219] Although the above-described features and elements can be described in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements.

[0220] Although implementations described herein can consider 3GPP specific protocols, it should be understood that implementations described herein are not limited to this scenario and can 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 should be understood that the solutions described herein are not limited to this scenario and are applicable to other wireless systems as well.

[0221] The processes described above can 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 (wireless and / or wired, which are transmitted through a wired and / or wireless connection) and 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 disks (CDs) - ROM disks, and / or digital versatile disks (DVDs). A processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.

Claims

1. A network node, the network node comprising: a processor configured to: receive configuration information, the configuration information indicating a condition indicating an end of a burst of packet data units (PDUs) sets; receive the burst of PDU sets, wherein the burst of PDU sets comprises PDUs; detect the end of the burst of PDU sets based on the PDUs satisfying the condition; and transmit an indication of the end of the burst of PDU sets to a base station.

2. The network node of claim 1, wherein the burst of PDU sets is a first burst of PDU sets, the configuration information further comprises an information element (IE) indicating a start of a second burst of PDU sets, the processor is further configured to receive the second burst of PDU sets, and the processor being configured to detect the end of the first burst of PDU sets based on the PDUs satisfying the condition comprises the processor being configured to: determine a number of PDU sets in the second burst of PDU sets based on the start of the second burst of PDU sets; determine a burst pattern based on the number of PDU sets in the second burst of PDU sets; and determine that the PDUs satisfy the condition based on the burst pattern.

3. The network node of claim 1, wherein the processor being configured to detect the end of the burst of PDU sets based on the PDUs satisfying the condition comprises the processor being configured to: determine a first timestamp associated with a first PDU set in the burst of PDU sets; determine a second timestamp associated with a second PDU set, wherein the second timestamp is different than the first timestamp; and determine that the PDUs satisfy the condition based on the second timestamp being different than the first timestamp.

4. The network node of claim 1, wherein the processor being configured to detect the end of the burst of PDU sets based on the PDUs satisfying the condition comprises the processor being configured to: identify a message header of a PDU in the burst of PDU sets, wherein the message header indicates the end of the burst of PDU sets; and determine that the PDUs satisfy the condition based on the indication in the message header.

5. The network node of claim 1, wherein the processor being configured to detect the end of the burst of PDU sets based on the PDUs satisfying the condition comprises the processor being configured to: determine that a PDU set was received during a first duration of time, wherein the burst of PDU sets comprises the PDU set; determine a second duration of time based on the determination that the PDU set was received during the first duration of time; and determine that the PDUs satisfy the condition on a condition that the second duration of time has elapsed.

6. The network node of claim 1, wherein the processor being configured to detect the end of the burst of PDU sets based on the PDUs satisfying the condition comprises the processor being configured to: determine a number of PDU sets, wherein the number of PDU sets is associated with the burst of PDU sets; determine the PDU sets based on the determined number of PDU sets; determine an expected byte size value for the determined PDU sets; and determine that the PDUs satisfy the condition based on the determined expected byte size value. ​ ​ ​ determining a received byte size value, wherein the received byte size value indicates a calculated byte size of the determined set of PDUs; and determining that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of an expected byte size value.

7. The network node of claim 1, wherein the processor configured to detect an end of the burst of the set of PDUs based on the PDU satisfying the condition comprises the processor configured to: determine an expected byte size value for the burst of the set of PDUs; determine a received byte size value based on the burst of the set of PDUs; and determine that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

8. The network node of claim 1, wherein the processor configured to detect an end of the burst of the set of PDUs based on the PDU satisfying the condition comprises the processor configured to: determine a number of sets of PDUs associated with the burst of the set of PDUs; determine an expected byte size value for the number of sets of PDUs; determine a received byte size value based on the number of sets of PDUs; and determine that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

9. The network node of claim 1, wherein the configuration information further comprises an information element (IE) indicating a set of PDU identifier (ID), and wherein the processor configured to detect an end of the burst of the set of PDUs based on the PDU satisfying the condition comprises the processor configured to: determine a burst pattern based on the set of PDU identifier; determine a number of sets of PDUs based on the burst pattern, wherein the number of sets of PDUs is associated with the burst of the set of PDUs; and determine that the PDU satisfies the condition based on the determined number of sets of PDUs.

10. A method to be performed by a network node, the method comprising: receiving configuration information indicating a condition indicating an end of a burst of a set of packet data units (PDUs); receiving the burst of the set of PDUs, wherein the burst of the set of PDUs comprises PDUs; detecting an end of the burst of the set of PDUs based on the PDU satisfying the condition; and transmitting an indication of the end of the burst of the set of PDUs to a base station.

11. The method of claim 10, wherein the burst of the set of PDUs is a first burst of the set of PDUs, the configuration information further comprises an information element (IE) indicating a start of a second burst of the set of PDUs, the method further comprises receiving the second burst of the set of PDUs, and detecting the end of the first burst of the set of PDUs based on the PDU satisfying the condition comprises: determining a number of sets of PDUs in the second burst of the set of PDUs based on the start of the second burst of the set of PDUs; determining a burst pattern based on the number of sets of PDUs in the second burst of the set of PDUs; and determining that the PDU satisfies the condition based on the burst pattern.

12. The method of claim 10, wherein detecting the end of the burst of the set of PDUs based on the PDU satisfying the condition comprises: determining a first timestamp associated with a first set of PDUs in the burst of the set of PDUs; ​ ​ ​ determining a second timestamp associated with the second set of PDUs, wherein the second timestamp is different than the first timestamp; and based on the second timestamp being different than the first timestamp, determining that the PDU satisfies the condition.

13. The method of claim 10, wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: identifying a message header of the PDU in the burst of sets of PDUs, wherein the message header indicates an end of the burst of sets of PDUs; and determining that the PDU satisfies the condition based on the indication in the message header.

14. The method of claim 10, wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: determining that a set of PDUs was received during a first time duration, wherein the burst of sets of PDUs includes the set of PDUs; determining a second time duration based on the determination that the set of PDUs was received during the first time duration; and determining that the PDU satisfies the condition on a condition that the second time duration has elapsed.

15. The method of claim 10, wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: determining a number of sets of PDUs, wherein the number of sets of PDUs is associated with the burst of sets of PDUs; determining a set of PDUs based on the determined number of sets of PDUs; determining an expected byte size value for the determined set of PDUs; determining a received byte size value, wherein the received byte size value indicates a calculated byte size of the determined set of PDUs; and determining that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

16. The method of claim 10, wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: determining an expected byte size value for the burst of sets of PDUs; determining a received byte size value based on the burst of sets of PDUs; and determining that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

17. The method of claim 10, wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: determining a number of sets of PDUs associated with the burst of sets of PDUs; determining an expected byte size value for the number of sets of PDUs; determining a received byte size value based on the number of sets of PDUs; and determining that the PDU satisfies the condition on a condition that the received byte size value is within an acceptable range of the expected byte size value.

18. The method of claim 10, wherein the configuration information further comprises an information element (IE) indicating a set of PDU identifier (ID), and wherein detecting an end of the burst of sets of PDUs based on the PDU satisfying the condition comprises: determining a burst pattern based on the set of PDU identifier; determining a number of sets of PDUs based on the burst pattern, wherein the number of sets of PDUs is associated with the burst of sets of PDUs; and determining that the PDU satisfies the condition based on the determined number of sets of PDUs. ​

Images