PDU Set Information RTP Header Extension

Abstract

Methods for signaling PDU set RTP header extensions (HE) may include negotiating the use of RTP HE between the AS and the AF. These methods may include the AF generating an RTP HE ID and the AF sending the RTP HE ID to the AS. The methods may also include the AS sending the RTP HE ID to the AF. The methods may include the AF sending the use of PDU set RTP HE to the NEF and the NEF sending PDU set RTP HE to the PCF. The methods may include the PCF constructing a PCC rule containing PDU set RTP HE usage information and the PCF sending the PCC rule to the SMF. The methods may also include the SMF sending PDU set RTP HE usage information to the UPF.

Description

Background Art

[0001] Related applications This application claims the benefit and priority of U.S. Patent Application No. 63 / 495,203, entitled "PDU Set Information RTP Header Extension," filed on April 10, 2023, the contents of which are hereby incorporated by reference in their entirety.

[0002] Background technology A packet data unit (PDU) set enables the conveyance of large application layer data across multiple PDUs. However, the PDUs that each carry a part of the data need to be identified as part of a set, or else it may be impossible or difficult to reassemble the fragments or parts of the data. Classical transport layer packet fragmentation protocols may be insufficient for PDU sets because they lack information associated with the importance of the set, variable bit lengths, and other characteristics.

Summary of the Invention

[0003] To address the above and other problems, the present disclosure is directed to implementations of systems and methods for signaling packet data unit (PDU) set information via a real-time protocol (RTP) header extension (HE). Specifically, the implementations of the systems and methods described herein signal PDU set information associated with the importance or priority of the set, discardability including the syntax, semantics, and guidelines of a discardability flag, how network nodes such as user plane function (UPF) can identify the presence of PDU set information in a PDU, and how to handle variable length fields such as PDU sequence numbers and / or PDU set sequence numbers.

[0004] In some embodiments, the method may include negotiating between the Application Server (AS) and the Application Function (AF) the use of RTP HE for sending PDU set information between the AS and the User Plane Function (UPF). The method may include the AF generating an RTP HE identifier (ID) and the AF sending the RTP HE ID to the AS. The method may include the AS using the RTP HE ID during the time it takes to generate an RTP session. The method may include the AS sending the RTP HE ID to the AF. The method may include the AF sending the use of PDU set RTP HE to the Network Exposure Function (NEF). Sending the use of PDU set RTP HE to the NEF by the AF may include calling an Application Programming Interface (API) which may include the AF sending an Nnef_AFsessionWithQoS request to the NEF and the AF receiving an Nnef_AFsessionWithQoS response from the NEF. The method may include the NEF sending the PDU set RTP HE to the Policy Control Function (PCF). Sending PDU Set RTP HE from the NEF to the PCF may include calling an API that may include sending an Npcf_PolicyAuthorization request from the NEF to the PCF and receiving an Npcf_PolicyAuthorization response from the PCF. The method may include the PCF constructing policy and charging control (PCC) rules that include PDU Set RTP HE usage information. The method may include the PCF sending PCC rules to the Session Management Function (SMF). The PCF may send PCC rules to the SMF in response to the SMF calling an API that may include sending an Npcf_SMPolicyControl request from the SMF to the PCF and receiving an Npcf_SMPolicyControl response from the SMF. The method may include the SMF sending PDU Set RTP HE usage information to the UPF. PDU Set RTP HE usage information may be sent from the SMF to the UPF in an N4 message.Negotiating the use of RTP HE between AS and AF can be done via the M3 interface.

[0005] A more detailed understanding can be obtained from the following explanation, which is given as an example in conjunction with the attached drawings, where the same reference numbers in the drawings refer to the same elements. [Brief explanation of the drawing]

[0006] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transmit / receive unit (WTRU) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RAN and CN that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This figure shows an example of an RTP header extension using a 1-byte header format, according to several embodiments. [Figure 3] This figure shows an example of an RTP header extension using a 2-byte header format, according to several embodiments. [Figure 4] This figure shows an example of a NAL unit type octet in an RTP packet payload according to several embodiments. [Figure 5] This figure shows an example structure of an HEVC NAL unit header according to several embodiments. [Figure 6] This figure shows an example structure of a VVCNAL unit header according to several embodiments. [Figure 7] This figure shows illustrative procedures for constructing a UPF according to several embodiments. [Figure 8] This figure shows an example of an RTP header extension using a 1-byte header format with slice number signaling, according to several embodiments. [Figure 9] This figure shows an example of an RTP header extension using a 2-byte header format with slice number signaling, according to several embodiments. [Figure 10] This figure shows another example of an RTP header extension using a 1-byte header format with slice number signaling, according to several embodiments. [Figure 11] This figure shows another example of an RTP header extension using a 2-byte header format with slice number signaling, according to several embodiments. [Figure 12] This is a flowchart of a method for signaling PDU set information via RTP header extensions, according to several embodiments. [Modes for carrying out the invention]

[0007] Before describing the specific implementation details of systems and methods for signaling packet data unit set information, it may be helpful to briefly describe the system environments in which these systems and methods may be implemented.

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

[0009] As shown in Figure 1A, the communication system 100 may include WTRUs (wireless transmit / receive units) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the internet 110, and other networks 112, but it will be understood that the disclosed embodiments consider any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d may all also be called stations (STAs) and may be configured to transmit and / or receive wireless signals, and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscriber-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0010] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks such as CN 106, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be next-generation NodeBs such as base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, gNodeBs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each represented as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0012] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0013] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in the RAN 104 may implement radio technologies such as Universal Mobile Communications System (UMTS) Terrestrial Radio Access (UTRA), which may establish an air interface 116 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0015] In one embodiment, base station 114a and WTRU 102a, 102b, 102c can implement radio technologies such as NR radio access, which can establish an air interface 116 using NR.

