Automatic and Dynamic Logon Mechanism in Satellite Networks

• US 20090316616A1
• Filed: 06/18/2009
• Published: 12/24/2009
• Est. Priority Date: 06/20/2008
• Status: Active Grant

• Current Assignee: Gilat Satellite Networks Limited
• Original Assignee: Gilat Satellite Networks Limited
• Inventors: Nachman, Elad, Yitzhaki, Eldad, Laish, Isacc Ben, Goldshtein, Moti
• Granted Patent: US 8,248,985 B2
• Time in Patent Office: Days
• US Class Current: 370/312
• CPC Class Codes: H04B 7/18517 Transmission equipment in earth stations
• CPC Class Codes: H04B 7/18523 Satellite systems for providing broadcast service to terrestrial stations, i.e. broadcast satellite service arrangements specially adapted for satellite broadcast receiving H04H40/90; picture transmission via satellite H04N1/00103; television transmission via satellite H04N7/20
• CPC Class Codes: H04B 7/18584 Arrangements for data networking, i.e. for data packet routing, for congestion control data switching networks H04L12/00

Abstract

In a satellite communication network, a link between a remote terminal and a traffic processor located at the hub may be used for providing services over a satellite link, such as traffic routing, protocol acceleration, data compression and data encryption. Aspects of this invention relate to methods and apparatus for automatically and dynamically associating remote terminals with traffic processors. These methods may be used for simplifying the satellite network'"'"'s configuring process, especially for large scale networks, for offering load balancing between traffic processors and for offering an efficient automatic redundancy mechanism when a traffic processor malfunctions.

Claims

1. In a satellite communication network comprising a hub and plurality of remote terminals, a method for a remote terminal of dynamically associating the remote terminal with one of a plurality of traffic processors included in said hub, the method comprising:

receiving status messages from the plurality of traffic processors over a listening period, wherein the listening period is predefined or configurable;

identifying a status profile included in a received status message; and

selecting a suitable traffic processor based on the identified status profile.

2. The method of claim 1, wherein the received status messages are transmitted using a multicast service.

3. The method of claim 2, wherein the received status messages are transmitted by the plurality of traffic processors over a same multicast stream or multicast address.

4. The method of claim 1, wherein the received status messages are transmitted using a broadcast service.

5. The method of claim 1, wherein the status profile included in a received status message comprises one or more of the following characteristics or metrics:

a processor utilization metric, a memory utilization metric, a total traffic throughput metric, a total packet or frame rate metric, a supportable remote terminals metric and a currently logged on remote terminals metric.

6. The method of claim 1, wherein the received status messages further include information elements comprising one or more of the following:

a traffic processor identifier, a network address, one or more traffic filters associated with one or more data streams.

7. The method of claim 1, wherein selecting a traffic processor further includes:

calculating a rank figure for a first traffic processor using the status profile included in a status message received from said first traffic processor; and

selecting the first traffic processor as a suitable traffic processor based on the calculated rank figure and based on rank figures calculated for one or more other traffic processors from which status messages were received.

8. The method of claim 7, wherein calculating the rank figure comprises using weights for one or more characteristics or metrics included in a status profile.

9. The method of claim 8, wherein said weights are included in the status profile.

10. The method of claim 8, wherein said weights are predefined or configurable.

11. The method of claim 7, wherein selecting a suitable traffic processor further comprises the following steps:

comparing the calculated rank figure for the first traffic processor with a previous best rank figure already calculated during said listening period;

replacing the previous best rank figure and parameters of its associated traffic processor with the calculated rank figure and parameters of the first traffic processor respectively, if the calculated rank figure is better than the previous best rank figure; and

determining the suitable traffic processor as the traffic processor associated with the best rank figure at a time following the expiration of the listening period.

12. The method of claim 1, wherein selecting a suitable traffic processor further comprises the following steps:

calculating a first rank figure for a traffic processor using a first status profile included in a first status message received from said traffic processor during said listening period;

replacing said first rank figure for said traffic processor with a second rank figure calculated using a second status profile included in a second status message received from said traffic processor during said listening period;

upon expiry of said listening period, determining a best rank figure from one or more rank figures corresponding to one or more traffic processors for which status messages were received during said listening period; and

selecting as the suitable traffic processor a traffic processor corresponding to the best rank figure out of the one or more traffic processors.

13. The method of claim 1, further including the following steps upon expiry of said listening period:

determining whether at least one valid status message has been received during said listening period;

if a valid status message has not been received during said listening period, determining whether a further attempt to receive valid status messages is allowed; and

if a further attempt to receive valid status messages is not allowed, selecting a predefined default traffic processor.

14. The method of claim 1, further comprising the following steps after selecting a suitable traffic processor:

logging on to the selected traffic processor;

receiving a status message from a second traffic processor different from the selected traffic processor;

calculating a rank figure of the second traffic processor using a status profile included in said received status message from the second traffic processor;

comparing the rank figure of the second traffic processor with a rank figure of the selected traffic processor;

selecting the second traffic processor if its rank figure exceeds the rank figure of the selected traffic processor by more than a predetermined threshold; and

