PDU set information RTP header extension

Abstract

A method for signaling a PDU set RTP header extension (HE) may include negotiating use of the RTP HE between an AS and an AF. The method may include generating, by the AF, an RTP HE ID and transmitting, by the AF, the RTP HE ID to the AS. The method may include transmitting, by the AS, the RTP HE ID to the AF. The method may include transmitting, by the AF, a usage of the PDU set RTP HE to the NEF, and transmitting, by the NEF, the PDU set RTP HE to the PCF. The method may include constructing, by the PCF, a PCC rule including PDU set RTP HE usage information, and transmitting, by the PCF, the PCC rule to the SMF. The method may include transmitting, by the SMF, PDU set RTP HE usage information to the UPF.

Description

[0001] Related applications This application claims the benefit and priority of U.S. Provisional Patent Application No. 63495203, filed April 10, 2023, entitled “PDU Set Information RTP Header Extension,” the entire contents of which are incorporated herein by reference. Background Technology

[0002] Packet Data Unit (PDU) sets allow large application layer data to be carried across multiple PDUs. However, each PDU carrying a portion of the data needs to be identified as part of the set; otherwise, reassembling data fragments or portions may be difficult (if not impossible). Traditional transport layer packet fragmentation protocols may be unsuitable for PDU sets because they lack information related to set importance, variable bit length, and other characteristics. Summary of the Invention

[0003] To address the above and other issues, this disclosure relates to embodiments of systems and methods for signaling Packet Data Unit (PDU) set information via Real-Time Protocol (RTP) Header Extensions (HE). Specifically, embodiments of the systems and methods discussed herein support signaling PDU set information relating to: set importance or priority; discardability (including the syntax, semantics, and guidelines for discardability flags); how network nodes (such as User Plane Functions (UPFs)) can identify the presence of PDU set information within a PDU; and how variable-length fields (such as PDU sequence numbers and / or PDU set sequence numbers) are handled.

[0004] In some aspects, the method may include negotiating the use of RTP HE between an Application Server (AS) and an Application Function (AF) for transmitting PDU set information between the AS and a User Plane Function (UPF). The method may include generating an RTP HE identifier (ID) by the AF and sending the RTP HE ID to the AS by the AF. The method may include using the RTP HE ID by the AS during RTP session creation time. The method may include sending the RTP HE ID to the AF by the AS. The method may include sending the PDU set RTP HE usage information to the Network Open Function (NEF) by the AF. Sending the PDU set RTP HE usage information to the NEF by the AF may include invoking an Application Programming Interface (API) that may include sending an Nnef_AFsessionWithQoS request from the AF to the NEF and receiving an Nnef_AFsessionWithQoS response from the NEF by the AF. The method may include sending the PDU set RTP HE to the Policy Control Function (PCF) by the NEF. Sending a PDU set RTP HE to the PCF via the NEF may include calling an API, which may include sending an Npcf_PolicyAuthorization request from the NEF to the PCF, and receiving an Npcf_PolicyAuthorization response from the PCF. This method may include the PCF constructing Policy and Charging Control (PCC) rules that include PDU set RTP HE usage information. This method may include the PCF sending the PCC rules to the Session Management Function (SMF). The PCF may send the PCC rules to the SMF in response to an SMF API call, which may include sending an Npcf_SMPolicyControl request from the SMF to the PCF, and receiving an Npcf_SMPolicyControl response from the SMF. This method may include the SMF sending PDU set RTP HE usage information to the UPF. PDU set RTP HE usage information can be sent from the SMF to the UPF in an N4 message. Negotiation of RTP HE usage between the AS and AF can be performed via the M3 interface. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein like reference numerals in the drawings indicate like elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows an embodiment in which... Figure 1A The diagram illustrates a system diagram of an example wireless transmit / receive unit (WTRU) used within a communication system. Figure 1C The illustration shows an embodiment in which... Figure 1A The diagram illustrates a system diagram of an example radio access network (RAN) and an example core network (CN) used within a communication system. Figure 1D The illustration shows an embodiment in which... Figure 1A The diagram shows another example RAN and another example CN used in the communication system. Figure 2 An example RTP header extension using a single-byte header format is shown according to some embodiments; Figure 3 An example RTP header extension using a two-byte header format is shown according to some embodiments; Figure 4 An example NAL cell type octet is shown in an RTP packet payload according to some embodiments; Figure 5 An example structure of the HEVC NAL unit header according to some embodiments is shown; Figure 6 An example structure of the VVC NAL unit header according to some embodiments is shown; Figure 7 An example procedure for configuring UPF according to some embodiments is shown; Figure 8 An example of an RTP header extension using a single-byte header format with striped numbering signaling, according to some embodiments, is shown; Figure 9 An example of an RTP header extension using a two-byte header format with striped signaling is shown according to some embodiments; Figure 10 Another example of RTP header extension using a single-byte header format with striped numbering signaling, according to some embodiments, is shown; Figure 11 Another example of an RTP header extension using a two-byte header format with striped signaling, according to some embodiments, is shown; and Figure 12 A flowchart is shown, according to some embodiments, of a method for signaling PDU collection information via RTP header extension. Detailed Implementation

