NO20015475L - Bandwidth allocation method and method for TCP / IP satellite based networks - Google Patents

Abstract

A communication system balances message traffic between return channel groups and within the groups so that a user does not have to control the specific transmission frequency used. The alignment frequencies and bandwidth of the return channel unit are set by the system in a return channel control message in the broadcast signal so that system and return channel group loads are taken into account and to take into account user message lag. An initial transmission from a remote user can be made using an ALOHA type burst signal which delivers a message delay to the control station, and is made at a frequency determined from a randomly weighted load based frequency selection process. The system, not the individual user, determines the frequency and channel assignment. For larger lag or priority users, periodic bandwidth will be provided. One method of balancing loads between and between groups of return channels in the communication system includes requesting return channel bandwidth in an uplink message from a Qem user to a control station. The uplink message may include both a lag indicator and a bandwidth allocation request given to a network operations center (NOC) that can be used to set the return channel bandwidth and frequency of the remote upline. A user message is sent on the assigned return channel frequency using the bandwidth allocated according to the lag indicator and a bandwidth allocation request so that the traffic load is maintained in balance between the established return channel frequency group and within each return channel frequency group.

Description

The present invention is generally for a bandwidth allocation plan for time-division multiple access (TDMA) systems and specifically for efficient bandwidth allocation for transmission control protocol/Internet Protocol (TCP/IP) systems over a TDMA based satellite network.

Using satellites for Internet and Intranet traffic, and especially multicasting of digital video using digital video broadcasting (DVB) and two-way broadband communication, has recently been the subject of a great deal of attention. Satellites can help alleviate Internet traffic congestion and bring Internet and interactive applications to countries that do not have an existing network infrastructure as well as provide support for interactive broadband applications.

One way to use satellite technology in this growing field is to have very small apparatus terminals (VSAT) that provide fast and reliable satellite-based telecommunications between essentially an unlimited number of geographically dispersed locations. VSAT technology has established effective tools for LAN Internet connections, multimedia image transmissions, group and interactive data transmissions, interactive voice, broadcast data, multicast data and video communications.

The Internet Protocol (IP) is the most commonly used mechanism for transporting multicast data. Examples of satellite networks capable of carrying IP multicast data include Hughes Network System's Personal Earth Station (PES) VSAT system and Hughes Network System's DirecPC® system. Combining VSAT delivery with standards-based IP multicast gives the user a less expensive and more flexible approach to achieving high-quality, real-time broadcasting. Satellite digital video broadcasting (DVB) technology and the Internet Protocol (IP) have converged ("IP/DVB") to allow users transparent access to a variety of broadcast content that includes live video, large software applications, and media-rich websites.

To support these developments, VSAT systems, such as the Personal Earth Station mentioned above, have allowed commercial users to have access to a generally limited number of satellite return channels to support two-way communications. The choice of return or input channel is usually limited to only a group of only a few possible channels pre-configured by a combination of hardware and/or software limitations. Some commercial systems may use a VSAT Internet access system terminal to receive HTTP responses via the outgoing satellite broadcast channel, and may send HTTP requests to the Internet over a VSAT incoming channel. Unfortunately, as these systems come to market in large numbers to consumers and the number of users increases, generally the limited number of incoming channels could be experienced as a limitation and reduce user throughput as a result of an increasing number of users competing for a final number of incoming satellite channels. The potential benefits that VSAT technology brings to consumers in the area of broadband delivery will necessarily decrease due to the limited bandwidth available in the incoming channels.

Split approach for the uplink channels is commonly used and can be used in time-division multiple access (TDMA) systems. TDMA is a technique for assigning multiple channels on the same frequency in a wireless transmission system such as a satellite communication system. TDMA allows a number of users to access a single radio frequency (RF) channel without interference by assigning a unique time window to each user within each channel. Access is controlled using a frame-based approach, and precise timing is required to allow multiple users access to the bandwidth (ie, time-shared access). Necessary for the transmission of information in a multiplexed form in the return channel.

Transmissions are grouped into frames where a frame synchronization ("sight") signal is usually given at the beginning of each frame. Following each frame sync signal is a number of time bits within the frame for burst transmissions. In the simplest case, a time bit will represent a fixed amount of bandwidth allocated to each of the users who need to transmit information. Each TDMA user gets a specific time window (or windows) in the channel and this time window is fixed for the user throughout the transmission. In more complicated systems, multiple time slots will be made available to users based on transfer needs or priority plans. After all time bits have been used up, other frame sync signals will be transmitted to repeat the cycle. However, even if the user has nothing to transmit, the time slot will still be reserved and it results in inefficient utilization of the available bandwidth.

TDMA requires a procedure for adjusting the time slots in burst transmissions to reduce burst overlap and the subsequent "collisions" of different users' transmissions. Additionally, giving each remote user access to the desired upline bandwidth (essentially equivalent to window access) will become more difficult when a larger number of different inputs and upline channels are shared among a larger number of users. With TDMA, each VSAT will access a control node via the satellite by broadcasting a burst of digital information on its assigned radio frequency carrier. Each VSAT sends bursts at its allocated time relative to the other VSATs in the network. Sharing access in this way - by time windows - allows VSATs to make the most efficient use of the available satellite bandwidth. As in most TDM-based protocols, bandwidth is available to each VSAT in fixed increments whether it is needed or not, as discussed above. Establishing a fair allocation of uplink bandwidth for each of the uplink users or inputs is difficult due to uneven (ie, fluctuating heavy or light) load within a group of uplink channels, and due to relative uneven load between groups of uplink channels.

Figure 1 provides an example of a conventional satellite communication system 100 that limits each of the "k" possible remote users 140 to a return channel group 160 out of "n" available groups. Each of the n return channel groups 160 may, for example, have "m" return channel frequencies available, thereby allowing each remote user an upline on one of the m frequencies as access is granted. Upline timing information may be extracted from the transceiver 150 using the received outgoing broadcasts 120 sent in the earth station 110 through the satellite 130. The outgoing broadcasts 120 may include multiple information systems each being received by a portion of the remote users 140. Time signals for each remote user may also be extracted from its associated information stream, and independently of the upline time information, and further it may be applicable only to the return channel group 160 assigned to the particular remote user 140. In addition, Internet/Intranet access may be provided to remote users 140 through the earth station 110 and port 170.

As the use of two-way satellite networks has moved into the consumer market, the industry has further pursued the Internet work of multiple satellite broadcast networks and their associated independent entrances ("inputs") or uplink channels. As the market expands, the number of possible uplink users will further increase and the previous approaches for allocating return channel bandwidth to users in fixed predetermined uplink channel groups necessarily require the addition of hardware and system complexity to be able to accommodate the increased uplink request. If the return channel groups base their frame time information on a specific satellite broadcaster that is not common to all remote users across all return channel groups, then users will necessarily be limited to their pre-assigned return channel groups, which thus limits flexibility.

Furthermore, this approach will result in increasing inefficiency both with regard to the allocation of hardware, costs and uplink channel bandwidth utilization, since many of the available groups in the uplink channels may either be heavily or lightly loaded or subject to load imbalance relative to other input groups. This could be the result of each user being pre-configured for access to a specific input channel, or to only a limited number of channels, either due to hardware or software limitations, or to window time information considerations as discussed above. This problem can be acute due to the sporadic and sometimes unpredictable nature of such transmissions, which can also result in an inefficient use of the available bandwidth.

Several bandwidth allocation solutions are available for "random use", or non-critical line-up systems, and can be used in conventional

