ETSI TS V1.3.1 ( ) Technical Specification

Transcription

1 TS V1.3.1 ( ) Technical Specification Digital Video Broadcasting (DVB); Guidelines for the implementation of DVB-IPTV Phase 1 specifications; Part 3: Error Recovery; Sub-part 3: Retransmission (RET)

2 2 TS V1.3.1 ( ) Reference RTS/JTC-DVB Keywords broadcasting, digital, DVB, IP, TV, video 650 Route des Lucioles F Sophia Antipolis Cedex - FRANCE Tel.: Fax: Siret N NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloaded from: The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on printers of the PDF version kept on a specific network drive within Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other documents is available at If you find errors in the present document, please send your comment to one of the following services: Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute European Broadcasting Union All rights reserved. DECT TM, PLUGTESTS TM, UMTS TM, TIPHON TM, the TIPHON logo and the logo are Trade Marks of registered for the benefit of its Members. 3GPP TM is a Trade Mark of registered for the benefit of its Members and of the 3GPP Organizational Partners. LTE is a Trade Mark of currently being registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association.

3 3 TS V1.3.1 ( ) Contents Intellectual Property Rights... 4 Foreword Scope References Normative references Informative references Abbreviations Example of messaging flow involved in DVB RET retransmission for LMB services HNED RET parameter configuration via SDP SDP example for RET-enabled CoD SDP example for RET-enabled LMB History... 13

