WO2001080491A2

WO2001080491A2 - Assembling transport packets into ip packets using a clock signal from the transport stream

Info

Publication number: WO2001080491A2
Application number: PCT/US2001/012560
Authority: WO
Inventors: Augusto Cardoso; John Passmore
Original assignee: B2C2, Inc.
Priority date: 2000-04-18
Filing date: 2001-04-17
Publication date: 2001-10-25
Also published as: AU2001255444A1; WO2001080491A3

Abstract

One embodiment of the present invention provides a system that converts transport packets into Internet Protocol (IP) packets using circuitry that is driven by an incoming clock signal from the transport stream. The system operates by receiving a stream of transport packets along with an associated incoming clock signal at an interface module. Next, the system assembles an IP packet from a plurality of transport packets using circuitry that is driven by the incoming clock signal. Next, the IP packet is stored into a memory. Finally, the system sends the IP packet across a network to a destination IP address using circuitry that is driven by an interface module clock signal. This interface module clock signal is generated locally within the system containing the interface module. In one embodiment of the present invention, the system assembles a plurality of IP packets into a High-level Data Link Control (HDLC) frame. This reduces the number of interrupts caused in downstream systems because only a single interrupt is required to process a HDLC frame, even if it contains multiple IP packets, instead of an interrupt for each IP packet. Furthermore, the system periodically sends the HDLC frame with any IP packets are available to be sent, instead of waiting for a minimum number of IP packets. In one embodiment of the present invention, the system inserts wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

Description

ASSEMBLING TRANSPORT PACKETS INTO IP

PACKETS USING A CLOCK SIGNAL FROM THE

TRANSPORT STREAM

Inventor: Augusto C. Cardoso Jr. and John Loren Passmore

BACKGROUND ,

Field of the Invention

The present invention relates to computer systems and data transmissions. More specifically, the present invention relates to a method and an apparatus for converting transport packets into Internet Protocol (IP) packets using circuitry that is driven by an incoming clock signal associated with the transport stream.

Related Art

Internet users are presently demanding more bandwidth than can be provided with a conventional modem connection through a telephone line. The 56K data transfer rate provided by a conventional modem connection is not sufficient to rapidly transfer graphical images that are commonly incorporated into web sites. Hence, people browsing through web pages within websites are continually waiting for images to load. Furthermore, other data-intensive services, such as high quality streaming video, are essentially impossible to provide through a 56K modem connection. People are presently developing a number of alternatives to the standard 56K modem. DSL modems can provide high data transfer rates through existing telephone lines, but they require expensive modifications to the switching equipment inside telephone company central offices. Hence, DSL technology cannot be used without a major investment by the local telephone system, and some local telephone systems have been hesitant to make such an investment. Furthermore, in many cases a DSL modem cannot achieve a high data transfer rate if the telephone line to the telephone system central office is too long, or if the telephone line has poor quality wiring.

Cable modems can also provide high data transfer rates, but providing modem access through a cable network requires a significant investment in new equipment by a local cable company, and some local cable companies have been hesitant to make such an investment. Furthermore, some regions are not yet wired for cable.

Another option is to use satellite communications channels to provide high data transfer rates. Unlike DSL modems or cable modems, satellite communication channels are not under the control of local utility providers.

However, using satellite communication channels poses other challenges. In order for satellite-based systems to be successful, low-cost, high-performance receiving stations must be developed to receive the satellite transmissions. More specifically, a system must be developed to convert a stream of transport packets, such as a Motion Picture Experts Group (MPEG) 2 transport stream, into a form that is suitable for transmission over a local computer network, such as IP packets.

One problem in developing such a system is that the transport stream is arriving at a very fast clock rate, and the stream must somehow be captured and moved from the clock domain of the transmitting circuit into the clock domain of the receiving circuit without losing data. Once the transport stream is within the clock domain of the receiving circuit it can be more easily manipulated by local circuitry.

One way to capture the transport stream is by sampling it at a multiple of the original transmit clock frequency. Unfortunately, as the data rate of the transport stream increases, it becomes very hard to sample the transport stream at a higher frequency in an error-free manner.

What is needed is a method and an apparatus for moving a transport stream from the clock domain of the transmitting circuit into the clock domain of the receiving circuit in a reliable manner without sampling the transport stream at a multiple of the transmit clock frequency. After the transport stream is converted into IP packets, and possibly into High- level Data Link Control (HDLC) frames, another problem is encountered in forwarding the data to downstream systems, such as routers and computer systems. When IP packets or HDLC frames are received by downstream systems, they typically cause interrupts which can require a great deal of time to process. Consequently, downstream systems can be easily overwhelmed by a burst of IP packets or HDLC frames. This can cause the downstream systems to drop frames and/or packets.

