ETSI TS 126 522 V18.2.0 (2025-07)

5G; 5G Real-time Media Transport Protocol Configurations (3GPP TS 26.522 version 18.2.0 Release 18)

RTS/TSGS-0426522vi20

General Information

• Status: Not Published
• Technical Committee: 3GPP SA 4 - Codec
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Completion Date: 25-Jul-2025

Standards Content (Sample)

TECHNICAL SPECIFICATION
5G;
5G Real-time Media Transport Protocol Configurations
(3GPP TS 26.522 version 18.2.0 Release 18)

3GPP TS 26.522 version 18.2.0 Release 18 1 ETSI TS 126 522 V18.2.0 (2025-07)

Reference
RTS/TSGS-0426522vi20
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 2 ETSI TS 126 522 V18.2.0 (2025-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found at 3GPP to ETSI numbering cross-referencing.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 3 ETSI TS 126 522 V18.2.0 (2025-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
Introduction . 6
1 Scope . 7
2 References . 7
3 Definitions of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 RTP Functionalities . 9
4.1 General . 9
4.2 RTP Header Extension for PDU Set Marking . 10
4.2.1 General . 10
4.2.2 One-byte RTP Header Extension Format . 10
4.2.3 Two-byte RTP Header Extension Format . 10
4.2.4 Semantics . 10
4.2.5 SDP Signaling . 11
4.2.6 Guidelines for PDU Set Marking . 12
4.2.6.1 End of Data Burst Field . 12
4.2.6.2 PDU Set Importance Field . 12
4.2.6.2.1 General . 12
4.2.6.2.2 H.264/AVC Codec . 13
4.2.6.2.3 H.265/HEVC Codec . 13
4.2.6.2.4 PSI based on affected PDU Sets . 15
4.2.6.2.5 PSI mapping based on PDU Set dependencies . 15
4.2.6.3 PDU Set Size Field . 16
4.2.7 Guidelines for AS . 17
4.3 RTP Header Extension for XR Pose. 17
4.3.1 General . 17
4.3.2 SDP Signaling . 17
4.3.3 Header Extension Format . 18
4.4 RTP Header Extension for in-band end-to-end delay measurement . 20
4.4.1 General . 20
4.4.2 One-byte RTP Header Extension Format . 21
4.4.3 Two-byte RTP Header Extension Format . 21
4.4.4 Syntax . 22
4.4.5 Semantics . 22
4.4.6 SDP signaling . 22
5 RTCP Feedback Reporting Procedures . 24
5.1 General . 24
5.2 Transmission of timing information data for QoE measurements . 24
5.2.1 General . 24
5.2.2 RTCP message-based transmission of timing information . 24
5.2.2.1 General . 24
5.2.2.2 Extended Report block for QoE timing information . 25
5.2.3 SDP signaling and attributes . 26
Annex A (informative): Guidelines for PDU Set identification . 27
A.0 General . 27
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 4 ETSI TS 126 522 V18.2.0 (2025-07)
A.1 Leveraging RTP Header Extensions . 27
A.2 Obtaining PDU Set information from RTP Header or Payload . 27
A.2.0 General . 27
A.2.1 RTP/SRTP header . 27
A.2.2 RTP payload . 28
A.2.2.1 General . 28
A.2.2.2 RTP payload for H.264/AVC codec . 28
A.2.2.3 RTP payload for H.265/HEVC codec . 29
Annex B (informative): Examples of SDP offers and answers . 31
B.1 SDP example for RTP header extension for XR pose . 31
Annex C (informative): RTP Header Extension for Absolute Sender Time . 32
Annex D (informative): IANA registration information for RTP Header Extensions . 33
D.1 Introduction . 33
D.2 urn:3gpp:pdu-set-marking:rel-18 . 33
D.3 urn:3gpp:xr-pose . 33
D.4 urn:3gpp:delay-measurement-response:rel-18 . 33
Annex E (informative): IANA registration information for RTCP XR block types . 35
E.1 Introduction . 35
E.2 Timing Information for QoE Metrics Calculation . 35
Annex F (informative): Change history . 35
History . 36

ETSI
3GPP TS 26.522 version 18.2.0 Release 18 5 ETSI TS 126 522 V18.2.0 (2025-07)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 6 ETSI TS 126 522 V18.2.0 (2025-07)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
Introduction
TR 26.998 [8] (5G Glass-type AR/MR) identified multiple aspects of normative work to support "5G/AR Real-time
Communication" (clause 8.4). TR 26.998 identified normative work needed to support delivery of immersive media via
RTP for IMS-based and WebRTC-based conversational services. To support XR split rendering as described in clause
8.6 of TR 26.998, RTP is also needed to transport immersive media and metadata information between the edge and
device.
To improve support for the above XR services and enablers, it is necessary to configure RTP with specific settings and
features that enable immersive experiences. Further improvements in performance and QoE over the 5G system can be
achieved by specifying RTP configurations that are integrated and optimized for the 5G system, and leverage cross-
layer optimizations used by other 3GPP specifications.
As these RTP configurations will be specified for use by multiple services, service enablers, and potentially, application
developers, it is very important that they do not introduce unnecessary complexities that would discourage commercial
deployment of the configurations. Therefore, technologies specified here should be commercially relevant and not
introduce implementation and interoperability complexity without clearly demonstrating performance gains or new
relevant functionalities.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 7 ETSI TS 126 522 V18.2.0 (2025-07)
1 Scope
The present document focuses on RTP [4] over UDP [9] for eXtended Reality in 5G.
RTP Header Extensions and RTCP Feedback Reporting are introduced for real-time immersive media and associated
metadata for use in 5G Systems.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] ITU-T Rec H.264 (08/2021): "Advanced video coding for generic audiovisual services" | ISO/IEC
14496-10:2022: "Information technology – Coding of audio-visual objects – Part 10: Advanced
Video Coding".
[3] ITU-T Rec H.265 (08/2021): "High efficiency video coding" | ISO/IEC 23008-2:2023: "High
Efficiency Coding and Media Delivery in Heterogeneous Environments – Part 2: High Efficiency
Video Coding".
[4] IETF RFC 3550 (2003): "RTP: A Transport Protocol for Real-Time Applications", H. Schulzrinne,
S. Casner, R. Frederick and V. Jacobson.
[5] IETF RFC 6184 (2011): "RTP Payload Format for H.264 Video", Y.-K. Wang, R. Even, T.
Kristensen, R. Jesup.
[6] IETF RFC 7798 (2016): "RTP Payload Format for High Efficiency Video Coding (HEVC)", Y.-K.
Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela.
[7] 3GPP TR 26.928: "Extended Reality (XR) in 5G".
[8] 3GPP TR 26.998: "Support of 5G glass-type Augmented Reality / Mixed Reality (AR/MR)
devices".
[9] IETF RFC 768 (1980): "User Datagram Protocol", J. Postel.
[10] IETF RFC 5761 (2010): "Multiplexing RTP Data and Control Packets on a Single Port", C.
Perkins, M. Westerlund.
[11] IETF RFC 8285 (2017): "A General Mechanism for RTP Header Extensions", D. Singer, H.
Desineni, R. Even.
[12] 3GPP TS 23.501: "System architecture for the 5G System (5GS)".
[13] IETF RFC 5905 (2010): "Network Time Protocol Version 4: Protocol and Algorithms
Specification”, D. Mills, J. Martin, J. Burbank, W. Kasch.
[14] IEEE 1588-2019 – IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems, June 2020.
[15] IETF RFC 4574 (2006): "The Session Description Protocol (SDP) Label Attribute", O. Levin, G.
Camarillo.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 8 ETSI TS 126 522 V18.2.0 (2025-07)
[16] IETF RFC 3611 (2003): "RTP Control Protocol Extended Reports (RTCP XR)", T. Friedman, R.
Caceres, A. Clark.
[17] 3GPP TS 26.119: "Media Capabilities for Augmented Reality".
[18] IETF RFC 7656 (2015): "A Taxonomy of Semantics and Mechanisms for Real-Time Transport
Protocol (RTP) Sources ", J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman.
[19] IETF RFC 5888 “The Session Description Protocol (SDP) Grouping Framework”, G. Camarillo et
al.
[20] ISO/IEC 60559:2020: “Floating-point arithmetic”.

3 Definitions of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in TR 21.905 [1] and the following apply. A term defined in
the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
Age of content: The time duration between the moment the content is created and the time it is presented.
Estimated-at-time: Time when the pose was estimated.
Data Burst: A data burst is a set of multiple PDUs 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.
Multimedia Session: An association among a group of participants engaged in the communication via one or more
RTP sessions, as defined in section 2.2.4 of IETF RFC 7656 [18].
Orientation quaternion: Quaternion used to represent the orientation of an object.
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), metadata, etc.).
PDU Set marking: Marking the PDUs carrying a payload with the PDU Set Information.
Rendered pose: An XR pose sent from a server to a client that was used for rendering at the server.
Roundtrip interaction delay: The sum of the age of content and the user interaction delay.
Scene Update Time: Time when the scene manager starts processing.
Split-render-output-time: Time of completing a rendering.
Split rendering server: Server to perform remote rendering.
Start-to-render-at-time: Time of starting a rendering.
User interaction delay: The time duration between the moment at which a user action is initiated and the time such an
action is taken into account by the content creation engine.
XR Pose: A position and orientation in space relative to an XR Space.
XR Service: A service supporting XR use case as defined in clause 5 of [7].
XR Space: A frame of reference in which an application chooses to track the real world. An XR Space provides a
relation of the user’s physical environment with other tracked entities.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 9 ETSI TS 126 522 V18.2.0 (2025-07)
3.2 Symbols
For the purposes of the present document, the following symbols apply:
Ih_p IP header overhead
P Number of RTP packets
R RTP payload data size
Rh_p RTP header overhead, including any RTP header extensions
S RTP packet maximum SDU size
Uh_p UDP header overhead
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905 [1].
AP Aggregation Packet
AVC Advanced Video Coding
BLA Broken Link Access
CRA Clean Random Access
DoF Degrees of Freedom
FU Fragmentation Unit
HE (RTP) Header Extension
HEVC High Efficiency Video Coding
IDR Instantaneous Decoder Refresh
IRAP Intra Random Access Picture
NAL Network Abstraction Layer
NRI nal_ref_idc
NTP Network Time Protocol
OS Operating System
PACI Payload Content Information
PPS Picture Parameter Set
PSI PDU Set Importance
PTP Precision Time Protocol
RADL Random Access Decodable Leading
RASL Random Access Skipped Leading
RTCP RTP Control Protocol
RTCP XR RTCP eXtended Report
SPS Sequence Parameter Set
SRS Split Rendering Server
SRTP Secure RTP
TID Temporal Identifier
UPF User Plane Function
UDP User Datagram Protocol
VCL Video Coding Layer
VPS Video Parameter Set
XR eXtended Reality
4 RTP Functionalities
4.1 General
This clause defines functional additions to RTP [4] for potential use in 5G Systems. The RTP protocol is designed to be
generic and extensible, e.g., by using RTP Header Extensions (HE) [11] and by defining RTP payload formats for
specific media codecs, e.g., [5][6].
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 10 ETSI TS 126 522 V18.2.0 (2025-07)
4.2 RTP Header Extension for PDU Set Marking
4.2.1 General
The RTP HE for PDU Set marking is defined in this clause. PDU Set marking can be performed by an RTP sender,
such as an Application Server (e.g., MRF), a sender UE that sends media to an RTP receiver, such as a UE, or other 5G
network components.
NOTE 1: The handling of PDU Sets in the 5G System for supporting high data rate and low latency traffic is
described in clause 5.37.5 of [12].
Endpoints that support the RTP HE for PDU Set marking shall support both RTP HE formats (i.e., the one-byte and the
two-byte formats) according to RFC 8285 [11].
If the RTP HE for PDU Set marking is the only RTP HE used, the endpoints shall use the 1-byte header format. If other
2-byte RTP HE elements are used in the same RTP stream, then the 2-byte header shall be used, unless the "a=extmap-
allow-mixed" is successfully negotiated through SDP offer/answer, as described by RFC 8285 [11].
NOTE 2: The headers are not shown with padding as this depends on other prospective extension elements in use,
as per RFC 8285 [11] alignment specifications.
The IANA registration information for the RTP HE for PDU Set marking is provided in Annex D.2.
4.2.2 One-byte RTP Header Extension Format
The one-byte RTP HE for the marking of PDU Sets and End of Bursts is defined as follows:
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
+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+
|
+.+.+.+.+.+.+.+.+
4.2.3 Two-byte RTP Header Extension Format
The two-byte RTP HE for the marking of PDU Sets and End of Bursts is defined as follows:
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       |
+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+