satellite communication systems 100 as shown in Figure 1. For example, the well-known ALOHA technique is used with the intention of minimizing the administration associated with allocating bandwidth to users when there is no data to transmit. ALOHA was developed to coordinate and arbitrate access to a shared communication channel. Although originally applied to terrestrial radio broadcasts, the system has been successfully implemented in satellite communication systems. A medium access method such as ALOHA is intended to prevent two or more systems from transmitting at the same time in the same medium. There must be a method of handling so-called "collisions". In the ALOHA system, a system will transmit regardless of whether data is available to transmit. If another system sends at the same time, a collision will occur, and the frame that was sent will be lost. However, a system can listen to broadcasts in the medium, even its own, or wait for an acknowledgment from the destination station to determine whether the frame was actually transmitted

However, so-called pure ALOHA systems have about seven percent bandwidth efficiency, which means that about fourteen times the required bandwidth must be allocated. Furthermore, delays to users who actually have traffic to send may find this unacceptable in time-sensitive applications, especially because the ALOHA technique wastes bandwidth and thus time windows for users who have no or low traffic load to send.

The pure ALOHA technique is simple and elegant, but other approaches called window-based ALOHA or random access mode were developed to double the traffic capacity. In the windowed ALOHA scheme, distinct time windows will be created where users can send a single frame in a packet, but only at the beginning of the window. Thus, the transmitter must buffer data until the beginning of the next window period. For example, a control node can send a signal at the beginning of each window to let all other users know that the window is available. By aligning the frames in windows, overlap in the mailings can be reduced. However, users must wait a fraction of a second for the beginning of the time window before they can send. Data can also be lost if users fight over the same window, but not as much data as would be lost in pure ALOHA systems. However, tests have shown that window-based ALOHA has a performance advantage and is best suited for short, "burst" messages in applications that require a fixed response time, such as credit card verification at the point of sale and ATM transaction processing. This contention technique allows VSATs to transmit at any time and to continue transmitting if they receive acknowledgments that no other stations are transmitting. However, this method will require a channel utilization of around 18 to 36 percent.

Other systems use a window reservation access mode where the host reserves windows for each user who sends an assigned number of packets. When allocating bandwidth to accommodate an allocated message length, more efficient use of the bandwidth will be made than with random access methods, and thus throughput will be improved. A disadvantage of this approach is that more time is required to set up the channel, which contributes to more delay, and there may be too few or too many packets allocated for message transfers for each user, leading to at least some inefficiency in utilization of the bandwidth. Furthermore, dynamic bandwidth reallocation will not be efficiently enough achieved using this approach.

Although an ALOHA type of channel access plan has been successfully used to achieve better uplink bandwidth, there are problems with either overloading or underloading the return channels, and also having an imbalance between groups of return channels.

What is therefore needed is an apparatus and method for dynamically allocating uplink bandwidth depending on the user's need for return channel access. What is further needed is an apparatus and method for balancing the upline loads between return channels that share a common upline channel group and which also balances the system load between groups of upline channels that share the same frame time division.

The present invention solves the aforementioned problems by providing a system, apparatus, and method for allocating upline bandwidth depending on the user's need for return channel access, and to ensure that a load balance condition between and among the return channel groups is maintained.

In one embodiment of the invention, a control station for two-way satellite communication will include an RF section for sending a broadcast signal and a receiver for a return channel from a remote user. A return channel subsystem includes a return channel manager for processing return channel information and setting a user bandwidth in the return channel. The return channel controller sets the transmitter frequency and bandwidth in the return channel by evaluating either or both of a user backlog indicator and a bandwidth allocation request provided by the remote user in one or more of the return channel messages. The return channel control device will also change the return channel frequency at a return channel group based on the traffic load in the return channel group.

In another embodiment of the invention, a transceiver will be used to send a remote synchronization message to a control node, and include a receiver that

detects a control node timing information message in a received broadcast signal. A timing recovery section uses the control node timing information message to determine a system-wide start time for an outgoing frame and a message buffer that temporarily stores an outgoing message from a user until it is sent. A transmitter links the outgoing message from a user during an allocated period after the start time of the transmitting frame and using an allocated transmission frequency determined by a group status message received in the broadcast signal. If necessary to achieve a load balance, the transmit frequency will be changed to another transmit frequency within the current channel group, or changed to a frequency within another channel group depending on the relative load in the two return channel groups, and the remote user's bandwidth requirements as reported in the group status message received in the broadcast signal. The ability to assign transmission to other frequencies in a different return channel group is at least a result of sharing a common system time frame information among all the return channel groups.

In a third embodiment of the invention, a method of controlling a return channel from a control station will include sending a broadcast signal, receiving a return channel line-up from a remote user, and setting a return channel bandwidth and frequency with a return channel controller that provides an assignment message in the broadcast signal for reception at the remote user. The return channel bandwidth and frequency are set by evaluating a lag indicator provided by the remote user and by evaluating the relative load of all the return channel groups and individual transmission frequencies in the return channel groups.

In a fourth embodiment of the invention, a method of sending a frame synchronization message from a remote user will include receiving a control node timing information message in a broadcast signal thereby determining a return channel frame start time using the control node timing information message, temporarily storing an outgoing user message and transmitting the outgoing user message on a broadcast frequency during an allocated period after the return channel frame start time. The transmission frequency and the allocated bandwidth can be determined by an incoming allocation message received in the broadcast signal. The remote user may initially transmit on a return channel configured to support an ALOHA burst signal. This burst signal includes a backlog indicator of the remote user's message traffic to the control node. The remote user can then be moved to a return channel that either shares access with other remote users, or provides dedicated upline access depending on available system resources and the remote user's bandwidth needs. The initial ALOHA sweep uplink is sent on a broadcast frequency selected locally by the remote user using a randomly weighted frequency selection process based on system or group load reported over the broadcast signal.

In a fifth embodiment of the invention, a communication system for balancing traffic on a plurality of return channels will include a control station that sends a broadcast signal to a remote user. The broadcast signal includes a non-true time frame mark, a timing information message and a return channel control message. A receiver at the remote user receives the broadcast signal and determines a return channel frame start time using the non-real time frame tag and the timing information message. A transmitter at the remote user transmits a user message on one of the return channels during a predetermined period after the return channel frame start time. An uplink frequency and bandwidth in the return channel is determined by the return channel control message to keep track of the system and return channel group load and to keep track of the user message backlog. An initial transmission from the remote user may be done using an ALOHA type burst signal which provides a lag indicator message. This initial broadcast may be done on a frequency determined from a randomly weighted, load-based frequency selection process with the intent of ensuring dynamic balance between the return channel groups.

In a sixth embodiment of the invention, a method for balancing loads between and among groups of return channels in a communication system will include a request for return channel bandwidth in an upline message from a remote user to a control station. The uplink message may include a backlog indicator and a bandwidth allocation request. A return channel bandwidth for the remote user may also be allocated by processing the lag indicator and a channel allocation message provided from the control station to the remote user in the broadcast signal. The channel allocation message may also allocate return channel bandwidth. A user message is sent on a return channel according to the channel allocation message.

The present invention in all its embodiments, collectively and individually, has a number of characteristics that distinguish it from conventional bandwidth allocation plans. For example, the present invention will dynamically allocate bandwidth based on how much the user actually needs and prescribe uplink frequency changes to balance the traffic load. This approach of the apparatus, system and method of the present invention not only balances the load between the return channel groups, but within each return channel group as well, which ensures an optimized bandwidth allocation plan. The system is set up for automatic load balancing each time a remote user starts a new uplink session, achieving the goal by having approximately the same number of uplink users sharing each input channel, even with larger and increasing numbers of system users. This approach is especially adapted and optimized for TCP/IP satellite traffic, and is a highly desired component for operating an efficient TCP/IP system over a TDMA based satellite system that includes multiple satellite networks with the required ground infrastructure support.