Hence, what is needed is a method and an apparatus for forwarding data to downstream systems in a manner that does not overwhelm the downstream systems.

SUMMARY One embodiment of the present invention provides a system that converts transport packets into Internet Protocol (IP) packets using circuitry that is driven by an incoming clock signal from the transport stream. The system operates by receiving a stream of transport packets along with an associated incoming clock signal at an interface module. Next, the system assembles an IP packet from a plurality of transport packets using circuitry that is driven by the incoming clock signal. Next, the IP packet is stored into a memory. Finally, the system sends the IP packet across a network to a destination IP address using circuitry that is driven by an interface module clock signal. This interface module clock signal is generated locally within the system containing the interface module. In one embodiment of the present invention, the system assembles a plurality of IP packets into a High-level Data Link Control (HDLC) frame. This reduces the number of interrupts caused in downstream systems because only a single interrupt is required to process a HDLC frame, even if it contains multiple IP packets, instead of an interrupt for each IP packet. In one embodiment of the present invention, the system inserts wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

In one embodiment of the present invention, the stream of transport packets includes MPEG2 transport packets, and the incoming clock signal is a clock signal that is defined within the MPEG2 standard.

In one embodiment of the present invention, assembling the IP packet further comprises filtering of the plurality of transport packets based upon packet identifier

(PID) to filter out transport packets containing data that is not of a specified type for the IP packet. In one embodiment of the present invention, assembling the IP packet further comprises continuity checking to ensure that all transport packets that are assembled into the IP packet are received in sequential order.

In one embodiment of the present invention, the system filters IP packets based upon media access control (MAC) address to filter out IP packets that are not directed to an IP destination address on the network.

In one embodiment of the present invention, the IP packet is assembled using at least one finite state machine that is clocked by the incoming clock signal to manipulate a plurality of registers within the interface module.

In one embodiment of the present invention, the stream of transport packets is received from a satellite.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a system for communicating a data stream from a satellite to a computer network in accordance with an embodiment of the present invention. FIG. 2 illustrates the internal structure of an interface module that converts satellite transmissions into IP packets in accordance with an embodiment of the present invention.

FIG. 3 illustrates a finite state machine that converts transport stream packets into IP packets in accordance with an embodiment of the present invention. FIG. 4 illustrates how transport packets are assembled into a plurality of IP packets within a HDLC frame in accordance with an embodiment of the present invention.

FIG. 5 is a flow chart illustrating the process of converting transport stream packets into IP packets in accordance with an embodiment of the present invention.

FIG. 6 is a flow chart illustrating the process of sending HDLC frames to a destination in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

The data structures and code described in this detailed description are typically stored on a computer readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs) and DVDs (digital video discs), and computer instruction signals embodied in a transmission medium (with or without a carrier wave upon which the signals are modulated). For example, the transmission medium may include a communications network, such as the Internet.

Communication System

FIG. 1 illustrates a system for communicating a data stream from a satellite 101 to a network 120 in accordance with an embodiment of the present invention. Satellite 101 can include any type of broadcast satellite or communication satellite that is capable of sending a transport stream, such as a digital MPEG2 transport stream.

Server 1 18 transmits a signal 119 to satellite 101. Server 118 can include any computational node including a mechanism for servicing requests from a client for computational or data storage resources. In one embodiment, server 118 is a web server that hosts a web site. Not shown in FIG. 1 is the circuitry for converting an output from server 118 into a signal 119 suitable for transmission to satellite 101.

Signal 1 19 is forwarded from satellite 101 to satellite dish 105, which is coupled with interface module 103.

Interface module 103 converts the signal from satellite 101 into a digital form that can be manipulated by the computer system. Interface module produces two different types of output. The first output is a Peripheral Component Interface (PCI) output 107, which enables interface module 103 to communicate directly with a computer system through a PCI bus. The second output is a HDLC output 104, which provides a serial interface between interface module 103 and router 108. Router 108 can include any type of system, such as a hub or a router, that facilitates communications across a network.