[0006] Before discussing the specific implementation details of systems and methods for transmitting information from a set of packet data units using signals, it may be helpful to briefly discuss the system environment in which these systems and methods can be implemented.

[0007] First refer to Figure 1A The diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables 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 Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0008] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 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. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a Station (STA)) may be configured to transmit and / or receive wireless signals and may include User Equipment (UE), mobile stations, fixed or mobile user units, subscription-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 wearable devices, 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 industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0010] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further divided into cell sectors. For example, the 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 multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0011] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via 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.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0012] More specifically, as noted above, communication 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, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies (such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA)), which can use wideband CDMA (WCDMA) to establish air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0013] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0014] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 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).

[0016] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), GSM EDGE (GERAN), etc.

[0017] Figure 1A Base station 114b 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 local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106.

[0018] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1AAs shown, but to be understood, RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from 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 use the same RAT as RAN 104 or a different RAT.

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

[0021] Figure 1B This is a system diagram illustrating the example WTRU 102. (Example: ...) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be understood that, while remaining consistent with the embodiments, WTRU 102 may include any sub-combination of the foregoing elements.

[0022] Processor 118 may be a general-purpose processor, a special-purpose 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. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, which may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0025] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

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

[0027] The processor 118 can receive power from the power supply 134 and can be configured to distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for powering 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.), solar cells, fuel cells, etc.

[0028] 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) about 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 air interface 116 and / or determine its location based on time information from signals received from two or more nearby base stations. It will be understood that, while remaining consistent with the embodiments, the WTRU 102 may acquire location information using any suitable location determination method.

[0029] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth.® Bluetooth ® Peripheral devices 138 may include one or more sensors. These sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0030] WTRU 102 may include a full-duplex radio transceiver for which the transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio transceiver may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., chokes) or via signal processing (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio transceiver for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) may be concurrent and / or simultaneous.

[0031] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As noted above, RAN 104 can use E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

[0032] RAN 104 may include eNodeBs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNodeBs while remaining consistent with the embodiments. Each of eNodeBs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNodeBs 160a, 160b, and 160c may implement MIMO technology. Therefore, eNodeB 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0034] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0035] The MME 162 can connect to each of the eNodeBs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, and so on. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0036] The SGW 164 can connect to each of the eNodeBs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-eNodeB handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0037] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0038] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (such as an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or can communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 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.

[0039] Despite WTRU in Figure 1A-1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0041] A WLAN in Infrastructure Basic Services 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 an access or interface to a Distribution System (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for an external BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between a source STA and a destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0042] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA (including the AP) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0043] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0044] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be divided into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80 MHz channels, and data can be transmitted via a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0045] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce the channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with a battery life above a threshold (e.g., to maintain a very long battery life).

[0046] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available frequency bands remain idle.

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

[0048] Figure 1DThis is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As noted above, RAN 104 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 may also communicate with CN 106.

[0049] RAN 104 may include gNBs 180a, 180b, and 180c, but it will be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each gNB 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0050] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0051] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (such as eNodeBs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNodeBs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c. In a non-standalone configuration, eNodeBs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0052] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability 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. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0053] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0054] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling sessions of different Protocol Data Units (PDUs) with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as Wi-Fi).

[0055] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a 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.

[0056] UPF 184a and 184b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 104 via the N3 interface. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, caching DL packets, and providing mobility anchoring.

[0057] CN 106 can facilitate communication with other networks. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or can communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 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. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via UPFs 184a and 184b through the N3 interface to UPFs 184a and 184b and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0058] Given Figure 1A-1D as well as Figure 1A-1D The corresponding descriptions regarding one or more of the following functions described herein may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, eNodeB 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device(s) described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0059] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0060] One or more emulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be utilized in test scenarios within test laboratories and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices can be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0061] Please refer to the following abbreviations and acronyms: AF application functions AS Application Server EOB sudden termination GTP-U GPRS Tunneling Protocol User Plane Protocol HE header extension PCC Policy and Billing 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 Functions XR Extended Reality.

[0062] As discussed above, Packet Data Unit (PDU) sets allow large application layer data to be carried across multiple PDUs. However, each PDU carrying a portion of the data needs to be identified as part of the set; otherwise, reassembling data fragments or portions may be difficult (if not impossible). Traditional transport layer packet fragmentation protocols may be unsuitable for PDU sets because they lack information that may be necessary or desired for the use. For example, in some implementations, transmitting the following information may be helpful: the PDU set sequence number or the sequence number of PDUs within the PDU set; the boundaries of the PDU set (e.g., start and / or end markers of the PDU set, the size of the PDU set in terms of the number of PDUs, etc.); the importance or priority of the PDU set (in absolute terms or relative to other PDUs); the byte size of the PDU set; and indications that PDUs can be discarded without significantly affecting the reconstruction media, etc.