4 4 TS V1.3.1 ( ) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to. The information pertaining to these essential IPRs, if any, is publicly available for members and non-members, and can be found in SR : "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to in respect of standards", which is available from the Secretariat. Latest updates are available on the Web server ( Pursuant to the IPR Policy, no investigation, including IPR searches, has been carried out by. No guarantee can be given as to the existence of other IPRs not referenced in SR (or the updates on the Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (). Please note that the present document is a revision to TR [i.1], and has been converted to a TS because the language used in the document is akin to that of a TS. NOTE: The EBU/ JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body by including in the Memorandum of Understanding also CENELEC, which is responsible for the standardization of radio and television receivers. The EBU is a professional association of broadcasting organizations whose work includes the co-ordination of its members' activities in the technical, legal, programme-making and programme-exchange domains. The EBU has active members in about 60 countries in the European broadcasting area; its headquarters is in Geneva. European Broadcasting Union CH-1218 GRAND SACONNEX (Geneva) Switzerland Tel: Fax: The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network operators, software developers, regulatory bodies, content owners and others committed to designing global standards for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. The consortium came together in 1993 to provide global standardisation, interoperability and future proof specifications. The present document is part 3, sub-part 3 of a multi-part deliverable full details of the entire series can be found in part 1, TS [i.2].

5 5 TS V1.3.1 ( ) 1 Scope The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 version 4: Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the Handbook. Part 3 of this multi-part deliverable deals with Error recovery technologies. The present document provides guidelines on the Retransmission (RET) technology. 2 References References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For a specific reference, subsequent revisions do not apply. Non-specific reference may be made only to a complete document or a part thereof and only in the following cases: - if it is accepted that it will be possible to use all future changes of the referenced document for the purposes of the referring document; - for informative references. Referenced documents which are not found to be publicly available in the expected location might be found at NOTE: While any hyperlinks included in this clause were valid at the time of publication cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are indispensable for the application of the present document. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. [1] TS (V1.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks". 2.2 Informative references The following referenced documents are not essential to the use of the present document but they assist the user with regard to a particular subject area. For non-specific references, the latest version of the referenced document (including any amendments) applies. [i.1] TR : "Digital Video Broadcasting (DVB); Guidelines for DVB IP Phase 1 Handbook". [i.2] TS : "Digital Video Broadcasting (DVB); Guidelines for the implementation of DVB-IPTV Phase 1 specifications; Part 1: Core IPTV Functions".

6 6 TS V1.3.1 ( ) 3 Abbreviations For the purposes of the present document, the following abbreviations apply: CoD DA DP DVB GA HNED IETF IGMP LMB MBwTM MC RET RTP RTCP RTCP FF RTCP RR RTCP RSI RTCP SDES RTSP SA SDP SP SSRC UC XML Content on Demand Destination Address Destination Port Digital Video Broadcasting Group Address Home Network End Device Internet Engineering Task Force Internet Group Management Protocol Live Media Broadcast MediaBroadcast with Trick Modes Multicast Retransmission Real-time Transport Protocol Real-time Transport Control Protocol RTCP Feedback RTCP Feedforward RTCP Receiver Report RTCP Receiver Summary Information RTCP Source description Real Time Streaming Protocol Source Address Session Description Protocol Source Port Synchronization SouRCe Unicast extensible Markup Language 4 Example of messaging flow involved in DVB RET retransmission for LMB services DVB retransmission solution for LMB services builds on the DVB RTP retransmission solution for CoD services, but has additional flexibilities and parameters, in order to make the solution sufficiently scalable. In this paragraph we show an architecture example and related RTP/RTCP message flows for a RET-enabled LMB service from the HNED point of view. Figure 1 shows the considered example architecture. The Head-end sources the multicast streams (carrying the LMB services), which the HNEDs can join by means of the IGMP protocol. The LMB service is RET-enabled and the HNEDs have been configured with RET DVB parameters, including network/transport address of the LMB RET server(s). In this example an HNED equipped with a DVB RET client can interact with the LMB RET server both in unicast and multicast way. From the HNED point of view, three different RTP sessions can be considered: 1) The original RTP multicast session, in which the Head-end sources the RTP multicast streams. The RET-enabled HNED issues in this session the unicast RTCP messages for retransmission requesting (RTCP Feedback messages) and for status reporting (RTCP Receiver Reports) to the LMB Retransmission server, hosting the RTCP (Feedback) target for the original RTP multicast session (depicted as a dashed line in figure 1). 2) The unicast RTP retransmission session in which the LMB RET server responds to the RTCP retransmission requests received from the HNEDs in the original RTP multicast session. In this session, the RET client of the HNED may also provide status reporting with respect to the unicast RTP retransmission stream towards the LMB RET server.

7 7 TS V1.3.1 ( ) 3) There may be optionally also a multicast RTP retransmission stream, which can be used by the LMB RET server to address individual network packet loss events in the original RTP multicast session that impact multiple HNEDs (packet loss event 1 in figure 1). This dedicated RTP session may not only carry RTP retransmissions packets but also RTCP Feedforward messages, which advertise packet loss events with the purpose to suppress retransmission requesting. NOTE: Such RTCP feedforward message is a unicast RTCP Feedback message from a DVB RET client that is relayed by the LMB RET server over the retransmission multicast session towards all DVB RET clients downstream from the LMB RET server. This DVB RET client could be an upstream client as depicted in the figure 1- or a subset of the HNEDs downstream of the LMB RET server The three different sessions are differentiated by means of different transport addresses (IP source and destination addresses and ports) and have in general different SSRC identifiers (RTP layer). Head End Original RTP Multicast GroupIP Address = G 1 Source IP Address =X Destination Port = N SSRC = A Upstream RET client (MC) Router LMB RET server Retransmission RTP Multicast Group IP Address = G 2 Source IP Address =Y Destination Port = M SSRC = B Packet Loss Event 1 Retransmission RTP Unicast Destination IP Address = B Source IP Address =Y Destination Port = P SSRC = C (MC) Router Packet Loss Event 2 RET client HNED A RET client HNED B Figure 4.1: Architecture example for a RET-enabled LMB service The following messaging flows is an illustrative example of the interactions involved in a DVB RET-enabled LMB service in which the three RTP sessions as explained above are present. The focus is on RTCP message exchange and DVB RET client behaviour. The scenario considered is the following: A RET-enabled HNED connects to a LMB service ("channel A") with IGMP, which establishes the original RTP multicast session from the HNED point of view. The HNED also connects to the LMB multicast retransmission session by means of IGMP. This session connection occurs every time the HNED changes channel. When packet loss takes place, this is detected by the RET client in the HNED. In this case this is packet loss impacting only one HNED (e.g. the packet loss is caused by a failure on the access link). When the HNED requests the retransmission and the LMB RET server responds with a unicast retransmission, the retransmission session is established. A second packet loss event takes place downstream of the LMB RET server, but now impacts multiple HNEDs. In this case the LMB RET server responds with a retransmission in the RTP multicast retransmission session.