[0016] In one embodiment, base station 114a, and WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a, and WTRUs 102a, 102b, 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. 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., eNBs and gNBs).

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

[0018] The base station 114b in FIG. 1A can be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a workplace, home, vehicle, campus, industrial facility, air corridor (for use by drones, for example), road, etc. In one embodiment, the base station 114b, and the WTRUs 102c, 102d can implement a wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b, and the WTRUs 102c, 102d can implement a wireless 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 pico cell or a femto cell. As shown in FIG. 1A, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the CN 106.

[0019] RAN104 can communicate with CN106, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN106 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 and / or CN106 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 or different RATs. For example, in addition to being connected to RAN104 which can utilize NR radio technology, CN106 can also communicate with other RANs (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0020] CN106 can also act as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmit Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 or a different RAT.

[0021] Some or all of the WTRUs 102a, 102b, 102c, and 102d within the communication system 100 can include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with different wireless networks via different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio technology.

[0022] Figure 1B is a system diagram showing an exemplary WTRU102. As shown in Figure 1B, the WTRU102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU102 may include any subcombinations of the aforementioned elements while maintaining consistency with one embodiment.

[0023] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. 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 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B represents the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0026] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmit / receive element 122 and to demodulate the signal to be received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

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

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

[0029] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its position based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any suitable positioning method while maintaining consistency with one embodiment.

[0030] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripherals 138 may include one or more sensors. The sensors may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor, a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biosensor, a humidity sensor, etc.

[0031] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signals associated with a particular subframe for both UL (for example, for transmission) and DL (for example, for reception) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit for reducing or substantially eliminating self-interference through signal processing either in hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU102 may include a half-duplex radio where the transmission and reception of some or all of the signals associated with a particular subframe for either UL (for example, for transmission) or DL ​​(for example, for reception) may be parallel and / or simultaneous.

[0032] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may communicate with WTRU102a, 102b, and 102c via the air interface 116 using E-UTRA wireless technology. RAN104 can also communicate with CN106.

[0033] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with one embodiment. Each of eNode-B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c can implement MIMO technology. Thus, eNode-B160a can, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a.

[0034] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the eNode-B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0035] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the aforementioned elements are represented as part of CN106, it should be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0036] The MME162 may be connected to each of the eNode-B162a, 162b, and 162c within RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 employing GSM and / or other radio technologies such as WCDMA and other RANs (not shown).

[0037] The SGW164 can be connected to each of the eNodeB160a, 160b, and 160c within RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions such as anchoring the user plane during inter-eNodeB handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0038] SGW164 can be connected to PGW166, which provides WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0039] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and traditional land-line communication devices. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0040] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in a typical embodiment, such a terminal is thought to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0041] In a typical embodiment, the other network 112 may be a WLAN.

[0042] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a distributed system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS to the STA may arrive via the AP and be sent to the STA. Traffic originating from the STA to destinations outside the BSS may be sent to the AP to be sent to their respective destinations. Traffic between STAs within the BSS may also be sent via the AP; for example, a source STA may send traffic to the AP, and the AP may send traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (e.g., directly between them) using a Direct Link Setup (DLS). In a typical embodiment, the DLS may use 802.11eDLS or 802.11z Tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode does not need to have APs, and STAs within or using IBSS (e.g., all STAs) can communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as the “ad-hoc” mode of communication.

[0043] When using the 802.11ac infrastructure operating mode, or a similar operating mode, an AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., 20 MHz bandwidth) or a dynamically set width. The primary channel may also be the operating channel of the BSS and may be used by the STA to establish a connection with the AP. In one typical embodiment, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented in an 802.11 system, for example. With respect to CSMA / CA, the STA, including the AP (e.g., all STAs), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA may backoff. One STA (e.g., only one station) can transmit at any given time on a given BSS.

[0044] A high-throughput (HT) STA can form a 40MHz wide channel for communication by using a 40MHz wide channel via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels, for example.

[0045] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels or two non-consecutive 80MHz channels, which may be called an 80+80 configuration. For 80+80 configurations, data can be passed through a segment parser that, after channel encoding, can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC).

[0046] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, e.g., limited capabilities, including support for specific and / or limited bandwidths (e.g., support only for that bandwidth). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0047] A WLAN system can support multiple channels and channel bandwidths, including 802.11n, 802.11ac, 802.11af, and 802.11ah, and may include a channel designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the smallest bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes, the primary channel may be 1MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only supports) the 1MHz mode. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy by an STA (supporting only the 1MHz operating mode) transmitting to the AP, all available frequency bandwidth may be considered busy, even if the majority of the available frequency bandwidth remains idle.

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

[0049] Figure 1D is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 may communicate with WTRU102a, 102b, and 102c via the air interface 116 using NR radio technology. RAN104 can also communicate with CN106.

[0050] RAN104 may include gNB180a, 180b, and 180c, but it will be understood that RAN104 can include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c can implement MIMO technology. For example, gNB180a and 180b can use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a can, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from WTRU102a. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c can implement coordinated multipoint (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0051] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or sustaining varying absolute times).

[0052] The gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c without accessing other RANs (e.g., eNode-B160a, 160b, and 160c). In a standalone configuration, the WTRU102a, 102b, and 102c can use one or more of the gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, the WTRU102a, 102b, and 102c can communicate with the gNB180a, 180b, and 180c using unlicensed in-band signals. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with / connect to gNB180a, 180b, and 180c while also communicating with / connecting to other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more eNode-B160a, 160b, and 160c. In a non-standalone configuration, eNode-B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, while gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0054] The CN106 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although the aforementioned elements are represented as part of CN106, it will be understood that any of these elements may be owned and / or operated by entities other than the CN operator.