[0063] To address the above and other issues, this disclosure relates to embodiments of systems and methods for signaling Packet Data Unit (PDU) set information via Real-Time Protocol (RTP) Header Extensions (HE). Specifically, embodiments of the systems and methods discussed herein support signaling PDU set information relating to: set importance or priority; discardability (including the syntax, semantics, and guidelines for discardability flags); how network nodes (such as User Plane Functions (UPFs)) can identify the presence of PDU set information within a PDU; and how variable-length fields (such as PDU sequence numbers and / or PDU set sequence numbers) are handled. For example, in some embodiments, the systems and methods discussed herein provide: signaling a PDU set importance / priority field; signaling a PDU set discardability flag; syntax, semantics, and guidelines on 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 regarding the use of the PDU set RTP header extension to carry PDU set information; and the number of bits required to signal the PDU sequence number (PSN) and PDU set sequence number (PSSN).

[0064] In some implementations, the RTP header extension mechanism defined in RFC 8285 can be extended to define new RTP header extensions to carry PDU collection information. In various implementations, the RTP header extension (HE) can be defined using single-byte and double-byte extension formats.

[0065] The syntax and semantics of the PDU collection information header extension can be as follows: Figure 2 and Figure 3 As shown in the definition. First refer to... Figure 2The illustration shows the RTP header extension 200 using the single-byte header format. The first two bytes (0xBEDE) identify that the packet includes the RTP single-byte header extension, and the fifth byte (the start of the header extension itself) includes a 4-bit identifier 202A and a 4-bit length field 202B. The length field 202B specifies the remaining header length in bytes minus one (i.e., a length "0" indicates a 1-byte header extension following the length field 202B). Figure 2 In the example, length 6 indicates that it includes a 7-byte header extension (i.e., bytes 6 to 12).

[0066] Figure 3 The example shows an RTP header extension 300 using a two-byte header format. The first 12 bits (0x100) specify the two-byte header format, and the next 4 bits are local application-specific identifiers. Identifier 302A at byte 5 is extended to one byte in length, and this length is similarly extended to utilize byte 6. The length field 302B specifies the remaining header length, but does not require the "minus one" of the single-byte format (i.e., length 0 would indicate that there are no subsequent bytes after the length byte). In the example shown, there are 10 additional bytes after the length field 302B in the header extension.

[0067] Any format of header extension may include some or all of the following fields: • End (E) flag, which can be 1 bit. The E flag can indicate whether the current PDU is the last PDU in the PDU set. A value of 1 indicates that the PDU is the last PDU in the PDU set. A value of 0 indicates that the PDU is not the last PDU in the PDU set. The End of Burst (EOB) field can be 2 bits. For the last PDU in the data burst, the EOB value can be set to 0x01. When this flag is set to 0x00, the current PDU is not the last PDU in the data burst. When this flag is set to 0x10, no EOB indication is 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 in the data burst. For all PDUs in the last PDU set in the data burst, this flag value can be set to 0x11. • Importance or Priority (PRI) field, which can be 4 bits. This field indicates the priority of a PDU set compared to other PDU sets within the same stream. The lower the value of the priority field, the higher the importance. For example, a PDU set with a priority value of 0 can be more important than a PDU set with a priority value of 1. • The dropability (D) field, which can be 1 bit. This field indicates whether the PDU set can be dropped without significantly affecting the decoding of the media. For example, when this field is set to 1, the PDU set can be dropped without significantly affecting decoding and reconstruction, and when this field is set to 0, the PDU set can be kept. • PDU Set Serial Number (PSSN), which can be 8 bits. This field can include a value indicating the sequence number of the PDU set to which the current PDU belongs. When video frames are encoded and decoded using multiple stripes, each PDU set contains the encoded and decoded stripe data. • PDU Serial Number (PSN), which can be 8 bits. This field indicates the sequence number of the current PDU within the PDU set. The number of PDUs in the PDU set will be higher when encoding and decoding video frames using a single stripe, and lower otherwise. • Burst Identifier (ID), which can be 8 bits. This value can be set as an identifier specific to a burst. PDUs intended to be sent within a single burst (e.g., these PDUs correspond to the same display time) should have the same burst ID.

[0068] In some implementations, the application server or the source UE can set a PDU set importance or priority field for the PDUs. For example, in some implementations, a PDU set containing audio data can be set to the highest importance compared to other media PDU sets. For instance, a PDU set belonging to audio media can be set to a priority value of 0x00. Since short audio errors or delays are generally more noticeable and annoying than short video errors or delays, it may be beneficial to transmit audio data with the highest priority or importance.

