1、 ETSI TR 102 542 V1.1.1 (2006-11)Technical Report Digital Video Broadcasting (DVB);Guidelines for DVB IP Phase 1 HandbookEuropean Broadcasting Union Union Europenne de Radio-Tlvision EBUUER ETSI ETSI TR 102 542 V1.1.1 (2006-11) 2 Reference DTR/JTC-DVB-199 Keywords broadcasting, digital, DVB, IP, TV,
2、 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 Individual copies of the present documen
3、t 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 Document Format (PDF). In case of dispute,
4、 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 current status of this and other ETSI
5、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 reproduced except as authorized by written
6、 permission. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2006. European Broadcasting Union 2006. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members.
7、 TIPHONTMand the TIPHON logo are Trade Marks currently being registered by ETSI 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 TR 102 542 V1.1.1 (2006-11) 3 Contents Intellectual Property Rig
8、hts4 Foreword.4 1 Scope 5 2 References 5 3 Abbreviations .5 4 Background to the scenarios.6 5 Turning on and booting an HNED .7 5.1 Physical/MAC layer connection.7 5.2 IP Layer connectivity via obtaining an IP Address 7 5.2.1 Location of the DHCP server8 5.2.2 Adding a new DHCP Class option8 5.3 Con
9、tent discovery.9 5.3.1 Content discovery with local DHCP server 10 5.3.2 Content discovery without DHCP server11 5.4 Content selection 11 5.4.1 DHCP server within the home 11 5.4.2 No DHCP server .13 5.5 Streaming the video content .13 5.6 Acquisition of Live Channels services .13 6 Sample complete
10、SD Essential, or potentially Essential, IPRs notified to ETSI in respect 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 search
11、es, has been carried out by ETSI. No guarantee can be given as to the 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 Report (TR) has been produced by Joi
12、nt Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comit Europen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). Founded in September 1993, the DVB Project is a market-led consortium of public and private secto
13、r organizations 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 econo
14、mic circumstances, of the consumer electronics and the broadcast industry. 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
15、 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
16、 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: +41 22 717 24 81 ETSI ETSI TR 102 542 V1.1.1 (2006-11
17、) 5 1 Scope The present document is designed to help people implement the DVB-IP Phase 1 Handbook (available also as TS 102 034 1) and is a companion to that document. The present document is organized in separate clauses in the order of boot-up of the HNED rather than in the same order as the Handb
18、ook, each dealing with a specific aspect of the DVB-IP technology, and offering explanations and examples not found in the Handbook. 2 References For the purposes of this Technical Report, the following references apply: NOTE: While any hyperlinks included in this clause were valid at the time of pu
19、blication ETSI cannot guarantee their long term validity. 1 ETSI TS 102 034: “Digital Video Broadcasting (DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks“. 2 ETSI TR 101 154: “Digital Video Broadcasting (DVB); Implementation guidelines for the use of MPEG-2 Systems, Video and Aud
20、io in satellite, cable and terrestrial broadcasting applications“. 3 IETF RFC 3927: “Dynamic Configuration of IPv4 Link-Local Addresses“. 4 IETF RFC 3203: “DHCP reconfigure extension“. 5 IEEE 1394: “IEEE Standard for a High Performance Serial Bus -Description“. 6 IEEE 802.1D-2004: “IEEE standard for
21、 local and metropolitan area networks-Media access control (MAC) Bridges (Incorporates IEEE 802.1t-2001 and IEEE 802.1w)“. 7 IEEE 802.11a-1999 (8802-11:1999/Amd 1:2000(E): “IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan are
22、a networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications-Amendment 1: High-speed Physical Layer in the 5 GHz band“. 8 IEEE 802.11b-1999 Supplement to 802.11-1999: “Wireless LAN MAC and PHY specifications: Higher speed Physical Layer (
23、PHY) extension in the 2.4 GHz band“. 9 IEEE 802.11g-2003: “IEEE Standard for Information technology-Telecommunications and information exchange between systems-Local and metropolitan area networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specif
24、ications-Amendment 4: Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band“. 3 Abbreviations For the purposes of the present document, the following abbreviations apply: ALG Application Level Gateway AVC Advanced Video Coding CRLF Carriage Return Line Feed DHCP Dynamic Host Configuratio
25、n Protocol DNG Digital Network Gateway DNS Domain Name System DSCP Differentiated Services CodePoint DSL Digital Subscriber Line DTD Document Type Declaration DVB Digital Video Broadcasting ETSI ETSI TR 102 542 V1.1.1 (2006-11) 6 DVBSTP DVB SD IP Layer connectivity via obtaining an IP Address; netwo
26、rk provisioning (optional); connection to the SD content selection; streaming of the video content. Network provisioning is optional and is dealt with in a separate clause. 5.1 Physical/MAC layer connection The physical/MAC layers consist of either 100 Mbps Ethernet or IEEE 1394 5, and the link laye
27、r needs to come up before anything else happens. The only variation on plain vanilla Ethernet, for example, is the mandatory use of IEEE 802.1D 6 user priority values and the corresponding IP DSCP markings. These can be used by the rest of the network to help obtain the Quality of Service required f
28、or the streamed video content. 5.2 IP Layer connectivity via obtaining an IP Address Once the link layer comes up, the HNED obtains the IP address from a DHCP server with the DVB mandatory DHCP options. The Handbook specifies the minimum DHCP options required to allow the DHCP server to be simple en
29、ough to fit into a DNG or other product on the home network segment. DHCP does not currently specify a way to co-ordinate the address pools of multiple DHCP servers on a network. The DHCP client simply takes the first address offered to it but, normally, the closest available server. This means that
30、 multiple DHCP servers cannot be used on the same network to serve the HNED. The IP address assigned by the DHCP server will be different for each HNED on the same home network segment, but will be part of the same IP subnet. The use of private or public IP address space and size of the subnet mask
31、is at the discretion of the Network Service Provider. Whilst the IPI specification proposes two ways for HNEDs to get an IP address: DHCP server or via RFC 3927 3 (IETF zero configuration mechanism), DHCP server is the normal way. It is expected that the RFC 3927 3 is only to be used in emergency wh
32、ere the DHCP server is down for some short-term reason. ETSI ETSI TR 102 542 V1.1.1 (2006-11) 8 5.2.1 Location of the DHCP server The DHCP server can be located in the home or in the access network. If it is in the home, it will likely be on the DNG, a scenario typical of DSL. The most popular means
33、 of address assignment is to have the home in a private IP address space whilst the public interface has an IP address given by the network operator. The DNG using Network Address Translation to change the IP addresses of the data from public to/from private address spaces. DNG HNED 2 HNED 1 Home Ne
34、twork Segment DHCP server Private IP space Network IP space IP 1 IP 2 IP 0 IP p Figure 2: Home Network with local DHCP server The DHCP server can be located on the external network, typical of a cable or Ethernet to the Home deployment. The DNG then acts as a bridge or DHCP “relay“ to relay the DHCP
35、 messages to the external DHCP server. You should be aware that the DVB Class options must be preserved in this case. DNG HNED 2 HNED 1 Home Network Segment Network IP space DHCP server Access Network IP 1 IP 2 Figure 3: Home Network with remote DHCP server 5.2.2 Adding a new DHCP Class option The D
36、HCP Class IDs defined in the Handbook are the minimum set needed to support the types of HNEDs originally supported in the commercial and technical requirements. The Handbook allows these attributes to be added to by any DVB member. The Class ID is meant to help the DHCP server give the appropriate
37、IP address for the type of HNED. It is an insecure method but, for example, will allow a DHCP server to give a private address to one type of HNED and a public one to another. It should not be manufacturer specific. Following is the procedure to add a new attribute: 1) Contact the DVB Project Office
38、 via the web site or email with the following information: name of the Class ID; company name; ETSI ETSI TR 102 542 V1.1.1 (2006-11) 9 contact name, email address and phone number of the legal representative who is the signatory to the request; contact name, email address and phone number of the tec
39、hnical representative for the request; technical and commercial motivation for the request 2) The DVB Project Office will optionally contact the company. 3) The DVB Project Office will then notify the technical and legal representative of their decision. 4) If the decision is positive then the class
40、 ID will be published on the DVB web site and, if possible, in the next maintenance revision of the Handbook. 5.3 Content discovery Now that the HNEDs have their IP address, they start looking for the SD multicast stream selection plus RTSP; unicast stream with RTSP. The first 2 are for live TV cont
41、ent while the latter is for content on demand or Media Broadcast with Trick Modes services. For Live TV, the RTSP messages are not mandatory; 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
42、the HN, and the gateway forwards it to the access network. Thus the Live TV stream can be received by the HNED. ETSI ETSI TR 102 542 V1.1.1 (2006-11) 12DNG HNED 2 HNED 1 Home Network Segment Access Network DHCP server Content provider Private IP space Network IP space NAT IGMP join Multicast LiveTV
43、stream Figure 7: IGMP live content selection with DHCP server If the RTSP protocol is used, the gateway needs to provide RTSP ALG (Application Level Gateway) feature: this ALG is replacing into the RTSP message payload the values of the IP address and UDP port given by the HNED by the public IP addr
44、ess of the gateway and an available UDP port. This RTSP message will be sent before doing the multicast 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 8: RTSP live c
45、ontent selection with DHCP server Finally, in case of unicast streaming, no multicast join is necessary 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
46、 stream Figure 9: Content on Demand selection ETSI ETSI TR 102 542 V1.1.1 (2006-11) 135.4.2 No DHCP server The only possibility with this configuration is to connect to a LiveTV stream without RTSP protocol. The IGMP join message has to be forwarded by the gateway to the access network, so the HNED
47、will be able to receive this stream. DNG HNED 2 HNED 1 Home Network Segment Access Network Content provider Private IP space Network IP space NAT IGMP join Multicast LiveTV stream Figure 10: Live content selection without DHCP server 5.5 Streaming the video content The video content uses an MPEG-2 t
48、ransport stream, as defined in TR 101 154 2, which is then encapsulated in RTP. Multicast Content Services use IGMP version 3 with Source Specific Multicast. This allows significant scalability and implementers should note that the previous version of IGMP is not allowed. 5.6 Acquisition of Live Cha
49、nnels services The acquisition of Live Channels services is performed through the retrieval of the content of the “Package“ and “Broadcast“ files. If there is a Package service, the 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 2) customer connects the HNED to