[0055] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c within RAN104 via the N2 interface and can act as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating non-accessible stratum (NAS) signaling, mobility management, etc. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service being utilized. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced high-capacity mobile broadband (eMBB) access, services for MTC access, and so on. AMF182a, 182b can provide control plane functionality for exchange between RAN104 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0056] SMF183a and 183b can be connected to AMF182a and 182b in CN106 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN106 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure traffic routing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0057] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c within RAN104, which can provide WTRU102a, 102b, and 102c with access to packet-switched networks such as the Internet 110, thereby facilitating communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0058] CN106 can facilitate communication with other networks. For example, CN106 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to local DN185a, 185b through UPF184a, 184b via an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and DN185a, 185b.

[0059] With regard to Figures 1A to 1D and their corresponding descriptions, one or more or all of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, eNode-B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

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

[0061] One or more emulation devices can perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario within a test laboratory and / or an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Wireless communication via direct RF coupling and / or RF circuitry (which may include, for example, one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0062] The following abbreviations and acronyms: AF Application Function AS Application Server EOB burst ended GTP-U GPRS Tunneling Protocol User Plane Protocol HE Header Extension 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 Functionality XR Augmented Reality , may be referenced.

[0063] As described above, a packet data unit (PDU) set enables the transport of large application layer data across multiple PDUs. However, each PDU carrying a portion of the data needs to be identified as part of the set, otherwise reassembling the fragment or portion of the data may be difficult, if not impossible. Classical transport layer packet fragmentation protocols may be insufficient for PDU sets because they lack information that may be necessary or desirable for their use. For example, in some implementations, it may be useful to communicate the PDU set sequence number or the sequence numbers of the PDUs within the PDU set, the boundaries of the PDU set (e.g., the start and / or end of the PDU set marking, the PDU set size in terms of the number of PDUs, etc.), the importance or priority of the PDU set (in absolute scale or relative to other PDUs), the size of the PDU set in bytes, and an indication that the PDU may be discarded without significantly impacting the reassembled medium.

[0064] To address the above and other issues, this disclosure is directed to implementations of systems and methods for signaling packet data unit (PDU) set information via Real-Time Protocol (RTP) Header Extensions (HE). More specifically, the implementations of systems and methods described herein provide signaling how network nodes can identify the presence of PDU set information in a PDU, including PDU set information associated with the importance or priority of the set, discardability including syntax, semantics, and guidelines for discardability flags, user plane functions (UPF), and how to handle variable-length fields such as PDU sequence numbers and / or PDU set sequence numbers. For example, in some embodiments, the systems and methods described herein provide signaling for the importance / priority field of a PDU set, signaling for a PDU set discardability flag, syntax, semantics, and guidelines for how to set the discardability flag, identification of the presence of a PDU set information RTP header extension in one or more received PDUs, and signaling between the AS and UPF for the use of the PDU set RTP header extension for the transport of PDU set information, as well as the number of bits required to signal the PDU sequence number (PSN) and PDU set sequence number (PSSN).

[0065] In some implementations, the RTP header extension mechanism defined in RFC 8285 may be extended to define new RTP header extensions for carrying PDU set information. In various implementations, RTP header extensions (HEs) may be defined using one-byte extension formats and two-byte extension formats.

[0066] The syntax and semantics of the PDU set information header extension can be defined as shown in Figures 2 and 3. Referring to Figure 2, an RTP header extension 200 using a one-byte header format is shown. The first two bytes (0xBEDE) are used to identify that the packet contains an RTP one-byte header extension, and the fifth byte (which starts the header extension itself) contains a four-bit identifier 202A and a four-bit length field 202B. The length field 202B specifies the remaining header length by one byte (i.e., a length of "0" indicates a one-byte header extension following the length field 202B). In the example in Figure 2, a length of 6 indicates that the header extension contains seven bytes (i.e., bytes 6 through 12).

[0067] Figure 3 shows an RTP header extension 300 using a two-byte header format. The first 12 bits (0x100) identify the two-byte header format, where the next 4 bits are a local application-specific identifier. The identifier 302A in byte 5 is expanded to a length of 1 byte, and similarly, the length is expanded to utilize byte 6. The length field 302B identifies the remaining header length but does not have the minus 1 of the one-byte format (i.e., a length of 0 indicates that there are no bytes following the length byte). In the example shown, there are 10 extra bytes after the length field 302B in the header extension.

[0068] Header extensions in either format may include some or all of the following fields: ● A 1-bit termination (E) flag. The E flag can indicate whether the current PDU is the last PDU in the PDU set. A value of 1 may indicate that this PDU is the last PDU in the PDU set. A value of 0 may indicate that this PDU is not the last PDU in the PDU set. ● Burst End (EOB) field, which can be 2 bits. The value of EOB can be set to 0x01 for the last PDU of a data burst. When this flag is set to 0x00, the current PDU is not the last PDU of the data burst. When this flag is set to 0x10, the EOB indication is not shown in the PDU set information RTP header extension. When this flag is set to 0x11, the PDU is part of the last PDU set of the data burst. For all PDUs in the last PDU set of the data burst, this flag value can be set to 0x11. ● A 4-bit importance or priority (PRI) field. This field may indicate the priority of a PDU set compared to other PDU sets in the same stream. A lower value in the priority field indicates higher importance. For example, a PDU set with a priority value of 0 may be more important than a PDU set with a priority value of 1. ● A 1-bit discardability (D) field. This field may indicate whether this PDU set can be discarded without significantly affecting the decoding of the medium. For example, when the field is set to 1, the PDU set can be discarded without significantly affecting decoding and reconstruction, and when the field is set to 0, the PDU set may not be discarded. ● The PDU set sequence number (PSSN), which can be 8 bits. This field may contain a value indicating the sequence number of the PDU set to which the current PDU belongs. When a video frame is coded using multiple slices, each PDU set contains the coded slice data. ● PDU Sequence Number (PSN), which can be 8 bits. This field may indicate the sequence number of the current PDU in the PDU set. When a video frame is coded using a single slice, the number of PDUs in the PDU set will be greater, and otherwise, this number will be smaller. ● A burst identifier (ID) that can be 8 bits. This value can be set as an identifier for a burst. PDUs intended to be sent in a single burst (for example, corresponding to the same displayed time) should have the same burst ID.