In FIG. 1, router 108 is coupled to clients 122-123 through network 120. Network 120 can include any type of wire or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment of the present invention, network 120 includes the Internet. In the embodiment illustrated in FIG. 1, network 120 is a local area network. Clients 122 and 123 can include any node on network 120 including computational capability and including a mechanism for communicating across network 120. Router 108 is also coupled to modem 109, which provides a low-to-mid- bandwidth communication path to server 118. More specifically, router 108 communicates with network service provider 114 through modem 109 and telephone line 1 12. Network service provider 114 communicates with server 118 through network 120. Network service provider 1 14 can include any type of mechanism for linking modem 109 with network 116 through telephone line 112. Note that instead of using modem 109 and telephone line 112, the system can alternatively use any other type of communication pathway to server 118. For example, the system can use an ISDN linkage, a DSL linkage, a wireless communication channel, or a satellite communication channel. Network 116 can include any type of wire or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment, network 116 includes the Internet. In one embodiment, network 116 and network 120 are the same network. The system illustrated in FIG. 1 operates generally as follows. Clients 122-

123 communicate with server 118 through a high-bandwidth pathway through satellite 101 and a low-to-mid-bandwidth pathway through modem 109. The high-bandwidth pathway is used to transfer data, such as graphical images from server 118 to clients 122-123. The low-to-mid-bandwidth pathway is used to transfer commands and other input from clients 122-123 to server 118. This type of asymmetric arrangement is well-suited for applications such as web sites that send large volumes of data (such as graphical images) to clients, and yet receive only a small amount of data from the clients.

Using the high-bandwidth pathway, server 118 sends signal 119 through satellite 101 into interface module 103. Interface module 103 converts this signal into IP packets within HDLC frames and sends the frames to router 108. Router 108 extracts the IP packets from the HDLC frames and sends the IP packets across network 120 to clients 122-123.

Using the low-to-mid-bandwidth pathway, clients 122-123 send data across network 120 to router 108. Router 108 forwards the data to network service provider 114 through modem 109. Network service provider 114 forwards the data across network 116 to server 1 18. Interface Module

FIG. 2 illustrates the internal structure of an interface module 103 that converts satellite transmissions into IP packets in accordance with an embodiment of the present invention. Interface module 103 includes tuner 202 and demodulator 204. Tuner 202 can include any type of circuit that can be tuned to receive signals from a satellite (or any other high-bandwidth MPEG2 data stream). Demodulator 204 can include any type of circuit that can demodulate signals received from a satellite through tuner 202. Demodulator 204 converts the signal received from satellite 101 into a digital form, which is transferred across data lines 215 and control lines 217 into transport interface 210.

Transport interface 210 includes circuitry for receiving data lines 215 and control lines 217. Note that control lines 217 include incoming clock signal 219, which is part of the transport stream. In one embodiment of the present invention, transport interface 210 is an MPEG2 transport interface for receiving MPEG2 transport signals.

Transport interface 210 forwards signals through PID filter 212. PID filter 212 contains circuitry that filters transport packets based upon packet type. Some packets, such as NULL packets, are discarded by PID filter 212. Other packets are routed in different directions. For example, transport packets containing audio and video data are routed directly into memory 218. Transport packets containing tabular data are routed through table translator 214 to produce tables, such as table 223 within memory 218. Transport packets containing IP packets are routed through transport to IP converter 216, which converts transport packets into IP packets and stores the IP packets into memory 218. For example, FIG. 2 illustrates IP packets 220-222 within memory 218.

Next, IP packets 220-222 are retrieved by HDLC interface 230 and are forwarded through HDLC output 104. Note that HDLC interface 230 operates under control of interface module clock signal 221, which is locally generated within interface module 103 by clock generator 232. Hence, HDLC interface 230 operates within the clock domain 252 of interface module clock signal 221. In contrast, components that write IP packets into memory 218, including transport interface 210, transport to IP converter 216, PID filter 212 and table translator 214, all operate under control of incoming clock signal 219, which is received from demodulator 204 along with the transport stream. Hence, transport interface 210, transport to IP converter 216, PID filter 212 and table translator 214 all operate within incoming clock signal domain 250.

Finite State Machine

FIG. 3 illustrates a finite state machine 302 that converts transport stream packets into IP packets in accordance with an embodiment of the present invention. Note that the circuitry illustrated in FIG. 3 resides within transport to IP converter 216 from FIG. 2. Finite state machine 302 receives incoming clock signal 219 and data lines 215 from transport interface 210. Finite state machine 302 manipulates a number of registers within transport-to-IP converter 216 to produce a 32-bit output word 304 that feeds into memory 218.