[0069] In some implementations, a set of PDUs containing reference frames (e.g., I-frames or frames encoded using only intra-frame compression) present in the video bitstream is given higher priority than non-reference frames (e.g., P-frames or B-frames, encoded based on previous frames or bidirectionally encoded based on previous and subsequent frames) present in the video bitstream. This is because reference frames are necessary for decoding the entire frame group (typically lasting tens of frames or seconds). Intra-Random Access Frames (IRAP) frames (such as Instant Decoder Refresh (IDR) frames, Clean Random Access (CRA) frames, Broken Link In (BLA) frames, and Progressive Decoder Refresh (GDR) frames) are given higher priority. The priority value for such frames can be set to 0x01.

[0070] Various implementations of video codecs can indicate the image type in the header, such as the Network Abstraction Layer (NAL) Unit header. The NAL Unit header can be carried in RTP packets, such as in the header extension block or the payload. Figure 4 The diagram illustrates an example of a NAL unit header 400 (such as those used in H.265 encoding). The first bit is a prohibition bit (i.e., left as 0) to identify any transmission errors. The next two bits (NAL Reference Identifier or NRI, sometimes called nal_ref_idc) indicate whether the NAL unit following the header is a reference frame or field, and the subsequent 5 bits indicate the NAL unit type, which specifies the type of data structure (e.g., a partitioned codec stripe, a picture, or a sequence parameter set, etc.).

[0071] For example, in a VVC bitstream, the nal_unit_type field with a value ranging from 7 to 11 (inclusive) indicates an Intra-Random Access Frame (IRAP) image. 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 can be set with a higher priority value in the RTP header extension, such as 0x01.

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

[0073] Similarly, in HEVC bitstreams, the nal_unit_type field with a value ranging from 16 to 23 (inclusive) indicates an Intra-Random Access Frame (IRAP) image. 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 can be set with a higher priority value in the RTP header extension, such as 0x01.

[0074] Similarly, for HEVC bitstreams, the corresponding type field value in the range 32 to 34 (inclusive) of the NAL unit header of the RTP packet can be used to identify the parameter set NAL units (such as Sequence Parameter Set (SPS), Picture Parameter Set (PPS), and Video Parameter Set (VPS)). As discussed above, since these information sets are important for decoding the bitstream, they can be given a higher priority in the RTP header extension. The priority value of such PDU sets can be set to 0x01.

[0075] In the H.264 bitstream, the nal_unit_type field with a value of 5 represents an Intra-Random Access Frame (IRAP) image. When the type field value in the NAL unit header of an RTP packet is 5, the corresponding PDU in that PDU set can be set with a higher priority value in the RTP header extension, such as 0x01.

[0076] The payload type field value of 7, 8, 13, or 15 can be used in the NAL unit header of an RTP packet to indicate H.264 parameter set NAL units such as Sequence Parameter Set (SPS) and Picture Parameter Set (PPS). Like other video codecs, these parameter sets can be sent with higher priority in the RTP header extension because they are important for decoding. The priority value of this PDU set can be set to 0x01.

[0077] In video encoding and decoding, temporal scalability is an option to decode only some frames of a video stream instead of the entire stream. This allows media servers to reduce the bitrate sent to the receiving end (which may not have a sufficient bitrate or CPU to process the entire stream). The image with the lowest time identifier value is used as the reference image in the bitstream.

[0078] Modern video codecs such as AVC, HEVC, and VVC include support for improved temporal scalability by including a Time ID (TID) signaling in the NAL unit header. Support for temporal scalability comes with limitations such as the inability to use images from lower temporal sub-layers as inter-frame prediction references, the sub-bitstream extraction process, and the requirement that each sub-bitstream extraction output be a compliant bitstream.

[0079] Therefore, the image with the highest time ID cannot be used as a reference image and can be discarded at the network layer when throughput is poor or network conditions are unstable. For example, a device or node generating a set of PDUs for transmission can set a discard flag on the PDU set and can monitor network conditions before transmitting the PDU set. In response to network conditions that match the discard policy (e.g., if throughput decreases below a threshold; if the error rate exceeds a threshold; if interference or congestion is detected; or any other such instance where a reduction in the amount of data to be transmitted is desired), the device can discard the PDU set (i.e., not transmit the PDU set). Similarly, in some implementations, a downstream or intermediate device or node receiving a PDU set for further transmission can identify a discard flag and similarly monitor network conditions. If the condition matches the discard policy before retransmitting the PDU set, the downstream or intermediate device or node can discard the PDU set.

[0080] A set of PDUs with a TID value of 1 (the lowest possible value) can be sent with higher priority. The priority value for this type of image can be set to 0x01 (for IRAP images) or 0x02 (for non-IRAP images). A set of PDUs with higher TID values ​​in the bitstream is given lower priority compared to a set of PDUs with lower TID values. The set of PDUs with the highest TID value in the bitstream is given the lowest priority.