[0069] In some implementations, the importance or priority field of a PDU set may be set by the application server or source UE for the PDU. For example, in some implementations, a PDU set containing audio data may be set to the highest importance compared to other medium PDU sets. For instance, a PDU set belonging to an audio medium may be set to a priority value of 0x00. Since short audio errors or delays are typically more perceptible and annoying than short video errors or delays, it may be beneficial to send audio data with the highest priority or importance.

[0070] In some implementations, a reference frame is required to decode an entire group of frames (typically lasting tens of frames or tens of seconds), so a PDU set containing reference frames present in the video bitstream (e.g., I-frames or frames encoded with intra-frame compression only) is set with a higher priority than non-reference frames present in the video bitstream (e.g., P-frames or B-frames encoded based on the previous frame or bidirectionally based on the preceding and succeeding frames). Intra-random access pictures (IRAP) such as instantaneous decoder refresh (IDR) frames, clean random access (CRA) frames, access to broken links (BLA) frames, and graded decoding refresh (GDR) frames are set with a higher priority. The priority value for the above pictures can be set to 0x01.

[0071] Various implementations of video codecs may indicate the picture type in a header, such as a Network Abstraction Layer (NAL) unit header. The NAL unit header can be carried within an RTP packet, such as in a header extension block or within the payload. An example of a NAL unit header 400, like the one used in H.265 coding, is shown in Figure 4. The first bit is a forbidden bit (i.e., left as 0) to identify any transmission errors. The next two bits (sometimes called the NAL Reference Identifier or NRI, nal_ref_idc) indicate whether the NAL unit following the header is a reference frame or field, and the following five bits indicate the NAL unit type, which identifies the type of data structure (e.g., an encoded slice of a partition, a picture, or a sequence parameter set).

[0072] For example, in a VVC bitstream, a nal_unit_type field with a value in the range of 7 to 11 (inclusive) is an intra-random access picture (IRAP) picture. When the type field value in the Network Abstraction Layer (NAL) unit header of an RTP packet is in the range of 7 to 11 (inclusive), the corresponding PDU in that PDU set may be set with a good high priority value in the RTP header extension, for example, using 0x01.

[0073] Parameter set NAL units such as Sequence Parameter Set (SPS), Picture Parameter Set (PPS), and Video Parameter Set (VPS) are important for decoding bitstreams. Therefore, PDU sets having payload type field values ​​in the NAL unit header of an RTP packet corresponding to such parameter sets (e.g., in the range of 14 to 16 for VVC bitstreams) may be set with a higher priority in the RTP header extension. The priority value for such PDU sets may be set to 0x01.

[0074] Similarly, in HEVC bitstreams, the nal_unit_type field with a value in the range of 16 to 23 (inclusive) is an intra-random access picture (IRAP) picture. When the type field value in the NAL unit header of an RTP packet is in the range of 16 to 23 (inclusive), the corresponding PDU in that PDU set may be set with a higher priority value in the RTP header extension, for example, using 0x01.

[0075] Similarly, for HEVC bitstreams, parameter set NAL units such as the Sequence Parameter Set (SPS), Picture Parameter Set (PPS), and Video Parameter Set (VPS) can be identified by the corresponding type field value in the NAL unit header of the RTP packet, ranging from 32 to 34 (inclusive). As mentioned above, these information sets are important for decoding the bitstream, so they can be set with a higher priority within the RTP header extension. The priority value for such PDU sets can be set to 0x01.

[0076] In an H.264 bitstream, the nal_unit_type field with a value of 5 is an intra-random access picture (IRAP) picture. When the type field value in the NAL unit header of an RTP packet is 5, the corresponding PDU in that PDU set may be set with a higher priority value in the RTP header extension, for example, using 0x01.

[0077] H.264 parameter set NAL units, such as Sequence Parameter Set (SPS) and Picture Parameter Set (PPS), may be indicated in the NAL Unit header of an RTP packet with a payload type field value equal to 7, 8, 13, or 15. As with other video codecs, these parameter sets are important for decoding, and therefore may be sent with higher priority in the RTP header extension. The priority value for such PDU sets may be set to 0x01.

[0078] In video coding, time scalability is an option to decode only a portion of the frames within a video stream, rather than the entire stream. This allows media servers to reduce the bitrate sent to viewers who do not have enough bitrate or CPU to handle the entire stream. The picture with the lowest time identifier value is used as the reference picture within the bitstream.

[0079] Modern video codecs such as AVC, HEVC, and VVC include improved support for temporal scalability by including time ID (TID) signaling in the NAL unit header. This temporal scalability support comes with limitations, such as the fact that pictures in a particular temporal sublayer cannot be used for interpredictive reference by pictures in a lower temporal sublayer, the subbitstream extraction process, and the requirement that each subbitstream extraction output is a matched bitstream.