Finally, the method and system of the present invention will allow expansion to an essentially unlimited number of users on the same return channel without extensive modifications in hardware and software and allow these users to all have approximately equal access to return channel capacity or bandwidth. This capability is provided at least in part by sharing system frame time information among all the return channel groups, regardless of whether the broadcast source of the return channel control information sent from the control station possibly includes multisatellite links. The system will preferably share a common non-real time reference given to all remote users regardless of whether the particular broadcast being received is its source.

These and other features and advantages of the present application will become more apparent from the detailed description provided hereinafter. However, it is to be understood that the detailed description and specific examples, while indicating a preferred embodiment of the invention, are provided by way of illustration only since various changes and modifications within the spirit and scope of the invention given in these detailed descriptions will be apparent to one skilled in the art .

The features and advantages of the invention will be more fully understood by considering the following detailed description of the invention with reference to the accompanying drawings which are: Figure 1 shows a conventional satellite communication system; Figure 2 shows the two-way satellite communication system of the present invention; Figure 3 shows the preferred IP/DVB protocol layer used in the present invention;

Figure 4 shows a block diagram of a preferred return channel transceiver; and

Figure 5 shows a diagram of the NOC return channel subsystem interconnect.

A preferred embodiment of the method and system which provides return channel TDMA frequency and bandwidth allocation according to the present invention is described below. Although the embodiment is described in general terms of Hughes Nework Systems' Two-Way DirecPC® for ease of discussion, the outcome of the communication bandwidth allocation system, apparatus and method of the present invention may be embodied in other forms by only minor variations to the detailed implementation. It will also be clear to one skilled in the art that all the features of the invention will not be described or shown in detail due to the need for brevity and clarity.

The present invention is designed to control the allocation of available bandwidth to groups of return channels that share the same

the line frame timing information derived over multiple transport streams. For simplicity, this two-way satellite communication system 200 will be characterized in Figure 2 as including one or more Network Operations Center (NOC) 210 (also commonly known as a "hub", "egress router", "control node", "control station" or "earth station", etc.) , at least one satellite 230 having an uplink and downlink transponder, one or more (ie 1 to k) remote users 240, each user node having a satellite receiver and transmitter capability provided by an associated transceiver 250 which also provides an integrated uplink ( or "return channel") capability. Transceiver 250 may transmit on one of many (ie, "n") return channel groups 260, which may, for example, have "m" channels or frequencies available for the uplink.

Thus, compared to the conventional transceiver 150 of Figure 1, the transceiver 250 will potentially have more upline frequencies available, that is, "m x n" frequencies instead of just "m" due to the bi-directional capability

the satellite communications system 200 to access any of the return channel groups 260, and the limitation of the conventional transceiver 150 to only have "m" channels available on its assigned return channel group.

Figure 2 also illustrates how two NOCs 210, ie NOC1 210a and NOC2 210b, each provide at least one DVB transport stream 220 (ie 220a and 220b) to the satellite 230 for further retransmission. The DVB transport stream is retransmitted from the satellite 230 as partially shown as DVB transport stream 220 for the sake of clarity, each NOC 210 in the system of the present invention may provide support for different receivers or output channels. The system symbol time information reference 270 is preferred to provide a common symbol time information to each NOC 210 in the system so that the time information used to derive the line frame start times can be recovered at all the remote users 240. The NOC 210 will also preferably provide access to the Internet or to an Intranet through port 170.

However, applications of the method and system of the present invention are not intended to be limited to a system having a specific number of NOCs 210 or remote users 240. Furthermore, the NOC 210 of Figure 2 will differ from the NOC 110 of Figure 1 in that each NOC 210 has the ability to support receiving and processing return channel traffic from a remote user 240 that is broadcast according to a common system time information plan.

A receiver channel in the transceiver 250 could, for example, operate at a rate of 28 Mbps, and the broadcast channel in the transceiver 250 could preferably be a VSAT-like TDMA channel. Depending on customer needs, the channel rates for sending "return" or "input" channels can be, for example, 64 kbps, 128 kbps, 256 kbps, or possibly even higher as consumer needs rise. A group of multiple transmitter channels can also share between them independent DVB transport streams 220 either transmitted from the same or different NOCs 210. The return channel will also preferably contain a link layer protocol, at the shed level to provide a substantially lossless channel.

The receiver channel in the transceiver 250 receives a DVB transport stream 220 from an NOC 210 which preferably uses an IP packet format which may include packets arranged according to the Multiprotocol Encapsulation (MPE) standard. A preferred superframe message 300 is shown in Figure 3 where a superframe marker is periodically sent. However, the superframe marker may be sent only every integer number of frames, such as every eighth frame. The stream has preferred DVB which complies with MPEG-2 formatting which supports multiple MPE messages in a single MPEG frame. The transport stream can include MPEG packets of fixed size 204 which can contain 188 bytes of user traffic and 16 bytes of transmitted error correction data (FEC), for example.

Preferably, an MPE header may contain specific media access control (MAC) data fields to indicate the type of media or traffic contained in the data stream, i.e. super frame numbering packet (SFNP), unicast, multicast, conditional access, return channel messages, or return channel group messages, and other data fields to indicate for example if the package is encrypted. Forward error correction (FEC) at different rates can also be supported, i.e. FEC rates of Vi, 2/3, 3A, 5/6 or 7/8. Furthermore, the header for each frame may also contain a packet identifier (PID) to distinguish between elementary streams in the DVB transport stream 220 so that remote users 240 can filter the messages by PID. To simplify the discussion, the DVB transport stream 220 will hereafter be referred to simply as "broadcast".

As for the main outcome of the present invention, allocation of bandwidth and frequencies to the return channels as well as system monitoring and control functions could be performed using a series of messages contained in different bits of the broadcast stream sent to remote users 240.

For example, the DVB MPE protocol layer can preferably provide MAC fields that support different user MAC addresses as described above. In particular, return channel messages may preferably include input command/acknowledgment packet (ICAP) messages and input group definition packets (IGDP). The return channel group messages will preferably support bandwidth allocation packets (BAP), input acknowledgment packets (IAP), and ICAP packet messages. These packages can all use User Datagram Protocol (UDP) datagrams that utilize a transport protocol supported by the TCP/IP protocol architecture and that support a connectionless transport service for unicast and multicast transmissions between UDP endpoints. Each of these message packages is described in more detail below and in the attached tables.

Referring to Figure 4, the transceiver 250 will preferably support TCP/IP applications, i.e. web skimming, electronic mail and FTP and also include multimedia broadcast and multicast applications using IP multicast, i.e. MPEG-1 and MPEG-2 digital video, digital audio and file broadcasting. The transceiver 250 provides a high-speed wireless return channel as an alternative to low-speed terrestrial return channels. Transceiver 250 contains a receiver (RCVR) 410, processor 420, RF transmitter (RF XMTR) 430, time recovery section 440, and transmit unit (TU) 450. RF XMTR 430 modulates and preferably transmits in burst mode the incoming carrier waves to the satellite 230 and NOC 210. The RF XMTR 430 can also operate with and be controlled by the TU 450 and RCVR 410 via the processor 420 which can also control the RCVR 410 using, for example, a universal serial bus (USB) adapter (not shown). Configuration parameters and input data from the processor 420 may also be inputs to the RF XMTR 430 through a serial port (not shown), and transmitter status information from the RF XMTR 430 may also be provided through the serial port to the processor 420. The TU 450 conditions the output data signals by incorporating the correct the signal protocols and modulation plans, i.e. IP/DVB protocol and TDMA using QPSK techniques including Offset-QPSK (OQPSK).

