WO2001061988A2

WO2001061988A2 - Multi-protocol data receiver for satellite to local area network connection

Info

Publication number: WO2001061988A2
Application number: PCT/US2001/004823
Authority: WO
Inventors: J. Mitchell Robinson; Michael J. Beeler; Frank Huebner
Original assignee: Viacast Networks, Inc.
Priority date: 2000-02-15
Filing date: 2001-02-15
Publication date: 2001-08-23
Also published as: WO2001061988A3; AU2001238299A1

Abstract

A multi-protocol Internet packet data receiver for signal source to local area network connection includes an integrated receiver decoder (19), an L-Band receiver decoder module (27), a converter personality module (21), a local area network router processor (23), and a connection to a local area network (25).

Description

MULTI-PROTOCOL DATA RECEIVER FOR SATELLITE TO LOCAL AREA NETWORK CONNECTION

Background of the Invention:

The present invention is directed to Digital Video Broadcast (DVB) data receivers serving a Local Area Network (LAN), such LAN being a subnet such as an Ethernet system.

The invention more specifically is directed to such a receiver which incorporates router

architecture.

DVB Internet, television, and other data information is generally broadcast over

various transmission medium, such as satellite (DNB-S), cable (DNB-C) and terrestrial (DNB-B), using MPEG-2 (Moving Pictures Expert Group) data transmission standards. These DNB systems have been used to carry Internet Protocol (IP) data.

While MPEG standards range from 1 to 4 (for the first through fourth standard agreed upon - MPEG-1 through MPEG-4), the MPEG-2 standards are currently most widely used. The MPEG-2 transport stream is specifically designed for transmission in conditions that can generate data errors. MPEG transport packets each have a fixed length of 188 bytes (8-bit

bytes). The syntax and semantics of a MPEG-2 transport stream are defined in the joint

International Organization for Standardization (IOS) and International Electrotechnical Commission (DEC) standard 13818-2. Accordingly the first byte is a synchronization byte have a unique 8-bit pattern (01000111) and is used to locate the beginning of each transport

packet. Following the sync byte is a 3 -byte prefix which includes a 1-bit transport packet error indicator, a 1-bit payload unit start indicator, a 1-bit transport priority indicator, a 13 -bit

Packet Identifier (PID), a 2-bit transport scrambling control, a 2-bit adaptation field control, and a 4-bit continuity counter. There are up to 184 bytes left for payload which carries the data to be communicated. An optional adaptation filed may follow the prefix for carrying both MPEG related and private information of relevance to a given transport stream or the elementary stream carried within a given transport packet. A Program Clock Reference (PCR) and splicing control are typical information carried in the adaptation field. This encapsulation with the associated data facilitates re-multiplexing and network routing operations. In some previous systems, the lower 9-bits of the 42-bit PCR provide a modulo- 300 rollover, that is incremented at 27MHz (the system clock rate).

Packet is a data bundle, usually in binary form, organized in a specified way for transmission. Depending upon the specific native protocol of a data network, this organized data bundle may be called a: packet, block, frame or cell. The first section of the stream of every packet is the header information including synchronizing bits, destination or target device address, origination address, packet length. The second section is the data text or payload. The payload may be fixed in length (e.g. X.25 packets and ATM cells), or variable in length (e.g. Ethernet and Frame Relay frames). At the end of the packet stream is the third section called the trailer which contains an end of packet byte, and error detection and correction bits. Often Reed Solomon encoding for Forward Error Correction (FEC) is utilized. Generally audio data is transmitted in medium speed data streams and video data is transmitted in high speed data streams.

Existing communications systems have each utilized a transmission decoder, known as a Transport Stream Demultiplexer (TSD). The principal function of the TSD is to specify the delivery of the bits in time. With MPEG-2 and with other standard TSDs, information such as the PTS is able to point to presentation units (i.e., 8-bit bytes of data presented to the decoder) at a resolution of 11.1 microseconds. This rate results from the 90kHz rate established by the upper bits of the PCR count used to produce the PTS. The input stream to a TSD is pure DNB-S or DNB-C signal and the output is audio, video, teletext, and MPE/TP (Multi-Protocol Encapsulated format, Internet Protocol) transport stream (packet payload plus other components). For communications systems feeding a subnet, such as an Ethernet, a router unit is utilized. Routers have been implemented by general purpose computers, such as PC's. The utilization of a PC has presented some drawbacks because of their inherent mean time between failures (MTBF), and because of their size (i.e., the real estate needed to meet storage and processing capacities). Often PCs operate with WindowsNT^® or other operating system (OS) for server based requirements. While many of these are powerful general purpose operating systems, as a communications device they are less adequate.

Internet Protocol (D?) routers examine only those data packets addressed to it. The router confirms the existence of a destination address as well as the latest information on available network paths to reach that destination, if provided by the subnet system provider. This may entail changing header information. The overall task complexity of an IP router is not great, but the tasks must be completed and repeated at a high rate of speed necessary to meet the demands for increasing data transmission speeds.

In the past, many of these circuits have been implemented with transmission-specific hardware circuitry to build a receiver to subnet system. The individual circuit components have been connected together with cabling. A resulting system has been relatively large and expensive.