[0080] Therefore, the picture with the best time ID cannot be used as a reference picture and can be discarded at the network level when throughput is poor or network conditions are unstable. For example, a device or node generating a PDU set for transmission can set a discard flag on the PDU set and monitor network conditions before sending the PDU set. In response to network conditions matching the discard policy (e.g., if throughput is reduced below a threshold, the error rate exceeds a threshold, interference or congestion is detected, or any other such case where it is desirable to reduce the amount of data being transmitted), the device can discard the PDU set (i.e., without sending the PDU set). Similarly, in some implementations, a downstream or intermediate device or node receiving a PDU set for further transmission may identify the discard flag and monitor network conditions as well. If the conditions match the discard policy before retransmitting the PDU set, the downstream or intermediate device or node may discard the PDU set.

[0081] A PDU set with a TID value of 1 (the lowest possible value) may be sent with a higher priority. The priority value for such a picture may be set to 0x01 (for IRAP pictures) or 0x02 (for non-IRAP pictures). A PDU set with a higher TID value in the bitstream is set with a lower priority compared to a PDU set with a lower TID value. A PDU set with the highest TID value in the bitstream is set with the lowest priority.

[0082] Another example of a NAL unit header 500 in an RTP packet payload, such as those used by HEVC implementations, is shown in Figure 5. The TID field, which may be called nuh_temporal_id_plus1, identifies the time identifier of the NAL unit plus 1 in some implementations (for example, the lowest possible value is 1, corresponding to a time ID of 0).

[0083] In some implementations, NAL units with the highest time ID or TID field value may be set with a true discard flag (0x1) in the RTP header extension. Similarly, in some implementations, NAL units with any other TID field value may be set with a false discard flag (0x0) or the lowest priority in the RTP header extension.

[0084] Furthermore, in some implementations, the HEVC codec may represent Random Access Skipped Leading (RASL) pictures, which are pictures or frames that use pictures preceding random access points in the coding order for predictive and differential encoding. Such pictures can be corrupted if decoding begins at a random access point (and the corresponding reference frame). Therefore, in some implementations, RASL pictures may be discarded. HEVC provides a mechanism to enable the identification of bitstream matches, where any originally present RASL pictures are discarded. Thus, system components can discard RASL pictures when necessary without worrying about making the bitstream non-compliant. In some such HEVC implementations, NAL units with a type field value equal to 8 or 9 are sent with a discardability flag in the RTP header extension set to true (0x1), or may be set at a lower priority in the RTP header extension. NAL units with any other type field value may be sent with a discardability flag in the RTP header extension set to false (0x0), or with a high priority in the RTP header extension.

[0085] Similarly, implementations of the VVC codec can identify RASL pictures that can be safely discarded. VVC provides a mechanism to enable the identification of bitstream matches, where the originally present RASL pictures are discarded. Thus, system components can discard RASL pictures when necessary without worrying about making the bitstream non-compliant. Some implementations of the VVC codec use a NAL unit header 600, as illustrated in Figure 6. In such implementations, NAL units with a type field value equal to a given value, such as 3, may be sent with a discardability flag in the RTP header extension set to true (0x1), or with a lower priority in the RTP header extension. NAL units with any other type field value may be sent with a discardability flag in the RTP header extension set to false (0x0), or with a higher priority / importance in the RTP header extension.

[0086] Returning to Figure 4 for a brief reference, a NAL Criteria ID or NRI field of 0x00 indicates that the content of the NAL unit will not be used to reconstruct the reference picture for interpicture prediction (values ​​other than 0x00 indicate that the NAL unit is a reference picture or frame, or that decoding of the NAL unit is required to maintain the integrity of the reference picture). When the field is 0 and the NAL unit will not be used to reconstruct the reference picture, the unit may be discarded without compromising the integrity of the reference picture. In such cases, the NAL unit with an NRI field value of 0x00 may be sent with a discardability flag in the RTP header extension set to true (0x1), or with a lower priority in the RTP header extension. All other NAL units with an NRI field value greater than zero may be sent with a discardability flag in the RTP header extension set to false (0x0), or with a higher priority / importance in the RTP header extension.

[0087] Therefore, in various implementations, the type of the NAL unit header 400, 500, or 600 within the RTP packet payload and the TID or NRI field can be used to determine the importance of the NAL unit for decoding, with the least important NAL units being set to the lowest priority in the RTP header extension and, in some implementations, marked for potential discard within the RTP header extension if network conditions require it.

[0088] Configuration details of the PDU Set RTP Header Extension may need to be communicated between the Application Server (AS) and the User Plane Function (UPF), and / or between other nodes, including intermediate notes. For a given QoS flow and / or Service Data Flow (SDF), a node providing Application Function (AF) may configure the use of the PDU Set Information RTP HE in the RTP session. This may be done via a node providing Policy Control Function (PCF), for example, via a Network Exposure Function (NEF). The use of the PDU Set Information RTP HE is negotiated between the AS and AF through an M3 interface or reference point, configured within the PCF (e.g., within Policy and Charging Control (PCC) rules), forwarded by the PCF to the Session Management Function (SMF) (e.g., within PCC rules), and forwarded by the SMF to the UPF (e.g., within an N4 message). Each of these nodes may be provided by a different computing device, or in many implementations, one or more of the nodes or functions may be provided by the same computing device. Therefore, communication between nodes can include broadcast communication, or it can include communication via API or procedural calls between functional nodes within the computing system.

[0089] Figure 7 is a diagram illustrating an exemplary procedure for configuring a UPF using RTP HE for PDU set information. In 1a, the Application Server (AS) and Application Function (AF) can negotiate the use of RTP HE to transmit PDU set information between the AS and the User Plane Function (UPF) during a media session and inform the network of support for PDU set information. For example, the negotiation may specify the type of header extension (e.g., 1-byte header format, 2-byte header format, bit depth, etc.). In some implementations, the specified information may include the NAL unit header type (e.g., which one or more headers from the examples in Figures 4-6 are being used). In some implementations, information on the RTP header extension ID generated during RTP session generation time may be signaled to the AF so that this information is carried to the UPF through the Policy Control Function (PCF) and Session Management Function (SMF). In another implementation, the RTP header extension ID is generated and signaled to the AS by the AF, and this ID is used by the AS during RTP session generation time.