These registers within transport-to-IP converter 216 include media access control (MAC) registers 305, PID filter register 318, continuity counter 319, pointer field register 326, adaptation counter 328 and data remaining counter 330. PID filter register 318 stores a packet identifier value from the current transport packet. This allows finite state machine 302 to take different actions depending upon what type of transport packet is being processed. Continuity counter 319 stores a four-bit current continuity value 322 from the current packet. Continuity counter 319 includes circuitry that automatically uses the current value 322 to compute a previous value 320 as well as a next value 324. By computing the next value 324 ahead of time, finite state machine 302 is able to compare a subsequently received continuity value with the next value 324 to ensure that packets are not skipped. The previous value 320 is computed in order to determine whether a prior packet is being retransmitted. Pointer field register 326 stores the pointer field (if it exists) from a transport packet. Pointer field register 326 points to the location within a transport packet in which the next IP packet begins. This enables finite state machine 302 to skip past a remaining portion of an IP prior packet, or to place the remaining portion of the prior

IP packet together with the rest of the prior IP packet in memory 218.

Adaptation field counter 328 stores the adaptation field (if it exists) from a transport packet. Finite state machine 302 uses adaptation field counter 328 in order to skip past an adaptation field in the transport packet. (Note that an adaptation field is defined within the MPEG2 transport standard.)

Data remaining counter 330 stores a value indicating how much data is remaining in the current IP packet. By decrementing data remaining counter 330, finite state machine 302 is able to determine when the data for the current IP packet ends.

Transport Packets to HDLC Frame

FIG. 4 illustrates how transport packets 410-421 are assembled into a plurality of IP packets 404-406 within a HDLC frame 402 in accordance with an embodiment of the present invention. More specifically, transport packets 410-413 are assembled into IP packet 404, transport packets 414-417 are assembled into IP packet 406, and transport packets 418-421 are assembled into IP packet 405. Note that a large number of transport packets typically make up a single IP packet. Once IP packets 404-406 are assembled, they are grouped together into a single HDLC frame 402. By grouping multiple IP packets into a single HDLC frame 402, a downstream system is interrupted less frequently, which can improve performance for the downstream system.

Note that the system does not wait to receive a certain number of transport packets or IP packets before sending HDLC frame 402. A HDLC frame is periodically sent with any transport packets or IP packets that are ready to send within a given time interval. In this way, the process of batching transport packets and IP packets into a HDLC frame does not incur significant additional delay or latency. Process of Converting Transport Packets into IP Packets

The system starts in an idle state (step 502). If no transport packet is received, the system remains in the idle state (step 502).

When a transport packet arrives, the system retrieves the packet identifier

(PID) from the packet (step 504). The system next uses the PID to determine whether to keep the packet (step 506). For example, the PID can indicate that the packet is a

NULL packet, in which case the packet is discarded (step 509) and the system returns to the idle state (step 502).

If the system decides to keep the packet, the system next checks continuity of the transport packet using continuity counter 319 from FIG. 3 (step 508). If the continuity is not OK, the system discards the entire IP packet that is presently being assembled (step 512) and returns to the idle state. If the continuity is OK, the system determines whether or not an adaptation field is present in the transport packet using adaptation counter 328 (step 514). If so, the system skips all data in the adaptation field (step 516).

Next, the system determines whether or not there is a pointer field using pointer field register 326 from FIG. 3. If so, this indicates that an IP packet ends within the payload of the present transport packet. The system saves the data up to the pointer into a previous IP packet if a previous packet is presently under construction.

Otherwise, the system skips the data for the previous IP packet (step 520).

Next, the system performs MAC address filtering to filter out packets that are not destined to IP addresses coupled to a downstream router or computer system. For example, in FIG. 1, the system filters out packets that are not destined for nodes on network 120.

If the current packet does not pass MAC address filtering, the system signals an error if necessary (step 507), and then discards the entire IP packet 512 (step 512) before returning to the idle state (step 502). If the current packet passes MAC address filtering, the system prepares the data (step 526) and then stores the data to memory 218 (step 528). After the data is stored in memory, the system returns to the idle state (step 502).

Note that all of the operations described above are performed within the clock domain of incoming clock signal 119.

FIG. 6 is a flow chart illustrating the process of sending HDLC frames to a destination in accordance with an embodiment of the present invention. This process is carried out by HDLC interface 230 illustrated in FIG. 2. The system starts in an idle state (step 602). If an HDLC frame is not available, the system remains in the idle state (step 602). When an HDLC frame becomes available, the system retrieves the HDLC frame from memory (step 604). Next, the system sends the HDLC frame to a destination (step 606). For example, in FIG. 1, this destination is router 108. In some cases, the system also triggers a "wait state" of programmable during in the HDLC transmission (state 608). This wait state allows a downstream system, such as router 108, to process preceding HDLC frames. This ensures that the system does not become overwhelmed by a burst of HDLC frames. After the HDLC frame is sent, the system returns to the idle state (step 602).