8 8 TS V1.3.1 ( ) After some time the HNED changes channel (channel B). During the time the HNED receives channel B (in the new original multicast session), the HNEDs detects several packet loss events, but all interaction with the LMB RET server occurs solely in unicast. After some time the HNED changes channel (channel C). During this session no packet loss events take place and there is no interaction with the LMB RET server at all. After some time the HNED changes channel to channel B again. Several packet loss events take place, and the last packet loss event in the considered scenario takes place upstream from the LMB RET server that is detected by the "upstream retransmission client" entity in the LMB RET server. The LMB RET server relays the RTCP Feedforward message in the RTP retransmission multicast session which suppresses the retransmission request by the HNED. Once the packet is recovered by the LMB RET server (outside the scope of DVB RET), this packet is retransmitted in the multicast RTP retransmission stream. More specifically in the considered scenario, some of the DVB RET parameters are configured at the HNED as follows: both a unicast and multicast retransmission service is advertised towards the HNEDs with signalling of all transport address related parameters; dvb-t-wait-min (ms) and dvb-t-wait-max (ms) are configured, meaning that the HNED reports packet loss at a random point in time between dvb-t-wait-min and dvb-t-wait-max upon packet loss detection; dvb-t-ret (ms) is configured, meaning that the HNED can issue a second (third, fourth,..) retransmission request after getting no response on the previous retransmission request within the time frame as specified by dvb-t-ret; RTCP-Bye is enabled; the HNED is instructed to send RTCP status report messages (RTCP RR) in the original RTP session; the HNED is not allowed to send RTCP status report messages (RTCP RR) in the unicast RTP retransmission session. LMB RET server IGMP proxy/mc replication IPI-1 interface LMB RET client IGMPv3 0, 1 Channel A Received RTP RET Unicast T RET RTP RET MC session A RTP RET UC session A RTCP SDES +RR T RET Original RTP MC session A 9 RTP RET Multicast 10 IGMPv3 11, 12, 13 RTCP SDES +Bye Time T Figure 4.2

9 9 TS V1.3.1 ( ) LMB RET server IGMP proxy/mc replication IPI-1 interface LMB RET client RTP RET MC session B RTP RET MC session C RTP RET UC session B RTCP SDES +Bye RTP RET Unicast RTCP SDES +RR RTCP SDES +Bye IGMPv3 IGMPv3 Channel B Received T RET 20, 21, 22 Channel C Received Channel B Received Original RTP MC session B Original RTP MC session C 25, 26 RTP RET MC session B2 RTP RET UC session B2 RTCP FF MC RTP RET MC RTP RET Unicast 27 28, T RET T RET T RET Original RTP MC session B2 Figure 4.3 Table 1 describes in more detail the different events and message exchanges for the particular example scenario. Table 4.1: Message exchanges and triggering events for a RET enabled LMB service with support for Multicast RTP retransmission (example) Time RTP/RTCP message (T) reception/transmission / Event 0 IGMPv3 message exchange to join RTP original session (channel A) and RTP RET MC session (for channel A) HNED timing 1 First RTP packets MC group Ch A received (GA=G1; SA=X; DP=N/N+1; SSRC=A) 2 Packet Loss detection by HNED 3 message sent by HNED (DA=Y; SA=Z; DP=M A source=a) Message sent at random point in time between T 2 + T min and T 2 + T max ; DVB-T-RET count-down started 4 RTP RET packet received by HNED (DA=Z; SA=Y; DP=R; SP=V A, SSRC=T) RTP packet is received by HNED before DVB-T-RET is elapsed after T3 (5) (DVB-T-RET now elapsed since T3, but nothing happens, as RET packet received) 6 RTCP SDES+RR message sent by HNED (DA=Y; SA=Z; DP=M A source=a) RTP session initiation/closure Original RTP MC session and MC RTP RET session established. UC RET RTP session established.