For the system to be changed to meet other transmission standards or new subnet client (customer) requirements, design specific circuitry has had to be substituted into the system. With PC implemented routers (subnet servers) changes would be made in the server by reprogramming. However, the drawbacks of using PC's is well known.

What is desired is a DVB data receiver for servicing a LAN subnet which DVB receiver has dedicated hardware of reduced size and power requirements.

What is further desired is a such a receiver which includes a programmable Internet Protocol data router for routing packets to a LAN subnet connected thereto. What is even further desired is that such receiver have a universal input for receiving any one of the various DVB synchronous data formats.

Additionally what is desired is to provide a de-encapsulation format which enables the router to universally process the packets regardless of original data format. Summary of the Invention:

The objectives of the present invention are realized in a receiver system for servicing a Local Area Network (LAN), such as an Ethernet (subnet) with Internet, television, and other types of audio/ video information data received, in Digital Video Broadcast from satellite (DVB-S), or cable (DVB-C), or Microwave Multi-point Distribution System/ Local Multi- point Distribution System (MMDS/LMDS) data (DVB-S), in any one of commonly known synchronous formats, such as RS 530, ASI (asynchronous serial interface), L-Band, TTL (transistor-transistor logic), LVDS (low voltage differential system), or other known interface which carries DVB.

The system includes an Integrated Receiver Decoder (IRD) which is connected to a satellite antenna or Inter Facility Link (IFL) or low noise block (L-Band) signal source. This circuit detects the synchronization byte in the header of each data packet and synchronizes the further movement, i.e. downstream processing of the data stream packets with the system clock. The output of this circuit is connected to a hardware implemented personality module (PM) which is specific to the data format selected to be received (RS 530, ASI, LVDS, TTL, L-Band, etc.). Each specific personality module is mechanically interchanged into the system to comply to the data format selected. Each personality module provides noise isolation and signal conversion to 8-bit parallel (byte wide) TTL connection.

A router circuit is implemented with a printed circuit board mounted microprocessor. The output configuration from the personality module permits the use of a high density card edge (HDCE) 112 pin connector interface with busses on the microprocessor card. This contributes to a reduction in size and footprint for the entire system.

At the front end of the router microprocessor circuit is a Transport Stream Demultiplexer (TSD) which can be implemented in hardware or software. This TSD forms an interface between the personality module (PM) output and the microprocessor input. The TSD converts DVB formatted data to Multi-Protocol Encapsulated (MPE) data, with the MPE specification being defined by IS O/IEC specification 13818-6[5] et al.

The microprocessor routes the data stream packets to a LAN subnet to which it is connected. Because the microprocessor operates upon MPE data, there is no need to reconfigure the microprocessor when the system is converted to another data format.

The microprocessor circuit stores a plurality of configuration programs for configuring a portion of the TSD to a specific data format. A customer application program is loaded into high speed peripheral storage connected directly to the microprocessor. This application program can contain client information, subnet configuration information, and other information used to perform the routing functions and any desired system housekeeping functions.

The router microprocessor is connected to the subnet (LAN) through an Ethernet card. Description of the Drawings:

The features, advantages and operation of the present invention will become readily apparent and further understood from a reading of the following detailed description with the accompanying drawings, in which like numerals refer to like elements, and in which:

Figure 1 is a general block diagram illustrating the principal circuit functions of the Multi-Protocol Encapsulation receiver system of the present invention;

Figure 2 is a detailed block diagram of the circuitry to implement the receiver system; Figure 2a is a circuit block diagram of a personality module; Figure 3 shows the logic flow for the decisions conducted by the FPGA input processor (DSMCC/ MPE processor - digital storage media command and control to multiprotocol .encapsulation);

Figure 4 shows the logic flow for the decisions conducted by the FPGA output processor;

Figure 5 is a decision chart for MPE formatting;

Figure 6 is a logic flow chart for the boot-up program for the core microprocessor controlled portion of the receiver system;

Figure 7 is the logic flow for the data format decisions implemented by the configuration program software including the initialization of the TSD circuit;

Figure 8 shows the logical decisions for the software in the transition from TSD to run time processing of incoming data packets in the router;

Figure 9 shows the logic flow for the decisions implemented by the router software; and Figure 10 shows the Ethernet card transmission to subnet connection.

Detailed Description of the Invention:

A receiver system 11 (Fig 1) receives Digital Video Broadcast (DVB) information 13 in a packetized data stream through cabling 15 (IFL 15) from a satellite antenna 17 or from another Inter Facility Link (IFL) which is not shown. The DVB information 13 is formatted to MPEG-2 standards, and can be in any one of standard transmission synchronous data formats, i.e., RS 530 (including RS 422), ASI, LVDS, TTL, L-Band (low noise block signal), Synchronous Parallel Interface (SPI), including a P 1284 parallel printer output, and other known data formats. An Integrated Receiver Decoder (IRD) 19 is connected to the cable 15. This IRD 19 is a commercially available circuit from such manufacturers as RCA, Dish Net Corp., Sony

