Patent Description:
A satellite communications network to which the present invention may be applied includes a constellation of satellites (e.g., a constellation of non-geostationary satellites like a constellation of low earth orbit - LEO - satellites, e.g.,<NUM> - <NUM>,<NUM> above the Earth's surface)) interconnected by satellite-to-satellite communication links. One example of such a satellite communications network is the current Iridium® constellation. Another example of such a satellite communications network is the Iridium NEXT constellation currently under development.

<FIG> illustrates, schematically, the topology of an example of such a satellite network <NUM> (e.g., a constellation of non-geostationary satellites in LEO. As illustrated in <FIG>, this network comprises <NUM> satellites (referenced <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), <NUM> on each one of <NUM> orbital planes O1 - <NUM>, the orbital planes being spaced approximately <NUM> degrees apart. As illustrated, the orbits are nearly polar (e.g., the orbits have an inclination of approximately <NUM>°) and are substantially circular (e.g., at a height of approximately <NUM> above the earth). In some implementations, the orbital period may be about (or on the order of) <NUM> minutes.

Individual satellites communicate with neighboring satellites via satellite-to-satellite communication links ("cross-links"). As illustrated in <FIG>, an individual satellite may be cross-linked to four neighboring satellites: two to neighbors fore and aft in the same orbital plane and two to satellites in neighboring planes to either side. In some implementations, the cross-links may be implemented in the Ka frequency band. As illustrated in <FIG>, in some implementations, near the North Pole NP and the South Pole SP, there may be no cross-links between satellites in adjacent planes. Moreover, although orbital planes O1 and O6 are adjacent, their satellites orbit in opposite directions. Therefore, in some implementations, there may be no cross-links between the satellites in orbital planes O1 and <NUM>.

As illustrated in <FIG>, the satellite communications network also includes <NUM> ground stations: GS1 (e.g., situated in Hawaii (USA)), GS2 (e.g., situated at Fairbanks (Alaska, USA)), GS3 (e.g., situated in Tempe (Arizona, USA)), GS4 (e.g., situated in Svalbard (Norway)), and GS5 (e.g., situated in Yellowknife (Northwest Territories, Canada)). At any given time, one or more satellites may be connected to one or more ground stations (e.g., by feeder link(s)). For example, as illustrated in <FIG>, satellite <NUM> is connected to GS1, satellite <NUM> is connected to GS2, satellites <NUM> and <NUM> are connected to GS3, satellites <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> are connected to GS4, and satellites <NUM>, <NUM>, <NUM> and <NUM> are connected to GS5. In some implementations, feeder links between satellites and ground stations may be implemented in the K frequency band.

Although not illustrated in <FIG>, additional terrestrial terminals (e.g., mobile satellite terminals like satellite telephones and other mobile satellite communications devices) may establish connections with one or more of the satellites, for example, for the purpose of routing communications from the terrestrial terminals to other terrestrial destinations and/or vice versa via the satellite communications network (and, in some cases, one or more other networks (e.g., the public switched telephone network (PSTN), the Internet, etc.)). In some implementations, such connections between satellites and terrestrial mobile satellite terminals may be implemented in the L frequency band.

<FIG> illustrates the network topology at a given point in time. However, the topology changes over time due to the movements of the satellites along their orbits and/or the rotation of the earth. For example, a few minutes after the point in time illustrated in <FIG>, the cross-link between satellites <NUM> and <NUM> may be broken (e.g., as satellites <NUM> and <NUM> near the south pole), while a cross-link between satellites <NUM> and <NUM> may be established (e.g., as satellites <NUM> and <NUM> move away from the south pole), satellite <NUM> may establish a connection with GS5 (e.g., as satellite <NUM> nears the north pole and the earth rotates), satellite <NUM> may break its connection with GS5 and establish a new connection with GS4, and satellite <NUM> no longer may be connected to a ground station.

As illustrated in <FIG>, the satellites and ground stations represent nodes of the satellite communications network. Data (e.g., packets), representing e.g. phone calls or other communications, may be routed between satellites and/or one or more ground stations in order for the data to be transmitted from its origin (e.g., a mobile satellite terminal) to its intended destination (e.g., a ground station for routing to a terrestrial terminal via another network like the PSTN or the Internet).

The satellite network <NUM> may employ various different techniques to handle problems (e.g., failure and/or congestion) with the cross-links between individual satellites. For example, in the event that a satellite detects a problem (e.g., failure or congestion) with a cross-link that it intended to use to transmit data to another satellite, the satellite may use another of its cross-links to transmit the data to a different satellite to enable the data to progress toward its ultimate destination. This technique may be referred to as local rerouting and an example is illustrated in <FIG>.

As illustrated in <FIG>, reference R1 identifies a route determined for a packet to traverse to reach satellite <NUM> from satellite <NUM>. The packet follows route R1 until it reaches satellite <NUM>. However, as illustrated in <FIG>, satellite <NUM> has detected that its cross-link with satellite <NUM> is experiencing a problem (e.g., failure and/or congestion). Therefore, route R1 is interrupted and a new route is determined to route the packet to satellite <NUM>. In particular, satellite <NUM> redirects the packet along route R2, allowing it to eventually reach its destination of satellite <NUM>. When such local rerouting is performed, to prevent the packet from being routed back to satellite <NUM>, a "no u-turn" function may be implemented. However, this function can be defeated by a failed link (e.g., if the cross-link between satellites <NUM> and <NUM> experiences a problem). Furthermore, the local rerouting solution may lead to sub-optimal routing, and, in some cases, even to deadlocks. Moreover, local rerouting may not allow for efficient and/or effective congestion management.

<NPL>, describes a fault-tolerant satellite communications network comprising a constellation of satellites and at least one ground station. The satellites are interconnected by satellite-to-satellite communication links and at least some of them are connected to a ground station by a ground-satellite communication link. Different routing tables are computed corresponding to respective fault scenarios and uploaded to the satellites, which use them for transmitting data upon the realisation of one said fault scenario.

<NPL> describes a satellite network wherein multi-path routing is used to avoid congested inter-satellite links.

Also, <CIT> teaches computing and using multiple routes to allow adaptative rerouting by satellite payloads when they encounter network failures or congestion conditions.

The invention aims at mitigating the above-mentioned drawbacks of the prior art, and more specifically of the local rerouting technique, potentially allowing for more efficient management of problematic cross-links (e.g., failed and/or congested cross-links) in a satellite communications network.

An object of the present invention, allowing achieving this aim, is a method of operating a satellite communication network comprising a constellation of satellites interconnected by satellite-to-satellite communication links, wherein individual ones of said satellites are configured to connect to at least one ground station by a ground-satellite communication link; the method comprising:.

Another object of the present invention is a satellite communications network comprising a constellation of satellites and at least one ground station, said satellites being interconnected by satellite-to-satellite communication links and individual ones of said satellites being configured to connect to said or at least one said ground station by a ground-satellite communication link; wherein:.

Another object of the invention is a module of a satellite configured for incorporation within a satellite communications network that includes a constellation of satellites, said satellites being interconnected by satellite-to-satellite communication links and said module including logic elements configured to:.

Particular aspects of such a method, such a satellite communications network, and such a satellite module constitute the subject-matter of the dependent claims.

Implementations described herein, including the above-described implementations, may include a method or process, a system, or computer-readable program code embodied on computer-readable media.

Additional features will become apparent from the subsequent description, taken in conjunction with the accompanying drawings, wherein:.

The invention may be applied to a satellite communication network of the kind described above with reference to <FIG>.

According to an aspect of the invention, cross-link problems (e.g., failure and/or congestion) in a satellite communications system may be addressed using routing tables that contain full descriptions of multiple routes between different source - destination satellite pairs (e.g., multiple routes between each possible source - destination satellite pair in the satellite communications network) and alert messages transmitted by satellites (or other nodes) experiencing problems (e.g., failure and/or congestion) with at least one of their cross-links.

In some implementations, each satellite receives, from a ground station (either directly or indirectly via one or more other satellites), a routing table that includes complete descriptions of a plurality of different routes linking it to all (or some subset of all of) the other satellites of the network. In other implementations, only some subset of the satellites may receive routing tables that include complete descriptions of pluralities of different routes linking them to all (or some subset of all of) the other satellites of the network. A "complete description" of a route may be, for example, an ordered list of nodes (e.g., satellites) forming the route. The routing table(s) distributed to the satellites may original from a terrestrial operations center.

In some implementations, there may be a hierarchical order between the routes linking a "source" satellite to a "destination" satellite. For example, one route may be designated as the "primary" route and be intended to be used as the default route; meanwhile, other routes may be designated as "backup" routes to be used in the event that one of the satellite-to-satellite links of the primary route experiences a problem (e.g., failure or congestion). Such backup routes also may have a hierarchical ordering defining the order in which they are to be used in the event of problems with cross-links in the different backup routes.

An example is illustrated in <FIG>. As illustrated in <FIG>, a primary route PR and three backup routes BR1, BR2 and BR3 have been defined between satellite <NUM> and <NUM>. The following Table <NUM> represents a portion of one example of a routing table for satellite <NUM> that shows examples of descriptions of these different routes linking satellite <NUM> to satellite <NUM>:.

As illustrated in Table <NUM>, the routing table for satellite <NUM> instructs satellite <NUM> to route a data packet destined for satellite <NUM> along the primary route PR, extending through satellites <NUM>, <NUM>, <NUM> and <NUM>, unless there is a problem (e.g., failure and/or congestion) with a cross-link within the primary route PR. Such a problem is illustrated in <FIG>, where there is a problem (e.g., failure and/or congestion) with the cross-link between satellites <NUM> and <NUM>. As described in greater detail below, satellite <NUM> will have received prior notification of this the problem impacting the cross-link between satellites <NUM> and <NUM> and, therefore, satellite <NUM> will choose to route the packet to satellite <NUM> using the first backup route BR1 instead of the primary route PR. In the event that backup route BR1 also is experiencing a problem with a cross-link, satellite <NUM> would use BR2 to route the packet to satellite <NUM> instead and so on.

In some implementations, the routing table for a satellite may include at least two routes for routing data from the satellite to a destination satellite that do not have any (or that have no more than some predefined number of) intermediary satellites in common.

In the example illustrated in Table <NUM>, each route between satellite <NUM> and <NUM> is characterized by a "status", which is illustrated in this example as taking one of two values: Inactive (I) (e.g., where one or more of the cross-links in the route are known to be experiencing a problem) or Active (A) (e.g., where none of the cross-links in the route are known to be experiencing a problem); this will be explained in greater detail below. In alternative implementations, the "status" may take one of three values: Active, Inactive (i.e. failed) and Congested. Such an approach may allow the satellites to route data differently depending on whether problems with cross-links are due to failures or congestion.

It should be noted that the routes linking satellite <NUM>, when it is the source node, to satellite <NUM>, when it is the destination node, may be the same as the routes linking satellite <NUM> to satellite <NUM> (albeit with satellites encountered in the reverse order) or different, depending on the particular implementation.

In one particular example of a satellite communications network, there are <NUM> satellites and each one uses a distinct routing table to route data through the satellite communications network, where each routing table comprises N><NUM> routes for each of the <NUM> possible destination satellites, plus the ground stations. In an example where N=<NUM> (e.g., where there is a primary route and three backup routes for each source - destination satellite pair), a route comprises on average <NUM> satellites (which may be more than the actual value), each satellite of the route is represented by a byte, and an additional byte is used to code the state of each route and, for the sake of simplicity, routes having a ground station as their destination are ignored, the set of all of the routing tables for a given topology may be represented in 66x65x(<NUM>+<NUM>) bytes, i.e. slightly more than <NUM> Kbytes.

In some implementations, the routing tables are transmitted to the satellites by the ground station(s), and the status of all of the routes in any given routing table may be set to "Active" by default. Depending upon the implementation, the routing table used by an individual satellite may be updated at each change of the network topology (which, e.g., may be due to the movement of the satellites along their orbits). Each routing table may be applicable during one or more predetermined active periods (e.g., periods during which the routing table corresponds to the current topology of the satellite communications network). In some implementations, several routing tables are uploaded to individual satellites in advance of their active periods, e.g. several days before. In such implementations, the individual satellites may update their active routing tables themselves, and the synchronization of this updating may be achieved automatically. A ground station may upload routing tables to a satellite when the satellite is connected to the ground station, or routing tables may be routed from the ground station to the satellite across the satellite communications network (e.g., using the routing table(s) of the relevant satellite(s) which are active at the time of the upload) if the satellite is not connected to the ground station.

In order to enable individual satellites to make intelligent choices about which routes listed in their routing tables to use to route data to particular destinations, some or all of the satellites are made aware of known problems (e.g., failures and/or congestion) in the satellite communications network. For example, a satellite experiencing a cross-link failure and/or congestion may initiate an alert (e.g., an alert packet) identifying the problem and/or its location which is transmitted to some or all of the other satellites. In some implementations, conventional flooding algorithms may be used to ensure distribution of the alert to all of the satellites via the satellite-to-satellite links. Such techniques may converge quickly due to the moderate size of a typical satellite communications network.

Various different techniques may be employed to detect a problem in the satellite communications network. For example, an individual satellite may have one or more modems and use the modem(s) to detect problems with its cross-links. In such implementations, the modem on a satellite can detect the failure of one of its cross-links by, for example, monitoring its synchronization state. If the modem detects that the cross-link is synchronized, the modem may determine that the cross-link is functional. In contrast, if the modem detects that the cross-link is not synchronized, the modem may determine that the cross-link has failed. Moreover, a satellite can determine that one of its cross-links is congested, for example, by comparing the known capacity of the cross-link to the current traffic on the cross-link. The described techniques for detecting problems (e.g., cross-link failure and/or congestion) in the satellite communications network are non-exhaustive examples. Other techniques may be employed for detecting problems (e.g., cross-link failure and/or congestion) in the satellite communications network.

Referring again to the example illustrated in <FIG>, when satellite <NUM> determines or otherwise becomes aware that there is a problem (e.g., failure and/or congestion) with its cross-link to satellite <NUM>, it generates an alert message AM indicating "link <NUM> - <NUM> interrupted" and initiates the distribution of the alert message through the satellite communications network by sending it through its remaining cross-links (in the example considered here, the cross-link with satellite <NUM> is its only remaining cross-link). As illustrated in <FIG>, that alert message AM emitted by satellite <NUM> may reach satellite <NUM> at time "t", then satellite <NUM> at time "t+<NUM>", satellites <NUM> and <NUM> at time "t+<NUM>", satellites <NUM>, <NUM>, <NUM> and <NUM> at time "t+<NUM>" and so on. In some implementations, satellite <NUM> also may detect the problem with the cross-link and send a similar (or the same) alert message.

When an individual satellite in the satellite communications network receives the alert message AM, it may change the status of all the routes in its active routing table that include the cross-link between satellites <NUM> and <NUM> to "Inactive", for example, as illustrated in Table <NUM>.

Other implementations are possible. For instance, each satellite could store a list of problematic (e.g., failed and/or congested) links and use the list to determine, on the fly, the highest-priority active route to a destination when the satellite needs to transmit data to the destination. Additionally or alternatively, in some implementations, when a cross-link is experiencing congestion, already-established, active connections may be allowed to continue to use the congested cross-link, but new connections may be discouraged (or prevented) from using the cross-link by using backup routes that utilize different cross-links instead. Such an approach may allow for a progressive de-congestion of the congested cross-link.

In some implementations, if a problem in the satellite communications network (e.g., the failure of the cross-link between satellites <NUM> and <NUM> illustrated in <FIG>) is resolved, one or more satellites that detect or otherwise become aware of the resolution (e.g., satellites <NUM> and <NUM>) may distribute "end-of-alert" messages, for example, using the same mechanism(s) used to distribute the original alert message, and satellites that receive such "end-of-alert" messages may change the status of implicated routes from "Inactive" or "Congested" to "Active" (or withdraw the <NUM> - <NUM> link from their list of failed/congested links).

In situations where the problem with a problematic cross-link is congestion, it may be advantageous to implement a mechanism to avoid rapid oscillations between statuses of problematic and non-problematic. For example, a non-congested cross-link may be determined to become congested when the traffic on the cross-link exceeds a first threshold T1 while a congested cross-link may be determined to become non-congested when the traffic on the cross-link decreases below a second threshold T2, where T2<T1.

In some implementations, Quality-of-Service (QoS) levels associated with different types of traffic carried across the satellite communications network may be used in determining how to route different traffic in the satellite communications network, particularly in the case of congestion on one or more cross-links. For example, in one implementation, traffic may be assigned to one of four different QoS levels, QoS1, QoS2, QoS3, and QoS4, where QoS1 traffic is to be given priority over QoS2, QoS3, and QoS4 traffic, QoS2 traffic is to be given priority over QoS3 and QoS4 traffic, and so on. In such implementations, when different QoS level traffic is being considered for routing over a congested cross-link, higher priority QoS level traffic may be routed over the congested cross-link before lower priority QoS level traffic. For example, if the traffic being routed over a cross-link causes the traffic on the cross-link to exceed a threshold level of congestion, the link may be determined to be congested and routed away from the cross-link for the lowest priority QoS level of traffic currently being routed over the cross-link and each successive higher priority QoS level of traffic until the traffic being routed across the cross-link falls below an uncongested traffic level.

<FIG> illustrate one example. Referring first to <FIG> illustrates the current traffic load across the <NUM> - <NUM> satellite pair cross-link in a case where four different QoS levels - QoS1 to QoS4 - are present. FC represents the free capacity of the link. As illustrated in <FIG>, the sum of the QoS1 and QoS2 traffic does not exceed the congestion threshold CT, but, when the QoS3 and QoS4 traffic are considered, the traffic across the cross-link exceeds the congestion threshold CT. As a result, one or both of satellites <NUM> and <NUM> may determine that the cross-link is congested for QoS3 and QoS4 traffic and transmit an alert message indicating "link <NUM> - <NUM> congested for QoS3 and QoS4" for distribution through the satellite communications network. Consequently, satellites that receive this alert message may consider routes that include the <NUM> - <NUM> satellite pair cross-link to be "Active" for QoS1 and QoS2 traffic but "Inactive" for QoS3 and QoS4 traffic. This may eliminate (or at least reduce) the congestion of the cross-link, for example, as illustrated in <FIG>, thereby potentially providing better Quality-of-Service to the higher priority QoS1 and QoS2 traffic than the QoS3 and QoS4 traffic. Alternatively, in some implementations, all QoS4 traffic may be rerouted away from the <NUM> - <NUM> satellite pair cross-link while only a portion of the QoS3 traffic is rerouted.

<FIG> is a flowchart that illustrates a process <NUM> of determining a route for routing data in a satellite communications network (e.g., a satellite communications network that includes multiple satellites that are interconnected by satellite-to-satellite communication links, such as, for example, the example satellite communications networks described above). The process <NUM> may be performed by a satellite, or a module of a satellite, in the satellite communications network. For example, the satellite, or the module of the satellite, may include one or more logic elements (e.g., one or more processors, field programmable gate arrays (FPGAs), and the like) that are configured to perform the process.

As illustrated in <FIG>, a data structure (e.g., a routing table) that identifies different possible destinations (e.g., other satellites and/or ground stations) and defines multiple different routes for routing data from the satellite to the destinations is stored (<NUM>). For example, the data structure may be stored in a computer-readable storage medium on board the satellite.

At some point, an indication of a problem in the satellite network (e.g., a failure of and/or congestion in a cross-link) is received (<NUM>). For example, as described above, another satellite in the satellite communications network may detect a problem and transmit an alert message identifying the problem to other satellites in the satellite communications network. After the indication of the problem has been received, a determination is made that the problem impacts a first one of the routes defined in the data structure for routing data from the satellite to a particular destination (e.g., a particular satellite or ground station) (<NUM>). As a consequence of determining that the problem impacts the first route from the satellite to the particular destination, the data structure is updated to reflect that the first route has been impacted by the problem (<NUM>). For example, the data structure may be updated to reflect that a failure has occurred in the first route and/or that the first route is congested.

Thereafter, data to be routed from the satellite to the particular destination is received (<NUM>). In response to receiving the data to be routed from the satellite to the particular destination, the data structure is accessed and a determination is made that the first route for routing data from the satellite to the particular destination has been impacted by a problem (<NUM>). For example, a determination may be made that a failure has occurred in the first route and/or that the first route is congested. As a consequence of having determined that the first route has been impacted by a problem, a second route for routing data from the satellite to the particular destination is selected from the different routes for routing data from the satellite to the destination that are defined in the data structure (<NUM>). The data then may be routed (e.g., transmitted) to another satellite according to the selected route.

Aspects of the present disclosure may be implemented entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in combinations of software and hardware that may all generally be referred to herein as a "module," "component," or "system. " Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

Any combination of one or more computer-readable media may be utilized. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of such a computer-readable storage medium include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an appropriate optical fiber with a repeater, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

A computer-readable signal medium may include a propagated data signal with computer-readable program code embodied therein, for example, in baseband or as part of a carrier wave. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable signal medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF signals, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including object oriented programming languages, dynamic programming languages, and/or procedural programming languages.

The figures illustrate examples of possible implementations according to various aspects of the present disclosure. In this regard, each block in a flowchart may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order illustrated in a figure. It will also be noted that each block of a flowchart, and combinations of blocks in a flowchart, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Claim 1:
A method of operating a satellite communication network (<NUM>) comprising a constellation of satellites (<NUM> - <NUM>) interconnected by satellite-to-satellite communication links, wherein individual ones of said satellites are configured to connect to at least one ground station (GS1 - GS5) by a ground-satellite communication link; the method comprising:
- a step of transmitting, from said or at least one said ground station and using said or at least one said ground-satellite communication link, at least one respective routing table to each of a plurality of said satellites, each routing table comprising a list of destination satellites and, for an individual destination satellite, definitions of at least two possible routes (PR, BR1 - BR3) leading to it, the definition of a route comprising an ordered list of interconnected satellites linking a source satellite to a destination satellite;
- a step of transmitting, from a satellite experiencing a problem with a communication link interconnecting it to another satellite or to said or one said ground station, an alert message (AM) to at least some of the other satellites, said alert message identifying said communication link as problematic; and
- a step of routing data packets through said communication network, wherein individual satellites use corresponding ones of said routing tables to choose one of said possible routes for avoiding the communication link identified as problematic by an alert message.