10 10 TS V1.3.1 ( ) Time RTP/RTCP message (T) reception/transmission / Event 7 Packet Loss detection by HNED 8 message sent by HNED (DA=Y; SA=Z; DP=M A source=a) 9 DVB-T-RET elapsed prior to reception of missing packet (as original packet or as RET packet) or reception of RTCP FF message ; message is re-sent by HNED (DA=Y; SA=Z; DP=M A source=a) 10 MC RET packet received (= reported missing packet) (GA=G1 R ; SA=Y; DP=N; SSRC=A) 11 End-user zaps to new channel B: IGMPv3 message exchange to -leave MC RTP original session and RTP RET MC session (channel A) -join RTP original session (channel B) and RTP RET MC session (for channel B) 12 RTCP SDES + Bye Message sent by HNED (DA=Y; SA=Z; DP=M A source=a) 13 First RTP packets MC group Ch B received (GA=G2; SA=X; DP=N/N+1; SSRC=B) 14 Packet Loss detection by HNED 15 message sent by HNED (DA=Y; SA=Z; DP=M B source=b) 16 RTP RET packet received by HNED (DA=Z; SA=Y; DP=R; SP=V B, SSRC=T) 17 RTCP SDES+RR message sent by HNED (DA=Y; SA=Z; DP=M B source=b) 18 Packet Loss detection by HNED 19 message sent by HNED (DA=Y; SA=Z; DP=M B source=b) 20 End-user zaps to new channel C: IGMPv3 message exchange to -leave RTP original session and RTP RET MC session (channel B) -join RTP original session (channel B) and RTP RET MC session (for channel C) 21 RTCP SDES + Bye Message sent by HNED (DA=Y; SA=Z; DP=M B source=b) HNED timing Message sent At random point in time between T 7 + T min and T 7 + T max ; DVB-T-RET count down started DVB-T-RET count down started Received before DVB T-RET has elapsed since T 9 Message sent at random point in time between T 14 + T min and T 14 + T max ; DVB T-RET count down started RTP packet is received by HNED before DVB T-RET is elapsed after T 15 Message sent At random point in time between T 18 + T min and T1 8 + T max ; DVB T-RET count down started RTP session initiation/closure New Original RTP MC session and MC RTP RET session established. HNED closes explicitly the RTP RET UC session. Unicast RTP RET session established. New Original RTP MC session and MC RTP RET session established. HNED closes explicitly the RTP RET UC session.

11 11 TS V1.3.1 ( ) Time RTP/RTCP message (T) reception/transmission / Event 22 First RTP packets MC group Ch C received (GA=G3; SA=X; DP=N/N+1; SSRC=C) 23 End-user zaps to channel B: IGMPv3 message exchange to -leave RTP original session and RTP RET MC session (channel C) -join RTP original session (channel B) and RTP RET MC session (for channel B) 24 First RTP packets MC group Ch B received (GA=G2; SA=X; DP=N/N+1; SSRC=C) 25 Packet Loss detection by HNED 26 message sent by HNED (DA=Y; SA=Z; DP=M B source=b) 27 RTP RET packet received by HNED (DA=Z; SA=Y; DP=R; SP=V B, SSRC=T) 28 Packet Loss detection by HNED (and by LMB RET server) 29 message sent by HNED (DA=Y; SA=Z; DP=M B source=b) 30 Reception of RTCP FF message (GA=G2 R ; SA=Y; DP=N; SSRC=B) 31 Reception of RTCP MC RET packet (GA=G2 R ; SA=Y; DP=N; SSRC=B) HNED timing Message sent at random point in time between T 25 + T min and T 25 + T max ; DVB T-RET count down started RTP packet is received by HNED before DVB T-RET is elapsed after T 26 Message sent at random point in time between T 28 + T min and T 28 + T max ; DVB T-RET count down started Before DVB-T-RET was elapsed since T 29 ; DVB-T-RET count down re-started Reported missing packet received, before DVB-T-RET was elapsed since T 30 RTP session initiation/closure Unicast RTP RET session for channel C was never established! New Original RTP MC session and MC RTP RET session established Unicast RTP RET session established. 5 HNED RET parameter configuration via SDP The DVB RET-related parameters can be signalled to the HNED with XML, which is done either via Broadcast Discovery records ([1] clause for LMB services) or by means of XML descriptions transmitted with RTSP ANNOUNCE method or RTSP DESCRIBE method response (for RTSP clients of LMB services or CoD/MBwTM services). The DVB RTSP client is required to support the reception of descriptions in XML format but additionally, a DVB RTSP client supporting DVB retransmission, should also understand session descriptions in SDP format. This section contains an example of an SDP description for a RET-enabled CoD and an example of an SDP description for a RET-enabled LMB RTP session. They include the RET relevant parameters/attributes including the ones defined in the various IETF references for DVB RET, but the focus is here on how to embed those RET parameters defined specifically (and exclusively) in the DVB handbook in an SDP description. More specifically, the DVB-specific parameter "dvb-t-ret" is a format-specific parameter that can only be specified in the m-line associated with the original RTP packet flow and "dvb-disable-rtcp-rr" is a DVB-specific attribute that can be specified in SDP per c-line or per m-line both for the original RTP and the unicast retransmission RTP flows. The parameter "dvb-t-ret" and attribute "dvb-disable-rtcp-rr" can be included in the SDP file both for LMB and for CoD services. Additionally, for RET-enabled LMB services the following DVB media-specific parameters may be included in the SDP file in the m-line associated with the original RTP session: "dvb-t-wait-min", "dvb-t-wait-max", "dvb-ssrc-bitmask", "dvb-ssrc-upstream-client", "dvb-rsi-mc-ret" and "dvb-enable-bye".