Corporation, Scientific Atlanta, hie, Motorola Corp. and General Instruments Co. As an

example, the IRD 19 is implemented with a General Instruments Model DSR 4200V. The data stream output from IRD 19 is sent to a hardware Personality Module (PM)

21, which is selected specific to the transfer configuration of the data format being processed

(i.e., RS 530 etc.).

A low noise block (L-Band) personality module circuit 27 is also connected to the cable 15 to pass L-Band signals onto the PM 21. L-Band module 27 (L-Band tuner) is commercially available under its generic identification from the above- recited suppliers, including General Instruments Co.

The PM 21 converts the signal format to digital TTL signals. For the various data

formats, conversions are performed according to the following table:

TABLE 1

RS 530 balanced transfer configuration to digital

(RS 422) (serial)

TTL TTL (digital) to TTL (byte wide stream)

ASI 270 MBS high speed digital/ serial to TTL (byte wide stream) L- Band high speed analog carrier to TTL (byte wide stream)

LVDS low voltage differential system to TTL (byte wide digital stream)

TTL TTL digital to TTL digital (byte wide stream) (Quantum)

SPI Parallel output to TTL (byte wide stream)

P1284 Parallel printer output to TTL (byte wide stream)

The output of the personality module (PM) 21 is a HDCE (high density card edge) 112

pin connector. This HDCE connector mates with a complementary connector on the router processor circuit 23. This router processor circuit 23 includes a Transport Stream Demultiplexer (TSD) function structure and a router function structure. A microprocessor engine (router function structure) in this router processor circuit 23 is available in the marketplace from Net+Arm Technology, Inc., such as Model Net+Arm 12, a 32 bit microprocessor. Its clock can be set to operate between 1 12MHz and 36.8MHz, with a nominal value of about 25MHz. This microprocessor will be referred to below as the "Net Core" or "Core" and operates on processing Internet Protocol (IP) data. The output of the IP router processor circuit 23 is connected to the local area network

(LAN) 25 which is serviced by the router circuit 23. Software programs 29 are loaded into memory on the router circuit 23 board.

The byte wide HDCE 112 pin interface input to the circuit 23 has 8 data pins and a number of control pins for parallel operation, and a clock and data pins for serial operation. These control pins include, mimmally, a clock (byte clock), a start indicator (system time clock), a valid indicator (VLD), and an Error Indicator (El). The serial mode interface of the HDCE has a data pin and a clock pin. In the serial interface configuration, the data is passed accompanied by a bit clock. A de-serializer is utilized. It takes the input clock and data and converts all data to parallel format. The formatting is done by correlating an 0x47 synchronization byte, or 0xB8H PRBS (pseudo random bit sequence/ pattern) is used in the serial stream for determining that with every 188 bytes, the 0x47 synchronization byte recurs periodically.

The receiver system circuitry 11 of Figure 1, is shown in greater detail in Figure 2. The DVB information 13 is cabled 15 from the antenna 17 to the Integrated Receiver Decoder (IRD) 19. The output from the IRD 19 is connected to the signal format Personality Module (PM) 21. The L- Band module circuit 27 (L-Band tuner) provides a parallel path to the PM 21 for low noise block signal which is not passed through the IRD 19. These components are as described in connection with Figure 1. The data stream speed at the Personality Module is determined by the input clock rate from the IRD 19 or the L-Band received signal, depending upon the data format implemented. The output from the PM 21 is connected to a Field Programmable Gate Array (FPGA) circuit 29, Figure 2. This FPGA 29 has a dedicated First-In-First-Out shift register (FIFO) 31 connected thereto for bi-directional exchange of information therewith. The FIFO 31 is a slave to the FPGA 29 circuit and holds data for an output processor resident as part of the FPGA 29 structure. The FPGA 29 is commercially available from Altera Corporation and is implemented with an Altera (ALTR) Model EPF10K30QC208-3 unit. It has an input processor and output processor resident therein which are programmed in Altera High Level Design code (AHDL).

A FLASH loaded, Program Flash Chip (PFC) 33 holds code for programming the FPGA 29 for the particular synchronous data format being processed (i.e., RS 530, et al.). The programs 37 containing application and configuration information and instructions, are dumped from the PFC 33 to a core microprocessor 35, under a load signal 39 generated from that core microprocessor 35. Microprocessor 35 is the Net+Arm model identified above.

The FPGA 29 and FIFO 31 implement a Transport Stream Demultiplexer (TSD) function. The output from the TSD, i.e. the output from FPGA 29, is sent to the core microprocessor 35, and is a 32 bit parallel signal with a clock address and an interrupt instruction byte. This 32 bit signal contains the multi-protocol encapsulated data input to the routing core microprocessor 35.

In addition to performing the routing functions for servicing the LAN 25 (of Figure 1), the core microprocessor 35 performs the control operations for the loading FPGA 29 and the initialization of FIFO 31. An application file program and a configuration file program are held in the Program Flash Chip 33. These programs are loaded 37 into the core microprocessor 35 at system start up. Included within the configuration file information are P addresses and other user information. The program load signal 39, at system start up (boot) is sent directly from the core microprocessor 35 under control of a boot-up program (boot file) to the Program Flash Chip 33. This causes the application and configuration file programs 37 resident in PFC 33 to be loaded into the core microprocessor 35. The core microprocessor 35 then loads the FPGA code 41 which includes the initialization 43 of the FIFO 31 and the ingress (input) and egress (output) processors resident in the FPGA 29 structure.

