Problem
Working on validation of OASIS project idea I faced a need to route data transmissions within global scale satellite constellation.
The problem appeared to be more complex than I expect from the beginning. The key complexity were:
- Lack of connectivity between nodes
- Window-based connections
- Low bandwidth/data ratio
- Dynamic topology on sphere
In other words, I faced a need to transmit high amounts of data through relatively low-speed links (low for required amounts of data) through dynamically changing “network” with unstable connections, moving in a complex way around very big rotating sphere.
Approach
Following my previous experience, I started from studying existing literature about the topic.
Common literature about communication networks and protocols, familiar for me from my first uni, contained nothing to help me. The problem was far out from generic computer networks.
SCPS, ITU, and documents from CCSDS contained some information, but was not too relevant for the problem – except two very interesting documents:
The description of everything in this papers was (as always in such documentation) slightly vague and very complex.
So I had to think myself.
Key insights
- Constellation is not a network.
Network is something connected relatively constant. Satellites in constellation can connect with each other only when they have LOS between each other. - Common address-based packet routing will not work here.
Because manually bind address means nothing in dynamically changing topology. - “High bandwidth” of laser link is low for given data amounts.
Amounts of data, gathered from commercial Earth observation satellites and processed on AI satellites, are very big, and transmission of them even through high-speed laser links takes time.
Conclusions
Following insights mentioned above, the routing system in satellite constellation must work different than any common routing we typically using in IT.
Main conclusions were:
- Data transfer routes must be plotted basing on actual spatial positions of the nodes, not on “network addresses”. I.e. (following conventions of ISO OSI model) routing must being done on physical, not on the network layer
- Shortest routes will be those which are physically shortest (i.e., closest to orthodromy)
- Because of relatively low bandwidth and high relative physical speed of nodes, routing must take in account not only their current positions, but their future positions
- Each node must be a router, i.e. have ability to calculate best route for further transmission of relaying data (or at least choose the best next node)
Routing logic
Is it possible to implement such routing? In case of satellite constellation – yes.
Satellites are moving following the laws of orbital mechanics. Their positions can be calculated and predicted with enough precision to choose proper (shorthest) route.
For relatively short periods (hours-days) it can be done on board of each satellite, utilizing daily-updated ephemerides of satellites of constellation (like in is done on GPS satellites).
Example of implementation
Here is a C# code snippet, realizing described routing system for my Unity simulation of OASIS constellation.
public static GameObject FindNextNodeFrom(List<GameObject> existingReceivers, GameObject currNode, GameObject destNode, double transmissionDuration)
{
if (destNode is null)
{
return null;
}
//Setting up "safe" radius of Earth with atmosphere, which will not block laser links.
double transmissionSafeRadius = Constants.Rearth + 100.0;
//Gathering orbital state of selected node (satellite)
InteractableObjectBehaviour currNodeInteractableObjectBehaviour = currNode.GetComponent<InteractableObjectBehaviour>();
(Vector vector_rNode, Vector vector_vNode) = currNodeInteractableObjectBehaviour.state;
//Selecting "visible" nodes - those which have LOS with current
List<GameObject> visibleReceivers = new List<GameObject>();
foreach (GameObject existingReceiver in existingReceivers)
{
(Vector vector_rRcvr, Vector vector_vRcvr) = existingReceiver.GetComponent<InteractableObjectBehaviour>().state;
if (Astrodynamics.Sight(vector_rRcvr, vector_rNode, transmissionSafeRadius))
{
visibleReceivers.Add(existingReceiver);
}
}
//Selecting "accessible" nodes - those which will have LOS with current on the end of transmission
(Vector vector_rNode1, Vector vector_vNode1) = currNodeInteractableObjectBehaviour.StateIn(transmissionDuration);
List<GameObject> accessibleReceivers = new List<GameObject>();
foreach (GameObject visibleReceiver in visibleReceivers)
{
(Vector vector_rRcvr1, Vector vector_vRcvr1) = visibleReceiver.GetComponent<InteractableObjectBehaviour>().StateIn(transmissionDuration);
if (Astrodynamics.Sight(vector_rRcvr1, vector_rNode1, transmissionSafeRadius))
{
accessibleReceivers.Add(visibleReceiver);
}
}
//Selecting the node which will be best for transmission, i.e., provide minimal angular distance towards the ground station.
InteractableObjectBehaviour destNodeInteractableObjectBehaviour = destNode.GetComponent<InteractableObjectBehaviour>();
(Vector vector_rDest, Vector vector_vDest) = destNodeInteractableObjectBehaviour.state;
double minDelta = double.MaxValue;
GameObject nextNode = null;
foreach (GameObject accessibleReceiver in accessibleReceivers)
{
(Vector vector_rRcvr, Vector vector_vRcvr) = accessibleReceiver.GetComponent<InteractableObjectBehaviour>().state;
double delta01 = Vector.AngleBetween(vector_rNode, vector_rRcvr);
double delta12 = Vector.AngleBetween(vector_rRcvr, vector_rDest);
double delta = delta01 + delta12;
if (delta < minDelta)
{
nextNode = accessibleReceiver;
minDelta = delta;
}
}
return nextNode;
}Algorithms & performance
Astrodynamics algorithms used in this code were taken from “Fundamentals of Astrodynamics and Applications”, Fourth Edition, by David Vallado. They are practically tested multiple times in different projects and have proven precision for practical space applications.
Despite this, they provide enough performance for usage in real-time simulation app for routing operations in simulated satellite constellation built with 192 node. Moreover, as you may notice, the routing does not cause FPS drops.
From this we may conclude that with improvements, such solution can be used even on real satellite hardware.