Content for TS 26.522 Word version: 18.1.0
5 RTCP Feedback Reporting Procedures
5.1 General
5.2 Transmission of timing information data for QoE measurements
5.2.1 General
5.2.2 RTCP message-based transmission of timing information
5.2.2.1 General
5.2.2.2 Extended Report block for QoE timing information
5.2.3 SDP signaling and attributes
...
...
5 RTCP Feedback Reporting Procedures p. 24
5.1 General p. 24
This clause defines the RTCP feedback reporting messages to transmit control information. There are a number of possible ways to carry a variety of control information using RTCP packets. This includes:
- profile-specific extensions to the sender (PT=200) and receiver report (PT=201),
- application-defined RTCP packet with payload type equal to 204 (PT=204),
- Generic RTP Feedback reports with payload type equal to 205 (RTPFB; PT=205), and
- payload-specific RTCP feedback messages with payload type equal to 206 (PSFB; PT= 206),
- extended reports (RTCP XR) with payload type equal to 207 (PT=207).
5.2 Transmission of timing information data for QoE measurements p. 24
5.2.1 General p. 24
In use cases for shared interactive immersive services, the user interaction information is sent from a UE to a server. The server handles the user's request to the immersive media scene (e.g., changing the context such as translation, rotation, and scaling or adding a new object in the scene). In the case of the edge-assisted UE type, the UE offloads the scene rendering.
In the context of interactive immersive services, one important parameter to estimate the user quality of experience is the roundtrip interaction delay. The roundtrip interaction delay is defined as the sum of the age of content and the user interaction delay.
The age of content is defined as the time duration between the moment the content is created and the time it is presented to the user. It is impacted by the downlink latency of the wireless network.
The user interaction delay is defined as 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. It is impacted by the uplink latency of the wireless network.
The estimated-at-time (T1) and start-to-render-at-time (T3) provide the times when the pose was estimated and when the SRS started to render the rendered frame, respectively. The split-renderer-output-time (T5) provides the time when the output of the SRS for a rendered frame is available. This T5 information can be used to measure the server processing delay and the overall application delay excluding the server processing delay. The SRS processes the interaction according to the actions in the action message from the UE and updates the scene. The Scene Manager records the sceneUpdateTime (T6) timestamp when it starts to process the actions. The sceneUpdateTime is used to measure the user interaction delay, age of content and the roundtrip interaction delay. The details of sceneUpdateTime, measurement of User-interaction-delay, Age-of-content and Roundtrip-interaction-delay QoE interaction metrics.
The user interaction delay, age of content, and round-trip interaction delay measurements are described as quality of experience metrics for XR content. These delay measurement metrics need to be calculated at the UE for providing better QoE to the user. Also, the server processing delay measurement helps the UE in the adaptation process with the split rendering server for achieving better QoE.
5.2.2 RTCP message-based transmission of timing information p. 24
5.2.2.1 General p. 24
The timing information data recorded at the SRS or at the RTP sender can be transmitted to the UE by enhancing the RTCP XR packets, which are specified in RFC 3611. The RTCP XR report is identified by payload type (PT) equal to 207, which refers to an extended report block message. For transmission of timing information data using RTCP XR messages, the block type (BT) defined in RFC 3611 can be extended with a value TBD.
5.2.2.2 Extended Report block for QoE timing information p. 25
This extended report block type permits detailed reporting of timing information recorded at the SRS. These reports can be used, for example, for calculating the QoE metrics such as round-trip delay, server processing delay, user interaction delay, age of content and the round-trip interaction delay at the UE.
The timing information required for measuring QoE metrics may be expressed in the same units as in the RTP timestamps of RTP data packets. This is so that, for each packet, one can establish the relation between the media data flowing and the corresponding QoE timing information recorded at the SRS for a specific media frame.
For optimum use of the RTCP bandwidth, the RTCP XR block payload may contain the whole or part of the timing information required to calculate the QoE metrics. t_info field present in Figure 5.2.2.2-1 represents the timing information present in an RTCP XR block report. When a bit is set to 'ONE' in t_info field the respective timing information shall be present in the payload. When a bit is set to 'ZERO' in t_info field, the respective time information shall not be present in the payload. E.g., when the sender like to transmit only T1 and T3 information, the t_info field is set to b0011 and only T1 and T3 information is present in the message payload.
The identifiers of all actions that were processed for the rendering of a frame at a specific time are reported in the RTP HE for XR pose defined in clause 4.3. The synchronization between the various timing information present in the below XR report and the action identifiers present in the RTP HE for XR pose is performed using the RTP timestamp information present in the RTP header of the packet containing the RTP HE for XR pose and the RTP timestamp field present in the below RTCP XR report block.
The QoE timing information Report Block has the following format:
The semantics of the fields in QoE time information Extended Report (RTCP XR) block are as follows:
- block type (BT) [8 bits]: A QoE time information Report Block is identified by a constant value.
- block length [16 bits]: The length of this report block, including the header, in 32-bit words minus one.
- resv [4 bits]: This field is reserved for future definition. In the absence of such definition, the bits in this field shall be set to zero by the sender and shall be ignored by the receiver.
- t_info [4 bits]: This field bits represent the timestamps that are present in the RTCP XR report block. When T1 is present in the RTCP XR report, first bit (least significant bit) is set to 1. When the LSB is set to 0, T1 information shall not be present. When T3, T5 and T6 are present in the RTCP XR block data, bits 2, 3 and 4 are set to 1 respectively. When T1, T3, T5 and T6 are present in an RTCP XR block data, the t_info field value shall be b1111. The timing information when present shall follow the order T1, T3, T5 followed by T6. For example, when the t_info field value is b0101, the RTCP XR block carries the T1 information followed by T5. T3 and T6 timing information will not be present in that RTCP XR block content. The transmission frequency of T1, T3, T5 and T6 time information in RTCP XR report block can be negotiated during the configuration phase.
- SSRC of source [32 bits]: The SSRC of the RTP data packet source being reported upon by this report block.
- RTP timestamp [32 bits]: This field represents the RTP timestamp of the media frame at which the corresponding QoE timing information date was recorded at the SRS. This correspondence may be used for synchronization between the media data and the QoE timing information measurements recorded at the SRS for a specific media frame.
- estimated-at-time (T1) [32 bits]: This field represents the time when the pose estimation was made. This time information is expressed in the same units and with the same random offset as the RTP timestamps in data packets.
- start-to-render-at-time (T3) [32 bits]: This field represents the time when the renderer in the split rendering server started to render the associated media frame. This time information is expressed in the same units and with the same random offset as the RTP timestamps in data packets.
- server-output-time (T5) [32 bits]: This field represents the recorded time at the output of the split rendering server. This time information is expressed in the same units and with the same random offset as the RTP timestamps in data packets.
- scene-update-time (T6) [32 bits]: This field represents the time when the Scene manager processes the interaction task according to the actions in the action message from the UE and updates the scene. This time information is expressed in the same units and with the same random offset as the RTP timestamps in data packets.
5.2.3 SDP signaling and attributes p. 26
RFC 3611 defines the SDP attribute "rtcp-xr" that can be used to signal to participants in a media session that they should use the specified RTCP XR blocks. This attribute is extendable with new parameters to cover any new type of XR report blocks.
The extended RTCP XR blocks with QoE time information SDP attribute extends the "a=rtcp-xr" attribute definition in RFC 3611 as described below in Augmented Backus-Naur Form (ABNF).
The new parameter name and its corresponding RTCP XR format is:
The "qoe-timing-info", parameter may specify an integer value. This value indicates the largest size the whole report block should have in octets.
Parameter name XR block (block type and name) -------------- ------------------------------------ qoe-timing-info TBD Timing Information for QoE Metrics Calculation Block