4.2.4 Semantics
The semantics of the fields of the RTP HE for PDU Set marking are defined as follows:
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 11 ETSI TS 126 522 V18.2.0 (2025-07)
- End PDU of the PDU Set [E] (1 bit): This field is a flag that shall be set to 1 for the last PDU of the PDU Set
and set to 0 for all other PDUs of the PDU Set.
- End of Data Burst [D] (1 bit): This field is a flag that shall be set to 1 for the last PDU of a Data Burst. It shall
be set to 0 for all other PDUs. A Data Burst may consist of one or more PDU Sets.
NOTE 1: The bit encodes the End of Data Burst indication as per the guidelines provided in clause 4.2.6.1.
- Reserved [R] (2 bits): This field is reserved for future usage (e.g., dynamic burst indication). It shall be set to 0
by the RTP sender and shall be ignored by the RTP receiver.
- PDU Set Importance [PSI] (4 bits): The PDU Set Importance field indicates the importance of this PDU Set
compared to other PDU Sets within the same Multimedia Session. This information may help RAN to discard
PDUs, when needed. Lower values shall indicate a higher importance PDU Set, with the highest importance
PDU Set indicated by 1 and the lowest importance PDU Set indicated by 15. When the RTP sender cannot
define an importance, it shall set the value to 0.
NOTE 2: A complete set of guidelines for setting the PSI field for the 3GPP audio/video codecs are provided in
clause 4.2.6.2
- PDU Set Sequence Number [PSSN] (10 bits): The sequence number of the PDU Set to which the current PDU
belongs, acting as a 10-bit numerical identifier for the PDU Set. The PSSN shall be incremented monotonically
by 1 for each subsequent PDU Set.
NOTE 3: This value wraps around at 1023, however, using the 16-bit RTP packet sequence number and PSSN pair,
a receiver may uniquely distinguish between any PDU Sets.
- PDU Sequence Number within a PDU Set [PSN] (6 bits): The sequence number of the current PDU within the
PDU Set. The PSN shall be set to 0 for the first PDU in the PDU Set and incremented monotonically for every
PDU in the PDU Set in the order of transmission from the sender.
NOTE 4: A receiver may use the RTP packet sequence number together with the PSN to distinguish between PDUs
within a PDU Set that contains more than 64 PDUs.
- PDU Set Size [PSSize] (24 bits): The PDU Set Size indicates the total size of all PDUs of the PDU Set to which
this PDU belongs. This field is optional and subject to an SDP signaling offer/answer negotiation, where the
RTP sender shall indicate whether it will provide the size of the PDU Set for that RTP stream. If not enabled, the
field shall not be present within the RTP HE. If enabled, but the RTP sender is not able to determine the PDU
Set Size for a particular PDU Set, it shall set the value to 0 in all PDUs of that PDU Set. The PSSize shall
indicate the size of a PDU Set including RTP/UDP/IP header encapsulation overhead of its corresponding PDUs.
The PSSize shall be expressed in bytes. It is recommended to add the PDU Set Size field when the Number of
PDUs in the PDU Set field is present.
NOTE 5: This field may be optionally present given the signaling of the "pdu-set-size" extension attribute in the
SDP offer/answer negotiation as per clause 4.2.5.
- Number of PDUs in the PDU Set [NPDS] (16 bits): The number of PDUs within the PDU Set indicates the
total number of PDUs belonging to the same PDU Set. This field is optional and subject to an SDP signaling
offer/answer negotiation, where the RTP sender may indicate whether it will provide the number of PDUs within
the PDU Set for that RTP stream. If enabled, but the RTP sender is not able to determine the Number of PDUs in
the PDU Set, it shall set the value to 0 in all PDUs of that PDU Set. It is recommended to add the Number of
PDUs in the PDU Set field when the PDU Set Size field is present.
NOTE 6: This field may be optionally present given the signaling of the "num-pdus-in-pdu-set" extension attribute
in the SDP offer/answer negotiation as per clause 4.2.5.
NOTE 7: Guidelines to set the PDU Set Size in bytes by an RTP sender are provided in clause 4.2.6.3.
NOTE 8: The use of NPDS for the NAT46/NAT64 correction is FFS.
4.2.5 SDP Signaling
An RTP sender capable of sending RTP HE for PDU Set marking shall use the SDP extmap attribute for RTP HE for
PDU Set marking in the media description of the RTP stream(s) carrying the RTP HE for PDU Set marking. An RTP
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 12 ETSI TS 126 522 V18.2.0 (2025-07)
receiver that does not support RTP HE for PDU Set marking can ignore that RTP HE when included. The signaling of
the PDU Set marking RTP HE shall follow the SDP signaling design and the syntax and semantics of the "extmap"
attribute as outlined in RFC8285.The URN for the PDU Set marking shall be set to "urn:3gpp:pdu-set-marking:rel-
18".
The ABNF syntax for the extmap attribute for the signaling of RTP HE for PDU Set marking is defined as follows,
extending the ABNF in RFC 8285:
extensionname = "urn:3gpp:pdu-set-marking:rel-18"
extensionattributes = [pdu-set-attribute *2(SP pdu-set-attribute)]
pdu-set-attribute = format / "pdu-set-size" / "num-pdus-in-pdu-set"
format = "short" / "long"
The extension attributes have the following semantics:
- format: indicates if the RTP HE for PDU Set marking uses the 1-byte (short) or the 2-byte (long) format. This
extension attribute shall not be included more than once.
NOTE: Regardless if this extension attribute is present or not, the use of long or short format is determined as
described by section 4.1.2 of RFC 8285, i.e., based on what format other RTP HEs use in the same RTP
session, unless both endpoints announced support for handling mixed format with "a=extmap-allow-
mixed" as described by section 6 of RFC 8285.
- pdu-set-size: if present, this extension attribute indicates that the RTP sender will provide the PDU Set size in
bytes in the RTP HE with every RTP packet. This results in an additional 3 bytes of length for the RTP HE. This
extension attribute shall not be included more than once.
- num-pdus-in-pdu-set: if present, this extension attribute indicates that the RTP sender will provide the number of
PDUs in the PDU Set (NPDS) in the RTP HE with every RTP packet. This results in an additional 2 bytes of
length for the RTP HE. This extension attribute shall not be included more than once.
Below is an example:
a=extmap:7 urn:3gpp:pdu-set-marking:rel-18 short pdu-set-size
4.2.6 Guidelines for PDU Set Marking
4.2.6.1 End of Data Burst Field
NOTE: These detailed guidelines are FFS.
4.2.6.2 PDU Set Importance Field
4.2.6.2.1 General
In general, whenever the RAN needs to discard packets (e.g., under congestion situations), it is better to discard packets
of lower importance rather than discarding packets randomly. If a discarded packet is critical for the media stream, the
QoE may be severely degraded. For this reason, the PDU Set Importance (PSI) field can be used to mark PDU Sets with
their importance level. The PSI field can then be used by the RAN to discard PDU sets. In case of congestion, PDU Sets
with higher PSI values are more likely to be discarded.
PDU Sets that contain audio data should be assigned a lower PSI value (i.e., higher importance) compared with PDU
Sets that contain other media types.
NOTE 1: PDU Sets that carry immersive audio data are not necessarily assigned a lower PSI value compared with
the other media PDU Sets. The PSI value of immersive audio PDU Sets is FFS.
PDU Sets that contains the reference frames present in the video bitstream should be assigned a lower PSI value
compared with PDU Sets that contain non-reference frames.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 13 ETSI TS 126 522 V18.2.0 (2025-07)
NOTE 2: It is assumed that the video bitstream uses referencing structures that have no coding delay caused by out-
of-order output, as typically done for low-delay applications.
The following clauses provides the guidelines for the 3GPP video codecs on setting the PSI field in the RTP HE for
PDU Set marking. For specific PSI value ranges, refer to clause 4.2.6.2.5.
4.2.6.2.2 H.264/AVC Codec
In an H.264/AVC bitstream, NAL units with the nal_unit_type field assigned the value 5 (refer to Table 7.1 in the
H.264/AVC specification [2]) are Instantaneous Decoding Refresh (IDR) pictures. When the Type field value in the
NAL Unit header of an RTP packet is 5, then the corresponding PDUs in that PDU Set should be set with higher
importance.
The parameter set NAL units such as Sequence Parameter Set (SPS) and Picture Parameter Set (PPS) are important for
decoding the bitstream. Therefore, PDU sets with a Type field value equal to 7, 8, 13 or 15 (refer to Table 7.1 in the
H.264/AVC specification[2]) in the NAL Unit header of the RTP packet should be assigned a higher importance (lower
PSI value) relative to PDU Sets with other Type field values.
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type  |
+---------------+
Figure 4.2.6-1: Format of the H.264/AVC NAL unit header
The NAL unit type octet contains the NRI (nal_ref_idc) field highlighted in Figure 4.2.6-1. The NRI field indicate the
relative transport priority. A value of b00 indicates that the content of the NAL unit is not used to reconstruct reference
pictures for inter picture prediction. Such NAL units can be discarded by the RAN (in case of congestion) without
risking the integrity of the reference pictures. Values greater than b00 indicate that the decoding of the NAL unit is
required to maintain the integrity of the reference pictures. The highest transport priority is b11, followed by b10, and
then by b01; finally, b00 is the lowest. PDU Sets with an NRI value b00 should be set with lower importance relative to
the PDU Sets with other NRI values. PDU Sets with an NRI value b11 should be set with higher importance relative to
the PDU Sets with other NRI field values.
The Type and NRI fields can be used to set the PSI. The PSI value assignment based on the Type and NRI field
values is for further study.
4.2.6.2.3 H.265/HEVC Codec
Different from H.264/AVC, H.265/HEVC NAL unit header (shown in Figure 4.2.6-2) is two bytes, contains a 6-bit
Type field, a 5-bit LayerID field, a 3-bit TID field, and no NRI field. The Type and TID fields in the NAL unit
header indicate the relative transport priority and can be used to set the PSI.
NAL unit types 0–31 indicate Video Coding Layer (VCL) NAL unit types; 32–40 indicate non-VCL NAL unit types.
NAL unit types 41–47 are reserved, and NAL unit types 48–63 are unspecified.
+---------------+---------------+
|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|  Type  | LayerId | TID |
+-------------+-----------------+
Figure 4.2.6-2: Format of the H.265/HEVC NAL unit header
All VCL NAL units of the same access unit have the same NAL unit type, which defines the type of the access unit and
its coded picture. There are three basic classes of pictures in H.265/HEVC: intra random access point (IRAP) pictures,
leading pictures, and trailing pictures.
In an H.265/HEVC bitstream, NAL units with the nal_unit_type field assigned a value in the range 16 to 23 (inclusive)
(refer to Table 7.1 in the H.265/HEVC specification [3]) are Intra Random Access Pictures (IRAP) pictures. This
includes IDR, CRA, and BLA picture types as well as types 22 and 23, which currently are reserved for future use.
ETSI
3GPP TS 26.522 version 18.2.0 Release 18 14 ETSI TS 126 522 V18.2.0 (2025-07)
When the Type field value in the NAL Unit header of RTP packet is in the range 16 to 23 (inclusive), then the
corresponding PDUs in that PDU Set should be assigned higher importance (i.e., lower PSI value).
The parameter set NAL units such as Sequence Parameter Set (SPS), Picture Parameter Set (PPS), Video Parameter Set
(VPS) are important for decoding the bitstream. Therefore, PDU Sets with payload Type field value in the
...