[0090] In 2a, in some implementations, the AF may call an API (e.g., Nnef_AFsessionWithQoS request) to provide the NEF with PDU set information RTP HE (e.g., header type, bit depth, NAL unit type, or any combination of these or other information). In 2b, the NEF may respond to the API call (e.g., Nnef_AFsessionWithQoS response). In various implementations, the response may indicate acceptance or acknowledgment, rejection (e.g., lack of support or error), or that the information has been passed further.

[0091] In 3a, in some implementations, the NEF can call an API (e.g., an Npcf_PolicyAuthorization request) to provide the PCF with PDU set information RTP HE. In some implementations, the PCF can use the presence of PDU set information RTP HE in the medium packet to construct a PCC rule, which may include PDU set information RTP HE usage information as described above. In 3b, the PCF can respond to the API call with an acknowledgment of receipt, an error, further configuration parameters, or any other such information (e.g., an Npcf_PolicyAuthorization response).

[0092] In step 4, the PCF can send PCC rules to the SMF. In some implementations (e.g., "pull" implementations), the PCF can send PCC rules to the SMF when the SMF calls an API (e.g., Npcf_SMPolicyControl) that requests PCC rules (as shown in, e.g., 4a, 4b). For example, the SMF can call Npcf_SMPolicyControl during PDU session establishment, sending a request to the PCF in 4a, which can then respond with a rule in 4b. Alternatively, in some implementations (e.g., "push" implementations), the PCF can forward PCC rules to the SMF using the notification behavior of the Npcf_SMPolicyControl API, such as when a PDU session is already established when the PCF generates the PCC rules. In some implementations, this can result in the direction of the arrows in 4a, 4b being reversed, with the SMF responding in 4b with an acknowledgment of receipt of the rules. In yet another implementation, the notification action may occur first, in 4a, where the PCF notifies the SMF that the updated rule is available, triggering the SMF to send an Npcf_SMPolicyControl request. Thus, sending the PCC rule to the SMF can be initiated by either the PCF or the SMF (e.g., a "pull" action, a "push" action, a "notify and pull" action, etc.).

[0093] In 5a, the SMF can send PDU set information and RTP HE usage information to the UPF in an N4 message (e.g., an N4 session establishment request), and in 5b, it can receive a response (e.g., an N4 session establishment response) which may include an acknowledgment of receipt, further configuration information, etc.

[0094] As mentioned above, in many implementations, the RTP header extension can be used to signal the PDU sequence number (PSN) and / or PDU set sequence number (PSSN). In the example implementations 200 and 300 in Figures 2 and 3, these numbers are 8 bits long. However, this may be insufficient for some implementations of medium data communication.

[0095] For example, in many implementations, the bit depth for the PSSN field is determined primarily by the number of slices present in the frame. A slice can refer to a portion of a picture (e.g., a rectangular region, a tile, etc.) and, depending on the codec used, can be based on coding true units, macroblocks, raster-scanned tiles, etc. A higher bit depth is required for the PSSN when there are more slices in the frame. The maximum number of slices is 1000 for VVC, 600 for HEVC, and 5802 for H.264. Extending the PSSN to 10 bits can allow for the independent representation of 1000 slices.

[0096] In many implementations, the bit depth for the PSN field can be determined based on the maximum possible size of the PDU set. When a frame is coded in a single slice, its data is encapsulated in a single set of PDUs. The number of PDUs required to encapsulate such a frame is large, and in this case, the number required for the PSN is also large.

[0097] In some implementations, the number of slices per picture may be configured in the Picture Parameter Set (PPS). In some implementations, a Hit Field (S) may be used to signal whether the number of slices present in a frame is less than 32. For example, in some implementations, the S bit may be set to 1 when the number of slices is less than 32. When the number of slices is greater than 32, the S bit may be set to 0.

[0098] Therefore, in such an implementation, when the number of slices is less than 32 (the S bit is set to 1), it is possible to allocate 8 bits to the PSN field. Considering the MTU size of 1200 bytes in an RTP packet with 8 bits allocated to the PSN field, we can transmit up to 307,200 (2Pow(8)*1200) bytes per frame or slice. When fewer than 32 slices are used per frame, 5 bits may be sufficient to uniquely represent the set of PDUs present in a frame. The additional 3 bits in the 8-bit PSSN field can be used to uniquely represent the set of PDUs present in multiple frames when they are transmitted together or as a burst.

[0099] Figures 8 and 9 show examples of RTP header extensions using 1-byte header format 200' and 2-byte header format 300' with slice number signaling, according to several embodiments. Slice fields 800, 900 may have a 1-bit flag set to 1 to indicate fewer than 32 slices, or set to 0 to indicate 32 or more slices. In the 200', 300' examples, the flag is set to 1, and therefore 8-bit PSSN fields (802, 902) and 8-bit PSN fields (804, 904) may be used.

[0100] If there are more than 32 slices, 10 bits can be allocated to the PSSN and 6 bits to the PSN. Considering the MTU size of 1200 bytes in an RTP packet, if 6 bits are allocated to the PSN field, we can transmit up to 76,800 (2POW(6)*1200) bytes per slice. When more than 32 slices are used per frame, more than 5 bits are required to uniquely represent a set of PDUs present in a frame. A PSSN field with 10 bits can be used to uniquely represent a set of PDUs present in multiple frames when they are transmitted together or in bursts.