The RCVR 410 receives broadcast signals 220 from the satellite 230 through the antenna section 460 and recovers and provides correct time-related signals to the time recovery section 440. The time recovery section 440 corrects and compensates the time of reception of the received frame markers according to the time information contained in the received broadcast signal, for example in an SFNP. The timing recovery section 440 will further allow the RF XMTR 430 through the processor 420 and the TU 450 to transmit at the correct time according to a TDMA time window allocation schedule. Finally, the antenna (ANT) 460 will send and receive signals to and from the satellite 230.

Now follows a discussion of the content, approach and operation of the bandwidth and frequency allocation system and methods of the present invention. Figure 5 shows some of the intermediate links in the NOC 210. The return channel subsystem (RCS) 510 in the NOC 210 talks to the NOC signal distribution section 540, the NOC timing information section 550, and the NOC processor 560. Among other functions, the RCS 510 will create a new collection of packets received from remote users 240 over the return channels and a NOC input receiver (not shown) to IP packets for further processing. Non-real-time frame timing information broadcast in the broadcast stream to remote users 240 and ultimately used for upline timing information in the return channels is derived from a pulse from the return channel controller 520 in the RCS 510. The return channel controller 520 will also allocate bandwidth, align the aperture configuration, and send frame pulses to the burst channel demodulator (BCD) 530. The number of BCDs 530 supported by the RCS 510 is preferably at least 32 arranged to allow redundant equipment support for at least 28 return channels. Multiple sets of return channel subsystems 510 may be provided in a group arrangement with networks (not shown) within each NOC 210 to allow processing of a large number of return channels preferably up to 100,000 or more for example. Return channel traffic from the remote users provided from the NOC RF section (not shown) and the NOC input receiver (also not shown) and routed through the NOC signal distribution section 540 is routed to one or more BCDs 530 to demodulate return channel data received from the remote users as controlled by the return channel controller 520 .

In addition, the return channel controller 520 will provide frame pulses to the NOC timing section 550. The NOC timing section 550 will preferably include appropriate means (not shown) for measuring and comparing packet delays associated with both internal NOC delays and NOC satellite delays respectively. The NOC time section 550 would also preferably have the function of a "delay follower" to determine and update the aforementioned delays. These delays can be determined from signals provided both from the internal system timing signals and broadcast signals that echo or are received from the satellite 230.

The NOC time section 550 provides the correct frame time information to the NOC multiplexer section (NOC MUX 570) through the NOC processor 560. The NOC MUX 570 combines broadcast data intended for the remote users 240 with frame time information from the NOC time section 550 and provides a packed data signal to the NOC signal distribution section 540 for transmission to the satellite 230 through the NOC RF section (not shown) and finally to the remote users 240. The remote users 240 use the broadcast time frame information to derive their own uplink start time which is preferably synchronized throughout the two-way satellite communication system 200.

The equipment, signals and subsystems where each of the NOC 210 and the transceivers 250 are preferably interconnected via one or more local area networks (LANs) (not shown) and further preferably are connected according to an open system architecture approach that allows modifications and upgrades to be made easier such as improvements in software and hardware when this is available or desired.

The underlying timing information approach of the present invention which allows bandwidth and frequency allocation and takes place over a larger number of return channels on different return channel groups must provide its information to the RCVR 410 so that the transceiver 250 can precisely control the timing of burst transmissions as a deviation from the received superframe header. The superframe header received in a superframe numbering packet (SFNP) sent in the broadcast is used by each remote user 240 to synchronize its broadcast start time frame marker in the superframe marker pulse generated in the return channel controller 520. This superframe numbering packet (SFNP) is used to lock

the network time information for the return channel, and as a guide to identify which network is being connected. This package will be sent on

"super frame number packet" MAC address (see Table 1). However, receiving the SFNP by itself will not be sufficient because there are delays from the time that the return channel controller 520 generates the superframe header until the timing receiver 410 actually receives the SFNP.

Further corrections are applied in the receiver 410 to compensate for internal NOC output delays, an NOC satellite transmission time delay, and a transmission delay from the satellite to each of the specific remote users 240, preferably based on a known parameter determined during a standard satellite user's "area" processing during system initialization , and by the addition of timing information provided by the NOC 210 in the broadcast signal 220.

Thus, once each superframe, an internal NOC delay between the time until the preceding superframe header was thought to have been sent and the time it was actually sent will be broadcast in an SFNP message to all remote users 240. This value, along with a "spatial time offset" (STO) related to transmission delays from NOC 210 to remote users 240 be used in each remote user 240 to calculate the actual start time of the superframe. Remote users 240 use the calculated superframe start time as their reference point for TDMA uplink frame times to determine an upcoming broadcast frame start time. Preferably, the internal NOC delay will be routinely updated by the NOC time section 550 and will then also be broadcast in subsequent SFNP messages to remote users 240.

By knowing the synchronized upline frame start time, a preferred sharing of the same upline frame start time among all remote users 240 allows the NOC 210 to effectively manage the bandwidth allocation and frequency allocations among all the remote users 240 both between and within all the return channel groups 260 .

The operation of the communication time system in the present invention will now be described. The NOC 210 takes formatted data packets and sends them on the DVB transport stream 220 to the satellite 230 for further retransmissions to remote users 240. The data stream or "payload" information is sent following a correctly formatted MPE header and initialization vector if the packet is encrypted.

Included in the DVB transport stream 220 is the SFNP that provides a superframe marker as well as the internal NOC delay and satellite drift correction for a preceding superframe marker sent in a preceding SFNP.

When a remote user 240 receives an SFNP in its respective RCVR 410, the received superframe packet will be adjusted in the timing recovery section 440 of the remote user 240 to determine its upcoming upline transmission time so that the transmitted or upline frame is received at the correct time in the NOC 210. which the sending site must preferably send is one satellite hop before the time the NOC 210 expects data to be received. The broadcast time can be measured by starting at a time later than the regenerated superframe time in the STO. The NOC delay and receiver satellite delay are subtracted from this time base. A final adjustment to account for satellite operation is then made. So, knowing the fixed frame length, i.e. 45 ms, the frame start time of a subsequent upline transmission frame can be determined.

Once the frame time is determined, a nominal value, ie close to 45 ms, is preferably used as a continuous basis with small adjustments to account for drift between the counter and the timing pulse. Once the TU 450 is aligned, only minor corrections will be necessary to keep the TU 450 in sync with the NOC 210.

Initially, if the remote user 240 needs uplink message traffic, access will be preferentially requested on a predetermined amount of ALOHA burst channels. The remote user 240 will preferably have various states where it may or may not be able to send messages. The state of the receiver 410 in the transceiver 250 may include: 1) Acquisition: The receiver 410 receives the broadcast signal 220. During this time the transceiver 240 is not able to transmit and uses SFNP for acquisition. 2) Learning mode: The receiver 410 learns about the available return channel group when receiving IGDP messages (see table 2). Remote user 240 will only use a return channel if its TU 450 and RF XMTR 430 are available. 3) Ranging: If the remote user 240 has not set up its time information for its current location, it will request a ranging section from the NOC 210 by sending a ranging request via a ranging burst. A closed loop process is used to adjust the time information and power consumption. 4) Request Bandwidth: Once the sending location has been ranged and data is to be sent, an ALOHA burst will be used to send the data. A backlog indicator will be used to trigger the NOC 210 to allocate bandwidth. 5) Transmit traffic: The remote user 240 sends user traffic via an allocated return channel in one of the return channel groups 260 using allocated "stream" bandwidth, i.e. bandwidth essentially dedicated to the entire TDMA transmission frame of the remote user 240.

