WO2001047275A1

WO2001047275A1 - Data transport stream demultiplexer system

Info

Publication number: WO2001047275A1
Application number: PCT/US2000/034382
Authority: WO
Inventors: Michael Jon Beeler; James Mitchell Robinson; Frank George Huebner
Original assignee: Viacast Networks, Inc.
Priority date: 1999-12-20
Filing date: 2000-12-19
Publication date: 2001-06-28
Also published as: AU2276401A

Abstract

A DVB data transport stream demultiplexer, using a simple demultiplexing system which operates on only the data portion of the DVB transport stream. Internet protocol data transported in a DVB transport stream over digital video broadcast systems via Multiprotocol Encapsulation (MPE) is demultiplexed and formed into a MPE/IP stream.

Description

DATA TRANSPORT STREAM DEMULTIPLEXER SYSTEM

FIELD OF THE INVENTION

The present invention relates to digital television transmission systems and in particular to demultiplexing systems and methods facilitating the use of Digital Video Broadcast (DVB) systems to transport Internet Protocol (IP) Data.

BACKGROUND OF THE INVENTION

Various standards exist for the transport of digitized television information. Among these are standards defined by:

(1 ) DIGITAL VIDEO BROADCASTING (DVB);

DVB Specification for Data Broadcasting EN 301 192 VI .1 .1 (1 997-1 2) by the European Telecommunications Standards Institute the entire contents of which are incorporated herein by reference.

(2) DIGITAL VIDEO BROADCASTING (DVB);

Framing Structure, Channel Coding and Modulation for 1 1 /12/GHZ Satellite Services EN300 421 VI .1 .2 (1997-08) by the European Telecommunications Standards Institute the entire contents of which are incorporated herein by reference.

(3) DIGITAL VIDEO BROADCASTING (DVB);

DVB Specification for Data Broadcasting TS 101 192 VI .2.1 (1 997-12) by the European Telecommunications Standards Institute the entire contents of which are incorporated herein by reference. Among other things, these standards provide for the transport of data via a technique known as Multiprotocol Encapsulation (MPE). The transmission of datagrams according to the multiprotocol

encapsulation specification is accomplished by encapsulating the datagrams in DSM-CC sections (see ISO/IEC 1 381 8-6[5]), which are compliant with the MPEG-2 private section format (see ISO/IEC 1 381 8-1 [1 ]). The mapping of the section into MPEG-2 Transport Stream packets is defined in MPEG-2 Systems ISO/IEC 1 381 8-1 [1 ].

A transmitted DVB Transport Stream must be demultiplexed at the receiver to recover data. Transport Stream Demultiplexers exist but are tailored for demultiplexing Video, Audio or Teletext and Data. U.S. patent number 5,598,41 5, for example, discloses a system for transmission of high rate data in an MPEG-2 data stream. The demultiplexer in this system recovers audio packets, video packets and data packets from the demodulated transport packet stream. Prior art demultiplexers require complex processing, particularly to d ai witu video and audio, AΛ nee exists for a simpler and taster system.

SUMMARY OF THE INVENTION

The instant invention is of a Transport Stream Demultiplexer System and Method which uses a simple demultiplexing scheme which operates on solely the data portion of the DVB transport

stream. The ingress to the Demultiplexer is a pure DVB-S or DVB-C/T or DVB-B input stream but the output is solely an MPE/IP stream to be processed by an IP router.

An object of the invention is to provide a demultiplexer which secures only the data portion of an incoming DVB transport stream.

Another object of the invention is to provide a demultiplexing system which will facilitate the use of Digital Video Broadcasting Systems for transporting Internet Protocol Data.

Another object of the invention is to provide a system to isolate Multiprotocol Encapsulated data packets from a DVB transport stream.

/^■ΛΓIOUIGI

OI LIIC IIIVCIIUUII ID LU JJI VJVIUC a syiLCiii Ivj process an incoming DVB transport stream to provide an output which is sent to an IP router. BRIEF DESCRIPTION OF THE DRAWINGS

Figures 1 A and I B show a data flow diagram symbolizing the overall data flow of the Transport Stream Demultiplexer.

Figure 2 shows the Transport Stream Demultiplexer

