TSV Working Group T. Jiang Internet-Draft P. Liu Intended status: Informational China Mobile Expires: 24 April 2025 21 October 2024 UDP Option Extension for 5G XR Media Services draft-jiang-tsvwg-5gxrm-metadata-00 Abstract Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in 3GPP. The service features at achieving high data rate, high reliability and low latency. The multiple streams of an XRM service use IP sessions to transport media contents with the provisioning of advanced QoS settings. The XRM Metadata or PDU Set QoS marking is used to differentiate the PDU Set requirements to the 5GS. RTP header extension (HE), as defined by 3GPP, can be used to transport XRM Metadata for un-encrypted media streams, while the encrypted XRM streams post challenges for UPFs to extract the Metadata. This draft proposes to use the IETF UDP Option extension, by defining a new SAFE type, to help enhance the carry & transport of encrypted XRM Metadata. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Jiang & Liu Expires 24 April 2025 [Page 1] Internet-Draft 5GXRM Metadata UDP Option October 2024 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 5G XRM Service & Transport Model . . . . . . . . . . . . 3 1.2. Definitions of Terms . . . . . . . . . . . . . . . . . . 4 2. Transport Un-encrypted 5G XRM Media and Metadata . . . . . . 5 2.1. 5G XRM QoS enhancement for PDU Set . . . . . . . . . . . 5 2.2. PDU Set Marking for XRM Metadata . . . . . . . . . . . . 6 3. Transport Encrypted 5G XRM Media and Metadata . . . . . . . . 7 3.1. Using UDP Option to Transport Encrypted XRM Metadata . . 7 3.2. UDP-option for 5GS NOT-violate UDP Transport rule . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. 3GPP Defined RTP HE Format . . . . . . . . . . . . . 12 A.1. One-byte RTP Header Extension . . . . . . . . . . . . . . 12 A.2. Two-byte RTP Header Extension . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Extended Reality & multi-modality communication, or XRM, is a type of advanced service that has been studied and standardized in 3GPP [TS.23.501]. With the objective of achieving high data rate, high reliability and low latency, it features multi-modal interactions among a group of service entities that might be (geographically) distributed at the mobile network edges. The streams of an XRM service have components of data from the modalities like video, audio, ambient-sensor and haptic detection. The benefits of seamlessly integrating multiple types of streams sourced via multiple inputs make it widely applicable in fields, like AR/VR, telepresence, gaming, education, etc. XRM services consolidate the inputs from more than one source and disseminate information to multiple destinations, which indicates an XRM application could be comprised of the input data from different kinds of devices/sensors or the output data to different types of Jiang & Liu Expires 24 April 2025 [Page 2] Internet-Draft 5GXRM Metadata UDP Option October 2024 destinations. This scheme possesses intrinsic advantages of providing services that would be complementary to each other, or even bearing progressive add-on gains, so that redundant delivery and information accuracy would be achieved effectively. 1.1. 5G XRM Service & Transport Model Thanks to different requirements of 5G XRM media steams featuring coordinated throughput, low latency and high reliability, XRM service faces challenges on various aspects, e.g. characteristics of generated data across modalities, accurate multi-modality data synchronization, QoS differentiation, large volume of small packets, and packet-size variation, etc. [_5G.TACMM]. XRM services use (multiple) IP sessions to carry & transport data streams. With an IP session corresponding to one-modal stream, the coordinated transmission among multi-modal flows (or streams) needs to be warranted. The client(s) of different types of data of one application may be located at either one destination (e.g., a UE), or multiple destinations (e.g. having VR glasses, gloves, and more). 5G uses the term PDU or Packet Data Unit to represent packets exchanged among UEs (or end devices), RAN (or radio access network), 5GC (or 5G core network) and external AppServers in DNNs (Data Networks). PDU is somewhat similar to APU or application data unit. A QoS Flow is the finest granularity of QoS differentiation in a PDU Session, suggesting that all PDU packets belonging to a QoS flow be treated according to the same QoS requirements [TS.23.501]. 5G XRM has defined a new term, namely the PDU Set, specifying a group of packets carrying the payload of e.g. a frame, a video slice/tile, etc. Packets (i.e., PDUs) belonging to the same PDU Set are decoded/ handled as a whole, meaning a frame/video slice may be decoded at the receiver only if all or certain amount of the packets carrying the frame/video slice are successfully delivered. For example, a frame within a GOP (Group of Pictures) can only be decoded by the client in case all frames on which that frame depends are successfully received. Hence the groups of packets within a PDU Set have inherent dependency on each other in media layer. Without considering the inter-dependancy among the packets within a PDU set, 5GS may perform resource scheduling with low efficiency. For example, upon network congestion, a 5GS may randomly drop packet(s) but deliver other packets of the same PDU set that are deemed useless to the client and thus waste radio resources [TS.23.501]. Figure 1 shows the 5G XRM transport model. The network function(NF) UPF is similar to an IP-domain router, which sends/receives IP packets (or PDUs in PDU sets) off the N6 interface to/from EAS'es (or App Servers) in Data Domains. Normally, a UPF would use the IP Jiang & Liu Expires 24 April 2025 [Page 3] Internet-Draft 5GXRM Metadata UDP Option October 2024 5-tuple for packet classfication and prioritization (i.e., using PDRs in the 3GPP 5G term [TS.23.501]). However, a 5-tuple cannot expose thoroughly PDU and PDU Set related QoS information of XRM media streams. As such, this draft will elucidate how to expose the information for effectively addressing the data processing of XRM streams at the UPF in 5GS. EAS: App Server in Data Domain ........................................... : /----------------\ : : | 5G Core | : : \----------------/ : : N1 N2 N4 : : / | | <= Downlink direction : / | +-------+ : +----+ +-------+ | | : +-------------+ | UE |--| gNB |----| UPF (N6)---------:---| EAS'es | +----+ +-------+ | | : | (1 or more) | : +-------+ : +-------------+ : | | Uplink direction => : +-N9-+ : ........................................... Figure 1: 5G XRM Transport Model 1.2. Definitions of Terms * PDU Session: Association between the UE and a Data Network that provides a PDU (Packet Data Unit) connectivity service. * PDU Set: One or more PDUs carrying the payload of one unit of information generated at the application level (e.g. frame(s), video slice(s), etc.). * PDU Set information: the critical information describing the settings of a PDU set. It is comprised of multiple components and also called Metadata in the draft. * PDU Set marking: Marking the PDUs carrying a payload with the PDU Set Information. * Data Burst: A data burst is a group of multiple PDU Sets generated and sent by the application such that there is an idle period between two data bursts. A Data Burst can be composed of one or multiple PDU Sets. Jiang & Liu Expires 24 April 2025 [Page 4] Internet-Draft 5GXRM Metadata UDP Option October 2024 2. Transport Un-encrypted 5G XRM Media and Metadata 2.1. 5G XRM QoS enhancement for PDU Set XRM Media streams, potentially consisting of diversified framing, slicing and encoding of video images, contain additional parameters like the relative importance among different PDUs that are generated from differrent types of frames. E.g., the I, P, B frames might determine tiered priorities among them. [TS.23.501] standardizes the enhancement to the 5GS QoS framework to support advanced settings of XRM PDU Sets, which are called 'XRM Metadata' in this draft. XRM Metadata supports differentiated QoS provisioning. For example, a Metadata component, the PDU Set Importance or PSI could be downward- assigned to less-critical PDU Set(s) so as to de-prioritize the resource consumption of less important PDU Set(s). In the case of another Metadata component, the PDU sequence number is assigned to a PDU for better ordered processing of PDUs at receviers. Figure 2 demonstrates the PDU Set QoS information and how they would be generated and transported by App servers (EAS'es) in DNN. EAS: App Server in Data Domain PSQoSInfo: PDU Set QoS Information, e.g. PSI, PDU Seq.#, etc. RTP HE: RTP Header Extension ........................................... : /----------------\ : : | 5G Core | : : \----------------/ : : N1 N2 N4 : : / | | <= DL : / | +-------+ : RTP HE(PSQoSInfo) +----+ +-------+ | | : +-------------+ | UE |--| gNB |----| UPF (N6)---------:---| EAS'es | +----+ +-------+ | | : | (1 or more) | : +-------+ : +-------------+ : | | UL => : +-N9-+ : ........................................... Figure 2: XRM RTPHE at EAS'es Jiang & Liu Expires 24 April 2025 [Page 5] Internet-Draft 5GXRM Metadata UDP Option October 2024 The 3GPP document TS 26.522 [TS.26.522] has standardized how RTP would be extended to transport XRM media and Metadata information between an edge server (or EAS) and an end device. As shown in the Figure 2, the RTP header extension (HE) for PDU Set marking can be performed by an application server (or EAS, RTP sender, etc.) for downstream XRM media traffic. TS 26.522 [TS.26.522] has defined both the one-byte and the two-byte RTP HE formats [RFC8285], to accommodate the XRM metadata. Please see the Appendix A for the definitions of RTP HE formats. 2.2. PDU Set Marking for XRM Metadata According to the latest progress in 3GPP, the PDU Set marking for XRM metadata can be classified into three categories, namely: * R18MA: Indicate the existing -mandatory- PDU Set markings as defined in the 3GPP Rel-18 [TS.23.501]. * R18OP: Indicate the existing -optional- PDU Set markings as defined in the 3GPP Rel-18 [TS.23.501]. There could be zero optional marking. * R19EX: Indicate the -extensible- PDU Set markings as defined in the 3GPP Rel-19 [TR.23.700-70] and beyond (to accommodate any future extension). There could be zero extensible marking. From the 3GPP perspective, the semantics of the RTP HE fields for PDU Set marking can be defined as follows: * E (1-bit, R18MA): Indicate the End (or the last) PDU of a PDU Set. * D (1-bit, R18MA): Indicate the End (or the last) PDU of a Data Burst; A Data Burst may consist of one or more PDU Sets. * PSI (4-bit, R18MA): PDU Set Importance, indicating the importance of a PDU Set compared to other PDU Sets within the same XRM Session. * PSSN (10-bit, R18MA): PDU Set Sequence Number, indicating the sequence number of a PDU Set to which the current PDU belongs. * PSN (6-bit, R18MA): PDU Sequence Number within a PDU Set: indicating the sequence number of the current PDU within the PDU Set. * PSSize (24-bit, R18OP): PDU Set Size, indicating the total size of all PDUs of a PDU Set to which this PDU belongs. Jiang & Liu Expires 24 April 2025 [Page 6] Internet-Draft 5GXRM Metadata UDP Option October 2024 * NPDS (16-bit, R18OP): Number of PDUs in a PDU Set: indicating the total number of PDUs belonging to the same PDU Set. * BSize (bit#-TBD, R19EX): Burst Size, indicating the size of a traffic burst, which might be comprised of one or more PDU sets. * TTNB (bit#-TBD, R19EX): Time to Next Burst, indicating the time between the end of the present burst and the beginning of the next burst. Please see the Appendix A on how the above PDU Set markings are encoded in an RTP extended header. 3. Transport Encrypted 5G XRM Media and Metadata There are other critical factors impacting the transport of encoded video packets. One of them is the ubiquitously-existential encryption of packet (header and) payload. For example, in the Figure 2, an EAS (or RTP sender) sources & transports XRM stream data, and associated Metadata. If both video contents and Metadata in a packet are encrypted at the source (i.e., the UDP source), then the Metadata or so-called PDU Set QoS information will remain hidden from intermediary routing entities, i.e., the UPF as in the Figure 2, until the same packet reaches the UDP destination in a UE. That the encryption preventing an (intermediary) UPF from extracting XRM Metadata brings in a new dimension of challenge to the 5G XRM service. The challenge revolving around the transport of encrypted XRM media leads to the exploration & adoption of several IETF mechanisms by 3GPP, with the focus on conveying critical XRM Metadata to UPFs. The 3GPP document [TR.23.700-70] has concluded to support three different schemes, namely the Media over QUIC (MoQT) [MediaOverQUIC], the QUIC- Aware Proxying HTTP [QUICawareProxying] and, finally, the UDP Option extension [transportUDPoption]. 3.1. Using UDP Option to Transport Encrypted XRM Metadata When we view the requirements of XRM payload and header encryption, along with the possible extensibility provided by [transportUDPoption], we believe adopting the UDP Option is a feasbile solution. Jiang & Liu Expires 24 April 2025 [Page 7] Internet-Draft 5GXRM Metadata UDP Option October 2024 As shown in the Figure 3, the UDP option scheme is supported to carry encrypted & integrity-protected XRM metadata that is transported between the UPF and the EAS. Security keys for UDP Option are negotiated between UPFs and EAS'es via a 3GPP-defined procedure. XRM Metadata corresponds to PDU Set information as in Section 2.2. The UPF extracts the XRM Metadata from extended UDP options as defined in Figure 4. EAS: App Server in Data Domain PSQoSMDInfo: PDU Set QoS Information, e.g. PSI, PDU Seq.#, etc. RTP HE: RTP Header Extension ........................................... : /----------------\ : : | 5G Core | : : \----------------/ : : N1 N2 N4 <= DL : / | | : RTP + UDP-option : / | +-------+ : (encrypted PSQoSMDInfo) +----+ +-------+ | | : +-------------+ | UE |--| gNB |----| UPF (N6)---------:---| EAS'es | +----+ +-------+ | | : | (1 or more) | : +-------+ : +-------------+ : | | UL => : +-N9-+ : ........................................... Figure 3: XRM RTPHE at EAS'es The Figure 4 shows the UDP option bit settings for XRM PDU Set information (i.e., XRM Metadata) (please reference to Section 2.2 for more details). The 'Kind' value will be allocated from the range [10...126] after registering to IANA. This UDP Option is a SAFE option type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind=TBD | Total-len | Len_EM |E| R |D| PSI(4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSSN(10) | PSN(6) | Len_EO | PSSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSSize (cont. 24-bit) | NPDS (16-bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len_EN | BSize + TTNB (size TBD ......) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jiang & Liu Expires 24 April 2025 [Page 8] Internet-Draft 5GXRM Metadata UDP Option October 2024 Figure 4: UDP Options for XRM PDU-Set information * Total-len: Total number of bytes of this option, including Kind and Total-len fields. * Len_EM: Total number of bytes for the existing -mandatory- PDU Set markings, which indicates the mandatory markings as defined in the Rel-18 [TS.23.501], including E, D, PSI, PSSN and PSN. * Len_EO: Total number of bytes for the existing -optional- PDU Set markings, which indicates the optional markings as defined in the Rel-18 [TS.23.501], including PSSize and NPDS. Its value could be zero. * Len_EN: Total number of bytes for the -extensible- PDU Set markings, which indicates the extensible markings that would be defined in later release(s), including BSize and TTNB as defined in the Rel-19 [TR.23.700-70]. Its value could be zero. Note: Total-len = Len_EM + Len_EO + Len_EN The advantage of applying UDP Option helps remove adding RTP HE to accommodate the XRM Metadata as defined in [TS.26.522]. The RTP HE is actually more suitable for un-encrypted media streams (see Section 2). For un-encrypted DL PDUs (of a PDU-set) reaching a UPF, the UPF extracts the XRM metadata for processing (from un-encrypted PDUs). Comparably, for encrypted streams from EAS'es, the XRM metadata is carried in (extended) UDP Options, for which there is no need to use the (redundant) RTP HE any more. Another advantage is that UDP is a layer-4 protocol and its header will normally not be processed by IP routers. Not only does this relieve the processing burden off IP transport devices, but also gives a clear demarcation of the transport & IP layer structure. 3.2. UDP-option for 5GS NOT-violate UDP Transport rule Some concerns are currently revolving around the extension of the UDP Option by arguing that UDP is a layer-4 transport protocol and its associated datagrams should be end-to-end processed, i.e., encapsulated at UDP sources and decapsulated at UDP destinations. The similar argument has been discussed in the Section 16 of [transportUDPoption]. As in Figure 2, we know the downlink IP packets enter into the 5GS via the UPF N6 interface from the IP domain (DNN) (right-side in the figure). The UPF functions to switch IP packets toward the UE (residing on the left side in the figure). Obviously, the UE is the genuine end receiver (of a UDP datagram). The UPF is only an intermediary node taking on IP functionalities, Jiang & Liu Expires 24 April 2025 [Page 9] Internet-Draft 5GXRM Metadata UDP Option October 2024 which is nothing different from a regular IP-domain node. Therefore, applying the UDP Option extension and having the intermediary (IP) node, e.g., a 5GS UPF, process UDP datagrams might be indeed a concern of violating the end-to-end transport structure. Fortunately, there exist good arguments for the 5G XRM service to adopt the UDP Option extension. A 5GS is unique in that it is a composite system, as shown in the Figure 2. It can be considered holistically as a 'blackbox' joining the external IP domain. It bears the 'Opaque' property to the outside. The IP DNN does not know that a UE and its anchored UPF (in 5GS) are two seperate entities, nor does it care. Instead, it only cares to forward IP packets downstream to the 5GS (via the N6 interface). How the 5GS (i.e., the UPF) may process packets is out of the scope (of the IP domain). Because of 5GS' 'composite & transparent' characteristics, we believe that a 5GS (UPF) can be granted the capability to 'intelligently' break the IP-UDP demarcation rule by peeking at the (encrypted) XRM Metadata that is carried in UDP Option. To the external IP domain, this still observes the end-to-end transport rule. Actually, there is already an I.D. discussing how to have end points explicitly distribute the encrpyted metadata to an intermediary network node [EncryptedMetaDataToNetworkNode]. As shown in the Figure 2, the UPF would be the node to use the metadata to assist in decrypting the media contents (and/or headers). Once the UPF gets all the detailed information, it can provision and enforce the QoS settings for the XRM streams [TS.23.501]. Further, the draft [transportUDPoption] also suggests clearly that the UDP Option is just a framework. Options might be defined even when all the details (along with any potential extension) are not yet complete. The use of such options can be described or supplemented in separate documents. This suggestion does bode well for the 5GS XRM service because our draft is exactly conforming to the tenet of the UDP Option framework. 4. Security Considerations There is generally no security concern as long as the XRM Metadata is encrypted and integrity-protected during the transport in UDP Option extension. An AUTH UDP Option can be added to allow the UPF to detect any modification to the Metadata. 5. IANA Considerations IANA request to assign a new Kind from the SAFE range [10...126] of the UDP option registry as per [transportUDPoption] Jiang & Liu Expires 24 April 2025 [Page 10] Internet-Draft 5GXRM Metadata UDP Option October 2024 Kind Length Meaning ----------------------------------------------------- TBD Varied XRM Metadata (XRMeta) 6. References 6.1. Normative References [EncryptedMetaDataToNetworkNode] Reddy, T., "An Approach for Encrypted Transport Protocol Path Explicit Signals", draft-reddy-tsvwg-explcit-signal- 01, July 2023. [MediaOverQUIC] Curley, L., "Media over QUIC Transport", draft-ietf-moq- transport-05, October 2024. [QUICawareProxying] Pauly, T., "QUIC-Aware Proxying Using HTTP", draft-ietf- masque-quic-proxy-03, October 2024. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, . [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, . [TR.23.700-70] "3GPP TR 23.700-70:: Study on architecture enhancement for Extended Reality and Media service (XRM); Phase 2", 3GPP TR 23.700-70, September 2024. [transportUDPoption] Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- udp-options-33, October 2024. [TS.23.501] "3GPP TS 23.501 (V17.0.0): System Architecture for 5G System; Stage 2", 3GPP TS 23.501, March 2021. Jiang & Liu Expires 24 April 2025 [Page 11] Internet-Draft 5GXRM Metadata UDP Option October 2024 [TS.24.501] "3GPP TS 24.501: Non-Access-Stratum (NAS) protocol for 5G System (5GS)", 3GPP TS 24.501, September 2022. [TS.26.522] "3GPP TS 26.522: 5G Real-time Media Transport Protocol Configurations", 3GPP TS 26.522, June 2024. [_5G.TACMM] Jiang, T., Shi, X., Gao, J., and P. Liu, "On the 5G Edge Network Challenges of Providing Tactile and Multi-modality Communication Services", International Conference on Edge Computing - EDGE'2021 , December 2021. 6.2. Informative References [GSMAnewSSTforXRM] GSMA, "LS reply on a new SST value for Extended Reality and Media Services", https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ TSGS2_157_Berlin_2023-05/Docs/S2-2306269.zip, February 2023. [_3GPPnewSSTforXRM] 3GPP, "Introduction of a new standard SST for Extended Reality and Media Services", https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/ TSGS2_157_Berlin_2023-05/Docs/S2-2308186.zip, May 2023. Appendix A. 3GPP Defined RTP HE Format The 3GPP document [TS.26.522] has defined two formats of RTP Header Extension for the marking of PDU Sets and XRM Metadata, namely the one-byte RTP HE and the two-byte RTP HE. The following two figures correspond to the two formats, respectively. Please note that, as of now, both HE extensions in [TS.26.522] conform to the standards of the Rel-18 in [TS.23.501]. A.1. One-byte RTP Header Extension Jiang & Liu Expires 24 April 2025 [Page 12] Internet-Draft 5GXRM Metadata UDP Option October 2024 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xBE | 0xDE | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len |E| R |D| PSI | PSSN | PSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSSize | NPDS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NPDS (cont.) | +-+-+-+-+-+-+-+-+ Figure 5: One-byte RTP HE for XRM Metadata A.2. Two-byte RTP Header Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x100 |appbits| length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len |E| R |D| PSI | PSSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | PSN | PSSize | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NPDS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Two-byte RTP HE for XRM Metadata Authors' Addresses Tianji Jiang China Mobile Email: tianjijiang@chinamobile.com Peng Liu China Mobile Email: liupengyjy@chinamobile.com Jiang & Liu Expires 24 April 2025 [Page 13]