The IGDP packet (see Table 2) is preferably used to define the return channels in a return channel group 260 and their availability, and to allow selection of the return channel group for user traffic (using ALOHA for the setup) and distance measurement. The return channel groups may also be used to allow for load sharing between a number of return channels and to minimize the NOC 210 output bandwidth required to control the return channel bandwidth allocation. The return channel groups are preferably limited to the amount of information needed to be buffered or processed in the receiver 410. The IGDP is preferably sent on return channel broadcast MAC addresses.

IGDP preferably uses one package per return channel group per superframe, for example 26 kbps for bandwidth for 75 return channels per group, and 300 return channels. It can also be sent on an "all RCVR" multicast address.

Each receiver 410 will preferably monitor all IGDPs. The receiver 410 will

preferably filter out return channel types that it is not configured to support, and may at the end of a time period remove the definition if it has not been received within three superframe times. An input group table is preferably created in each receiver 410 from information contained in all of these packets. This table is preferred to be

almost static to minimize the cost of processing in a processor 420 required to reorganize its input group table. Minimizing the table changes is desired to reduce potential interruptions in system 220's operations. When the remote user 250 is active, ie has bandwidth, it will preferably monitor its currently assigned input group as well as a second input group near the time it is moved between input groups.

In order to limit wait times when a remote user 240 needs to transmit, all idle transceivers 250 with valid area information will be able to make a randomly weighted choice, i.e., every fourth time frame (in the superframe), between all input groups that report a non-zero ALOHA metric. The remote user 240 will preferably start monitoring this input group, and the previous input group will also preferably be monitored until all previous BAPs have been received or lost. By making such a randomly weighted choice, the possibility of suddenly making a lightly loaded upline channel heavily loaded is reduced if several remote users 240 need upline access at approximately the same time.

First, the transceiver 240 may randomly select two of the ALOHA channels for the next configured number of frames for the input group it has selected. A reasonable assumption is that the ALOHA burst configuration is generally static over time, and that the ALOHA burst channel will become available. When the remote user 240 needs to become active, and does not have an outstanding ALOHA packet, it can randomly draw a number of frames. Ignoring any frame time that does not have available bandwidth from above, the transceiver 250 will preferably send a single burst during a randomly selected frame time and wait for the acknowledgment. If it does not receive an acknowledgment or the acknowledgment is lost, it can repeat the transmission of the ALOHA packet up to a number of repetitions indicated in the SFNP by using a so-called "diverse ALOHA" approach.

The ICAP packet (see Table 3) may be used in conjunction with the DVB MPE protocol MAC addressing scheme to, among several reasons, explicitly acknowledge ALOHA bursts by using acknowledgment packets sent preferentially, for example, on an input group's multicast address to reduce NOC 210 output bandwidth. Tables 3a to 3d provide a selection of message acknowledgment types that are preferably supported by the system and method of the present invention.

While the ALOHA packet is outstanding, i.e. waiting for acknowledgment, the transceiver 250 will preferably monitor up to three input groups, i.e. one for an ALOHA acknowledgement, one for a new input group to be attempted and one for the previously assigned input group, for example, in the case a late acknowledgment or other message type is sent later on the previously assigned input group.

Upon receipt of an acknowledgment, the Bandwidth Allocation Packet (BAP) will preferably be used to define the current bandwidth allocation for all inputs associated with that input group. For each frame, receiver 410 may receive a different BAP from the input group for which it currently expects to receive bandwidth. In order to be able to send data and produce receipts, the receiver 410 may need to scan the entire input group table to derive the following fields that it may need: 1) Input Group - Since the receiver 410 can monitor two input groups, it will preferably confirm the input group based on the MAC address of the packet and only process the BAP for where it expects to use bandwidth. 2) Input index - This is the accumulated scour deviation per window size in a frame and can be used as an index in the frequency table in IGDP. 3) Frame number - This field can come directly from the frame number field in the package. 4) Shed Id - This can be the four least significant bits in an index in the shed allocation table in BAP (see table 4). 5) Scour variance - The accumulated scour variance preferably starts at zero and increases with each scour size. The shear deviation is preferably the accumulated shear deviation MOD window size of a frame (ie modulo division). 6) Shed size - This field can come directly from the shed allocation table and will preferably never cross a frame boundary. 7) Acknowledgment Variance - This is the index to the shed allocation table entries.

Preferably, IDGP will be able to use one package per entry group per frame, or 535 kbps of the bandwidth for 25 active users per entrance, 75 entrance routes per group, and 300 inputs for example. Since it is preferentially sent on the input group's multicast address, each receiver 410 only has to process 134 kbps. To try and ensure that active users do not have performance disruptions or data lost due to a load balancing in a return channel subsystem 510, adherence to the following rules by a remote user 240 would be preferred: 1) At least five frames before moving a remote user 240 to a different input group but on the same return channel subsystem 510, the remote user 240 must be notified so that it can begin monitoring both input group streams, and will need to continue monitoring both streams until all outstanding input acknowledgment packets (IAPs) are received or has been lost. See below and Table 5 for a description of the IAP. 2) There must be at least one frame time that has no bandwidth allocated between bursts that are allocated to different inputs. This is to ensure that the remote user 240 will be able to fill all of its allocated windows and still have at least one frame time to settle to a new frequency. This condition will preferably concern bursts defined over contiguous BAPs and when moving between input groups on the same RCS 510. 3) It is preferred that at least one complete frame with no bandwidth is allocated between a normal and a range measurement burst. This is to ensure that the transceiver 250 will be able to fill all of its allocated windows and still have at least one frame time for fine-tuning and adjusting transmission parameters. 4) After the BAP moving the remote user 240 to a different input group is sent, the RCS 510 will continue to receive bursts on the old input group for a time that exceeds the round time delay. The RCS 510 will preferably accept to acknowledge these frames and the remote user 240 will continue to monitor acknowledgments from the old input group. 5) Remote users 240 shall not have their bandwidth moved to another input group while still monitoring a previous input group from which it has recently been moved. 6) The transceiver 250 will preferably only be assigned multiple bursts during a single time frame if all are on the same input route, and all are gathered in the frame, but without the burst overhang to turn the RF XMTR 430 on and off for each packet. 7) All the sheds, except the last one, are preferably large enough for the maximum size of the packets (largest multiple of window size < 256, for example), but only for the first one that wants a shed overhang/aperture included in its size. 8) Once an assignment ID (see Tables 3a-3d) is assigned to a transceiver 250 for an input group, it will not change while the transceiver remains active except as part of being moved between input groups. 9) Once an assignment ID is assigned to a transceiver 250 for an input group, it should preferably be left idle for five superframe times after it is no longer in use.

The Input Acknowledgment Packet (IAP) in Table 5 is preferably used explicitly to acknowledge each input packet allocated bandwidth with a valid Cyclic Redundancy Code (CRC) regardless of whether any encapsulated data is present, to allow faster recovery from input packet errors. ALOHA and unassigned ranging packets are acknowledged explicitly (see Table 5). The IAP is preferred to use one package per entry group per frame, or approximately 57 kbps of the bandwidth for 25 active users per entrance, 75 entrances per group, and 300 inputs for example. Since the IAP is preferably sent on the input group's multicast address, each receiver 410 only has to process approximately 15 kbps. If the IAP is lost, the transceiver 250 will be able to automatically resend the packet. The loss of the IAP for a certain input group can be detected by the next IAP packet that is received, or if no IAP is received for four frame times for example.