Figure 3 diagrams processes performed by the DVB input processor.

Figures 4 and 5 and 6 outline processes performed by the synchronization detector.

Figure 7 shows a process performed by the PID detector.

Figures 8 and 9 show a process performed by the DSMCC/MPE Framer.

Figures 1 0 and 1 1 shows processes performed by the Egress processor.

Figures 1 2 and 13 and 1 show processes performed by the MP Transfer Formatter.

Figure 1 5 is a diagram of a DVB satellite system for transporting IP

Qdlύ.

Figure 1 6 is a diagram of a wireless service system for transporting IP data.

Figure 1 7 is a diagram of a terrestrial service system for transporting IP data. DETAILED DESCRIPTION

Figure 2 shows the overall configuration of a Transport Stream

Demultiplexer (TSD) according to this invention. Item 1 represents a transport stream demultiplexer system. It receives, as an input, a standard byte wide serial DVB stream item 1 3 along with a byte clock item 14 and a valid indicator item 1 5. The input DVB stream is a pure DVB-S or DVB-C/T or DVB-B input stream from a broadband transmission system such as satellite or wireless or cable. The Transport Stream Demultiplexer 1 2 output is solely a Multiprotocol Encapsulated Internet Protocol stream (MPE/IP stream) for fast processing by an Internet Protocol (IP) router. The output "egress" interface is a 32 bit wide data interface, item 1 6, with a clock, item 1 7 and address, item 1 8, and interrupt, item 1 9, to the microprocessor (not shown).

