Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 26.522  Word version:  18.1.0

Top   Top   Up   Prev   Next
0…   4…   4.3…   5…   A…   B…

 

4  RTP Functionalitiesp. 9

4.1  Generalp. 9

This clause defines functional additions to RTP (RFC 3550) for potential use in 5G Systems. The RTP protocol is designed to be generic and extensible, e.g., by using RTP Header Extensions (HE) RFC 8285 and by defining RTP payload formats for specific media codecs, e.g. RFC 6184, RFC 7798.
Up

4.2  RTP Header Extension for PDU Set Markingp. 10

4.2.1  Generalp. 10

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.
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.
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.
The IANA registration information for the RTP HE for PDU Set marking is provided in Annex D.2.
Up

4.2.2  One-byte RTP Header Extension Formatp. 10

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
      +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+
                      |
      +.+.+.+.+.+.+.+.+
Up

4.2.3  Two-byte RTP Header Extension Formatp. 10

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              |
      +.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+.+
Up

4.2.4  Semanticsp. 10

The semantics of the fields of the RTP HE for PDU Set marking are defined as follows:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
Up

4.2.5  SDP Signalingp. 11

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 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 RFC 8285. 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:
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.
  • 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
Up

4.2.6  Guidelines for PDU Set Markingp. 12

4.2.6.1  End of Data Burst Fieldp. 12

4.2.6.2  PDU Set Importance Fieldp. 12

4.2.6.2.1  Generalp. 12
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.
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.
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.
Up
4.2.6.2.2  H.264/AVC Codecp. 13
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.
Reproduction of 3GPP TS 26.522, Fig. 4.2.6-1: Format of the H.264/AVC NAL unit header
Up
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.
Up
4.2.6.2.3  H.265/HEVC Codecp. 13
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.
Reproduction of 3GPP TS 26.522, Fig. 4.2.6-2: Format of the H.265/HEVC NAL unit header
Up
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. 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 NAL Unit header of RTP packet in the range 32 to 34 (inclusive) should be assigned higher importance (lower PSI value).
RFC 7798 specifies Aggregation Packets (APs) to enable the reduction of packetization overhead for small NAL units, such as most of the non-VCL NAL units, which are often only a few octets in size. An AP aggregates NAL units within one access unit. Each NAL unit to be carried in an AP is encapsulated in an aggregation unit. An AP consists of a payload header (denoted as PayloadHdr) followed by two or more aggregation units. In an AP, the Type field in the PayloadHdr is equal to 48. APs are typically used to aggregate parameters sets (VPS, SPS, PPS) into a single packet. When APs are used, the sender should consider the NAL unit types of the aggregation units while assigning the PSI value. For example, if the aggregation unit contains parameter sets, PDU Sets containing those should be assigned higher importance (lower PSI value).
It could be that there are PDUs with different NAL unit types in a PDU Set. For example, if the first PDU in PDU Set is a prefix SEI message or Access Unit Delimiter (AUD), it would be misleading if the sender looked only at the first PDU of the PDU Set to determine the PSI value. The sender should ignore the NAL units with non-VCL NAL unit types 35 and 39 and instead consider NAL unit types of the subsequent VCL NAL units while determining the PSI value for such PDU Sets.
A leading picture is a picture that follows a particular IRAP picture in decoding order and precedes it in output order. There are two types of leading pictures in H.265/HEVC: Random access decodable leading (RADL) pictures and Random access skipped leading (RASL) pictures. A RADL picture is a leading picture that is guaranteed to be decodable when random access is performed at the associated IRAP picture. Therefore, RADL pictures are only allowed to reference the associated IRAP picture and other RADL pictures of the same IRAP picture. A RASL picture is a leading picture that may not be decodable when random access is performed from the associated IRAP picture. Only other RASL pictures are allowed to be dependent on a RASL picture. Hence, in H.265/HEVC bitstreams, RASL pictures can be discarded during random access. H.265/HEVC provides mechanisms to enable specifying the conformance of a bitstream wherein the originally present RASL pictures have been discarded. Consequently, system components can discard RASL pictures, when needed, without worrying about causing the bitstream to become non-compliant.
PDU Sets with Type field value equal to 6 or 7 (refer to Table 7.1 in H.265/HEVC specification [3]) in the NAL Unit header of RTP packet are RADL pictures. PDU Sets with Type field value equal to 8 or 9 (refer to Table 7.1 in H.265/HEVC specification [3]) in the NAL Unit header of RTP packet are RASL pictures. PDU Sets that contain RADL pictures should be assigned lower importance (higher PSI value) relative to the IRAP pictures and higher importance (lower PSI value) relative to the RASL pictures in the bitstream.
In video coding, temporal scalability is the option to decode only some of the frames in a video stream instead of the whole stream. This enables a media server to reduce the bitrate sent towards viewers that don't have enough bitrate or CPU to handle the whole stream. In H.265/HEVC, pictures with lowest temporal identifier value (TID) are used as reference pictures in the bitstream and are important for decoding the dependent frames. PDU Sets with TID value 1 (lowest possible value) should be set with higher importance (lower PSI value) relative to PDU Sets that have a higher TID value. The PSI value for such pictures should be lower for IRAP pictures and slightly higher for non-IRAP pictures compared to the pictures with higher TID values. Pictures with highest TID value cannot be used as reference pictures and can be discarded at the network level when the throughput is not good, or network conditions are unstable. PDU Sets with higher TID values should be set with lower importance (higher PSI value) compared with the PDU Sets with lower TID values.
In H.265/HEVC, each leading picture and trailing picture type has two type values. The even picture type numbers indicate sub-layer non-reference pictures and odd picture type numbers indicate sub-layer reference pictures. An encoder can use the sub-layer non-reference picture types for pictures that are not used for reference for prediction of any picture in the same temporal sub-layer. Note that a sub-layer non-reference picture may still be used as a reference picture for prediction of a picture in a higher temporal sub-layer.
PDU Sets that contain sub-layer reference picture types should be assigned a lower PSI value compared with the PDU sets with the corresponding sub-layer non-reference picture types.
Up
4.2.6.2.4  PSI based on affected PDU Setsp. 15
When the transport layer is forced to perform immediate dropping/discarding of a PDU Set but has a freedom of selection among the PDU Sets, the PDU Set with smaller degrees of artifact would be the better choice in most cases. Dropping of a PDU Set may corrupt the decoded output of itself and the other PDU Sets though they may already be transmitted perfectly to the receiving end or yet in a queue waiting to be transmitted. The degrees of artifact can be explicitly transferred as the number of affected frames which precedes/follows the PDU Set, or can be implicitly transferred as the importance value where the lower value means the higher PDU Sets are affected while higher values proportionally mean less number of PDU Sets are affected, for example. By considering such a quantization of various affected PDU Sets can be translated into importance field, using 4 bits to represent 16 possible size ranges is recommended.
The information on the size of propagation error which caused by the dropping of each PDU Set may be provided by the application layer. The information may present the size of error propagation implicitly with a proportional mapping of error propagation size to an index such as the importance of the PDU Set in the media stream.
The importance value of a PDU Set in PDU Set Information (PSI) RTP HE is set as follows:
  • The error propagation size is mapped to importance field value. The higher the error propagation size of a PDU Set, that PDU Set is more important, and it shall be assigned the lower PSI value. PDU Sets with low error propagation are of less importance and the PSI value for such PDU Sets shall be higher compared to PDU sets with higher error propagation size.
