SMPTE RP 206-1999 Opportunistic Data Flow Control Using Ethernet as a Control Channel in an MPEG-2 Transport Emissions Multiplex.pdf

《SMPTE RP 206-1999 Opportunistic Data Flow Control Using Ethernet as a Control Channel in an MPEG-2 Transport Emissions Multiplex.pdf》由会员分享，可在线阅读，更多相关《SMPTE RP 206-1999 Opportunistic Data Flow Control Using Ethernet as a Control Channel in an MPEG-2 Transport Emissions Multiplex.pdf（3页珍藏版）》请在麦多课文档分享上搜索。

1、STD-SMPTE RP 20b-ENGL 3iq99 = 8357403 00039b4 5T2 SMPTE RECOMMENDED PRACTICE RP 206-1 999 Opportunistic Ethernet as a Data Flow Control Using Control Channel in an MPEG-2 Transport Emissions Multiplex 1 Scope This practice proposes a means of implementing oppor- tunistic data flow control in a DTV M

2、PEG-2 transport broadcast using the flow control messages defined in SMPTE 325M. This practice defines an implementa- tion that uses ethemet as the control channel from the emissions multiplexer to the data server. The data servers data are delivered to the emissions multi- plexer via either an ASI,

3、 SDTI, or ethemet point-to- point connection. An emissions multiplexer requests opportunistic data packets as the need for them arises. The data server responds by forwarding data already encapsulated in MPEG-2 transport stream packets. Emissions multi- plexer control messages are transmitted to the

4、 data server over ethernet with the SMPTE 325M opportun- istic flow control messages encapsulated in the net- work protocol of choice. The data servers information is delivered via a dedicated data link of sufficient qualw to ensure reliable interaction between the hardware/software entities in the

5、multiplexer and data server. There is no guarantee of real time response in this system. 2 Normative reference The following standard contains provisions which, through reference in this text, constitute provisions of this practice. At the time of publication, the edition indicated was valid. All st

6、andards are subject to revision, and parties to agreements based on this practice are encouraged to investigate the possibiliiy of applying the most recent edition of the standard indicated below. SMPTE 325M-1999, Digital Television - Opportunistic Data Broadcast Flow Control Page 1 of 3 pages 3 Def

7、inition of terms 3.1 control channel: The logically unidirectional connection from the emissions multiplexer to the data server where the SMPTE 325M opportunis- tic flow control messages are carried. 3.2 data channel: The logically unidirectional connection from the data server to the emissions mult

8、iplexer where the MPEG-2 transport stream packets are delivered for output by the emis- sions multiplexer. 3.3 dataserver: A computing device that emits data encapsulated within MPEG-2 transport stream packets intended for broadcast at the correct data rates specified for the particular services. In

9、 the case of opportunistic data, there is no defined fixed data rate. The transport stream packets are delivered to the emissions multiplexer via the data channel. 3.4 opportunistic data: A data stream whose bit rate is unspecified and, over any time interval, may range from zero to the full bandwid

10、th of the emissions channel. 3.5 opportunistic data flow control: The mecha- nism by which a multiplexer requests additional MPEG-2 transport stream packets from a data server. 3.6 opportunistic data session: T h e i n t e rc o n- nection of a data server containing opportunistic data and an emissio

11、ns multiplexer that is able to insert the data into the transport multiplex when- ever there is unused available bandwidth. There may exist multiple sessions between the same physical multiplexer and the data server. Copyright 8 1999 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. H

12、artsdaie Ave., White Plains, NY 10607 (914) 761-1 100 Approved December 3,1999 RP 206-1999 DS 3.7 PID: Packet identifier. A 13-bit field in an MPEG-2 transport stream packet header that identifies the transport stream packet as part of a larger data stream that is separate from other streams marked

13、with different PIDs. network protocol shall be the responsibility of the manufacturer. 4.1.3 The end-point identification shall be the responsibility of the manufacturer and is based won the network motocols selected bv the DS DS manufacturer. For TCP/iP or UDP/IP, th end stations shall be identifie

14、d by their IP address. The TCP/IP or UDPAP communication shall use Physical connections muti- plexer and data server 4.1 The physical connection where SMPTE 325M opportunistic data flow control messages are carried from an emissions multiplexer to one or more data servers shall be ethernet. The stan

15、dard practice of using ethernet hubs or eth- ernet repeaters to interconnect multiple data servers to an emissions multiplexer should be followed. 4.1.1 The selection of the network protocol(s) that is (are) used above the ethernet MAC layer to deliver control messages shall be the responsibility of

16、 the manufacturer. This practice discusses the use of either the TCP/IP or UDPAP network pro- tocols* 4.1.1.1 The UDPAP protocol is recommended in ethemet environments where the ethemet carrying the control channel is dedicated to the carriage of the control channel. In this environment, it is assum

