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…

 

A  Guidelines for PDU Set identificationp. 27

A.0  Generalp. 27

This informative Annex provides guidelines for network functions like the UPF, which needs to determine PDU Set information, as described in clause 5.37.5 of TS 23.501. The network function is typically provisioned with at least the Service Data Flow Filter to identify the Service Data Flow, and optionally additional information about the presence of RTP HEs according to RFC 8285, the used RTP Payload Type, the used RTP Payload Format and other information.
When the RTP sender multiplexes RTP data and control packets onto the same Service Data Flow using a single port, the RTP Sender should implement the Payload Type separation according to Section 4 of RFC 5761 and the network function should separate RTP data from RTCP data accordingly.
To avoid IP fragmentation, the RTP sender should select a sufficiently small RTP payload.
Up

A.1  Leveraging RTP Header Extensionsp. 27

When the PDU Set related RTP HEs are available within the RTP headers, the network function only needs parse the RTP header and the RTP HEs. The RTP HE for PDU Set Marking is defined in clause 4.2.
An intermediate network function determines based on the RTP header X bit being set to 1, whether the optional HE fields are present in the RTP packet, after the SSRC and the (optional) CSRC fields in the RTP header. All information for the PDU Set identification is present within the RTP HE and the network function does not need to know the RTP Payload format. The RTP Payload may be encrypted (i.e. SRTP).
When multiple RTP HEs are present within the RTP header, the network function uses the RTP HE ID for finding the PDU Set related HE.
Up

A.2  Obtaining PDU Set information from RTP Payloadp. 27

A.2.0  Generalp. 27

When the RTP HE for PDU Set marking is not available, some or all of PDU Set information can be derived from the RTP/SRTP header, HE and/or payloads, e.g., by a network function like the UPF. The possible PDU Set information to be derived based on the RTP/SRTP header, HE and the payloads are provided as following.

A.2.1  RTP/SRTP headerp. 27

When RFC 6184 or RFC 7798 are used as payload formats, a network function can obtain some of the PDU Set information from RTP headers by following these guidelines.
Reproduction of 3GPP TS 26.522, Fig. A.2.1-1: RTP header fields as defined in RFC 3550
Up
When the RTP/SRTP is used to convey the video content and when the PDU Set represents a video frame, the video frame may be identified based on the RTP header fields as following:
  • The "marker (M)" bit is used with the video payload formats in clause A.2 to indicate the frame boundary, by setting the M bit on the last PDU of a frame. With the "M" bit and the sequence number in RTP header, the Indication of End PDU of a PDU Set and PDU SN within a PDU Set/frame can be derived. The network function should monitor the preceding packets to detect and compensate for potential packet reordering.
  • The "timestamp" field indicates the sampling instant of the first octet in the RTP data packet and all RTP packets in the video frame is generally marked with the same timestamp. Therefore, with the "timestamp" field and the sequence number in RTP header, the Indication of End PDU of a PDU Set and PDU SN within a PDU Set/frame can be derived.
  • PDU Set Size can only be determined by a network function with reception of the last PDU belonging to the PDU Set, by summing up the individual PDU contributions to the PDU Set Size. PDU Set Importance cannot be derived using the RTP header fields.
Up

A.2.2  RTP payloadp. 28

A.2.2.1  Generalp. 28

When the RTP Payload is not encrypted, intermediate network functions may obtain additional information from the RTP payload.
The PDU Set information identification based on the RTP payload format is presented in this clause, including information on the RTP payload formats for H.264/AVC [5] and H.265/HEVC [6] codecs. The information about the used RTP Payload format for a service data flow is provided in advance to 5GC (e.g., UPF).
It is generally recommended that the network function considers non-VCL NAL units as part of the PDU Set of the associated VCL NALUs, e.g. identified by the same timestamp.
Up

A.2.2.2  RTP payload for H.264/AVC codecp. 28