The Program Flash Chip 33, which can be implemented with an FLASH device, is loaded with firmware FLASH loader 45. A terminal interface structure 49 is connected to the core microprocessor 35 for an operator to read system configuration and status conditions. This terminal can optionally included both a key pad and a LCD display.

The core microprocessor 35 uses an external 16 Meg dynamic RAM (D-RAM) module 51. An RS 232 port 47 is resident on the microprocessor 35 for receiving remote inputs 53. The output of the core microprocessor 35 is connected to an Ethernet 10/100 Base- T port 55 first through a buffer 57, and then through an Ethernet interface circuit 59. Core microprocessor 35 has resident therein a boot file 61 loaded into the core microprocessor from the Program Flash Chip 33.

The PM 21 is implemented as shown in Figure 2a. A coupler and isolation circuit 20 is selected according to the signal format being received. This device is known in the art, and can include the appropriate connector, a transformer, and other device. The output from this coupler and isolation circuit 20 is sent to a receiver/ driver which separates the various components of the signal into a TTL signal with pin configuration according to accepted electronic institute and committee standards. Each output pin includes a driver circuit for increasing signal strength. Noise filtering in included as needed.

An individual PM 21 is configured for the particular data format (signal format) selected to be processed. Various PM configurations can be mechanically substituted in to the system. The signal output pin configuration for the PM 21 meets the published standards of

Table 2.

TABLE 2

TTL IEEE and EIA standards for TTL P1284 IEEE standard for P 1284

LVDS SMPTE standard for LVDS

SPI MPEG specification CCIR 601/602

ASI MPEG DVB specification

L-Band ETSI standard 421 (EN300421) RS 530 EIA/TIA standards for RS 530

Data is processed through the FPGA 29 in modular format to allow each section of the array to process data in sequential order. In the first stage of the process, each packet is

synchronized with the system clock pulses.

The synchronization process determines whether a packet unit is in MPEG-2 synchronization. A packet synchronization byte is detected every 188 or 204 bytes as will be

discussed below in connection with the decision logic flow of the Altera High Level Design Language (AHDL) used in FPGA 29. As referred above, the synchronization byte is a hexadecimal 47H or B8H character. A lack of synchronization will inhibit (not allow) the

next stage of the process. Until three successful synchronization predictions are received

(using the sync detection algorithm), the process will not transition. Once three predictions

are detected the process continues and synchronization is checked continually. If at anytime synchronization fails, the packet data is stopped and discarded.

In the next stage, the Program Identifiers (PIDs) are deleted (from the Program

Elementary Stream). Fill PIDs are used to ensure the transport stream always transmits data at 100% capacity for the configured data rate. Unwanted PDDs are removed by performing a logical AND to determine whether the packet being processed has a PID which should be sent to the next stage. The process utilizes a delay line architecture to store the header of a packet to ensure that the condition of the leading bytes can be used to determine whether the packet is to be processed or discarded.

Once the status of the delayed bytes is checked, a PID detection register, match register and push register resident in the FPGA 29 must all equal "1" before data is passed to FIFO 31. The push register determines if no packet is currently being processed. When the push register is "1," the pointer field in the header is checked. If the pointer field is not zero, the value is moved to a counter and the delay line is extended until the counter decrements to zero. When the counter is zero, each data byte is sent to the next stage.

Data is passed onto the succeeding stage in order to keep the count in the delay line below 187 bytes. If the count reaches 187 bytes processing stops.

Resident as part of the FPGA 29 circuit is an input processor and output processor. The FPGA 29 output processor allows data from its input processor to be stored in an elastic storage within the circuit until the output processor can pull data from the FIFO 31. The FPGA 29 output processor runs at a higher clock speed than its input processor, and has a bus width at least four times as large as its input processor.

The FPGA 29 input processor begins processing data when the D[8] bit of a packet is high. Upon this condition, the FPGA 29 output processor begins reading data from the FIFO 31 at the system clock speed. This continues until the D[8] bit is again high. The confines of packet payload defined by these two markers is less than 1518 bytes. If a packet is found to be more than 1518 bytes, it is discarded.

The FPGA 29 output processor performs the MPE transfer formatting once the following checks have been verified: a) first byte of the packet is 0x3E; and b) entire packet is less than 1518 bytes marked by the D[8] bit. A packet is then delayed by two clock cycles and then two additional bytes are pre-appended to the header as 0x3E3E to assist in byte alignment to the input buss of the core microprocessor 35. A counter is set with the new packet length to be sent out from the FPGA 29 output processor. The entire packet is sent to a long word alignment to move the format from an eight bit format to a 32 bit format (four bytes wide). The contents are held in storage in the FPGA 29 and an interrupt signal is sent to the core microprocessor 35. The logic decision flow for the program performed by the FPGA 29 input processor

