RTP Control Protocol (RTCP)
Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program
Specific Information (PSI) Decodability Statistics Metrics
ReportingShanghai Research Institute of
China Telecom Corporation LimitedNo. 1835, South Pudong RoadShanghai200122Chinatongjg@sttri.com.cnShanghai Research Institure of
China Telecom Corporation LimitedNo. 1835, South Pudong RoadShanghai200122Chinabijy@sttri.com.cnHuawei14 David HamelechTel Aviv64953Israelroni.even@mail01.huawei.comHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinabill.wu@huawei.comHuawei101 Software Avenue, Yuhua DistrictNanjingJiangsu210012Chinarachel.huang@huawei.comTR 101 290An MPEG2 Transport Stream (TS) is a standard container format used in
the transmission and storage of multimedia data. Unicast/multicast MPEG2
TS over RTP is widely deployed in IPTV systems. This document defines an
RTP Control Protocol (RTCP) Extended Report (XR) block that allows the
reporting of MPEG2 TS decodability statistics metrics related to
transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR
block are related to Program Specific Information (PSI) carried in MPEG
TS.The European Telecommunications Standards Institute (ETSI) has
defined a set of syntax and information consistency tests and
corresponding indicators that are recommended
for the monitoring of MPEG2 Transport Streams . The tests and corresponding
indicators are grouped according to priority:
Necessary for decodability (basic
monitoring)Recommended for continuous or periodic
monitoringRecommended for application-dependent
monitoringThis memo defines a new block type for use with MPEG2 Transport
Streams to augment those
defined in . The new block type supports
reporting of the number of occurrences of each Program Specific
Information (PSI) indicator in the first and second priorities listed
in Sections 5.2.1 and 5.2.2, respectively, of
. The third
priority indicators are not supported. The metrics defined here
supplement information from the PSI-Independent Decodability
Statistics Metrics Block .The use of RTCP for reporting is defined in . defines an extensible
structure for reporting using an RTCP Extended Report (XR). This
document defines a new Extended Report block for use with and .The Performance Metrics Framework provides guidance on
the definition and specification of performance metrics. The RTP
Monitoring Architectures provides guidelines
for RTCP XR block formats. The new report block described in
this memo is in compliance with the monitoring architecture specified
in and the Performance Metrics Framework
.These metrics are applicable to any type of RTP application that
uses the MPEG2 TS standard format for multimedia data, for example,
MPEG4 over MPEG2 TS over RTP. This new block type can be useful for
measuring content stream or TS quality by checking TS header
information and identifying the existence (and
characterizing the severity) of bitstream packetization problems that
may affect users' perception of a service delivered over RTP. It may
also be useful for verifying the continued correct operation of an
existing system management tool.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.ETSI TR 101 290 generally defines indicators
related to error events whereas the XR block defined in this document
contains counts of occurrences of the indicators.
The block defined in this document reports MPEG2 TS PSI decodability
statistics metrics beyond the information carried in the standard RTCP
packet format and PSI-Independent Decodability Statistics Metrics Block ,
which are measured at the receiving end of the RTP stream. It contains
counts of seven metrics defined in ETSI TR 101 290 .
Information is reported about basic monitoring parameters necessary to
ensure that the TS can be decoded, including:
Program Association Table (PAT) errorsPAT2 errorsProgram Map Table (PMT) errorsPMT2 errorsPacket Identifier (PID) errorsInformation is also reported about continuous monitoring parameters necessary to ensure
continuous decoding, including:
Cyclic Redundancy Check (CRC) errorsConditional Access Table (CAT) errorsIn these parameters, PAT2 errors and PMT2 errors are actually
replacements for and improvements on PAT errors and PMT errors,
respectively, and are therefore preferred in future implementations. In
addition, measurement results for some of these parameters (e.g., PAT
errors or PMT errors) may be different based on whether scrambling is
employed. The other parameters defined in Section 5 of are ignored
since they do not apply to all MPEG2 implementations. For further
detailed information on these parameters, see .The MPEG2 TS PSI Decodability Metrics Block has
the following format:
The MPEG2 TS PSI Decodability Metrics Block is identified by the
constant 32;.
These bits are reserved. They MUST be set to zero by senders ignored by
receivers (see Section 4.2 of ).
The constant 6, in accordance with the definition of this field in
Section 3 of . The block MUST be discarded if the block
length is set to a different value.
As defined in Section 4.1 of .As defined
in Section 4.1 of .As defined in
Section 4.1 of .A
count of the number of PAT errors that occurred in the above
sequence number interval. The Program Association Table (PAT) is the
only packet with Packet Identifier (PID) 0x0000. A PAT error occurs when
(1) a packet with PID 0x0000 does not occur at least every 0.5
seconds, (2) a packet with PID 0x0000 does not contain table_id
0x00 (i.e., a PAT), or (3) the Scrambling_control_field in the TS packet
header is not 00 for a packet with PID 0x0000. See Section 5.2.1 of
. Every program within the MPEG TS stream is listed in the
PAT; if it is missing, then no programs can be decoded.
The measured value is an unsigned value. If the
measurement is unavailable, then the value 0xFFFF MUST be reported. NOTE 1 of the table in Section 5.2.1 of recommends using
PAT_error_2_count.
Upon
reception, if PAT_error_2_count is available (that is, other than
0xFFFF), then receivers MUST ignore PAT_error_count.A
count of the number of PAT2 errors that occurred in the above
sequence number interval. A PAT2 error occurs when (1) a packet
with PID 0x0000 containing table_id 0x00 does not occur at least
every 0.5 seconds, (2) a packet with PID 0x0000 contains a table
with a table_id other than 0x00, or (3) the Scrambling_control_field in
the TS packet header is not 00 for a packet with PID 0x0000. See
Section 5.2.1 of . The measured value
is an unsigned value. If the measurement is unavailable, then the value
0xFFFF MUST be reported.A
count of the number of PMT errors that occurred in the above
sequence number interval. A PMT_error occurs when (1) a packet
containing a table with table_id 0x02 (i.e., a PMT) does not occur at
least every 0.5 seconds on the PID that is referred to in the PAT or
(2) the
Scrambling_control_field in the TS packet header is not 00 for all
packets with PID containing a table with table_id 0x02 (i.e., a PMT).
See Section 5.2.1 of .
The measured value is an unsigned value. If the measurement is unavailable,
the value 0xFFFF MUST be reported. NOTE 2 of the table in Section 5.2.1 of recommends using
PMT_error_2_count.
Upon reception, if PMT_error_2_count is available
(that is, other than 0xFFFF), then receivers MUST ignore
PMT_error_count.A
count of the number of PMT2 errors that occurred in the above
sequence number interval. A PMT2_error occurs when (1) a packet
containing table_id 0x02 (i.e., a PMT) does not occur at least every
0.5 seconds on each program_map_PID that is referred to in the PAT
or (2) the
Scrambling_control_field in the TS packet header is not 00 for all
packets containing a table with table_id 0x02 (i.e., a PMT) on each
program_map_PID that is referred to in the PAT. See Section 5.2.1
of .
The measured value is an unsigned
value. If the measurement is unavailable, then the value 0xFFFF MUST be
reported.A
count of the number of PID errors that occurred in the above
sequence number interval. A PID error occurs when no data stream is
present corresponding to a given PID. This may be caused by
multiplexing or demultiplexing, then remultiplexing. See Section
5.2.1 of .
The measured value is an
unsigned value. If the measurement is unavailable, then the value 0xFFFF
MUST be reported.A
count of the number of CRC errors that occurred in the above
sequence number interval. A CRC_error occurs if data corruption
occurred in any of the following tables -- CAT, PAT, PMT, Network
Information Table (NIT), Event Information Table (EIT), Bouquet
Association Table (BAT), Service Description Table (SDT), or Time
Offset Table (TOT), as defined in Section 5.2.2 of .
The measured value is an unsigned value. If the
measurement is unavailable, then the value 0xFFFF MUST be reported.A
count of the number of CAT errors that occurred in the above
sequence number interval. A CAT_error occurs when (1) a packet with
PID 0x0001 contains a table with a table_id other than 0x01 (i.e., not a
CAT) or (2) a packet does not contain a table with table_id = 0x01
(i.e., a CAT) when scrambling is employed (i.e., the Scrambling_control_field is set as a value other than 00). See Section 5.2.2 of
. The measured value is
an unsigned
value. If the measurement is unavailable, then the value 0xFFFF MUST be
reported.These bits
are reserved. They MUST be set to zero by senders ignored by
receivers (see Section 4.2 of ). defines the use of the Session Description Protocol (SDP) for signaling the use of RTCP XR blocks. However, XR
blocks MAY be used without prior signaling (see Section 5 of
).This session augments the SDP attribute "rtcp-xr" defined in
Section 5.1 of by providing an additional value of
"xr-format" to signal the use of the report block defined in this
document. The ABNF syntax is as follows:When SDP is used in Offer/Answer context, the SDP Offer/Answer
usage defined in for unilateral "rtcp-xr"
attribute parameters applies. For detailed usage of Offer/Answer for
unilateral parameters, refer to Section 5.2 of .For usage outside of Offer/Answer, refer to Section 5.3 of .New report block types for RTCP XR are subject to IANA registration.
For general guidelines on IANA allocations for RTCP XR, refer to Section
6.2 of .This document assigns the block type value 32 "MPEG2 Transport Stream PSI Decodability Statistics Metrics
Block" in the "RTCP XR Block Type" subregistry of the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry".This document also registers a new parameter "ts-psi-decodability"
in the "RTCP XR SDP Parameters" subregistry of the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry".The contact information for the registrations is:This proposed RTCP XR block introduces no new security
considerations beyond those described in and
.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]RTP: A Transport Protocol for Real-Time ApplicationsColumbia UniversityRTP Control Protocol Extended Reports (RTCP XR)Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.eduSDP: Session Description ProtocolDigital Video Broadcasting (DVB); Measurement guidelines for
DVB systemsETSIDesign Considerations for Protocol ExtensionsGuidelines for Use of the RTP Monitoring FrameworkGuidelines for Considering New Performance Metric
DevelopmentTelchemy IncorporatedDe Kleetlaan 6a b1Diegem1831Belgium+32 2 704 5622bclaise@cisco.comRTP Control Protocol (RTCP) Extended Report (XR) Block for
MPEG2 Transport Stream (TS) Program Specific Information (PSI)
Independent Decodability Statistics Metrics reportingInformation technology - Generic coding of moving pictures
and associated audio information - Part 1: SystemsISO/IEC