For return channel message transmissions, the burst data frame may have specific structures for ALOHA bursts (ie, unallocated bandwidth), and when the bandwidth is allocated. Examples of the different types of packet overhangs preferably used for these two data frame structures are given in Tables 6 and 7 respectively. Two different overhang structures can be used to maximize the efficiency of allocated bandwidth messages, by minimizing the size of required message overhang. The RCS 510 can detect the type of shed from the frame numbering information in the packet overhang.

The input packet format may contain a variable size of the overhang and zero or more bytes for encapsulated datagrams. The encapsulated datagrams are sent as a continuous byte stream for concatenated datagrams, preferably with no relation to the input packet. Correct interpretation requires reliable, in-order processing of all data bytes, preferably only once. To solve problems due to data loss in the input, a selective acknowledgment such as a sliding window protocol can be used. As is the case for such sliding window protocols, the sequence number space will be at least twice the window size and data outside the window will be dropped by the receiver.

For allocated streams, i.e. where the bandwidth has been allocated to a remote user 240 (see Table 7), input burst data will preferably be retransmitted if there is no acknowledgment in the IAP for this frame number, or if the acknowledgment is lost. If a synchronization problem occurs, the RCS 510 can force the transceiver 250 to be inactive by removing its bandwidth allocation. This will preferably cause the transceiver 250 to reset its sequence numbers and datagram counters to zero and start at the beginning of a new datagram. Since the sequence number is preferably reset each time the transceiver 250 becomes active, any data sent in ALOHA or in unallocated ranging bursts could be duplicated due to retransmissions, if the acknowledgments are lost and also due to "diversity" ALOHA as discussed previously.

When reverse bursts are assigned to the same transceiver 250, it is preferred not to power down the device, and use the saved overhang associated with the burst processing to deliver additional "payload" or user message traffic. This will help to maintain a desired 1 to 1 relationship between allocated sheds and parcels.

In the system, apparatus and method of the present invention, and with a preferred remote user and return channel addressing plan, there will be essentially no limit on the number ("k") of remote users 240 that can use upline data in the return channel. A minimum of 2<24> (~16 million) transceivers is preferably supported in the addressing plan included in the DVB stream and more preferably up to 2 (~256 million) transceivers are supported.

Furthermore, because the return channel is preferred to be essentially a lossless channel, compression techniques can be effectively used to reduce bandwidth requirements. IP overhang compressions have the potential to provide a tremendous improvement in bandwidth since such compressions eliminate 10-15 bytes for each and every IP packet.

While a preferred embodiment has been described above in terms of a TDMA bandwidth or window allocation approach, this preferred embodiment is not to be considered limiting in any way and is provided by way of example only. As a further example, the method and system may provide bandwidth and frequency allocations over any type of communication system having multiple users sharing the same media, and may find particular application in any window timing system that requires bit timing management, i.e., a frequency timing system that uses a phase-locked loop (PLL) or frequency locked loop (FLL) based on the same time standard. In addition, although the present invention provides advantages in using TCP/IP applications, the system, apparatus and method of the present invention will not be limited to this choice of protocols.

It will be obvious that the present invention can be varied in many ways. Such variations are not to be regarded as departing from the spirit and scope of the invention, and all such modifications which are obvious to one skilled in the art are intended to be included within the scope of the following claims. The breadth and scope of the present invention is therefore limited only to the scope of the appended claims and their equivalents.

Claims (141)