[0081] Figure 5 Another example of the NAL cell header 500 in the RTP packet payload (such as those used by HEVC implementations) is shown. The TID field (which may be referred to as nuh_temporal_id_plus1 in some implementations) specifies the time identifier of the NAL cell plus 1 (e.g., having the lowest possible value of 1, corresponding to time ID 0).

[0082] In some implementations, NAL units with the highest Time ID or TID field value may have a "Yes" (0x1) discardability flag set in the RTP header extension. Similarly, in some implementations, NAL units with any other TID field value may have a "No" (0x0) discardability flag set or be set to the lowest priority in the RTP header extension.

[0083] Additionally, in some implementations, the HEVC codec can instruct a Random Access Skip Preamble (RASL) image, which is an image or frame (the image preceding the random access point in the encoding order used for prediction and differential coding). This image may be corrupted if decoding begins at the random access point (and the corresponding reference frame). Therefore, in some implementations, the RASL image can be discarded. HEVC provides a mechanism that allows specifying the compliance of a bitstream (in which the originally present RASL image has been discarded). Thus, system components can discard RASL images when necessary without concern about causing the bitstream to become non-compliant. In some such HEVC implementations, NAL units with a type field value equal to 8 or 9 can be sent with a discardable flag set to "Yes" (0x1) in the RTP header extension or with a lower priority RTP header extension. NAL units with any other type field value can be sent with a discardable flag set to "No" (0x0) in the RTP header extension or with a higher priority RTP header extension.

[0084] Similarly, implementations of the VVC codec can identify RASL images that can be safely discarded. VVC provides mechanisms that allow specifying the compliance of bitstreams (where the original RASL images have been discarded). Therefore, system components can discard RASL images when needed without worrying about making the bitstream non-compliant. Some implementations of the VVC codec use, for example... Figure 6 The diagram illustrates the NAL unit header 600. In this implementation, a NAL unit having a type field value equal to a predetermined value (such as 3) can be sent with the dropability flag set to "Yes" (0x1) in the RTP header extension or with a lower priority RTP header extension. A NAL unit having any other type field value can be sent with the dropability flag set to "No" (0x0) in the RTP header extension or with a higher priority / importance RTP header extension.

[0085] Briefly return to the reference Figure 4 The NAL Reference ID or NRI field 0x00 indicates that the contents of the NAL unit are not used to reconstruct a reference image (used for inter-frame prediction). Values ​​other than 0x00 indicate that the NAL unit is a reference image or frame, or that the NAL unit needs to be decoded to maintain the integrity of the reference image. When this field is 0 and the NAL unit is not used to reconstruct the reference image, the unit can be discarded without compromising the integrity of the reference image. Therefore, in this instance, a NAL unit with an NRI field value of 0x00 can be sent with the RTP header extension set to "Yes" (0x1) or with a discardable flag set in a lower-priority RTP header extension. All other NAL units with an NRI field value greater than zero can be sent with the RTP header extension set to "No" (0x0) or with a discardable flag set in a higher-priority / importance RTP header extension.

[0086] Therefore, in various implementations, the type and TID or NRI fields of the NAL unit headers 400, 500, and 600 in the RTP packet payload can be used to determine the importance of the NAL unit for decoding. The least important NAL units are set to the lowest priority in the RTP header extension, and in some implementations, they are marked as potentially dropped in the RTP header extension if network conditions require it.