Up
4.2.6.2.5  PSI mapping based on PDU Set dependenciesp. 15
RTP senders should consider that multiplexed RTP streams are treated as a single Multimedia Session and set the PSI field accordingly, i.e., the PSI field for one bitstream that depends on other RTP stream(s) in the same Multimedia Session may need to be set taking the PSI field for PDU Sets in other multiplexed RTP streams into account. In some cases, dependencies can exist across bitstreams even when they are not multiplexed, particularly for XR services.
In case of such dependencies, it may not be sufficient to set the PSI values based on codecs and media types alone. PSI values shall be set in this case based on the following, which are listed in an increasing order of importance, i.e., decreasing order of PSI values.
  • The PDU Set is considered not necessary for the processing of any other PDU Set. Such PDU Sets should be assigned the highest PSI values 14-15. When multiplexing, if a PDU Set is assigned PSI value of 15, similar PDU Sets of all streams should be assigned the PSI value 15 to prevent unfair treatment. If interdependency is known, e.g., in stereo streams (left eye is more important than right eye), then the more important stream can be assigned the PSI value 14.
    • In H.264/AVC, these include the PDU Sets with an NRI value equal to b00 in the NAL unit header.
    • In H.265/HEVC, the NAL unit header does not contain a field like NRI that indicates the relative transport priority. Hence, it is up to the application to identify such PDU Sets.
  • The PDU Set is necessary for the processing of some PDU Sets of the stream to which it belongs. Such PDU Sets should be assigned a PSI value in the range 9-13 (inclusive). The lower end of the range should be used for IDR/IRAP pictures since they are more important for decoding of the bitstream.
    • In H.264/AVC, these include:
      • IDR pictures with nal_unit_type equal to 5
      • Non-IDR pictures with nal_unit_type in the range 1 to 4 (inclusive)
    • In H.265/HEVC, these include:
      • IRAP pictures with nal_unit_type field assigned a value in the range 16 to 23 (inclusive)
      • RADL or RASL pictures with nal_unit_type in the range 6 to 9 (inclusive)
  • The PDU Set is necessary for the processing of all the other PDU Sets of the stream to which it belongs. Such PDU Sets should be assigned a PSI value in the range 6-8 (inclusive).
    • In H.264/AVC, these include:
      • SPS, PPS, i.e., NAL units with the nal_unit_type field equal to 7, 8, 13 or 15
    • In H.265/HEVC, these include:
      • SPS, PPS, VPS, i.e., NAL units with the nal_unit_type field in the range 32 to 34 (inclusive)
  • The PDU Set is necessary for the processing of some PDU Sets of the stream to which it belongs and also necessary for the processing of some PDU Sets of some other streams to which it does not belong. Such PDU Sets should be assigned a PSI value in the range 4-5 (inclusive).
  • The PDU Set is necessary for the processing of all PDU Sets of the stream to which it belongs and also of some other streams to which it does not belong. Such PDU Sets should be assigned a PSI value in the range 2-3 (inclusive).
  • The PDU Set is necessary for the processing of all PDU Sets of all streams. Such PDU Sets should be assigned the lowest PSI value 1.