30 is shown in Figure 3. The circuit first inquires if the packet in process has a counter still running, step 32. If no, it then determines if the Program Unit Start Indicator (PUSI) bit is equal to "1," step 34. If no, it reiterates back to step 32. If yes, then the MPE length is read and stored, step 36. Thereafter the packets are read and the counter is decremented, step 38. Step 38 is performed if the determination in step 32 was a yes.

After step 38, Figure 3, the program determines 40 if the byte being read is the first or last byte of an MPE packet, step 40. If no, then the FIFO bit D[8] is set to "0," step 42. Thereafter the FPGA input processor looks to the FIFO 33. In step 40, if the determination is yes, then FIFO bit D[8] is set to "1," step 44, and the input processor looks to the FIFO 33. The FPGA 29 egress (output) processor 46 receives an input from the FIFO 33, Figure

4. It then determines if an empty flag was set, step 48. If yes, the process iterates. If no, the program determines if a packet (data packet) is being processed 50. If yes, the program determines if the FIFO bit is "0," step 52. If no, the program returns to step 48. If yes, the counter is decremented for each byte, step 54. If the answer to step 50 is no, there is no data packet in progress, it is then determined if the FIFO bit D[8] is equal to "1". If no, the program returns to step 48. If yes, the length of the packet is read, step 56. Thereafter, the counter is decremented for each byte, step 54. Both the counter value and the FIFO bit D(8] are monitored 58. If the counter is 11011 and the bit D[8] is "1" the process goes to the MPE Transfer formatter 60. If they are not, the process returns to step 48. The MPE formatter process 62, Figure 5, first sends the first two bytes of a packet through the system as Hex 3E3E, step 64. It then reads the number of bytes to be sent for the packet, step 66. Ifthe first byte of the egress word is empty, step 68, it fills the first word, step 70. Ifthe first byte of the egress word is not empty 68, the process then determines ifthe second byte is empty, step 72. If yes, it then fills the second word 74. The process then determines ifthe third by of the egress word is empty, step 76. If yes, it fills the third word, step 78. If no, it fills the last word, step 80.

Following each of the word filling steps 70, 74, 78, 80, the process inquires if there are more bytes, step 82. If yes, it returns to step 68. If no, it determines ifthe last byte of a long word is filled, step 84. If no, it fills the remaining bytes of the long word, step 86. If yes the program issues an interrupt and sends the packet, step 88 on to the microprocessor 35.

When the interrupt is serviced by the core microprocessor 35, it will begin reading the data from the FPGA 29 output processor. As each 32 bit word is read out, the FPGA 29 output processor decrements its counter and begins freeing memory for the next packet.

When the counter reaches zero, the FPGA 29 output processor memory is empty. In the event the FPGA 29 output processor is slow in reading the contents of its memory and the FIFO 31 is filling, the packet is discarded and the memory purged to begin with the contents of the next packet. The core microprocessor 35 receives the 32 bit data, these being the MPE formatted packets. The format of an MPE packet is shown in Table 3. h operation, the core microprocessor 35 verifies the received length of a packet against the actual (intended) length of the transport packet. Ifthe two lengths differ, the packet is discarded, once a packet is received by the core microprocessor 35, the MPE headers are removed and the data is passed to the routing function (module portion) of the core microprocessor 35. ,E 3

Syntax Size Value

(bits)

