LEO constellations create a network that includes the satellites (as routing nodes) connected by Inter-Satellite Links, and the satellite terminals dynamically connected to one or more satellites. The combination of transient, high-rate changes with high latency presents a unique challenge for designing a routing protocol that can provide guaranteed bandwidth, and support the frequent changes without packet drops. Current works focus on end-to-end routing between multiple gateways and terminals and do not provide guaranteed service.This paper addresses the problem of routing traffic from a source terminal to a destination terminal on a LEO constellation using Asymmetric Differential Routing (ADR) to plan ’semi-fixed’ routes. ADR keeps most of the planned route fixed and only minor (differential) adjustments are required to account for handovers.

A low earth orbit (LEO) observation satellite offers a shorter distance to the target area, low cost, and low communication latency. The low orbit translates to high orbital speed and results in short observation and communication contact periods. Swarms of multiple satellites offer extended coverage and spatial resolution for applications such as earth observation and monitoring. LEO communication satellite constellations create a network that includes hundreds to tens of thousands of satellites with onboard processing capabilities (as routing nodes) connected by Inter-Satellite Links (ISL) that provide continuous coverage of the earth. The LEO constellations aim to provide end-to-end routing between multiple gateways and terminals. This paper assumes the LEO constellation satellite payload includes sensors and processing capabilities. We explore the problem of managing an autonomous LEO virtual satellite swarm that will provide continuous and adjustable coverage. We preset a novel virtual swarm: a subset of the constellation satellites is dynamically assigned to the swarm when they cover the target area. The virtual swarm algorithm provides distributed data synchronization among the swarm virtual satellites and a distributed dynamic assignment of physical satellites to the virtual swarm satellites.

As of 2018, several low orbit (LEO) constellations are being designed and planned. These include SpaceX, OneWeb, LeoSat, Telesat and lately Amazon Kuiper. Some of these constellations include Inter-Satellite Links (ISL) communication at the initial or second phase as well as on-board processing capabilities. The LEO constellations create a network that includes the satellites (as routing nodes) connected by ISLs, and the satellite terminals that dynamically connect to one or more satellites. The LEO network presents unique challenges to traffic routing and service planning due to dynamic changes in the network topology (interconnection between satellites, and between satellites and terminals). In addition, the LEO latency (which is low, compared to GEO and MEO) is significant when using legacy routing protocols (The constellation end-to-end latency can be in the order of 100 mSecs and ground-to-satellite latency is in the order of 10 mSecs).This paper addresses the problem of sending traffic from a source terminal to a destination terminal connected through multiple satellites while guaranteeing and enabling planning of the service metrics/QoS (bandwidth and latency) and handling satellite handovers.

A global service LEO constellation aims to provide service to any terminal covered by the constellation planes. To reduce the satellite cost, which is directly related to its power usage and weight, each satellite should be able to service (cover) all the terminals within its Field-of-View (FoV) using the satellites beams in the most efficient way. LEO satellite network vendors use different approaches to handle the user terminals diverse locations. A stepping (or tracking) beam constellation provides service to predefined areas instead of a full coverage. As a result, satellites using stepping beams are more efficient, as power is used only for populated areas. When the constellation shifts, beams are allocated such that each area is serviced by one of the satellites that has the area in its FoV. Stepping beams constellations raise unique and complicated tasks. When admitting a new service area, we should verify it can be covered by a satellite beam at any coverage combination of the moving constellation. The algorithms should take into account the satellite limitations (power, number of beams).Previous works analyzed the overall efficiency of each constellation architecture and the technologies of the on-board beams, while little attention was paid to the algorithm that validates a consistent coverage of new service areas. The major contribution of this paper is a novel algorithm for validating new service areas in a LEO stepping beam constellation.

As of 2018, several low orbit (LEO) constellations are being designed and planned. These include SpaceX, OneWeb, LeoSat, Telesat and others. Some of these constellations include Inter-Satellite Links (ISL) communication at the initial or second phase as well as on-board processing capabilities. The LEO constellations create a network that includes the satellites (as routing nodes) connected by ISLs, and the satellite terminals that dynamically connect to one of the satellites. The LEO network presents unique challenges to traffic routing and service planning due to dynamic changes in the network topology (interconnection between satellites, and between satellites and terminals). In addition, the LEO latency (which is low, compared to GEO and MEO) is significant when using legacy routing protocols (each ISL latency can be in the order of 10 mSecs or more and ground to satellite latency is in the order of 10 mSecs). In case of a polar constellation, the LEO satellite orbit is south-to-north on one half of the constellation and north-to-south on the other half. As a result, there are neighboring planes in which satellites are moving in opposite directions. Satellites can easily establish and maintain ISLs with neighboring satellites on the same plane. However, a link with a neighboring satellite on the adjacent plane can only be established if the satellite on that plane is moving in the same direction. The barriers between the two satellite groups are called seams. This paper is the first to analyze the impact of the seam on location based routing in a polar constellation. We propose an asymmetric seam-aware location-based routing algorithm, and use a random walk on a geographical shortest path lattice for load balancing.