Note that all of the operations described with reference to FIG. 6 are performed within the clock domain 252 of interface module clock signal 221. The foregoing descriptions of embodiments of the invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the invention. The scope of the invention is defined by the appended claims.

Claims

What Is Claimed Is:

1. A method for converting transport packets into Internet Protocol (IP) packets using circuitry that is driven by an incoming clock signal, comprising: receiving a stream of transport packets at an interface module that converts the stream of transport packets into IP packets; receiving the incoming clock signal that is sent along with the stream of transport packets; assembling an IP packet from a plurality of transport packets from the stream of transport packets using circuitry that is driven by the incoming clock signal; storing the IP packet into a buffer in a memory; retrieving the IP packet from the buffer in the memory using circuitry that is driven by an interface module clock signal, the interface module clock signal being generated locally within a system containing the interface module; and sending the IP packet across a network to a destination IP address using circuitry that is driven by the interface module clock signal.

2. The method of claim 1 , wherein the stream of transport packets includes MPEG2 transport packets, and wherein the incoming clock signal is a clock signal that is defined within the MPEG2 standard.

3. The method of claim 1 , further comprising assembling a plurality of IP packets into a High-level Data Link Control (HDLC) frame using circuitry that is driven by the incoming clock signal.

4. The method of claim 3, further comprising inserting wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

5. The method of claim 1 , wherein assembling the IP packet from the plurality of transport packets further comprises filtering of the plurality of transport packets based upon packet identifier (PID) to filter out transport packets containing data that is not of a specified type for the IP packet.

6. The method of claim 1, wherein assembling the IP packet from the plurality of transport packets further comprises continuity checking for the plurality of transport packets to ensure that all transport packets that make up the IP packet are received in sequential order.

7. The method of claim 1, further comprising, before sending the IP packet across the network, filtering the IP packet based upon media access control (MAC) address to filter out IP packets that are not directed to an IP destination address on the network.

8. The method of claim 1, wherein the act of assembling the IP packet comprises using at least one finite state machine that is clocked by the incoming clock signal to manipulate a plurality of registers within the interface module.

9. The method of claim 1 , wherein the stream of transport packets is received from a satellite.

10. A method for converting MPEG2 transport packets into Internet Protocol (IP) packets within HDLC frames using circuitry that is driven by an incoming clock signal, comprising: receiving a stream of MPEG2 transport packets originating from a satellite at an interface module that converts the stream of MPEG2 transport packets into IP packets; receiving the incoming clock signal along with the stream of MPEG2 transport packets, the incoming clock signal being defined within the MPEG2 standard; assembling an IP packet from a plurality of MPEG2 transport packets from the stream of MPEG2 transport packets using circuitry that is driven by the incoming clock signal; storing the IP packet into a buffer in a memory; assembling a plurality of IP packets into a High-level Data Link Control (HDLC) frame; retrieving the HDLC frame from the buffer in the memory using circuitry that is driven by an interface module clock signal, the interface module clock signal being generated locally within a system containing the interface module; and sending the HDLC frame across a HDLC communication channel using circuitry that is driven by the interface module clock signal.

11. The method of claim 10, further comprising inserting wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

12. The method of claim 1.0, wherein assembling the IP packet from the plurality of MPEG2 transport packets further comprises filtering of the plurality of

MPEG2 transport packets based upon packet identifier (PID) to filter out MPEG2 transport packets containing data that is not of a specified type for the IP packet.

13. The method of claim 10, wherein assembling the IP packet from the plurality of MPEG2 transport packets further comprises continuity checking for the plurality of MPEG2 transport packets to ensure that all MPEG2 transport packets that make up the IP packet are received in sequential order.

14. The method of claim 10, further comprising, before sending the IP packet across the network, filtering the IP packet based upon media access control (MAC) address to filter out IP packets that are not directed to an IP destination address on the network.

15. The method of claim 10, wherein the act of assembling the IP packet comprises using at least one finite state machine that is clocked by the incoming clock signal to manipulate a plurality of registers within the interface module.

