1、STD=SMPTE RP 203-ENGL 2000 8357YOL OUO4LOL T57 W RP 203-2000 Real Time Opportunistic Data Flow Control in an MPEG-2 Transport Emission Multiplex 1 scope This practice defines the means of implementing opportunistic data flow control in a DTV MPEGP transport bmdcast according to flow control mes- sag
2、es defined in SMPTE 325M. An emissions multi- plexer requests opportunistic data packets as the need for them arises and a data server responds by forwarding data already inserted into MPEG-2 trans- port stream packets. The control protocol that allows this transfer of asynchronous data is extensibl
3、e in a backward compatible manner to allow for more ad- vanced control as may be necessary in the future. Control messages are transmitted over a dedicated data link of sufficient quality to ensure reliable real- time interaction between the multiplexer and the data server. 2 Normative references Th
4、e following stanards contain provicions which, through reference in this text, constitute provisions of this practice. At the time of publication, the diions indicated were valid. All standards are subject to revision, and parties to agreements based on this practice are encouraged to investigate th
5、e possibility of applying the most recent edition of the standards indicated below: SMPTE S5M-1998, Television - Serial Data Trans- port Interface SMPTE 325M-1999, Digital Television -Opportunistic Data Broadcast Flow Control DVB-AOlO, Interfaces for CATV, SMATV Head- ends and Similar Professional E
6、quipment, Annex B: Asynchronous Serial Interface(AS1) Page 1 of 3 pages 3 Definition of terms 3.1 control channel: The logically unidirectional connection from the emissions multiplexer to the data server over which the SMPTE 325M oppor- tunistic data flow control messages are carried. 3.2 data chan
7、nel: The logically unidirectional connection from the data server to the emissions multiplexer over which the MPEG-2 transport stream packets are delivered for broadcast by the emissions multiplexer. 3.3 dataserver: A computing device that emits data encapsulated within MPEG-2 transport stream packe
8、ts intended for broadcast at the correct data rates specified for the particular services. In the case of opportunistic data, there is no defined fixed data rate. 3.4 opportunistic data: A data stream whose bit rate is unspecified and, over any time interval, may range from zero to the full bandwidt
9、h of the emissions channel. 3.5 opportunistic data session: T h e i n t e r c o n- nection of a data sewer containing opportunistic data and an emissions multiplexer that is able to insert that data into the transport multiplex whenever there is unused available bandwidth. There may exist multiple s
10、essions between the same physical multiplexer and data server. 3.6 opportunistic data flow control: The mecha- nism by which a multiplexer requests additional MPEG-2 transport packets from a data server and by which that data server emits a response. Copyright O 2000 by THE SOCIETY OF MOTION PICTURE
11、 AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., white Plains, NY 10607 (914) 761-1 I00 RP 209-2W 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 mar
12、ked with different PIDs. 4 Physical connection between multi- plexer and data server 4.1 The physical connection over which oppor- tunistic data flow control messages are carried from a multiplexer to one or multiple data servers can take either of two forms according to the circumstances of a given
13、 system implementa- tion. This physical connection is defined as origi- nating at a multiplexer output port and terminating at a data server input port. 4.1.1 One data link, one session: There may exist one physical data link for each opportunis- tic data session. 4.1.2 One data link, multiple sessi
14、ons: There may exist one shared physical data link for multiple opportunistic data sessions. In cases where mul- tiple data servers share a common flow control data link, a distribution amplifier must be used to distribute the signal from the multiplexer due to the point-to-point nature of the recom
15、mended physical data links (see 4.2). 4.2 Two physicaVdata link standards are appli- cable for real time opportunistic data flow control becaiuse they meet several requirements. The link must have sufficient bandwidth to carry the flow control messages fast enough to be useful. The link must be capa
16、ble of reliable, real time opera- tion with a minimum latency of transmission. The link protocol must be sufficiently compact so as to facilitate hardware-only parsing and/or generation of the messages in implementations that require minimum response latency. 4.21 DVB-ASI: The data link operates at
17、a usable data rate of 216 Mb/s and places no significant constraints on the timing or format of packets carried over it. It is recommended that manufac- turers implement DVB-AS1 receivers that are polarity insensitive because it allows increased interoperability with SMPTE 259M routing equip- ment.
18、4.2.2 SMPTE 305M (SDTI): The data link oper- ates at a raw data rate of 270 or 360 Mb/s. At 270 Mb/s, seven transport stream packets may be placed on each line, resulting in a usable bandwidth of 165 Mb/s. The underlying physical medium is SMPTE 259M. The transmission of data packets must be held of
19、f during the horizontal sync and SDTI framing portions of the signal and must conform to the encapsulation provisions set forth in SMPTE 305M. It is not recommended that the extended data space of SMPTE 305M be used. Y 5 Logical communication between multiplexer and data sewer 5.1 The logical commun
20、ication of flow control information between the multiplexer and data server is session based. Each opportunistic data session is assigned a unique transport PID that will be used to carry flow control information specific to a given session. When performing flow control of multiple opportunistic dat
21、a 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 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 p
22、resent on the data link. 5.2 Flow control response time should be con- sidered in the context of the real-time nature of the emissions multiplex. At any given time, the multiplexer may observe that no valid MPEG-2 transport stream packet is waiting to be transmitted. This will result in the emission
23、 of a null transport stream packet if the multiplexer is unable to acquire an opportunistic data packet in a suffi- cient amount of time. The possibility of single packet-time flow control is made available by the inherently high data rates and low latencies of the recommended data links. An MPEG-2
24、transport stream packet encapsulated flow control message takes less than 7 ps to travel over either recommended data link. Therefore, a sys- tems designer may consider how many flow control messages may be transferred in the period of time it would take forthe emissions multiplexer to transmit a tr
25、ansport stream packet. As an example: with a trans- mission data rate of approximately 19.4 MWs, the transmission time for a single MPEG-2 transport Page 2 of 3 paw stream packet is 78 ps. Using the physical interfaces defined in this practice would allow the transmission of roughiy 11 control messa
26、ges in the span of time required to transmit a single emissions transport stream packet. 5.3 SMPTE 325M addresses the network, trans- port, session, and presentation layers of an op- portunistic data flow control messaging mechanism in the common OS1 network model. 5.4 SMPTE 325M allows for an exten
27、sible flow control protocol by utilizing the DSM-CC message 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 t
28、he first protocol version will be interoperable with any future protocol versions (backward compatibility). 6 Opportunistic data flow control issues a request for a specified number of whole MPEG-2 transport packets and waits for a com- plete response from the data server. 6.3 Practical configuratio
29、n information is neces- sary to bound the request-and-wait mode of operation. 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 long the
30、 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.32 Maximum data server request size: This tells the multiplexer how much data the se
31、rver 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 the data not to arrive at the multiplexer as expected. 6.1 The application layer is imple
32、mented by the multiplexer and data server equipment manufac- turers and consists of the multiplexer observing a need for more opportunistic data and the data Server the data packets- 6.4 The multiplexer should be able to accept the full amount of data that it has requested at the fastest data rate a
33、nd lowest latency of the data link that it supports. 6.2 The operational model for opportunistic data flow control is request and wait. The multiplexer Annex A (informative) Bibliography ANSIISMPTE 259M-1997, Television - 10-Bit 4:22 Com- ponent and 4& Composite Digital Signals - Serial Digital Interface tion - Part 6: Extensions for DSM-CC ISOIIEC 13818-6:1998, Information Technology - Generic Coding of Moving Pictures and Associated Audio Informa- SMPTE 332M-2000, Television - Encapsulation of Data Packet Streams Over SDTI (SDTI-PF)