DBN_Datagram_Section () { table_id 8 Set to Ox3E

DSM-CC provate data section section_syntax_indicator 1 Default to "1" (= CRC in use) private_section_indicator 1 Default to "0" Reserved 2 Set to "11" section_length 12 Depends on selected format options

Up to 1284 for Ethernet ouput option

Up to 1528 for ASI/SPI output option

(assuming Ethernet input to IPE

MAC_address_6 8 LS Byte of destination MAC address

MAC_address_5 8

Reserved 2 Set to "11" payload_scrambling_control 2 "00" = no scrambling (default)

"01" = odd control word scrambling "10" = even control word scrambling address_scrambling_control "00" = no scrambling (default) "01" = odd control word scrambling "10" = even control word scrambling

LLC_SNAP_flag Default to "0"

(= no LLC/SNAP encapsulation) current_next_indicator Set to "1" section iumber As per ETR 211 (DVB SI-DAT) Set to "0" (=no fragmentation) last_section_number As per ETR 211 (DVB SI-DAT) Set to "0"

MAC_address_4 MAC_address_3 MAC_address_2 MAC_address_l MS Byte of destination MAC address

If (LLC_SNAP_Flag = "1") { LLC 24 If used then set to 0xAAAA03 OUI 24 If used then set to 0x000000 (= Ethernet input datagrams)

Protocol 16 If used then set to 0x0800 (SNAP fo riP data (RFC 1700)) In this fast routing module portion, the following decisions are made. If a unicast address is determined to be on "my" net, the packet is sent to the microprocessor's control portion for internal processing. If a unicast address is read as on "my" subnet, but is not the processor's address, the core microprocessor 35 then checks to see that an Address Resolution Protocol (ARP) entry exists. If an ARP entry exists, then an Ethernet packet is built and sent to the Ethernet. If no ARP entry exists, then a process is started to get the ARP resolved. If the ARP cannot be resolved, the packet is discarded. Ifthe unicast address read is not on "my" subnet, the packet is discarded. Ifthe unicast address is not on "my" subnet, the address resolution protocol is loaded for a gateway. If a defined gateway does not exist, the packet data is discarded, and if it does exist the packet is built and sent to the Ethernet.

If a multicast address exists and no IGMP (Internet Group Management Protocol) multicast routing is enabled, the packet is built and sent to the Ethernet. If a multicast address exists and IGMP is enabled, then it is determined that a subscriber must be requesting to be a part of the multicast group to receive the data, and the packet is built and sent to the Ethernet. The core microprocessor 35 has an embedded operating system which is programmed in the C family of languages. The decision logic for the boot file 61 program is shown in Figure 6. It includes checking 63 for images (FPGA configuration code instructions) in flash chip memory 33. The set of images is displayed 65. After a wait 67 of about 5 seconds for any key to be pressed by the operator, the software asks 69 if a key has been pressed. If a key has been pressed, boot dialog is started 71. Included in this boot dialog 71 is the displaying 73 of flash contents, the downloading 75 of a new image (FPGA code), and displaying a program start 77. The step after displaying a program start is the generation of the start program load signal 79.

If a key has not been pressed the software interrogates 81 if a valid set of images is present. If not, the program goes into the boot dialog step 71. If a valid set of images is present, then the start program load signal is generated 79. This step 79 causes the microprocessor 35 control to leave the boot file program.

The decision logic for the operation of the core microprocessor 35 under the configuration file and application file software programs is shown if Figures 7, 8 and 9. Of these figures, Figure 9 shows the routing logic.

The information stream is interrogated, Figure 7, to determine the data format depending on the FPGA 29 code detected by the core microprocessor 35 query of the FPGA 29 (microprocessor 35 polls FPGA 29). The program interrogates ifthe type of FPGA code is: TTL, step 83; ASI, step 85; SPI, step 87; RS 530 serial, step 91; P1284, step 89; LVDS, step 93; L-Band, step 95; or unknown, step 97. As the program gets a negative (no) response to any of these, it continues the interrogation chain. If there is a "yes" to the serial format, RS 530, steps 91, the program sets up a serial clock and a serial data input, step 101, then sets up a serial to parallel conversion (in the FPGA code), step 103. Thereafter it initializes, step 105, the TSD. This step 105 is carried out by the core microprocessor 35 by it generating the load signal 39 to load the FPGA 29 code and initialize the FIFO 31 from the FPGA code, step 107. If ASI format is detected in step 85, Figure 7, the program, sets up a clock plus a data input and a validation whereby a valid envelope strobe looks at the valid bit in the packet header, step 109. Following this step 109, the process performs the initializing step 105 and the loading step 107, previously described. For a positive response from any of the remaining other decision steps 83, 87, 91, 93,

95, 97, or upon the completion of the initialization step 105, the microprocessor 35 transfers to then set the packet mode equal to "188" or "204", step 110, Figure 8. The microprocessor 35 process then checks for L-Band format, step 111. If there is no L-Band, it looks for an interrupt for the data from the TSD (FPGA 29 output), step 113. This looking for an interrupt, step 113, is performed iteratively until an interrupt is detected. If there is L-Band format detected, step 111, the process sets up a tuner frequency and symbol rate, step 115, and then returns to the main decision stream which next incurs step 113 described above. TSD processing 112 ends with steps 111 or 115. Run time processing 114 of data packets begins with step 113. Once an interrupt is detected, the MPE packet is read, step 117, and the microprocessor 35 goes to the routing program, step 119.

In the routing program 119, Figure 9, the system first looks for a unicast address, step 121. If there is a unicast address, it is then determined ifthe address is for "my" subnet, step 123. Thereafter the packet header is interrogated 125 to determine a "my" IP address is present. ("My designates the microprocessor system and the subnet - LAN - which it services.) If there is a "my" address, the particular internal task is performed 127, this task being any of a preselected group of tasks 129, such as initiating a web page, FTP server message, command operation, and others programmed into code.

If step 125 determines there is not an internal address, then the ARP is loaded 131, and the IP is interrogated 133 to determine ifthe Internet protocol is known or unknown. If it is unknown (there has been a processing error), the packet is dropped 135. If it is known, the program goes to starting the Ethernet transmission, step 137, and sends the packet to the subnet serviced.

If in step 123, the address is not on "my" subnet, the process loads 139 the ARP (address resolution protocol) gateway. It then determines if a defined gateway exists, step

141. If it does not, the packet data is dropped, step 135. Ifthe defined gateway does exist the process starts the Ethernet transmission 137.

If in the previous unicast address detection step 121, no unicast address is detected, the process interrogates if a remote command is present, step 143. If a remote command is present, it is determined if it is to this unit ("my" address), step 145. If it is not to this unit, the remote command data is dropped, step 135. If it is to this unit, the remote command is operated upon 147, and the appropriate predetermined housekeeping step is performed 149 (reset, change frequency, change bit rate, etc.).

In the previous step 143, if no remote command is present, an inquiry is made if there is an Internet Group Management Protocol (IGMP) enable signal, step 150. If no, the data is sent to the LAN with the start of the Ethernet transmission, step 137. If there is an IGMP enable, step 150, then a multicast condition is determined and the IGMP (Internet Group Management Protocol) server is activated 151. The activation of the IGMP server, causes the IGMP client list to be loaded into the server, step 153. Thereafter, a decision is made if an IGMP group enable is present, step 155. If this client enable is not present, the packet data is dropped 135. If this client enable is determined 155 to be present, the packet is sent to the LAN (subnet being serviced) with the start of the Ethernet transmission, step 137.

The Ethernet transmission 137 hardware, Figure 10, services the individual clients 157 connected to the network architecture 159. This architecture 159 also has connected to its default gateway or other ISP (Internet services provider) 161, and other types of known connections.

In its operation and structure, the present invention provides an advantage over prior systems which permits in the present invention, the use of a smaller, special purpose router microprocessor, thereby permitting the real estate and power consumption of the entire receiver system to be significantly reduced, as well as realizing a reduction is cost. The invention re-configures the process "blocks" of a receiver which receives DVB transmission stream information and distributes it to a LAN (Ethernet). By isolating (limiting) Multi- Protocol Encapsulation (MPE) to data only (packet payload), at the TSD output, the processing decoding and processing duties of the (downstream) routing microprocessor have been greatly simplified, and do not need to be changed for a change of format (i.e., between: L-Band, TTL, RS 530, LVDS, etc.).

Many changes can be made in the above-described invention without departing from the intent and scope thereof. Substitutions can be made while describing the invention in equivalent embodiments. It is thereby intended that the above description be read in the illustrative sense and not in the limiting sense.

Claims

What is claimed is:

1. A multi-protocol Internet packet data receiver for signal source to local area network connection, comprising: an integrated receiver decoder (IRD), connectable to a signal source, for receiving any of the following packet data format signals: TTL, ASI, SPI, P1284, RS 530 and LVDS; an L-Band receiver decoder module, connectable to a signal source, for receiving low noise block format (L-Band) packet data signals; a converter personality module (PM) comiected to the output of said integrated receiver decoder and to said L-band receiver decoder module, selected for the a specific signal personality for exclusively receiving one of said TTL, ASI, SPI, P1284, RS 530, LVDS, and L-Band data format signals, and for converting that signal format to a byte wide packet data format; a LAN router processor connected to the output of said personality module for de- ecapsulating the multi-protocol packet information received from said personality module into a uniform packet header format thereby providing multi-protocol encapsulation; wherein said LAN router processor also including a routing microprocessor for routing unicast and multicast packet data according to said multi-protocol encapsulation header information; and a local network circuit (LAN) connected to the output of said routing microprocessor and connectable to a network.

2. The receiver of claim 1, wherein said L-Band receiver decoder module is an L-Band tuner; and wherein said converter personality module includes a coupler and isolation circuit for receiving signals from said integrated receiver decoder and said L-Band tuner, and a receiver/ driver circuit connected to the output of said coupler and isolation circuit, said receiver/ driver providing TTL signal outputs according to the standards for the particular signal format selected.

3. The receiver of claim 2, wherein said LAN router processor includes: a field programmable gate array (FPGA) connected to receive said standard TTL signal outputs from said converter personality module receiver/ driver circuit; a first-in-first-out shift register (FIFO) connected to said FPGA for data transfer therewith; a program flash chip holding software for said routing microprocessor and code for said FPGA and initialization of said FIFO; and wherein said routing microprocessor is the "core" microprocessor for performing routing functions, said core microprocessor being connected on an imput to the output of said FPGA and on its routing output to said LAN circuit and to said program flash chip for receiving software therefrom.

4. The receiver of claim 3 wherein said LAN circuit includes: a buffer circuit connected to said routing output of said core microprocessor; an Ethernet chip circuit connected to the output of said buffer circuit; and a 10/100 Base-T port connected to the output from said Ethernet chip circuit.

5. The receiver of claim 4 also including a dynamic random access memory (D-RAM) connected to said microprocessor for bi-directional information exchange.

6. The receiver of claim 5 also including a operator terminal connected to said core microprocessor for initiating operation thereof.

7. The receiver of claim 6 wherein the software held in said program flash chip includes a boot file, an application file, a configuration file, FPGA code and FIFO initialization code; and wherein said core microprocessor includes a program load signal connection to said program flash chip and a data connection for receiving said boot file, application file, configuration file, FPGA code and FIFO initialization code upon a said program load signal.

8. The receiver of claim 7 also including a connection from said core microprocessor for loading said FPGA code and said FIFO initialization code received from said program flash chip into said FPGA, whereupon said FPGA loads said FIFO with said FIFO initialization code.

9. The receiver of claim 8 wherein said FPGA has resident as a part thereof and integral therewith an input processor and an output processor whereof data is processed therethrough in sequential order; whereof said input processor is programmed with said FPGA code to synchronize each packet with the system clock pulsed, for determining MPEG-2 synchronization by detecting a synchronization byte every 188 or 204 bytes, for gating a packet through if proper synchronization is detected, and then deleting Program Identifiers (PIDs) present and inserting predetermined fill PIDs; and whereof said output processor is programmed with said FPGA code to perform MPE transfer once it determines that the first byte of the packet is 0x3E and the entire packet is less than 1518 bytes marked by the D[8] bit, wherein after, the packet is delayed two clock cycles and then two additional bytes are pre-appended to the packet header as 0xE3E to assist in byte alignment to the input of said core microprocessor.

10. The receiver of claim 9 wherein under the operation of said FPGA code software, said FPGA input processor establishes a delay line architecture to store the header of each packet in said FIFO to ensure the leading bytes can determine ifthe packet is to be processed or not, thereafter a PID Detection, match detection and push condition must be enabled which sets up the position of the packet pointer field for proper alignment with data movement in synchronization with the system clock.

11. The receiver of claim 10 wherein said boot file includes instructions for directing said core microprocessor under the following processing steps: checking the FPGA code (images) configuration from program flash memory; displaying said images; waiting for a operator "key" instruction; entering a boot dialog when a key is pressed to display the program flash chip contents, down load a new image and start the receiving and routing program; and by passing boot dialog to go directly to program start, if a valid set of images is present.

12. The receiver of claim 11 wherein said configuration and application files include instructions for implementing the TSD and data MPE formatting to include the following processing steps: checking for data format being exclusively one among TTL, ASI, SPI, RS 530, P1284,

LVDS, L-Band, unknown; if RS 530, then setting up a serial clock and serial data input; setting up a serial to parallel conversion; initializing the TSD by loading FPGA code and FIFO initialization; and if not RS 530, then setting up the clock, data input and valid envelope strobe; and proceeding to said initializing the TSD step.

13. The receiver of claim 12, wherein after the initializing the TSD set the configuration and application files direct the following: setting a packet mode to 188 or 204; determining L- Band data format and if so, setting up the tuner frequency and symbol rate; if no L- Band, and after setting up the tuner frequency and symbol rate, then checking for an interrupt from the TSD, and in the presence of same reading the MPE packet; and passing onto routing.

14. The receiver of claim 13, wherein the configuration and application files direct the routing operation of the core microprocessor to include the following processes: determining ifthe data is unicast, and if unicast, then determining if it is to be sent to the receiver's ("my") subnet (LAN), and if so, if there is an IP address, and if so, performing the internal task; ifthe unicast data is not to "my" subnet, then loading address resolution protocol (ARP) ARP address/ gateway if enabled, and then determining if a gateway exists, if not then dropping the data, if yes then passing the data onto the LAN; and ifthe unicast data is not my IP address then loading ARP and determining if this is a known IP, if not dropping the data, if yes then passing the data onto the LAN.

15. The receiver of claim 14, wherein the configuration and application files also direct the operation of the core microprocessor to include the following processes: ifthe data is determined to not be unicast, then looking for a remote command, and if no remote command is present then determining if an IGMP enable signal is present; sending the data onto the LAN if IGMP enable is not present, but setting up an IGMP server on if an IGMP is present; loading IGMP client lists upon the set up of the IGMP server, and determining if an IGMP group enable is present; dropping the data if no IGMP group enable is present, and sending the data to the LAN ifthe IGMP enable is present.

16. A method of receiving DVB packet information and routing it to a LAN wherein the router need process only MPE data, comprising the steps of: receiving DVB transmission stream information (TSI) containing Internet packets; establishing a single data format decoder/ tuner for passing packets in that selected data format; converting the TSI passed through the decoder/ tuner to TTL standard format; converting the data payload portion of each packet to MPE data; and routing said MPE packet data according to routing instructions, system configuration, and client requests.

17. The method of claim 16, wherein the step of converting includes the steps of: demultiplexing the transmission stream packet information,; synchronizing its further movement to the system clock; and establishing a standard length of 188 bytes and alternately 204 bytes for the packet data length.

18. A selectable format DVB transmission receiver and router, having reduced router architecture requirements, for connecting to a LAN, comprising: a integrated receiver decoder, connected to said DVB transmission, for processing serial and digital formatted DVB transmission stream information containing Internet packets; an L-Band tuner, connected to said DVB transmission, for processing L-Band signal into a digitized form; a converter selected to match the selected format for DVB data format, connected to receive the outputs from said integrated receiver decoder and said L-Band tuner for providing a digital (TTL) signal according to the standard format for the format selected; a transmission stream decoder connected to said converter output for providing the payload portion (data) of each Internet packet in Multi- Protocol Encapsulated (MPE) format; and a routing microprocessor for routing each said MPE data containing packet to any of the LAN, another location, local LAN.

19. The transmission receiver and router of claim 18, wherein said transmission stream decoder includes: a Field Programmable Gate Array (FPGA), connected to the output of said selected converter; a FIFO connected to said FPGA providing a time delay function for said FPGA; and wherein said routing microprocessor receives MPE data containing packets for routing.

20. The transmission receiver and router of claim 19, wherein said FPGA and said router operation and configuration are established by firmware and software loaded therein.