Up

4.2.6.3  PDU Set Size Fieldp. 16

The PDU Set Size field may be present in the RTP HE for PDU Set marking if appropriately enabled for an RTP sender as per clause 4.2.5. In case the PDU Set Size is enabled the application shall express the PDU Set Size in bytes as per the PSSize semantics defined in clause 4.2.4.
The PDU Set Size value of a PDU Set should be determined by the RTP sender based on the RTP payload corresponding to the PDU Set, transmission path MTU Size, or alternatively, maximum RTP SDU size, and network IP transport configuration.
The RTP sender should follow the corresponding steps in determining the PDU Set Size.
  1. The RTP sender should receive from a media encoder (e.g., a H.264/AVC encoder, a H.265/HEVC encoder) payload data corresponding to a PDU Set. It is recommended that all Non-VCL NAL units (e.g. SPS NAL unit) are handled together with the associated VCL NAL units within the same PDU Set. The size of the received payload data (R) should be determined in bytes.
  2. The RTP sender should perform next RTP fragmentation and packetization of the payload data (R). The maximum size of an RTP packet SDU (S) should be determined given a transmission path MTU size, or alternatively, a preconfigured maximum RTP SDU payload size less than the path MTU size. The RTP sender should determine the number of RTP packets (P) post-fragmentation given S and a packetization configuration of the RTP payloader. The RTP payloader should implement the payload formatting according to the corresponding payload type of the PDU Set (e.g., RFC 6184 for H.264/AVC, RFC 7798 for H.265/HEVC) and the packetization configuration to yield the P RTP packets' SDUs. P corresponds to the number of PDUs of the PDU Set.
  3. The RTP sender should determine for each one of the P RTP packets the size of the RTP header overhead including any RTP HE overhead (Rh_p) as configured based on the SDP offer-answer negotiation.
  4. The RTP sender should further determine per RTP packet the size of the UDP/IP headers overhead associated with an OS UDP socket sending out the RTP packets. This may be done by the RTP sender using UDP socket options available programmatically over OS network stack API calls or based on SDP-configured IP endpoints and corresponding transmission IP addresses. The RTP sender should determine the type of the underlying IP version used for transport, i.e., IPv4 or IPv6, and determine accordingly the IP header overhead (Ih_p) for each encapsulated RTP packet. If IPv4 options are configured for the UDP socket, or alternatively, if IPv6 header extensions are sent over the UDP socket, the RTP sender should consider the additional incurred size these have to the IP header overhead (Ih_p) of each RTP packet. The RTP sender should consider a fixed size UDP header overhead (Uh) of 8 bytes for each RTP packet.
  5. The RTP sender should determine the PDU Set Size as the sum in bytes of all RTP/UDP/IP headers overhead of each one of the P packets and the received RTP payload corresponding to the PDUs of the PDU Set, e.g., . The value should be indicated in the PSSize field of the RTP HE for PDU Set marking for all PDUs of the PDU Set before the corresponding RTP PDUs are sent over the UDP socket.
In case any of the above steps fails to determine for a PDU Set any of the Ih_p, Uh_p, Rh_p, P, or R, the RTP sender should set the PSSize to 0 for the PDU Set.
Up

4.2.7  Guidelines for ASp. 17

This clause describes guidelines for an AS that is on the media path between two or more UEs, e.g., an MRF, MCU etc. Such an AS may receive media over RTP with RTP HE for PDU Set marking added by the sender UE.

Up   Top   ToC