12 12 TS V1.3.1 ( ) 5.1 SDP example for RET-enabled CoD The SDP example for the RET-enabled COD service describes a SSRC multiplexing scheme. In the given example, the HNED must not issue RTCP RR reports both with respect to the Retransmission and Original RTP packet flows. The original packets are buffered for 1 second, and there should be at least 300 ms between two consecutive messages requesting retransmission for the same packet. The bandwidth that can be maximum consumed by the HNED for its RTCP (FB) reporting is 50 kb/s. v=0 o=dvb-iptv-service-provider-x IN IP4 dvb-iptv-service-provider-x.cod-servicey-with-ret.com c=in IP a=dvb-disable-rtcp-rr m=video RTP/AVPF a=rtpmap:33 MP2T/90000 a=ssrc: cname:cod-server-89@dvb-iptv-service-provider-x.com a=rtcp-fb:33 nack a=fmtp:33 dvb-t-ret=300 b=rr:50 a=rtpmap:96 rtx/90000 a=ssrc: cname:cod-server-89@dvb-iptv-service-provider-x.com a=fmtp:96 apt=33;rtx-time= SDP example for RET-enabled LMB The SDP example for the RET-enabled LMB service describes a session multiplexing scheme in which retransmissions can be sent both unicast and multicast mode. In the given example, the HNED can send in the original session RTCP FB messages in stand-alone (non-compound) mode. The original packets are buffered for 1 second by the LMB RET server, and there should be at least 300 ms between two consecutive messages requesting retransmission for the same packet. The HNED must respect a waiting time of 200 ms before issuing an message upon packet loss detection, unless it is an early reporter, for which the "dvb-ssrc-bitmask" is signalled. The HNED is expected to issue the RTCP bye in the original RTP session when applicable. In the retransmission flow the RTP and RTCP packets are multiplexed on the same port. The HNED is expected to issue RTCP RR reports in the retransmission session. The bandwidth that can be consumed by the HNED for its RTCP reporting is 5 % of the original stream bandwidth (default value, not signalled). The RTCP RSI messages pertaining to the original MC RTP session are distributed in the MC retransmission RTP session. v=0 o=dvb-iptv-service-provider-x IN IP4 dvb-iptv-service-provider-x.lmb--servicez-with-ret.com a=rtcp-unicast:rsi m=video RTP/AVPF 33 c=in IP /255 a=source-filter:incl IN IP a=ssrc: cname:head-end-01@dvb-iptv-service-provider-x.com a=recvonly a=rtpmap:33 MP2T/90000 a=rtcp:40001 IN IP a=rtcp-fb:33 nack a=rtcp-rsize a=fmtp:33 dvb-t-ret=400;dvb-t-wait-min=200;dvb-t-wait-max=200;dvb-ssrc-bitmask=3;dvb-ssrc-upstreamclient=123401;dvb-rsi-mc-ret;dvb-enable-bye m=video RTP/AVPF 97 c=in IP a=ssrc: cname:ret-server-02@dvb-iptv-service-provider-x.com a=recvonly a=rtpmap:97 rtx/90000 a=fmtp:97 apt=33;rtx-time=1000; a=rtcp-mux m=video RTP/AVPF 98 c=in IP /255 a=source-filter:incl IN IP a=recvonly a=rtpmap:98 apt=33;rtx-time=1000 a=dvb-disable-rtcp-rr

13 13 TS V1.3.1 ( ) History Document history V1.1.1 November 2006 Published as TR V1.2.1 April 2008 Published as TS V1.3.1 January 2010 Publication