1. Control station for two-way satellite communication, characterized by: RF section to send a broadcast signal and to receive a return channel from a remote user; and return channel subsystem including a return channel controller for processing return channel information and setting a user bandwidth in the return channel. 2. Control station according to claim 1, where the return channel subsystem is further characterized by containing a sweep channel demodulator which demodulates the return channel information. 3. Control station according to claim 2, characterized in that the return channel control device controls the scour channel demodulator. 4. Control station according to claim 2, characterized in that the return channel control device reserves the sweep channel demodulator to the remote user based on a bandwidth allocation request given in the return channel information. 5. Control station according to claim 1, characterized in that the return channel control device sets the user bandwidth in the return channel by evaluating a user lag indicator provided by the remote user in the return channel message. 6. Control station according to requirement 5, characterized in that the return channel message is an ALOHA burst message. 7. Control station according to claim 6, characterized in that the ALOHA burst message contains a bandwidth allocation request. 8. Control station according to claim 7, characterized in that the return channel control device periodically allocates bandwidth to the remote user in response to the bandwidth allocation request. 9. Control station according to claim 6, characterized in that the ALOHA burst message contains an information packet of a predetermined window size. 10. Control station according to claim 5, characterized in that the return channel control device allocates bandwidth if the user delay indicator is greater than a threshold value. 11. Control station according to claim 1, characterized in that the return channel control device further assigns a frequency to the return channel. 12. Control station according to claim 11, characterized in that the return channel control device allocates the frequency in the return channel through an input allocation packet given to the remote user through a broadcast signal. 13. Control station according to claim 11, characterized in that the return channel control device changes the frequency of the return channel from a first frequency to a second frequency where the first and the second frequency are within a first return channel group and a second return channel group respectively. 14. Control station according to claim 1, characterized in that the return channel control device changes a frequency in the return channel. 15. Control station according to claim 14, characterized in that the return channel control device changes the frequency in the return channel from a first frequency to a second frequency where the first and the second frequency are each within the same return channel group. 16. Control station according to claim 1, characterized in that the broadcast signal is an asynchronous DVB transport stream. 17. Control station according to claim 1, characterized in that the return channel information is provided in a TDMA signal. 18. Control station according to claim 1, characterized in that the return channel controller allocates a power access return channel to the remote user based on a bandwidth allocation request given in the return channel information. 19. Control station according to claim 18, characterized in that the return channel control device assigns a dedicated frequency to the remote user. 20. Control station according to claim 18, characterized in that the return channel control device changes an assigned frequency to the remote user. 21. Control station according to claim 1, characterized in that the return channel control device sets the user bandwidth of the return channel by providing a bandwidth allocation packet to the remote user over the broadcast signal. 22. Control station according to claim 1, characterized in that the return channel control device assigns the frequency to the return channel by evaluating a user lag indicator provided by the remote user in a return channel message. 23. Control station according to claim 1, characterized in that the RF section receives a plurality of return channels from a plurality of distant users and where said return channel subsystem processes return channel information from the plurality of return channels and sets respective user bandwidths in each of the plurality of return channels. 24. Control station according to claim 23, characterized in that a subset of the plurality of return channels is configured to support ALOHA burst transmissions. 25. Control station according to claim 23, characterized in that the return channel subsystem further includes a plurality of sweep channel demodulators where each is assigned an associated one of the plurality of return channels to demodulate respective return channel information. 26. Control station according to claim 23, characterized in that the return channel control device allocates bandwidth to each of the plurality of return channels based on a predetermined traffic load. 27. Control station according to claim 23, characterized in that the return channel control device allocates bandwidth to part of the plurality of return channels based on a predetermined traffic load and an assigned bandwidth for at least part of the plurality of return channels based on a bandwidth allocation request. 28. Control station according to claim 23 characterized in that the return channel control device provides a load status for a plurality of return channel groups and a load status for a plurality of return channels over an input group definition packet provided to the remote user through the broadcast signal. 29. Transceiver to send a frame-synchronized message to a control node, characterized by : receiver detecting a control node timing message in a received broadcast signal; time recovery section that uses the control node time message to determine a transmit frame start time; message buffer that stores an outgoing user message; and transmitter adapted to transmit up to a satellite the outgoing user message on a transmitter frequency during an assigned period after the time of the frame start time wherein the transmitter frequency is determined by a first input group definition packet received in the broadcast signal wherein the first input group definition packet is associated with a first return channel group. 30. Transceiver according to claim 29 further characterized by a processor which provides a traffic downstream indicator included in the outgoing user message. 31. Transceiver according to claim 29, characterized in that the transmitter frequency is in the first return channel group. 32. Transceiver according to claim 31, characterized in that the transmitter frequency is changed to a different transmitter frequency in the first return channel group based on the first input group's definition packet received in the broadcast signal. 33. Transceiver according to claim 31, characterized in that the receiver receives a second input group definition packet in the broadcast signal and the transmitter frequency is changed to a different transmitter frequency in a second return channel group based on the second input group definition packet. 34. Transceiver according to claim 33, characterized in that the receiver monitors both the first and the second input group definition packet in the broadcast signal after the uplink bandwidth has been allocated by the control node. 35. Transceiver according to claim 33, characterized in that the transmitter frequency is changed a predetermined number of frames after the receiver receives a second input group definition packet. 36. Transceiver according to claim 31, characterized in that the transmitter frequency is changed to a different transmitter frequency in a second return channel group by using a random weighting based on a return channel group load factor. 37. Transceiver according to claim 29, characterized in that the allocated period includes at least one TDMA window after the transmitter frame start time. 38. Transceiver according to claim 37, characterized in that the allocated period is determined by a bandwidth allocation packet received in the broadcast signal. 39. Transceiver according to claim 37, characterized in that the bandwidth allocation package allocates a current bandwidth where an entry of TDMA windows in a message frame is dedicated to the outgoing user messages. 40. Transceiver according to claim 29, characterized in that the allocated period is determined by a predicted traffic load established in the control node. 41. Transceiver according to claim 29, characterized in that the received broadcast signal is an asynchronous DVB transport stream. 42. Transceiver according to claim 29, characterized in that the receiver monitors a plurality of input group definition packets where each corresponds to a specific one of a plurality of return channel groups. 43. Transceiver according to claim 42, characterized in that the transmitter frequency is assigned to be in the first return channel group based on a group load factor received in the broadcast signal. 44. Transceiver according to claim 42, characterized in that the transmitter frequency is changed to be in a different return channel group based on a group load factor received in the broadcast signal. 45. Transceiver according to claim 42, characterized in that the transmitter frequency is changed to a different group of the plurality of return channel groups based on a random weighting factor given in the broadcast signal. 46. Transceiver according to claim 29, characterized in that the outgoing user message is encrypted. 47. Transceiver according to claim 29, characterized in that the outgoing user message is compressed according to a lossless compression standard. 48. Transceiver according to claim 29, characterized in that the outgoing user message is sent on a lossless return channel. 49. Transceiver according to claim 29, characterized in that the outgoing user message is modulated on the transmitter frequency by using a QPSK modulation plan. 50. Transceiver according to claim 49, characterized in that the QPSK modulation plan is an offset QPSK (OQPSK) plan. 51. Transceiver according to claim 29, characterized in that the outgoing user message is limited to a maximum bandwidth of the control node. 52. Transceiver according to claim 29, characterized in that the outgoing user message is in an ALOHA burst format. 53. Transceiver according to claim 52, characterized in that the ALOHA shed sends the outgoing user message at least twice. 54. Transceiver according to claim 52, characterized in that the ALOHA burst is retransmitted a maximum number of times indicated in a message received in the broadcast signal. 55. Transceiver according to claim 52, characterized in that the outgoing user message contains a bandwidth allocation request. 56. Transceiver according to claim 52, characterized in that the ALOHA burst is a windowed ALOHA burst aligned with the transmitter frame start time. 57. Transceiver according to claim 52, characterized in that the outgoing user message has a size smaller than a predetermined threshold value. 58. Procedure for controlling a return channel from a control station, characterized by: to transmit a broadcast signal; receiving a return channel line from a remote user; and setting a return channel bandwidth with a return channel controller providing a bandwidth allocation message in the broadcast signal. 59. Method according to claim 58 further characterized by demodulating the received return channel upline with a sweep channel demodulator controlled by the return channel control device. 60. Method according to claim 58, characterized in that the return channel bandwidth is set by evaluating a lag indicator provided by the remote user in a return channel message. 61. Method according to claim 60, characterized in that the return channel control device allocates bandwidth if the lag indicator is greater than a threshold value. 62. Method according to claim 60, characterized in that the return channel line is an ALOHA type burst message. 63. Method according to claim 62, characterized in that the ALOHA type of the scan message is a windowed ALOHA message. 64. Method according to claim 58, characterized in that the broadcast signal is an asynchronous DVB transport stream. 65. Method according to claim 58, characterized in that the return channel line is a TDMA signal. 66. Method according to claim 58, characterized in that the return channel control device controls a frequency in the return channel upline through an assignment message given to the remote user through the broadcast signal. 67. Method according to claim 66, characterized in that the return channel control device changes the frequency in the return channel line from a first frequency to a second frequency where the first and the second frequency are each within a first return channel group. 68. Method according to claim 66, characterized in that the return channel control device changes the frequency in the return channel line from a first frequency to a second frequency where the first and the second frequency are in a first return channel group and a second return channel group respectively. 69. Method according to claim 58, characterized in that the return channel bandwidth is set according to a bandwidth allocation request received in the return channel upline. 70. Method according to claim 69, characterized in that the return channel control device periodically allocates bandwidth to the remote user. 71. Method according to claim 70, characterized in that the return channel control device allocates a current bandwidth to the remote user. 72. Method according to claim 71, characterized in that the return channel control device assigns a dedicated return channel line frequency to the remote user. 73. Procedure according to claim 58 further characterized by: receiving a plurality of return channel uplines from a plurality of remote users; and setting a return channel bandwidth for each of the plurality of return channel lines with the return channel controller. 74. Method according to claim 73, characterized in that the return channel control device controls a frequency for each of the plurality of return channel uplines through an allocation message. 75. Method according to claim 73, characterized by setting a return channel bandwidth for each of the plurality of return channel uplinks includes predicting a return channel traffic load. 76. Method according to claim 73, characterized in that a return channel bandwidth for a part of the plurality of the return channel uplinks is set using an assumed return channel traffic load, and a return channel bandwidth for at least one of the plurality of the return channel uplinks is set based on a bandwidth allocation request sent in the at least one of the plurality of said return channel lines. 77. Method according to claim 73, characterized by setting a return channel frequency for each of the plurality of return channel uplinks is based on evaluating a traffic load for each of the plurality of return channel uplinks. 78. Method according to claim 73, characterized by a group load factor for each of a plurality of return channel groups is periodically sent in the broadcast signal. 79. Method according to claim 78, characterized by a frequency for each of the plurality of return channel lines is determined by a corresponding group load factor. 80. Method according to claim 78, characterized by a bandwidth for each of the plurality of return channel lines is determined by a corresponding group load factor. 81. Method according to claim 73, characterized by setting a return channel group for each of the plurality of return channel lines is based on evaluating a traffic load for each of a plurality of return channel groups. 82. Method for sending a frame synchronized message, characterized by receiving a control node time message in a broadcast signal; determining a return channel frame start time using the control node timing message; to save an outgoing user message; and sending the outgoing user message during an allocated period after the return channel frame start time where a transmitter frequency is determined by an allocation message received in the broadcast signal. 83. Method according to claim 82 further characterized by evaluating the stored outgoing user message and sending a traffic backlog indicator. 84. Method according to claim 82, characterized in that the allocation message is associated with a first return channel group and the transmitter frequency is in the first return channel group. 85. Method according to claim 84, characterized in that the transmitter frequency is changed to a different transmitter frequency in the first return channel group based on said allocation message. 86. Method according to claim 84, characterized in that the transmitter frequency is changed to a different transmitter frequency based on a traffic load factor. 87. Method according to claim 82, characterized in that the transmitter frequency is changed from a first return channel group to a different transmitter frequency in a second return channel group. 88.' Method according to claim 82 further characterized by changing the transmitter frequency to a different transmitter frequency based on a randomly weighted frequency selection based on a traffic load factor. 89. Method according to claim 82 further characterized by monitoring a previous return channel group and a current return channel group after the transmitter frequency has been assigned to the current return channel group. 90. Method according to claim 82, characterized in that the transmitter frequency is changed to a different transmitter frequency a predetermined number of frames after receiving the allocation message. 91. Method according to claim 82, characterized in that the allocation period is determined by a bandwidth allocation message received in the broadcast signal. 92. Method according to claim 82, characterized in that sending the outgoing user message includes sending an ALOHA scan message. 93. Method according to claim 92, characterized in that the ALOHA shed sends the outgoing user message at least twice. 94. Method according to claim 93, characterized in that the ALOHA burst is sent a maximum number of times as indicated in a message sent in the broadcast signal. 95. Method according to claim 92, characterized in that the ALOHA burst message includes a bandwidth allocation request. 96. Method according to claim 82 further characterized by encryption of the outgoing user message. 97. Method according to claim 82, characterized in that the outgoing user message is sent in a TDMA format. 98. Method according to claim 97, characterized in that sending the outgoing user message includes sending a windowed ALOHA burst message aligned with the return channel frame start time. 99. Method according to claim 97, characterized in that the allocated period includes at least a time window after the return channel frame start time as determined by a bandwidth allocation message received in the broadcast signal. 100. Method according to claim 82 further characterized by compressing the outgoing user message by using a lossless compression standard. 101. Method according to claim 82, characterized in that sending the outgoing user message includes modulating the transmitter frequency using a QPSK modulation scheme. 102. Method according to claim 82 further characterized by limiting the outgoing user message to a maximum bandwidth less than a current bandwidth. 103. Communication system to balance traffic on a variety of return channels which are characterized by : control station for sending a broadcast signal to a remote user, said broadcast signal including a non-true time frame marker, a timing message, and a return channel control message; receiver at the remote user to receive the broadcast signal and to determine a return channel frame start time using the non-real time frame marker and the timing message; and transmitter at the remote user to transmit up to a satellite a user message on one of the return channels in the plurality of return channels during a predetermined period after the return channel frame key start time is given where an upline frequency to said to said return channel is determined in the return channel control message. 104. Communication system according to claim 103, characterized by a bandwidth of said one of the return channels is determined in the return channel control message. 105. Communication system according to claim 103 further characterized by a return channel control device in the control station where said return channel control device provides the return control message. 106. Communication system according to claim 105, characterized in that the return channel control device further provides a bandwidth allocation message in the broadcast signal which sets a bandwidth in said one of the return channels. 107. Communication system according to claim 106, characterized in that the bandwidth of said one of the return channels is set based on an assumed load factor. 108. Communication system according to claim 105, characterized in that the bandwidth of said one of the return channels is set by evaluating a user lag indicator sent by the remote user to the control station. 109. Communication system according to claim 108, characterized in that the bandwidth of said one of the return channels is set to a current bandwidth. 110. Communication system according to claim 108, characterized in that the upline frequency of said one of the return channels is set to a dedicated frequency based on an evaluation of the user lag indicator. 111. Communication system according to claim 105, characterized in that the return channel control device changes the upline frequency to a different frequency within a first return channel group. 112. Communication system according to claim 105, characterized in that the return channel control device changes the upline frequency to a different frequency in a second return channel group. 113. Communication system according to claim 112, characterized in that the return channel control device changes the uplink frequency to a different frequency based on a system load factor. 114. Communication system according to claim 103, characterized by a bandwidth of said one of the return channels is determined by a bandwidth allocation request included in the user message sent by the remote user. 115. Communication system according to claim 114, characterized in that the user message is an ALOHA type burst transmission. 116. Communication system according to claim 115, characterized in that the user message includes the bandwidth allocation request and an additional user message where the aforementioned additional user message has a size that is smaller than a predetermined threshold value. 117. Communication system according to claim 103, characterized in that the broadcast signal is an asynchronous DVB transport stream. 118. Communication system according to claim 103 further characterized by a plurality of remote users who share the plurality of return channels and a return channel control device where the return channel control device controls the upline frequency for each of the plurality of return channels through the return channel control message. 119. Communication system according to claim 118, characterized in that the return channel control device controls a bandwidth allocation for each of the plurality of return channels. 120. Communication system according to claim 118, characterized in that a subset of the plurality of return channels are ALOHA sweep channels, and where the return channel control device switches a remote user upline from an ALOHA sweep channel to a non-ALOHA sweep channel in accordance with the return channel control message. 121. Communication system according to claim 120, characterized in that the ALOHA sweep channel is selected from the subset of the plurality of return channels by the remote user using a randomly weighted frequency selection criterion. 122. Communication system according to claim 120, characterized in that the non-ALOHA sweep channel is selected by the control station by using a group load factor. 123. Communication system according to claim 103, characterized in that the broadcast signal is encapsulated in an IP/DVB protocol layer. 124. Communication system according to claim 103 further characterized by a communication satellite which brings forward the transmitted broadcast signals to the receivers. 125. Procedure for balancing the load among and between groups of return channels in a communication system, characterized by: requesting return channel bandwidth in an uplink message from a remote user to a control station where the uplink message includes a lag indicator; allocating at least one return channel bandwidth for the remote user by processing the backlog indicator; to provide a channel assignment message from the control station to the remote user in a broadcast signal where the channel allocation message at least allocates the return channel bandwidth; and sending a user message on a return channel according to the channel allocation message. 126. Method according to claim 125 further characterized by assigning a return channel line frequency. 127. Method according to claim 126, characterized in that assigning the channel uplink frequency includes changing an uplink frequency from a first frequency to a second frequency. 128. Method according to claim 127, characterized in that the upstream frequency is changed to balance a traffic load between the groups of the return channels. 129. Method according to claim 127, characterized in that the alignment frequency is changed based on a group load factor. 130. Method according to claim 127, characterized in that the first frequency and the second frequency are assigned to a first return channel group. 131. Method according to claim 127, characterized in that the first frequency and the second frequency are assigned to a first return channel group and a second return channel group respectively. 132. Method according to claim 126, characterized in that assigning the return channel uplink frequency includes a frequency hopping in an uplink frequency between a predetermined number of uplink frequencies according to a dynamic system traffic load. 133. Method according to claim 132, characterized in that allocating the return channel uplink frequency by frequency hopping further depends on a plurality of lag indicators from a plurality of remote users. 134. Method according to claim 132, characterized in that the predetermined number of upline frequencies is assigned to a return channel group. 135. Method according to claim 132, characterized in that the frequency hopping balances a traffic load within a first return channel group. 136. Method according to claim 125, characterized in that requesting return channel bandwidth includes sending an ALOHA burst transmission from the remote user. 137. Method according to claim 125, characterized in that the return channel bandwidth is allocated to at least to allow a user message less than a predetermined threshold value to be sent up. 138. Method according to claim 125, characterized in that part of the available return channels are ALOHA scan return channels. 139. Method according to claim 125, characterized in that the control station periodically sends a group load factor for each of the groups in the return channels. 140. Method according to claim 125, characterized in that requesting return channel bandwidth includes sending a first ALOHA type burst transmission from the remote user on an ALOHA channel. 141. Method according to claim 125 further characterized in that the remote user selects the return channel from one of the groups of return channels by using a randomly weighted factor based on a system traffic load.