1、 ETSI TS 102 542-3-3 V2.1.1 (2016-04) Digital Video Broadcasting (DVB); Guidelines for the implementation of DVB-IPTV Phase 1 specifications; Part 3: Error Recovery; Sub-part 3: Retransmission (RET) TECHNICAL SPECIFICATION ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 2 Reference RTS/JTC-DVB-360-3-3 Key
2、words broadcasting, digital, DVB, IP, TV, video ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice
3、 The present document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorizati
4、on of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be awa
5、re that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following se
6、rvices: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version
7、shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2016. European Broadcasting Union 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo
8、are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI 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. ETSI ETSI TS 102 542-3-3 V2.1
9、.1 (2016-04) 3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Abbreviations . 5g34 Example of messaging flow involved in DVB RET retransmission for LMB services . 6g35 HNED RET
10、 parameter configuration via SDP . 11g35.0 Signalling of HNED RET parameters 11g35.1 SDP example for RET-enabled CoD 12g35.2 SDP example for RET-enabled LMB . 12g3History 14g3ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 4 Intellectual Property Rights IPRs essential or potentially essential to the prese
11、nt document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in res
12、pect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of
13、 other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI 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 (
14、EBU), Comit Europen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). NOTE: The EBU/ETSI 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 J
15、TC 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
16、 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: +41 22 717 21 11 Fax:
17、+41 22 717 24 81 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 ser
18、vices. 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 d
19、ata. The consortium came together in 1993 to provide global standardization, 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. Modal verbs terminology In the present docu
20、ment “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except
21、when used in direct citation. ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 5 1 Scope The present document is designed as a companion document to help implement the DVB-IPTV Phase 1 specification Transport of MPEG2-TS Based DVB Services over IP Based Networks 1, which is referred to as the Handbook. Par
22、t 3 of this multi-part deliverable deals with error recovery technologies. The present document provides guidelines on the Retransmission (RET) technology. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number)
23、 or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:
24、/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. 1 ETSI TS 102 034: “Digital Video Broadc
25、asting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks“. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-spe
26、cific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the a
27、pplication of the present document but they assist the user with regard to a particular subject area. i.1 ETSI TS 102 542-1: “Digital Video Broadcasting (DVB); Guidelines for the implementation of DVB-IPTV Phase 1 specifications; Part 1: Core IPTV Functions“. 3 Abbreviations For the purposes of the
28、present document, the following abbreviations apply: CoD Content on Demand DA Destination AddressDP Destination Port DVB Digital Video Broadcasting GA Group Address HNED Home Network End Device IETF Internet Engineering Task Force IGMP Internet Group Management Protocol LMB Live Media Broadcast MBwT
29、M Media Broadcast with Trick Modes MC Multicast RET Retransmission RTP Real-time Transport Protocol RTCP Real-time Transport Control Protocol ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 6 RTCP FB RTCP FeedBack RTCP FF RTCP FeedForward RTCP RR RTCP Receiver Report RTCP RSI RTCP Receiver Summary Informa
30、tion RTCP SDES RTCP Source DEScription RTSP Real Time Streaming Protocol SA Source Address SDP Session Description Protocol SP Source Port SSRC Synchronization SouRCe UC UniCast XML eXtensible Markup Language 4 Example of messaging flow involved in DVB RET retransmission for LMB services DVB retrans
31、mission 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 an architecture example and related RTP/RTCP message flows for a RET-enabled LMB s
32、ervice from the HNEDs point of view are shown. Figure 1 shows the considered example architecture. This example makes use of IPv4 techniques. A similar message flow can also be achieved by IPv6 techniques but this possibility is not covered here. The Head-end sources the multicast streams (carrying
33、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
34、 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 fo
35、r 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 4.1). 2) The unicast RTP retransmission session in wh
36、ich 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. 3) There
37、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 4.1). This dedicated RTP session may not only carry R
38、TP 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 retran
39、smission 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 4.1 - or a subset of the HNEDs downstream of the LMB RET server. The three different sessions are differentiated by means of differ
40、ent transport addresses (IP source and destination addresses and ports) and have in general different SSRC identifiers (RTP layer). ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 7 Figure 4.1: Architecture example for a RET-enabled LMB service The following messaging flows is an illustrative example of t
41、he 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
42、, 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 clien
43、t 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 packe
44、t 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. After some time the HNED changes channel (channel B). During the time the HNED receives channel B (in
45、 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 LM
46、B 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 R
47、ET 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 the present document), this packet is retransmitted in the m
48、ulticast RTP retransmission stream. Retransmission RTP UnicastDestination IP Address = BSource IP Address =Y Destination Port = P SSRC = C(MC) RouterLMB RET serverHead EndHNED ARET clientHNED BRET clientUpstreamRET client(MC) RouterOriginal RTP Multicast GroupIP Address = G1Source IP Address =X Dest
49、ination Port = N SSRC = ARetransmission RTP Multicast Group IP Address = G2Source IP Address =Y Destination Port = M SSRC = BPacket LossEvent 1Packet LossEvent 2ETSI ETSI TS 102 542-3-3 V2.1.1 (2016-04) 8 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 pa