16. An apparatus for converting transport packets into Internet Protocol (IP) packets using circuitry that is driven by an incoming clock signal, comprising: an interface module that receives an incoming stream of data, the incoming stream of data including a stream of transport packets; a demodulator within the interface module that demodulates the incoming stream of data to translate the incoming stream of data from a modulated analog form into a digital form; and a transport-to-IP circuit within the interface module that converts transport packets into IP packets, the transport-to-IP circuit including, a receiving circuit that receives the stream of transport packets along with the incoming clock signal that is sent with the stream of transport packets, an assembling circuit that assembles an IP packet from a plurality of transport packets from the stream of transport packets using circuitry that is driven by the incoming clock signal, and stores the IP packet into a buffer, and a sending circuit, driven by an interface module clock signal, that is configured to send the IP packet from the buffer to a destination

IP address across a network, wherein the interface module clock signal is generated locally within a system containing the interface module.

17. The apparatus of claim 16, wherein the stream of transport packets includes MPEG2 transport packets, and wherein the incoming clock signal is a clock signal that is defined within the MPEG2 standard.

18. The apparatus of claim 16, wherein the assembling circuit is further configured to assemble a plurality of IP packets into a High-level Data Link Control (HDLC) frame.

19. The apparatus of claim 18, further comprising a wait state generation mechanism that inserts wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

20. The apparatus of claim 16, wherein the assembling circuit is further configured to filter of the plurality of transport packets based upon packet identifier (PID) to filter out transport packets containing data that is not of a specified type for the IP packet.

21. The apparatus of claim 16, wherein the assembling circuit is further configured to check continuity for the plurality of transport packets to ensure that all transport packets that make up the IP packet are received in sequential order.

22. The apparatus of claim 16, further comprising a MAC address filtering circuit that is configured to filter the IP packet based upon media access control

(MAC) address to filter out IP packets that are not directed to an IP destination address on the network.

23. The apparatus of claim 16, wherein the assembling circuit includes, a plurality of registers; and at least one finite state machine that is clocked by the incoming clock signal to manipulate the plurality of registers.

24. The apparatus of claim 16, wherein the stream of transport packets originate from a satellite.

25. A method for converting transport packets into IP packets within HDLC frames, comprising: receiving a stream of transport packets originating at an interface module that converts the stream of transport packets into IP packets; assembling an IP packet from a plurality of transport packets from the stream of transport packets; storing the IP packet into a buffer in a memory; assembling a plurality of IP packets into a High-level Data Link Control (HDLC) frame; retrieving the HDLC frame from the buffer in the memory; and sending the HDLC frame across a HDLC communication channel.

26. The method of claim 25, further comprising inserting wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.

27. The method of claim 25, wherein assembling the IP packet from the plurality of transport packets further comprises filtering of the plurality of transport packets based upon packet identifier (PID) to filter out transport packets containing data that is not of a specified type for the IP packet.

28. The method of claim 25, wherein assembling the IP packet from the plurality of transport packets further comprises continuity checking for the plurality of transport packets to ensure that all transport packets that make up the IP packet are received in sequential order.

29. The method of claim 25, further comprising, before sending the HDLC frame across the communication channel, filtering the IP packet based upon media access control (MAC) address to filter out IP packets that are not directed to an IP destination address on the network.

30. The method of claim 25, wherein the act of assembling the IP packet comprises using at least one finite state machine to manipulate a plurality of registers within the interface module.

31. The method of claim 25, wherein the act of assembling the HDLC frame takes place at the end of a time interval, without waiting for a specific number of transport packets or IP packets, so that the HDLC frame can be sent without incurring additional delay in waiting for a minimum number of transport packets or IP packets to be received.

32. An apparatus for converting transport packets into IP packets within HDLC frames, comprising: an interface module that receives an incoming stream of data, the incoming stream of data including a stream of transport packets; a demodulator within the interface module that demodulates the incoming stream of data to translate the incoming stream of data from a modulated analog form into a digital form; and a transport-to-HDLC circuit within the interface module that converts transport packets into IP packets within HDLC frames, the transport-to-HDLC circuit including,

a receiving circuit that receives the stream of transport packets, an IP packet assembling circuit that is configured to assemble an IP packet from a plurality of transport packets from the stream of transport packets; a HDLC assembly circuit that is configured to assemble a HDLC frame from a plurality of IP packets and to store the HDLC frame into a memory, and a sending circuit that is configured to send the HDLC frame from the memory across a network to a destination IP address.

33. The apparatus of claim 32, further comprising a wait state generation mechanism that inserts wait states of programmable duration between HDLC frames in order to allow a downstream receiver sufficient time to process successive HDLC frames.