Figures 1 A and I B show a data flow diagram symbolizing the overall data flow of the transport stream demultiplexer. Item 1 is the input processor. Item 2 is a DVB input (ingress) processor. It receives a standard byte wide data stream (D[7:0j), item 3, a clock (CLK) signal, item 4, and a valid indicator (VLD) item 6. It outputs the eight bit wide data stream (D[7:0j) and a clock (CLK) signal. These outputs go to the synchronization detector item 7. Item 7 also receives a 188 or 204 Mode signal item 8. The synchronization detector looks for a synchronization byte, i.e. a hexadecimal 47 in

the 1 88th byte time slot of each DVB transport packet (i.e. every 188 transitions of the clock) if operating in the 188 mode or every 204 transitions of the clock, if operating in the 204 mode. (Hexidecimal B8 may also be used as a synchronization byte.) In a preferred embodiment the system will not consider itself in-sync until it has detected a synchronization byte in each of three

consecutive transport packets., i.e. three predictions. It then produces an in-sync signal.

Synchronization is checked continuously. Data will not be outputted to the next module untii the system is in sync. Even after the system is in sync and is operating a subsequent loss of synchronization will cause the synchronizer to discontinue outputting data to the next module. Even if only one sync byte in one transport packet is missed the system will immediately go out of sync. Item 9 is the Packet Identifier Detector (PID). It receives both data item 10 from the synchronizer, 7, and a clock signal (CLK). No data can be processed by this Detector unless an in-sync condition exists. It aiso receives information on input 1 1 specifying predetermined Packet identifier(s). These identifier(s) can be changed by changing the information on this input either by programming or otherwise. The PID detector, 9, scans the incoming data stream and looks for a match between the packet identifier (PID) of each incoming transport packet with a predetermined packet identifier stored in the PID detector 9 and/or received on input 1 1 . Note that more than one predetermined packet identifier may be utilized at a time. If a match is detected the corresponding

transport packet may be forwarded for further processing. If a match is not detected the corresponding transport packet will be discarded. The Matching process may be implemented, for example, by using an AND or digital comparator function.

In the preferred embodiment of this invention only those transport packets bearing multiprotocol encapsulated data in their payloads will produce matches. By knowing in advance the packet identifiers of those transport packets which bear multiprotocol encapsulated data one can preprogram the packet identifier, item 9, with oniy those known packet identifiers. With this programming the PID detector 9 will discard all transport packets which have no multiprotocol encapsulated data or have not configured. PID detector 9 will also retain and forward those transport packets which do contain multiprotocol encapsulated data thus producing a data stream containing only multiprotocol encapsulated data packets. These are the packets which bear the Internet Protocol data. The PID Detector also looks at the header of each transport

packet checking to see if the Payload Unit Start Indicator (PUSI) bit is set. If the PUSI is set it indicates that this packet contains the

beginning of a Digital Storage Multimedia CC packet. Until the PID Detector finds a transport packet having the PUSI bit set, it will not output data to the next stage. Data will simply be silently discarded until a PUSI bit is located.

The data output 20 of item 9 goes to the Digital Storage Multimedia CC/MPE Framer item 21 . Item 21 first verifies that the

first byte of the payload is an hexidecirna! 3E which is known to be the first byte of valid MPE packets.

The eight bit wide output 20 from the PID detector is fed into the DSMCC framer, item 21 . This output 20 has been stripped of DVB headers by the PID.

The ingress MPE packets to the framer 21 are comprised as follows: Each has twelve (12) MPE Header bytes. The first byte of the Header is a hexidecirna! 3E and the second and third bytes are the length. After the Header there can be up to fifteen hundred (1500) bytes of an IP Datagram. The final four (4) bytes are Cyclic Redundancy Check (CRC) bytes. The maximum total number of bytes is 1 51 6. Of course, there can be fewer bytes.

The DSMCC framer 21 is responsible for extracting the length of the MPE section. Before this can be done, the first byte of every MPE section must be verified as hexidecimal 3E. If a first byte is not a 3E, then the associated packet is discarded and the process does not further process any bytes of that packet.

Once the first byte is verified to be a hexidecimal 3E, the next two bytes are cached as the length of the entire MPE section. Knowing the length allows DSMCC 21 to know when to stop sending data to the FIFO. In a preferred embodiment, the value of the length is set in a counter. Then the counter is counted down to zero. The end of the MPE section corresponds to the zero count. Since the design is a pipelined architecture (continuous flowing), the output of DSMCC 21 is simply what is inputted to the machine. The output 23 to the FiFO item 22 is a nine bit interface, unlike the input of the DSMCC 21 which is an eight bit interface. The ninth bit is added and is used to indicate to subsequent processors whether or not the byte is the first of an MPE packet. The ninth bit (highest order bit), is set to a binary "1 " in the first byte of the MPE packet as it is passed to the FIFO. If this bit is set to "1 ", the following processes know that the associated byte is the beginning of a packet. The ninth bit is set to a binary "0" in all bytes other than the first byte and last byte of a MPE packet. It is, of course, possible in an alternate embodiment to frame with zeros and have all other ninth bits set to one. That is just a reversal of the use of ones and zeros.

In a preferred embodiment when the length counter

decrements to zero, the corresponding byte should be the last byte of the MPE section. In the last byte of the MPE section, the ninth bit is also set to "1 ". It should be easy to see that the MPE section is framed by the "l "(s) in the ninth bit of only the first and last bytes of a section.

Thereby, the DSMCC framer marks the beginning and end of an MPE frame. The framed MPE output is sent to the FIFO which acts as a means to offer elasticity to the overall receiving machine. The FIFO 22 provides the buffer, between the Ingress and Egress processes. The ingress process is clocked by one clock and the egress process is clocked by a second clock. Clock 28 from the ingress processor clocks data into FiFO 22 and clock 29 from the egress processor docks data out of FiFO 22.

The data flow goes from FIFO item 22 to the Egress Processor item 24. The Egress Processor constantly checks to see if the empty bit on line 27 of FIFO 22 is set. If the empty bit is not set then the processor will begin to read the contents of FIFO 22. Egress Processor 24 also checks to see if the ninth bit, Bit D[8] of the first byte is set to a " 1 ". If the ninth bit is not set to a " 1 " this condition indicates that a FIFO overrun or error has taken place. In the event of such an overrun or error the processor will discard the contents of the FIFO 22 until the processor 24 detects a byte having

a ninth bit set to a "1 " and the first byte is a hexidecimal 3E.

When the start bit is found having a " 1 " in the ninth bit position the first byte is checked to see if it is a hexidecimal 3E. If the processor 24 detects a hexidecimal 3E in the first byte, it recognizes that byte as the beginning of a valid MPE section coming from FIFO 22. Next, the processor 24 reads the next two bytes which contain information indicating the length of the MPE section.

In a preferred embodiment, a counter is preset to the value of the length. The counter is then counted down until it reaches zero. During the countdown the processor 24 reads bytes from the FIFO one byte for each ciock pulse of the countdown. The counter should reach zero at a time corresponding to the reading of the last byte of the MPE section from FIFO 22. The processor 24 checks that last byte to see if it has a "1 " set in the ninth bit position, indicating that it is a vaiid last byte of an MPE section. If it is a valid last byte the MPE section is recognized as valid.

As the processor 24 reads a vaiid MPE section from FIFO 22, it sends it to an interfacing sizer process where the eight bit data bytes are reformatted to thirty-two bit words. When the last byte of the MPE section is found, a check is made to align the last long word to a thirty-two (32) bit word. Hexidecimal FF's are written

into any unoccupied bytes to ensure that all 32 bit positions are filled.

In the MPE transfer, two hexidecimal 3E bytes are placed into the first two memory slot locations to act as alignment fills.

The egress packets are comprised as follows: The first two bytes each consist of a hexidecimal 3E used as a Header PAD for

alignment. The next twelve (1 2) bytes are MPE Header bytes. Next are up to fifteen hundred (1 500) bytes of an IP Datagram, followed by four (4) bytes of CRC. If a full 1 500 bytes of an IP Datagram are present, the total number of bytes is 1 518. But the whole packet must also be divisible by 32 bits so it may be necessary to add fiiler bytes. As an example, assume that the total number of bytes is 1 518. Each byte has eight (8) bits. So, 1 51 8 times 8 bits equals a total of 12,144 bits. To insure long word (32 bit) alignment, divide 1 2, 144 bits by 32 bits which equals 379 and 1 6/32 indicating that 1 2, 1 44 is 1 6 bits short of being an even multiple of 32. In this example it is necessary to add two 8 bit bytes (equal to 1 6 bits) as fill. The processor can easily handle this process and supply the necessary number of fill bytes.

The egress MPE packets are typically stored in RAM in the MPE transfer formatter 25. From there, the packets are readable on output 1 6 at bus speed in a 32 bit wide format. Figure 3 diagrams processes performed by the DVB input processor 2. As can be seen, a check is made to see if the incoming Valid signal VLD is high. If yes, the bytes are forwarded to the synchronization detector 7.

Figures 4 and 5 and 6 outline a synchronization process, performed by the synchronization detector item 7.

Figure 7 illustrates a process performed by the PID detector, item 9. A check is made to see if a header has a PID configured to a predetermined pattern.

Figures 8 and 9 illustrate processes performed by the DSMCC/MPE Framer Item 21 .

Figures 10 and 1 1 outline processes performed by the Egress processor, item 24.

Figures 1 2 and 1 3 and 14 illustrate processes performed by MPE Transfer Formatter, item 25.

Figure 1 5 shows a digital video broadcast satellite for the efficient transport of Internet Protocol (IP) data. Coder multiplexer 50 receives Video and Audio inputs and codes them into a DVB transport stream. It aiso receives IP data which is coded by Multiprotocol Encapsulation and multiplexed into the DVB transport stream. That stream is transmitted by transmitter 51 to satellite 52 which retransmits it to receiver 53. Transport packets from 53 are sent to demultiplexer 54.

The demultiplexer discards all video MPEG packets and audio

MPEG packets and fill MPEG packets, creates a MPE/IP stream and

sends the IP data to the Ethernet 55. The election to intentionally discard the Video, Audio and Fill, permits a simpler system and results in a streamlined design which yields significantly higher data transmission rates.

Figure 1 6 shows a digital wireless service system for the efficient transport of Internet Protocol (IP) data. Encoder multiplexer 60 receives Video and Audio inputs and codes them into a DVB-B transport stream. It also receives IP data which is coded by Multiprotocol Encapsulation and Multiplexed into the DVB-B transport stream. That stream is transmitted over the digital wireless service system generally indicated by item 61 . LMDS/MMDS stands for Loca l Multi poi nt Distributi on Services/Multichannel Multipoint Distribution Service. The transport stream is received by receiver 63. Transport packets from 63 are sent to demultiplexer 64.

The demultiplexer discards ail video MPEG packets and audio MPEG packets and fill MPEG packets, creates a MPE/IP stream and sends the IP data to the Ethernet 65.

Figure 1 7 shows a digital terrestrial service system for the efficient transport of IP data. A cable system is an example of a terrestrial service s /stem. Encoder Multiplexer 70 receives video

and audio inputs and codes them into a DVB-C/T transport stream. It also receives IP data which is encoded by multiprotocol Encapsulation and multiplexed into the DVB-C/T transport stream. That stream is transmitted over the terrestrial service system generally indicated by item 71 . The transmitted Transport Stream is received by receiver 73. Transport packets from 73 are sent to demultiplexer 74.

The demultiplexer discards al! video MPEG packets and audio MPEG packets and fiil MPEG packets, creates a MPE/IP stream and sends the IP data to the Ethernet 75.

In a preferred embodiment the input processor 1 and the output processor 26 are implemented using a FPGA on a single chip. The FIFO is on a second chip. In one embodiment, an ALTERA FPGA mode! number EPF10K30A C208-3 was used to implement the input and output processes. The FiFO was implemented using a 4K Byte Cypress number CY7C4241 V-25AC.

Although the invention has been described in connection with a preferred embodiment, it should be appreciated that numerous adaptations and modifications may be made thereto without departing from the spirit and scope of the invention as set forth in the claims.

Claims

WE CLAIM:

1. A system for demultiplexing a DVB input stream comprising: a synchronizer for synchronizing the stream; a packet identifier detector for scanning the stream and detecting a match between an incoming packet identifier and predetermined packet identification to filter out unwanted DVB

packets, to produce a multiprotocol encapsulated data stream.

2. A system as in claim 1 further comprising a framer.

3. A system as in claim 2 further comprising a first in first out

memory.

4. A system as in claim 3 wherein the said synchronizer and framer are on a first chip and said first in first out memory is on a second chip.

5. A system as in claim 1 wherein the synchronization detector continuously determines whether the demultiplexer is in synchronization.

6. A system as in claim 1 wherein the synchronizer produces an in-sync signal to indicate that a state of synchronization exists.

7. A system as in claim 6 wherein further processing will not occur until an in-sync signal is produced.

8. A system as in claim 6 wherein the in-sync signal will be produced after the detection of synchronization of each of at least /4727

three successive DVB transport packets.

9. A system as in claim 1 wherein the said predetermined packet

identification is changeable by programming.

10. A system as in claim 1 wherein the Multiprotocol Encapsulated data stream is reformatted to contain bytes having thirty-two bits.

11. A system as in claim 10 wherein the input DVB input stream is clocked with a first clock and the thirty-two bit bytes are clocked with a second clock.

12. A DVB processing system comprising: a DVB packet identifier; an input for said packet identifier providing a DVB transport sucαin CutiLαiπi viucu, aUulG emu uaw irin-M JilciuOi i,

cait OUiμuL TOi SαiQ μ<3 , ct. IGciiuiici pi uVi y UdLα n it on i tα uGPi, said packet identifier being operative to discard all said video and audio information.

13. A system as in c.ai -urtner comprising a reformatter to convert an eight bit wide data format to a thirty-two bit wide

•£^•-•^^4-

IUI I I l<3L.

14. A system as in claim 13 wherein the synchronizer is clocked by a first clock and the reformatter is clocked by a second clock.

15. A system as in claim 2 wherein the framer frames eight bit wide Multiprotocol Encapsulated packets by adding a ninth bit to each byte.

16. A system as in claim 1 5 wherein a first byte and a last byte of each packet contains a binary one in the ninth bit and all other ninth

bits are set to zero.

1 7. A system for transporting Internet Protocol data using digital video broadcast systems comprising: a broadband transmission system; a coder/multiplexer receiving Video, Audio and Internet Protocol Data and encoding the Video and Audio into a DVB transport stream; said encoder also encoding the Internet Protocol Data using Multiprotocol Encapsulation and multiplexing it into the transport stream; a transmitter for sending the DVB transport stream to the broadband transmission system which retransmits it to a receiver; said receiver sending transport packets to a demultiplexer which discards the Video and Audio and outputs a MPE/IP stream.

1 8. A system as in claim 1 7 wherein the broadband transmission system includes a satellite.