For a video content with H.264/AVC RTP payload, the PDU Set Information can be obtained by the following approach.
According to RFC 6184, the first octet in the RTP payload indicates the content of the RTP payload, e.g. coded slice of an IDR frame, coded slice of a P frame, and also the possible structures of the RTP payload, e.g. single NAL unit packet, AP and fragmentation unit (FU). Depending on the indication of the first octet of the RTP payload, a second octet (the FU header) should also be processed.
  • For single NAL unit packets and APs, it can be easily detected that each RTP packet can be treated as a complete PDU Set when the first Type field of Figure A.2.2-1 is less than 28.
  • In case of APs, the network function may need to process all embedded NAL units.
  • When the first Type field in Figure A.2.2-1 is 28 or 29, one NAL unit is carried over multiple RTP packets. In this case, the first byte of RTP payload is also named the FU indicator and the following byte is the FU header. The NAL unit type is contained in the Type field of the FU header (Figure A.2.2-1). In the FU header, the "S" bit and "E" bit separately represents the start and end of the NAL unit. Therefore, based on the NAL unit type (also known as FU indicator for FU) and the FU header, the start/end of the PDU Set can be identified.
Reproduction of 3GPP TS 26.522, Fig. A.2.2-1: RTP header [4] and NALU header format for H.264 [2]
Up
With the RTP payload (i.e. NALU header and optionally FU header) and the sequence number in the RTP header, the indication of the End PDU of the PDU Set and the PDU SN within a PDU Set can be derived.
When using FUs (Type equals 28 or 29), the size of the NALU can only be determined after reception of the last packet of this FU. Thus, a network function can only determine the PDU Set Size with the reception of the last PDU of this FU.
As described in clause 4.2.6.2.2, the Type and NRI value in the NAL unit header indicates the relative transport priority and can be used to set the PSI. Besides, different NRI values can also indicate different requirements, which can be used to provide different protections against transmission losses, e.g. reliabilities (tolerable frame/slice error rate), and priorities.
Up

A.2.2.3  RTP payload for H.265/HEVC codecp. 29

For a video content with H.265/HEVC RTP payload, the identification of the PDU Set can be realized by following approach.
According to RFC 7798, within the RTP packet, the first two octets of the RTP payload indicate the content of RTP packet. Besides, it also indicates the possible structures of the RTP payload, e.g. single NAL unit packet, APs, FUs, and Payload Content Information (PACI) carrying RTP packet.
  • For single NAL unit packets and APs, it can be easily detected that each RTP packet can be treated as a single PDU Set when the NAL unit type is less than 49.
  • When NAL unit type is 49, one NAL unit is carried over multiple RTP packets. In this case, the first two-byte of RTP payload is also named the payload header (denoted as NAL unit, NALU, header) and the following byte is the FU header. In the FU header, the "S" bit and "E" bit separately represents the start and end of the NAL unit. The FuType field contains the actual NAL unit type. Therefore, based on the Type field of the first two octets (also known as FU indicator for FU) and the FU header, the start/end of the PDU Set can be identified.
  • When NAL unit type is 50, this is a PACI packet which may carry a single NAL unit packet or FU. In this case, the first two-byte of RTP payload is also named as the PACI header (denoted as NAL unit header). In the following two bytes, the "A" bit is the copy of "F" bit and cType field is the copy of Type field in the PACI payload NAL unit. Then the following is the PHES field, whose length is determined by the PHSize. Finally, the following is the PACI payload NAL unit, during which the first byte is FU header when cType (within the PACI payload header) is 49. Therefore, based on the PACI header and PACI payload NAL unit, the start/end of the PDU Set can be identified.
Reproduction of 3GPP TS 26.522, Fig. A.2.3-1: The Structure of the HEVC NAL Unit Header [6]
Up
Reproduction of 3GPP TS 26.522, Fig. A.2.3-2: The Structure of FU Header
Up
With the RTP payload (i.e. NAL unit header and optionally FU header) and the sequence number in the RTP header, the indication of the End PDU of the PDU Set and the PDU SN within a PDU Set can be derived.
As described in clause 4.2.6.2.3, the Type field and the TID field in the NAL unit header indicates the relative transport priority and can be used to be mapped to the PSI. They can also indicate different requirements, which can be used to provide different protections against transmission losses, e.g. reliabilities (tolerable frame/slice error rate), and priorities.
When using FUs (Type equals 49, or 50 where cType is 49), the size of the NAL unit can only be determined after reception of the last packet of this FU. Thus, a network function can only determine the PDU Set Size with the reception of the last PDU of this FU.
Up

Up   Top   ToC