logging on to the second traffic processor.

15. In a satellite communication network comprising a hub and plurality of remote terminals, the hub further comprising a plurality of traffic processors, a method for said hub of dynamically associating each remote terminal with one of said plurality of traffic processors, the method comprising:

periodically transmitting status messages from each of the plurality of traffic processors to each of the plurality of remote terminals, wherein every transmitted status message includes a status profile associated with the traffic processor transmitting the status message; and

receiving at a first traffic processor a first log on message from a first remote terminal, wherein the first remote terminal selects to log on to the first traffic processor based on status profiles included in the status messages transmitted to the first remote terminal by the plurality of traffic processors.

16. The method of claim 15, wherein the status messages are transmitted using a multicast service.

17. The method of claim 16, wherein the status messages are transmitted by the plurality of traffic processors over a same multicast stream or multicast address.

18. The method of claim 15, wherein the status messages are transmitted using a broadcast service.

19. The method of claim 15, wherein the status profile included in a transmitted status message comprises one or more of the following characteristics or metrics:

a processor utilization metric, a memory utilization metric, a total traffic throughput metric, a total packet or frame rate metric, a supportable remote terminals metric and a currently logged on remote terminals metric.

20. The method of claim 15, wherein the transmitted status messages further include information elements comprising one or more of the following:

a traffic processor identifier, a network address, one or more traffic filters associated with one or more data streams.

21. The method of claim 15, further comprising the following steps:

transmitting a plurality of remote publish messages from the first traffic processor to the other traffic processors in said plurality of traffic processors, wherein each remote publish message includes at least one information record regarding a first remote terminal from which a log on message was received;

receiving said plurality of remote publish messages at a second traffic processor;

at the second traffic processor, identifying said first remote terminal from a record included in a remote publish message;

at the second traffic processor, removing information corresponding to the first remote terminal from a memory associated with the second traffic processor; and

sending messages in accordance with applicable protocols from first and second traffic processors to routers or networks coupled with a satellite network, said messages designed to advertise changes in at least one of the following;

routing tables, packet forwarding tables, network topology.

22. The method of claim 21, wherein transmitting remote publish messages further comprises the following steps:

creating a set of a predefined or a configurable number of empty lists;

setting a timer to a predefined or a configurable publishing interval;

upon receiving the first log on message from the first remote terminal, inserting a record associated with said first remote terminal into all said lists;

upon expiry of said timer, transmitting a first non-empty list in a remote publish message;

discarding said first non-empty list;

creating a new empty list;

setting said new empty list as the last in the set of lists; and

resetting said timer to said publishing interval.

23. The method of claim 21, wherein a first information record included in a remote publish message and transmitted by the first traffic processor, said first information record regarding the first remote terminal, includes information that the second traffic processor is configured to use for at least the purpose of:

determining whether a second remote terminal is logged on to the second traffic processor, wherein the first and second remote terminals are co-located and configured to employ redundancy;

removing information corresponding to the second remote terminal from a memory associated with the second traffic processor if the second remote terminal is logged on to the second traffic processor; and

sending messages in accordance with applicable protocols from the first and second traffic processors to routers or networks coupled with a satellite communication network, said messages designed to advertise changes in at least one of the following;

routing tables, packet forwarding tables, network topology.

24. The method of claim 23, wherein the information included in the first information record regarding the first remote terminal comprises identifiers of remote terminals configured to employ redundancy with the first remote terminal.

25. The method of claim 23, wherein the information included in the first information record regarding the first remote terminal comprises a virtual router IP address.

26. A satellite communication network comprising a hub, which further includes at least two traffic processors, and a plurality of remote terminals, wherein:

each traffic processor is configured to establish links with plurality of remote terminals once these remote terminals log on to it; and

each remote terminal is configured to dynamically select a traffic processor and log on to it, for at least the purposes of load balancing the network traffic or recovering from a traffic processor malfunction, or both.

27. The system of claim 26, wherein a remote terminal is configured to dynamically select a traffic processor and log on to it following the remote terminal being powered up or following restoration of a communication link between the remote terminal and the hub.

28. The system of claim 26, wherein a remote terminal is configured to dynamically select a traffic processor and log on to it in response to detecting that a more suitable traffic processor is available.

29. A remote terminal in a satellite communication network comprising:

a processor; and

memory storing computer readable instructions that, when executed, cause the remote terminal to;

receive status messages from a plurality of traffic processors in the satellite communication network over a listening period;

identify a status profile included in a received status message; and

select a suitable traffic processor based on the identified status profile.

30. A hub in a satellite communication network comprising:

a plurality of traffic processors; and

memory storing computer readable instructions that, when executed, cause the hub to;

periodically transmit status messages from each of the plurality of traffic processors to each of a plurality of remote terminals, wherein every transmitted status message includes a status profile associated with the traffic processor transmitting the status message; and

receiving at a first traffic processor a first log on message from a first remote terminal, wherein the first remote terminal selects to log on to the first traffic processor based on status profiles included in the status messages transmitted to the first remote terminal by the plurality of traffic processors.