[0101] Figures 10 and 11 show examples of RTP header extensions using 1-byte header format 200'' and 2-byte header format 300'' with slice number signaling, according to several embodiments. Slice fields 1002, 1102 and slice fields 800, 900 may have a 1-bit flag set to 1 to indicate fewer than 32 slices, or set to 0 to indicate 32 or more slices. In the 200'', 300'' examples, the flag is set to 0, and therefore 10-bit PSSN fields (1002, 1102) and 6-bit PSN fields (1004, 1104) may be used.

[0102] Figure 12 shows a flowchart of method 1200 for signaling PDU set information via RTP header extension, according to several embodiments. In 1202, a device such as a WTRU, computing device, encoder, media source device, streaming service, wireless gateway, or any other type and form of device can identify data for transmission. The data may be stored in the device's memory, retrieved from another device, or generated by the device or another device.

[0103] In 1204, in some implementations, the device may determine the type of data. The data type may consist of audio data, video data (including augmented reality data, virtual reality data, or augmented reality data), or any other type and form of data. In some implementations, determining the data type may involve identifying a session or application layer header or payload indicating the data type, or a bitstream header indicating the data type. Audio and video data may be encoded through various encoders, and they may be identified, for example, within the header of an application layer packet or bitstream.

[0104] In 1206, in some implementations, the device may determine that the data is real-time audio data, such as streaming audio, Voice over Internet Protocol (VoIP) audio data, or any other type and form of real-time audio data. If so, in 1208, the importance or priority of the data may be set to the highest value (which may be the lowest actual value, such as 0x00, depending on the implementation).

[0105] If the data is not audio data, in 1210, in some implementations, the device may determine whether the data is video data. For example, the data may include encoded frames or portions of frames of a video bitstream. The video data may be pre-recorded or generated live or in real time, such as video conferencing or live streaming video data, augmented reality data or augmented reality data, etc. If so, in 1212, in some implementations, the device may determine whether the data is a reference frame (e.g., an I-frame, or a frame used for predicting or differential encoding of other frames, but not relying on the other frames themselves for encoding) or a parameter set for decoding video data. If so, in 1214, in some implementations, the importance or priority of the data may be set to a second-higher value (which may be a second-lowest actual value such as 0x01, depending on the implementation). Otherwise, in 1216, in some implementations, the importance or priority of the data may be set to be proportional to (or inversely proportional to, depending on the implementation) the time identifier of the video data (such that video data with the highest or longest time identifier has the lowest importance or priority).

[0106] In 1218, in some implementations, the device may determine whether data is discardable. Video data may be discardable in various implementations if it has the highest or largest time identifier, if it is not used to reconstruct a reference picture, or if it is a RASL picture or any other type and form of video frame or picture (or part of a frame or picture) that can be discarded without affecting the decoding or rendering of other video frames or pictures or causing the bitstream to become non-compliant. In some implementations, this may be identified based on the type field or time identifier field in the NAL unit header. If data is discardable, in 1220, in some implementations, a discard flag may be set, or set with lower importance or priority in the RTP header extension.

[0107] In 1222, in some implementations, the number of slices per picture or frame of video may be identified and compared to a threshold. In some implementations, the number of slices may be identified within the Picture Parameter Set (PPS) of the video data. If the number of slices does not exceed the threshold, in 1224, in some implementations, a standard length field, such as 8 bits, may be used for the PDU Set Sequence Number (PSSN), and 8 bits may be used for the PSU Sequence Number (PSN). If the number of slices exceeds the threshold, in 1226, in some implementations, an extended length field may be used for the PSSN, and the PSN may be shortened accordingly (e.g., by adding 2 bits to the PSSN, e.g. by removing 2 bits from the PSN, or any other similar exchange).

[0108] In some implementations, if the data is neither audio nor video data, a default value or other header value may be used in 1228.

[0109] In 1230, PDUs and / or PDU sets can be generated according to various determined header values, including priority, discardability, and / or PSSN and PSN length.

[0110] Accordingly, implementations of the systems and methods described herein provide signaling of PDU set information via RTP header extensions. Similar header extensions may be used with other protocols in various implementations to achieve the same benefit. For example, implementations of the systems and methods described herein provide signaling of how to handle PDU set information associated with the importance or priority of a set, destructibility including syntax, semantics, and guidelines for destructibility flags, and variable-length fields such as PDU sequence numbers and / or PDU set sequence numbers.

[0111] In a first aspect, the disclosure is directed to a method for prioritizing packet data units. The method includes identifying data for transmission by a wireless transmit / receive unit (WTRU). The method also includes the WTRU determining the priority of the data transmission relative to other data transmissions by the WTRU based on the type or content of the data for transmission. The method also includes the WTRU generating a set of packet data units (PDUs) comprising a plurality of PDUs containing the identified data for transmission, each PDU in the PDU set having a header value indicating the priority corresponding to the determined priority. The method also includes the WTRU transmitting the generated set of PDUs.

[0112] In some implementations, determining the priority of data transmission involves determining that the data contains reference frames of the video and selecting a higher priority than that for data containing non-reference frames of the video. In some implementations, determining the priority of data transmission involves determining that the data contains a parameter set for decoding or presenting the video and selecting a higher priority than that for data containing non-reference frames of the video. In some implementations, the method involves determining by WTRU that the number of per-picture slices of video frames of the identified data for transmission exceeds a threshold, and generating a PDU set further involves setting a per-PDU header value of the PDU set indicating that the number of per-picture slices exceeds a threshold, and in such implementations, each PDU in the PDU set includes a header field indicating a PDU set sequence number having more bits than a header field indicating a PDU sequence number.

