1、 ETSI TS 102 542 V1.2.1 (2008-04)Technical Specification Digital Video Broadcasting (DVB);Guidelines for the implementation of DVB-IP Phase 1 specificationsEuropean Broadcasting Union Union Europenne de Radio-Tlvision EBUUER ETSI ETSI TS 102 542 V1.2.1 (2008-04) 2 Reference RTS/JTC-DVB-219 Keywords
2、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 Indiv
3、idual copies of the present document can be downloaded from: http:/www.etsi.org 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 Documen
4、t Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the cur
5、rent status of this and other ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reprodu
6、ced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2008. European Broadcasting Union 2008. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTM, TIPHONTM, the TIPHON logo and the
7、 ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TS 102 542 V1.2.1 (2008-04) 3 Contents Intellectual Property Rights6 Foreword.6 1 Scope 7 2 Refere
8、nces 7 2.1 Normative references .7 2.2 Informative references8 3 Abbreviations .8 4 Background to the Scenarios9 5 Turning on and Booting an HNED.10 5.1 Physical/MAC Layer Connection.10 5.2 IP Layer connectivity via obtaining an IP Address 10 5.2.1 Location of the DHCP Server.11 5.2.2 Adding a New D
9、HCP Class Option12 5.3 Content Discovery12 5.3.1 Content Discovery with Local DHCP Server .13 5.3.2 Content Discovery without DHCP Server 14 5.4 Content Selection .14 5.4.1 DHCP Server within the Home.14 5.4.2 No DHCP Server 16 6 SD Essential, or potentially Essential, IPRs notified to ETSI in respe
10、ct of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). 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
11、existence of 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 Broadcas
12、ting Union (EBU), Comit Europen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). Please note that the present document is a revision to TR 102 542, and has been converted to a TS because the language used in the document is akin to that of a
13、 TS. 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 JTC Broadcast became a tripartite body by including in the Memorandum of Understanding also CENELEC, which is responsible fo
14、r 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 6
15、0 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: +41 22 717 24 81 Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organiz
16、ations in the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters market-led systems, which meet the real needs, and economic circu
17、mstances, of the consumer electronics and the broadcast industry. ETSI ETSI TS 102 542 V1.2.1 (2008-04) 7 1 Scope The present document is designed as a companion document to help implement the DVB-IP Phase 1 version 3: Transport of MPEG2-TS Based DVB Services over IP Based Networks 1, which is refer
18、red to as the Handbook. The present document is organized in separate sections in the order of the boot-up sequence of the HNED rather than in the same section structure as the Handbook. Each clause deals with a specific aspect of the DVB-IP technology, and offers explanations and examples not found
19、 in the Handbook. Additionally, it provides guidelines to implement the Broadband Content Guide (BCG) specification 3. 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 revisio
20、ns 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 reference
21、s. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.etsi.org/Reference. For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, the primary source of the referenc
22、ed document should be cited, in order to ensure traceability. Furthermore, the reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the method of access to the referenced document and the full network address, with the same punctuation
23、 and use of upper case and lower case letters. NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are indispensable for the application of the present doc
24、ument. For dated references, only the edition cited applies. For non-specific references, the latest edition of the referenced document (including any amendments) applies. 1 ETSI TS 102 034 (V1.3.1): “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks“
25、. 2 ETSI TS 101 154 (V1.8.1): “Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream“. 3 ETSI TS 102 539 (V1.2.1): “Digital Video Broadcasting (DVB); Carriage of Broadband Content Guide (BCG) informatio
26、n over Internet Protocol (IP)“. 4 ETSI TS 102 822-2 (V1.3.1): “Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems (“TV-Anytime“); Part 2: System description“. 5 ETSI TS 102 822-6-1 (V1.3.1): “Broadcast and On-line Services: Search, select, and rig
27、htful use of content on personal storage systems (“TV-Anytime“); Part 6: Delivery of metadata over a bi-directional network; Sub-part 1: Service and transport“. 6 ETSI TS 126 346: “Universal Mobile Telecommunications System (UMTS); Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs
28、(3GPP TS 26.346 Release 7)“. ETSI ETSI TS 102 542 V1.2.1 (2008-04) 8 7 SMPTE Specification 2022-1: “Forward Error Correction for Real-time Video/Audio Transport Over IP Networks“. 8 DVB BlueBooks A109: “DVB-HN (Home Network) Reference Model Phase 1“. 9 ETSI TS 102 323: “Digital Video Broadcasting (D
29、VB); Carriage and signalling of TV-Anytime information in DVB transport streams“. 10 ETSI TS 102 005: “Digital Video Broadcasting (DVB); Specification for the use of Video and Audio Coding in DVB services delivered directly over IP protocols“. 2.2 Informative references 11 IETF RFC 3927: “Dynamic Co
30、nfiguration of IPv4 Link-Local Addresses“. 12 IETF RFC 3203: “DHCP reconfigure extension“. 13 IEEE P802.11-REVma/D6.0, 2006: Unapproved Draft Standard for Information Technology- Telecommunications and information exchange between systems- Local and metropolitan area network- Specific requirements P
31、art 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. NOTE: This document reflects the combining of the 2003 Edition of 802.11 plus the 802.11g, 802.11h, 802.11i and 802.11j Amendments) (Revision of IEEE Std 802.11-1999). 14 IEEE 802.1d (2004) “IEEE Standard for L
32、ocal and metropolitan area networks: Media Access Control (MAC) Bridges“. 15 IETF RFC 3376: “Internet Group Management Protocol, Version 3“. 16 IETF RFC 1112: “Host extensions for IP multicasting“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: ALG Appli
33、cation Level Gateway AVC Advanced Video Coding BCG Broadband Content Guide BiM Binary MPEG Format for XML CRLF Carriage Return Line Feed DHCP Dynamic Host Configuration Protocol DNG Digital Network Gateway DSCP Differentiated Services CodePoint DSL Digital Subscriber Line DTD Document Type Declarati
34、on DVB Digital Video Broadcasting DVBSTP DVB SD it is perfectly possible for the HNED to just join the corresponding multicast group. 5.4.1 DHCP Server within the Home The multicast join message is sent on the HN, and the gateway forwards it to the access network. Thus the Live TV stream can be rece
35、ived by the HNED. ETSI ETSI TS 102 542 V1.2.1 (2008-04) 15DNG HNED 2 HNED 1 Home Network Segment Access Network DHCP server Content provider Private IP space Network IP space NAT IGMP join Multicast LiveTV stream Figure 8:IGMP live content selection with DHCP server If the RTSP protocol is used, the
36、 gateway needs to provide RTSP ALG (Application Level Gateway) feature: this ALG replaces into the RTSP message payload the values of the IP address and UDP port given by the HNED by the public IP address of the gateway and an available UDP port. This RTSP message will be sent before doing the multi
37、cast join. DNG HNED 2 HNED 1 Home Network Segment Access Network DHCP server Content provider Private IP space Network IP space RTSP msg RTSP ALG IGMP join Multicast LiveTV stream Figure 9: RTSP live content selection with DHCP server Finally, in case of unicast streaming, no multicast join is neces
38、sary but the gateway still needs its RTSP ALG feature. DNG HNED 2 HNED 1 Home Network Segment Access Network DHCP server Content provider Private IP space Network IP space RTSP msg RTSP ALG Unicast CoD stream Figure 10: Content on Demand selection ETSI ETSI TS 102 542 V1.2.1 (2008-04) 165.4.2 No DHC
39、P Server Again, as in clause 5.3.2, this may work provided that the DNG forward the multicast report message, and forward incoming multicast packets in the home. The only possibility with this configuration is to connect to a Live TV stream without RTSP protocol. DNG HNED 2 HNED 1 Home Network Segme
40、nt Access Network Content provider Private IP space Network IP space NAT IGMP join Multicast LiveTV stream Figure 11: Live content selection without DHCP server 6 SD this is presented in the BCG clause of the present document. ETSI ETSI TS 102 542 V1.2.1 (2008-04) 18If there is a Package service, th
41、e HNED can collect (via Push or Pull mode) the “service names“ of the channels composing its bouquet. Then, the HNED can access (via Push or Pull mode) the XML file that contains the BroadcastDiscovery structure. For the Broadcast Discovery Information Record, there are two modes: “TS Full SI“ (SD F
42、or the push mode, it is not mandated to announce segments; it is not even mandated to announce the payload id. In that case, the HNED will check when receiving the header of the DVBSTP packets. The second offer is a broadcast one; it has the same segment and version as the first offer, which is acce
43、ptable because we talk here about a different offer. NOTE: The PayloadID attribute is expressed in the XML data structure in hexadecimal coded with 1 or 2 characters, while it is coded with exactly 2 hexadecimal characters in the URL of the HTTP request. The SegmentID attribute is expressed in the X
44、ML data structure in hexadecimal coded with 1 to 4 characters, while it is coded with exactly 4 hexadecimal characters in the URL of the HTTP request. The SegmentVersion attribute is expressed in the XML data structure in decimal, while it is coded with exactly 2 hexadecimal characters in the URL of
45、 the HTTP request. For example, for the first pull location : the HTTP requests to retrieve the segments are : GET /dvb/sdns/service_discovery?id= this allows managing timers in a more efficient way. 7.1.1.3 IGMPv3 IGMPv3 defines the following Membership Query message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0
46、1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x11 | Max Resp Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
47、 | Resv |S| QRV | QQIC | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address 1 | +- -+ | Source Address 2 | +- . -+ . . . . . . +- -+ | Source Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Max Resp Code field
48、is quite equivalent to the v2 Max Resp Time, with possibilities for more complex values. 7.1.1.4 Impact is on the HNED In IGMPv3 (RFC 3376 15), clause 7.2.1 says: “In order to be compatible with older version routers, IGMPv3 hosts MUST operate in version 1 and version 2 compatibility modes“. So having a DVB-IP compliant HNED means that it follows the IGMPv3 spec, meaning that it must conform to this statement. The detection of which version of IGMP runs on the router is done by looking at the Query message receive