[0087] Configuration details of the PDU set RTP header extension may need to be transmitted between the Application Server (AS) and User Plane Function (UPF) and / or between other nodes (including intermediate nodes). For a given QoS flow and / or Service Data Flow (SDF), the node providing the Application Function (AF) can configure the PDU set information RTP HE usage in the RTP session. This can be done via the node providing the Policy Control Function (PCF) and, for example, via the Network Open Function (NEF). The PDU set information RTP HE usage is negotiated between the AS and AF via the M3 interface or reference point, configured in the PCF (e.g., in a Policy and Charging Control (PCC) rule), delivered by the PCF to the Session Management Function (SMF) (e.g., in a PCC rule), and delivered by the SMF to the UPF (e.g., in 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 may include broadcast communication or communication between functional nodes within a computing system via API or procedure calls.

[0088] Figure 7 This is an illustration of an example process for configuring a UPF using RTP HE with PDU set information. At 1a, the Application Server (AS) and Application Function (AF) can negotiate the use of RTP HE for transmitting PDU set information between the AS and the User Plane Function (UPF) during a media session and notify the network about support for PDU set information. For example, this negotiation can specify the type of header extension (e.g., single-byte header format; double-byte header format; bit depth; etc.). In some implementations, the specified information may include the NAL unit header type (e.g., currently using...). Figure 4-6 (Which header or headers in the example). In some implementations, the RTP header extension ID information generated at RTP session creation time can be signaled to the AF, so that the 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 by the AF and signaled to the AS, and the ID is used by the AS during RTP session creation time.

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

[0090] At 3a, in some implementations, the NEF may invoke an API (e.g., an Npcf_PolicyAuthorization request) to provide the PCF with PDU collection information RTP HE. In some implementations, the PCF may use the presence of the PDU collection information RTP HE in the media packet to construct PCC rules, which may include PDU collection information RTP HE usage information as discussed above. At 3b, the PCF may respond to API calls (e.g., an Npcf_PolicyAuthorization response) with acknowledgments, errors, further configuration parameters, or any other such information.

[0091] At point 4, the PCF can send PCC rules to the SMF. In some implementations (e.g., the "pull" implementation), the PCF can send PCC rules to the SMF when the SMF invokes an API that requests PCC rules (e.g., Npcf_SMPolicyControl) (as shown in 4a and 4b). For example, the SMF can invoke Npcf_SMPolicyControl during PDU session establishment and can transmit the request to the PCF at point 4a, and the PCF can respond with a rule at point 4b. Alternatively, in some implementations (e.g., the "push" implementation), the PCF can use a notification operation of the Npcf_SMPolicyControl API to forward the PCC rules to the SMF, such as if the PDU session has been established when the PCF creates the PCC rules. In some implementations, this may result in reversing the direction of the arrows at 4a and 4b, where the SMF responds at 4b with an acknowledgment of receipt of the rule. In other implementations, the notification operation may occur first, where the PCF notifies the SMF that the updated rules are available, thereby triggering the SMF to transmit the Npcf_SMPolicyControl request at 4a. Therefore, sending the PCC rules to the SMF can be initiated by either the PCF or the SMF (e.g., a "pull" operation, a "push" operation, a "notify and pull" operation, etc.).

[0092] At 5a, the SMF can send PDU collection information and RTPHE usage information to the UPF in an N4 message (e.g., an N4 session establishment request), and can receive a response (e.g., an N4 session establishment response) at 5b, which may include confirmation, further configuration information, etc.

[0093] As discussed above, in many implementations, RTP header extensions can be used to signal the PDU sequence number (PSN) and / or PDU set sequence number (PSSN). Figure 2 and Figure 3 In example implementations 200 and 300, these numbers are 8 bits long. However, this may not be sufficient for some implementations of media data communication.

[0094] For example, in many implementations, the bit depth of the PSSN field is primarily determined by the number of stripes present in the frame. A stripe can refer to a portion of an image (e.g., a rectangular region, a tile, etc.) and can be based on codec real units, macroblocks, raster scan tiles, etc. (depending on the codec used). When there are a large number of stripes in the frame, the PSSN requires a higher bit depth. The maximum number of stripes is 1000 for VVC, 600 for HEVC, and 5802 for H.264. Extending the PSSN to 10 bits allows for the independent representation of 1000 stripes.

[0095] In many implementations, the bit depth of the PSN field can be determined based on the maximum possible size of the PDU set. When encoding and decoding a frame using a single stripe, this data is encapsulated into a single PDU set. In this case, the number of PDUs required to encapsulate such a frame is large, and the number of PSNs required is also large.

[0096] In some implementations, the number of stripes per image can be configured in the Image Parameter Set (PPS). In some implementations, a 1-bit field (S) can be used to signal whether the number of stripes present in the frame is less than 32. For example, in some implementations, the S bit can be set to 1 when the number of stripes is less than 32, and set to 0 when the number of stripes is more than 32.

[0097] Therefore, in this implementation, when the number of stripes is less than 32 (S bit is set to 1), 8 bits can be allocated to the PSN field, and 8 bits can be allocated to the PSSN field. Considering the MTU size in an RTP packet is 1200 bytes, with 8 bits allocated to the PSN field, we can transmit up to 307200 (2^8 * 1200) bytes per frame or stripe. When each frame uses fewer than 32 stripes, 5 bits may be sufficient to uniquely represent the set of PDUs present in the frame. The additional 3 bits in the 8-bit PSSN field can be used to uniquely represent the set of PDUs present in those frames when multiple frames are transmitted together or as bursts.

[0098] Figure 8 and Figure 9 These are examples of RTP header extensions using single-byte header format 200' and double-byte header format 300' with stripe numbering signaling, according to some embodiments. Stripe fields 800 and 900 may include a single-bit flag that is set to 1 to indicate fewer than 32 stripes, or set to 0 to indicate 32 or more stripes. In examples 200' and 300', this flag is set to 1, and therefore, 8-bit PSSN fields (802, 902) and 8-bit PSN fields (804, 904) can be used.

[0099] When there are more than 32 stripes, 10 bits can be allocated to the PSSN and 6 bits to the PSN. Considering the MTU size of a 1200-byte RTP packet and the 6 bits allocated to the PSN field, we can transmit a maximum of 76,800 (2^6 * 1200) bytes per stripe. When each frame uses more than 32 stripes, more than 5 bits are needed to uniquely represent the set of PDUs present in the frame. The 10-bit PSSN field can be used to uniquely represent the set of PDUs present in these frames when multiple frames are transmitted together or as bursts.

[0100] Figure 10 and Figure 11 These are examples of RTP header extensions using single-byte header format 200'' and double-byte header format 300'' with stripe number signaling, according to some embodiments. Stripe fields 1002 and 1102 may include a single-bit flag that is set to 1 to indicate fewer than 32 stripes, or set to 0 to indicate 32 or more stripes. In examples 200' and 300', this flag is set to 0, and therefore, 10-bit PSSN fields (1002, 1102) and 6-bit PSN fields (1004, 1104) can be used.

[0101] Figure 12A flowchart of a method 1200 for signaling PDU set information via RTP header extension, according to some embodiments, is shown. At 1202, a device (such as a WTRU, computing device, encoder, media source device, streaming media service, wireless gateway, or any other type and form of device) can identify the data to be transmitted. This data may be stored in the device's memory, may be retrieved from another device, or may be generated by the device or another device.

[0102] In some implementations, at point 1204, the device can determine the type of data. The type of data can include audio data, video data (including augmented, virtual, or extended reality data), or any other type and form of data. In some implementations, determining the type of data can include identifying a session or application layer header or payload that indicates the type of data, or identifying a header of a bitstream that indicates the type of data. Audio and video data can be encoded via various encoders, which can be identified, for example, in the header of a bitstream or application layer packet.

[0103] In some implementations, at 1206, the device can determine whether 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, at 1208, the importance or priority of the data can be set to the highest value (which can be the lowest actual value, such as 0x00, depending on the implementation).

[0104] If the data is not audio data, in some embodiments, at 1210, the device may determine whether the data is video data. For example, the data may include encoded frames or portions of a video bitstream. The video data may be pre-recorded or live or real-time generated, such as video conferencing or live streaming video data, augmented or extended reality data, etc. If yes, in some embodiments, at 1212, the device may determine whether the data is a reference frame (e.g., an I-frame, or a frame used for prediction or differential coding of other frames but not dependent on other frames for encoding) or a set of parameters used to decode the video data. If yes, in some embodiments, at 1214, the importance or priority of the data may be set to the second highest value (which may be the second lowest actual value, such as 0x01, depending on the embodiment). If no, in some embodiments, at 1216, the importance or priority of the data may be set proportionally (or inversely proportionally, depending on the embodiment) to the time identifier of the video data (such that video data with the highest or largest time identifier has the lowest importance or priority).

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

[0106] In some implementations, at 1222, the number of stripes for each image or frame of the video can be identified and compared to a threshold. In some implementations, the number of stripes can be identified in the Image Parameter Set (PPS) of the video data. If the number of stripes does not exceed the threshold, in some implementations, at 1224, a standard length field (such as 8 bits) can be used for the PDU Set Sequence Number (PSSN), and 8 bits can be used for the PSU Sequence Number (PSN). If the number of stripes does exceed the threshold, in some implementations, at 1226, an extended length field can be used for the PSSN, and the PSN can therefore be shortened (e.g., adding two bits to the PSSN and removing two bits from the PSN, or any other similar exchange).

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

[0108] At 1230, PDUs and / or sets of PDUs can be generated based on various defined header values ​​(including priority, dropability, and / or PSSN and PSN length).

[0109] Therefore, implementations of the systems and methods discussed herein support signaling PDU set information via RTP header extensions. In various implementations, similar header extensions can be used with other protocols to achieve the same benefits. For example, implementations of the systems and methods discussed herein support signaling PDU set information relating to: set importance or priority; discardability (including the syntax, semantics, and guidelines for discardability flags); and how variable-length fields (such as PDU sequence numbers and / or PDU set sequence numbers) are handled.

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

[0111] In some implementations, determining the priority of data transmission includes: determining that the data includes reference frames of video; and selecting data with a higher priority than data including non-reference frames of video. In some implementations, determining the priority of data transmission includes: determining that the data includes a set of parameters for decoding or rendering video; and selecting data with a higher priority than data including non-reference frames of video. In some implementations, the method includes: determining by the WTRU that the number of stripes for each video frame image of the identified data for transmission exceeds a threshold; and generating a PDU set further includes: setting a header value in each PDU in the PDU set indicating that the number of stripes for each image exceeds the threshold; in this implementation, each PDU in the PDU set includes a header field indicating a PDU set sequence number, the header field having more bits than a header field indicating a PDU sequence number.

[0112] In some implementations, determining the priority of data transmission includes: determining that the data includes real-time audio data; and selecting data with a higher priority than data lacking real-time audio data.

[0113] In some implementations, the method includes: identifying second data for transmission by a WTRU; determining, by the WTRU, the priority of the second data transmission relative to other data transmissions performed by a first WTRU based on the type or content of the second data for transmission, wherein the second data has a lower priority than the other data transmissions; and generating a second set of PDUs by the WTRU, the second set of PDUs including a second plurality of PDUs, the second plurality of PDUs including the identified second data for transmission, wherein 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.

[0114] In a further embodiment, determining the priority of the second data transmission includes determining that the second data includes non-reference frames of video. In another further embodiment, determining the priority of the second data transmission includes determining that the second data includes a time identifier with a maximum value. In yet another further embodiment, determining the priority of the second data transmission includes determining that the second data includes non-reference frames of video associated with a subsequent reference frame of the video. In yet another further embodiment, the header value indicating the dropability, lower importance, or lower priority of the second PDU set is a header extension flag or an importance field of a header extension. In yet another further embodiment, the header value is received by the WTRU from an application function or an application server. In yet another further embodiment, the method includes: in response to detecting network conditions that satisfy a drop policy, the WTRU discards the second PDU set without transmitting the second PDU set.

[0115] In another aspect, this disclosure relates to a wireless transmitting / receiving unit including one or more processors configured to perform any of the embodiments of the methods discussed above. In yet another aspect, this disclosure relates to a network device including one or more processors configured to perform any of the embodiments of the methods discussed above. In yet another aspect, this disclosure relates to a circuit configured to perform any of the embodiments of the methods discussed above. In yet another aspect, this disclosure relates to a non-transitory computer-readable medium including instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform any of the embodiments of the methods discussed above.

[0116] While the features and elements described above are presented 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. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer-readable medium 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 include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM discs and digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for packet data unit prioritization, comprising: identifying, by a wireless transmit / receive unit (WTRU), data for transmission; determining, by the WTRU, a priority of a data transmission relative to other data transmissions by the WTRU based on a type or content of the data for transmission; generating, by the WTRU, a set of packet data units (PDUs), the set of PDUs comprising a plurality of PDUs, the plurality of PDUs comprising the identified data for transmission, wherein each PDU in the set of PDUs comprises a header value indicating a priority corresponding to the determined priority; and transmitting, by the WTRU, the generated set of PDUs.

2. The method of claim 1, further comprising: identifying, by the WTRU, second data for transmission; determining, by the WTRU, a priority of a second data transmission relative to other data transmissions by the first WTRU based on a type or content of the second data for transmission, the priority of the second data being lower than the other data transmissions; and generating, by the WTRU, a second set of PDUs, the second set of PDUs comprising a second plurality of PDUs, the second plurality of PDUs comprising the identified second data for transmission, wherein each PDU in the second set of PDUs comprises a header value indicating discardability, lower importance, or lower priority of the second set of PDUs.

3. The method of claim 2, wherein determining the priority of the second data transmission comprises: determining that the second data comprises a non-reference frame of a video.

4. The method of claim 2, wherein determining the priority of the second data transmission comprises: determining that the second data comprises a time identifier having a maximum value.

5. The method of claim 2, wherein determining the priority of the second data transmission comprises: determining that the second data comprises a non-reference frame of a video associated with a subsequent reference frame of the video.

6. The method of any one of the preceding claims, wherein the header value indicating discardability, lower importance, or lower priority of the second set of PDUs is a header extension flag or an importance field of a header extension.

7. The method of claim 6, wherein the header value is received by the WTRU from an application function or an application server. discarding, by the WTRU, the second set of PDUs without transmitting the second set of PDUs in response to detecting network conditions satisfying a discard policy.

9. The method of any one of the preceding claims, wherein determining the priority of the data transmission comprises:

8. The method of any of the preceding claims, further comprising: determining that the data comprises a reference frame of a video; and selecting a higher priority than a priority of data comprising a non-reference frame of the video.

10. The method of any one of claims 1 to 8, wherein determining the priority of the data transmission comprises: determining that the data comprises a parameter set for decoding or presenting a video; and selecting a higher priority than a priority of data comprising a non-reference frame of the video. ​ ​ ​ ​ 11. The method of any of the preceding claims, further comprising: determining, by the WTRU, that a number of slices per video frame image of the identified data for transmission exceeds a threshold value; wherein generating the set of PDUs further comprises setting, in each PDU of the set of PDUs, a header value indicating that the number of slices per image exceeds the threshold value; and wherein, in each PDU of the set of PDUs, a header field indicating a PDU set sequence number has a number of bits greater than a header field indicating a PDU sequence number.

12. The method of any of claims 1-8, wherein determining a priority of data transmission comprises: determining that the data comprises live audio data; and selecting a priority that is higher than a priority of data that lacks live audio data.

13. A wireless transmit / receive unit comprising one or more processors configured to perform any of the methods of claims 1-12.

14. A network device comprising one or more processors configured to perform any of the methods of claims 1-12.

15. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform any of the methods of claims 1-12.

Images