17、ed that there is a significantly low prob- ability of collisions occurring on the ethernet. Thus, delivery is nearly guaranteed and the use of a nonguaranteed delivery protocol is considered acceptable. UDPAP is preferred in this environ- ment because of its lower overhead. 4.1.1.2 The TCP/IP protoc

18、ol is recommended in ethernet environments where the ethemet carrying the control channel is being shared with other applications. Care must be taken that packets from other applications do not adversely impact the performance of the system. TCP/IP is recom- mended because of its reliable data deliv

19、ery mechanism, and in ethernet where collisions can occur, the desire for a guaranteed delivery of the SMPTE 325M opportunistic flow control mes- sages is ideal. 4.1.2 The MPEG-2 transport stream packets de- fined in SMPTE 325M shall be carried in the payload portion of the network protocol. The num

20、ber of SMPTE 325M messages carried in the payload portion of a single message of the a well-known port number specific to the system. All SMPTE 325M messages shall be distributed to this port number. It is the responsibility of the manufacturers application to demultiplex multiple sessions as define

21、d below (see 5.1). 4.2 Figure 1 illustrates multiple data servers (DS) connected to an emissions multiplexer (EM). The data channel connections from the DS to the EM are point-to-point connections. The control channel connections from the EM to the DS use ethernet as per this practice and are repres

22、ented as a bus. EM Figure 1 - Multiple data servers 5 Logical communication between mutti- plexer and data sewer 5.1 The logical communication of flow control information between the multiplexer and data server is session based. Each opportunistic data session is assigned a unique transport PID that

23、 will be used to carry flow control information specific to a given session. When performing flow control of multiple opportunistic data ses- sions on a single data link, each session must be marked with a PID that is unique with respect to that data link. However, it is recommended Page 2 of 3 page

24、s STDeSMPTE RP 206-ENGL 1999 = 8357401 00039bb 375 RP 206-1999 that all PIDs in a broadcast environment be assigned uniquely to avoid accidental confusion of one stream for another even where only one session is present on a data link. 5.2 SMPTE 325M allows for an extensible flow control protocol by

25、 utilizing the DSM-CC version field to denote versions of the standard protocol. The basic protocol consists solely of a request from the multiplexer for a specified number of whole MPEG-2 transport stream packets. It is intended that any equipment designed to the first protocol version will be inte

26、roperable with any future protocol versions (backward compatibil- ity). 6 Opportunistic data flow control 6.1 The application layer is implemented by the multiplexer and data server equipment manufac- turers and consists of the multiplexer observing a need for more opportunistic data and the data se

27、wer responding with the requested data packets. 6.2 The operational model for opportunistic data flow control is request and wait. The multiplexer issues a request for a specified number of whole MPEG-2 transport stream packets and waits for a complete response from the data server. 6.3 Practical co

28、nfiguration information is neces- sary to bound the request-and-wait circum- stance. It is recommended that the following information be communicated to the multiplexer and used by the multiplexer manufacturer appro- priately. 6.3.1 Maximum data server response time: This tells the multiplexer how l

29、ong the data server may take to respond to any requests for addi- tional data. The multiplexer should consider this latency when making a request so that the re- quest is issued within at least the maximum response time. 6.3.2 Maximum data server request size: This tells the multiplexer how much dat

30、a the server is capable of providing at any one request over the specified response time. The multiplexer should consider this capacity when making a request to avoid the case where too much data are requested causing data not to arrive at the multiplexer as expected. 6.4 The multiplexer should be a

31、ble to accept the full amount of data that it has requested at the fastest data rate and lowest latency of the data link that it supports. 6.5 The data request pattern of the multiplexer is arbitrary and the responsibility of the multi- plexer manufacturer according to the internal architecture of t

32、he equipment, It is expected that the multiplexer will contain a buffer to hold a number of opportunistic data packets locally so that one is ready for transmission when needed. However, this is not mandatory and is irrelevant from the external opportunistic data flow control perspective. Annex A (i

33、nformative) Bibliography ANSI/SMPTE 259M-1997, Television - 10-Bit 4:2:2 Com- ponent and 4fse Composite Digital Signals - Serial Digital Interface ISOIIEC 1381 8-6:1998, Information Technology - Generic Coding of Moving Pictures and Associated Audio informa- tion - Pari 6: Extensions for DSM-CC SMPT

34、E 305M-1998, Television - Serial Data Transport Interface Over IEEE 802 Networks RFC 1042, Standard for the Transmission of IP Datagrams DVB-A010, Interfaces for CATV, SMATV Headends and Similar Professional Equipment, Annex 8: Asynchronous Serial Interface (ASI) The Ethernet - A Local Area Network, Version 1.0, Digital Equipment Corporation, Intel Corporation, Xerox Corpora- tion, September 1980 Page 3 of 3 pagas