[0113] In some implementations, determining the priority of data transmission involves deciding which data contains real-time audio data and selecting a higher priority for that data than for data that does not contain real-time audio data.

[0114] In some implementations, the method includes: identifying a second data for transmission by WTRU; determining the priority of the second data transmission relative to other data transmissions by the first WTRU based on the type or content of the second data for transmission, wherein the priority of the second data is lower than that of other data transmissions; and generating a second PDU set by WTRU that includes a second set of PDUs containing the identified second data for transmission, each PDU in the second PDU set containing a header value indicating the discardability, low importance, or low priority of the second PDU set.

[0115] In further implementations, determining the priority of a second data transmission includes determining that the second data contains non-referenced frames of video. In yet another further embodiment, determining the priority of a second data transmission includes determining that the second data contains a time identifier having a maximum value. In yet yet another further implementation, determining the priority of a second data transmission includes determining that the second data contains non-referenced frames of video associated with subsequent referenced frames of video. In yet another further embodiment, the header value indicating the discardability, low importance, or low priority of the second PDU set is a header extension flag or importance field of the header extension. In yet another further implementation, the header value is received by the WTRU from an application function or application server. In yet another further implementation, the method includes, by the WTRU, discarding the second PDU set without transmitting the second PDU set in response to the detection of network conditions that satisfy a discard policy.

[0116] In another aspect, the disclosure is directed to a wireless transmit / receive unit comprising one or more processors configured to perform any of the embodiments of the methods described above. In yet another aspect, the disclosure is directed to a network device comprising one or more processors configured to perform any of the embodiments of the methods described above. In yet another aspect, the disclosure is directed to a circuit configured to perform any of the embodiments of the methods described above. In yet another aspect, the disclosure is directed to a non-temporary computer-readable medium containing instructions that, when executed by one or more processors of a computing device, cause one or more processors to perform any of the embodiments of the methods described above.

[0117] While the features and elements are described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. In addition, the methods described herein can be implemented in computer programs, software, or firmware embedded on computer-readable media for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media, but not limited to, include magnetic media such as read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, internal hard disks, and removable disks, as well as magneto-optical media, and optical media such as CD-ROM disks and digital multipurpose disks (DVDs). Processors associated with software can be used to implement radio frequency transceivers for use in WTRUs, UEs, terminals, base stations, RNCs, or any host computer.

Claims

1. A method for prioritizing packet data units, The Wireless Transceiver Unit (WTRU) identifies the data related to transmission, The WTRU determines the priority of the data transmission relative to other data transmissions by the WTRU, based on the type or content of the data being transmitted. The WTRU generates a set of packet data units (PDUs) comprising a plurality of PDUs containing the identified data relating to transmission, wherein each PDU in the set includes a header value indicating the priority corresponding to the determined priority. The WTRU transmits the generated PDU set. A method characterized by comprising:

2. The WTRU identifies the second data related to the transmission, The WTRU determines the priority of the second data transmission relative to other data transmissions by the first WTRU, based on the type or content of the second data relating to the transmission, wherein the priority of the second data is lower than that of the other data transmissions. The WTRU generates a second set of PDUs, each PDU in the second set of PDUs, each PDU in the second set of PDUs, which includes the identified second data relating to the transmission, and each PDU in the second set of PDUs includes a header value indicating the discardability, lower importance, or lower priority of the second set of PDUs. The method according to claim 1, further comprising:

3. Determining the priority of the second data transmission is The second data mentioned above determines that it includes a non-referenced frame of the video. The method according to the second invention, characterized by including the following:

4. Determining the priority of the second data transmission is The second data is determined to include a time identifier having the maximum value. The method according to the second invention, characterized by including the following:

5. Determining the priority of the second data transmission is The second data is determined to include non-referenced frames of the video associated with later referenced frames of the video. The method according to the second invention, characterized by including the following:

6. The method according to any one of claims 1 to 5, characterized in that the header value indicating the discardability, lower importance, or lower priority of the second PDU set is a header extension flag or importance field for header extensions.

7. The method according to 6, characterized in that the header value is received by the WTRU from an application function or application server.

8. The method according to any one of claims 1 to 7, further comprising the WTRU discarding the second PDU set without transmitting the second PDU set in response to detection that network conditions satisfy the discard policy.

9. Determining the priority of the aforementioned data transmission is, It is determined that the aforementioned data includes a reference frame of the video, Selecting a higher priority for data containing non-referenced frames of the aforementioned video. The method according to any one of claims 1 to 8, characterized by including the following:

10. Determining the priority of the aforementioned data transmission is, The data is determined to include a set of parameters for decoding or presenting the video. Selecting a higher priority for data containing non-referenced frames of the aforementioned video. The method according to any one of claims 1 to 8, characterized by including the following:

11. The WTRU further comprises determining that the number of picture-by-picture slices of the video frame of the identified data relating to the transmission exceeds a threshold, Generating the PDU set further includes setting a header value in each PDU of the PDU set that indicates that the number of slices per picture exceeds the threshold, In each PDU of the PDU set, the header field indicating the PDU set sequence number has a larger number of bits than the header field indicating the PDU sequence number. The method according to any one of claims 1 to 10, characterized by the features described herein.

12. Determining the priority of the aforementioned data transmission is, It is determined that the aforementioned data includes real-time audio data, Selecting a higher priority for data that lacks real-time audio data. The method according to any one of claims 1 to 8, characterized by including the following:

13. A wireless transceiver unit comprising one or more processors configured to perform the method described in any one of claims 1 to 12.

14. A network device comprising one or more processors configured to perform the method described in any one of claims 1 to 12.

15. A non-temporary computer-readable medium characterized by including instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform the method according to any one of claims 1 to 12.

Images