Trending News
Home / Technology / AI & IT / Virtualization or software-defined Ground Stations enable Satellite Ground Segment as a Service (GSaaS)

Virtualization or software-defined Ground Stations enable Satellite Ground Segment as a Service (GSaaS)

General trends for new Space Missions include increasing mission commercialization, the embarkment of higher fidelity sensors, the increasing use of satellite formations/constellations, the reduction of satellite size, mass, and power, and providing end-users with high level and/or Near-Real-Time products (e.g. damage maps).

 

A trend in future space missions is on-demand, 24/7 access to orbiting satellites. For extremely low-cost, experimental space missions,∗ this type of access coverage is not affordable. First, it is cost-prohibitive for these small missions to build their own ground stations let alone an entire network that provides global coverage. Industry ground stations capable of megabit per second downlinks have extensive specialized hardware components and, on average, cost several hundred thousand dollars.

 

Communication with Low-Earth Orbit (LEO) satellites requires the set up of a ground
station which is a complex and costly installation. Moreover, a LEO satellite is accessible only
during certain time slots from a given ground station. In other words, access to LEO satellites is
on an intermittent basis and is constrained by the availability of ground stations.

 

In order to support increasing data volumes, the antenna systems and/or demodulation hardware get bigger and more complex. This drives the cost per contact. For missions that have a higher demand or have to meet certain timeliness requirements the only way out it to use more antenna systems at appropriate locations. At the same time missions are no longer willing to pay for dedicated ground station infrastructure. All these pieces along with the increasing interface complexity have severe consequences for ground station service providers: On one hand building up and maintaining antenna systems and their associated infrastructure is getting more expensive. On the other hand funding is decreasing.

 

One way is to increase the reuse of existing assets. i.e. what if we could avoid capital expenditure (CAPEX) for the buildup of new antenna systems and instead use existing systems? Ground station virtualization aims exactly at this: reuse of existing antenna and interfacing assets. Instead of building new infrastructure a mission-selected ground station service provider could approach another ground station service provider and ask for access to their antenna system.

 

An idle antenna system does not earn money, one that is rented to another party does. This is a win-win situation: One entity brings along the customer, thus increasing the utilization
of the antenna system, while the other provides the infrastructure to provide the service.

 

Virtual Ground Station

A virtual ground station is a software representation of a real life ground station. It is equipped with virtual equipement as a transceiver, an antenna and a rotor controller. Virtual equipment offers the same services its real life counter part offers. For example, the virtual transceiver can be turned on or off and its mode and frequency can be set. Like a ground station equipped with a tracking application, the virtual ground station offers services to start and stop tracking sessions. In addition, it has an owner and it knows where it’s located in terms of latitude, longitude, and
altitude.

 

A virtual ground station can be used by any client with a computer attached to the Internet which
augments the degree of accessibility. Besides, a virtual ground station and its clients don’t have
to be collocated. A client can access a satellite as long as a remote virtual ground station has
access to it.

 

However, networking one single ground station isn’t enough. The true benefit of this solution comes from networking many ground stations from all around the world. This enables a user to track a satellite no matter where it is, as long as there is a ground station in its footprint.

 

Furthermore, with a sufficient number of networked ground stations, it is even possible to address another problem related to LEO satcom services: the intermittent nature of the services. In effect, on average, Satcom services are only available a few times a day and usually for a maximum of approximately 15 minutes. Thus, even when an uninterrupted download of a file
requires less than one hour, it can take several hours of elapsed time to download using a LEO satellite. In other words, several passes may be required to download a single file from an LEO satellite. One way to improve this situation is to consecutively use many different remote ground stations forming an extended tracking session.

 

Ground station virtualization challenges

However, the implementation of this concept has many challenges because of the lack of flexibility of the current ground stations (GS) whose aim is to enable communication between ground users and space assets. In addition to the RF equipment needed for communication, ground stations traditionally have a suite of support systems for mission-specific data handling needs such as demultiplexing of data streams, encryption functions, data compression, time tagging, data storage, data quality measurements, and spacecraft ranging. This has led to challenges in multi-mission support due to highly specialized mission-specific equipment and a lack of flexibility for the end-users.

 

Additionally, the complexity of space systems is increasing and with it the possibility for systems errors and failures. Rising levels of automation introduce more software code and more computer hardware. The global distribution of space system components requires extensive networking. Increasing levels of international collaboration and peer-to peer space systems result in complex interfaces and interactions that are difficult to model.

 

With the adoption of terrestrial networking standards for end-to-end communication between space and ground systems, the core function of a ground station is simplifying and becoming similar to that of a standard Internet router. Therefore, the fundamental purpose of a ground station is evolving to become more simple; it is to bridge space and terrestrial networks and route packets appropriately.

 

Despite these similarities with Internet routers, there are some basic differences between them and ground stations. Due to the tracking constraints and narrow beamwidths of the RF links, communication channels tend to be circuit-switched; a ground station is scheduled for a particular time interval to exclusively maintain a communication channel with a single satellite. The bidirectional pointing requirements for high-speed communicational channels and slow
antenna slew rates prevent rapid multiplexing between multiple satellites. In contrast, the physical networks for routers are fixed and don’t require reconfiguration for each packet
stream. Therefore, while ground station resources remain scarce, this circuit-switched induced bottleneck requires efficient scheduling to enable multiple mission support.

 

The complexity of ground stations is currently significantly greater than Internet routers. In fact, ground stations usually contain a router in addition to all the equipment needed to support ground to space communication links. This increased complexity lowers the mean time to failure
and potentially increases the mean time to repair. Hardware repairs are manually intensive and regular inspections are needed. To bound costs, architectures must manage this complexity by decreasing failure detection and recovery times.

 

Similarly, there is a widespread movement toward rapid prototyping and deploying inexpensive space missions by using commercial-off-the-shelf (COTS) components. Another challenge is the  the integration of non-mission critical components whose behaviors were not fully understood and typically designed for lighter workloads into mission-critical system service. Hardware fails (such as power supplies and disk drives) and software locks up or fails to free resources forcing system reboots.

 

Also, ground stations require real-time (or near real time) control of resources to maintain satellite contact channels. Telemetry feedback is used to adjust antenna pointing angles and receiver frequencies to maximize received signal strength. In contrast, routers simply manage queues without the complexity of hardware feedback control.

 

Networking globally distributed ground stations,  enable the development of commodity services for these ground station networks, and provides high-availability techniques that enable reliable systems from unreliable components.

 

 

DOD requirement

Pentagon officials often complain that the nation’s current satellite ground architecture is stymied by stovepiped, custom-built proprietary ground systems. While historically most satellite systems have been built with their own unique ground service platform, the Air Force has long wanted to move to a common platform for multiple families of satellites called Enterprise Ground Services. While EGS may have to be tweaked to work with the unique mission parameters of any satellite system, the idea is for all of the Air Force’s satellite systems to start from a common suite of command and control ground services.

 

Not only is this expected to save money in the long run since they won’t have to develop a new ground services architecture for each new satellite system, but the Air Force also hopes that transitioning to EGS will make it easier for satellite operators to move from system to system without having to learn an entirely new platform.

 

Ground Station Virtualization using a layered model

The model is hierarchical and layered according to levels of autonomy; lower levels capture hardware devices and higher levels capture autonomous ground station services.

 

Ground station virtualization is used to decouple ownership of an antenna system from its operation. This enables multiple OEs to use the same underlying physical system. As the antenna system can only point to one satellite at a time so sharing of this asset has to be organized by time.

 

The virtual hardware level captures the fundamental capabilities of low-level ground station components and enables generic commanding of heterogeneous hardware. This is a master/slave control paradigm where the ground station exposes lower level control interfaces for all hardware.

 

Hardware Level

The hardware level (HL) captures the fundamental capabilities of low-level ground station hardware and enables generic commanding of heterogeneous hardware components. Device-specific commanding protocols have been abstracted away to present a standard interface to ground station hardware (comparable to device drivers found in computer operating systems).

 

Researchers have modeled the ground station dedicated hardware to support ground to space communication links, which we all hardware pipelines.  These consist of hardware associated with antennas, low noise receive amplifiers (LNA), output power amplifiers, radios, modems, and multiplexing hardware for flexible configurations. Pipelines also perform ranging functions to measure satellite distances and positions.

 

Session Level

The session level (SL) captures typical automation services of a single ground station installation. Users task a ground station to maintain a contact session with a satellite and employ local automation services of the station to perform routine component control during the pass. At the heart of this level is the session object which the ground station “executes” on a reserved set of hardware over a specific interval of time to maintain communication with a target satellite.

 

The session level captures typical automation tasks and services of a single ground station installation. Users define a session, which tasks these automation services over a specific time interval to maintain communication channels. A communication channel definition includes one or more pipelines (transmit, receive, or transceive) and associated data processing services. Session level services employ the virtual hardware level primitives to control lower level
ground station resources.

 

SL services automate typical ground station services such as antenna tracking, Doppler shift radio frequency correction, satellite ranging, and position estimation. These services employ hardware-level primitives to control lower-level ground station resources.

 

The scheduling service accepts reservations for the use of ground station systems. Ground requests are processed through terrestrial networks. Space requests are received through low resource utilization pipelines (such as simple omnidirectional antennas). Until stations are no longer a scarce resource, schedule will be a critical function. Resource availability and user access priority are taken into account during the scheduling of sessions.

 

The station controller automates the execution of satellite contact sessions. It monitors scheduled contact session requests, configures ground station hardware to support the requested communication channels, and enables requested automation and data processing services. It performs real-time control of station hardware to maintain and optimize communication channels during a satellite pass. Antennas are tracked, radios tuned, and link parameters (such as FEC levels and bit rates) adjusted to account for variable bit error rates. The controller also manages health monitor output and recovers from failures automatically or alerts on non-recoverable errors.

 

The station is monitored for proper operation by health monitor systems. These consist of sensors, both software and hardware, logging resources for storing telemetry, and health assessment functions for detecting failures and performance degradations. The estimator determines the target satellite position, antenna pointing angles, and Doppler correction factors. Possible sources for this information include pipeline ranging systems, satellite provided GPS data, or calculated values from orbital element sets.

 

The state management service stores session descriptions and their schedules, session products which contain GS telemetry and communication channel bit logs, a cache of satellite configuration information (pipeline frequencies, data processing needs, etc.), user access information, etc.
The remote access server authenticate remote users and provides secure, encrypted ground station control. It controls access to the scheduling services, the data processing services, and also enables access to communication channels and low level virtual hardware commanding.

 

Processing bits on the ground side of the pipeline is handled by the data processing services. Networking and communication services include bit synchronization, forward error correction (FEC), and link and network level protocol management.

 

Network Level

The network level (NL) captures the services of a federated ground station network (FGN). AFGN is a collection of autonomous, globally distributed ground stations with network services such as authentication, resource discovery, and scheduling. The underlying motivation for such a network is the sharing of geographically diverse, heterogeneous ground stations and the synergy of cooperating ground station teams to enhance satellite contact sessions.

 

The network level captures the services of a ground station network. These networks provided increased capabilities over single ground station installations and are federated from stations under different administrative domains. Link intermittency is reduced and temporal coverage is increased as globally distributed ground stations with overlapping contact windows handoff satellite contact session.

 

The registry service accepts registrations from ground stations offering their capabilities to the network. This registry service enables users to locate available ground station resources. Full scheduling authority rests with the ground stations.

 

The virtual ground station service composes distributed ground stations and presents a virtual single interface to station end users. This service enables peer ground station cooperation and masks failovers and handoffs without explicit user knowledge. Autonomy can be handled centrally with stations acting as slaves or distributed among them where they act as peers.

 

These three layers capture the core services of a ground station network and present different interfaces to users based on autonomy levels. At the virtual hardware level, users have full control of station hardware. At the session level, a station is tasked to automatically track a satellite and provide network data connections between ground and space assets. At the network level, teams of stations are tasked to maintain extended contacts, to optimize links, and provide redundancy in the presence of failures

 

Access Enforcement

A virtualization layer is introduced to facilitate the operation of the physical antenna system. The virtualization layer has two types of interfaces :

  • A management interface that is used for the coordination/scheduling of the physical antenna system
  • Low level antenna specific interface at TCP/IP level. i.e. the devices that make up the antenna system can be directly accessed using their native protocols. This includes the Antenna Control Unit (ACU), programmable Up- and Downconverters, HPAs, as well as the base band units.

 

Modern base band units such as AMERGINT’s satTRAC, Zodiac’s Cortex CRT/HDR family or Kongsberg’s DFEP allow to access the data at TCP/IP level. Furthermore they are highly configurable in terms of modulation scheme, bitrate and coding. These two attributes allow to re-use the base bands in a multi-mission world. As the baseband units are fairly expensive the reuse is essential to reduce cost. Most ground stations have redundant base bands. In such a case the external OE can fully make use of this redundancy, too.

 

The general idea is to allow network access to the physical antenna system only one from operating entity at a time. The principle idea is that shared devices are dynamically assigned to the network in which they are used. The associated logical network structure thus dynamically changes. The antenna owner controls the “position” of the switch by means of the schedule. Once switched to an external operating entity itself has no longer the ability to connect/interfere/capture traffic between the external OE and the physical system. Technically this is realized by use of Software Defined Networking.

 

An enforcement element consists of a SDN switch and a SDN controller. The SDN switch is a commercial of the shelf product that can be readily ordered. The SDN controller is a critical piece of software. It has to be programmed such that the resulting flow tables at the switch will allow one entity to access the shared devices at a time. From a functional perspective the SDN combination provides classical firewall functions. However, the price is much lower and packet
processing happens at line speed

 

 

References and resources also include:

https://arc.aiaa.org/doi/pdfplus/10.2514/6.2016-2331

https://descanso.jpl.nasa.gov/RCSGSO/Paper/A0089Paper.pdf

https://core.ac.uk/download/pdf/32552482.pdf

About Rajesh Uppal

Check Also

Cloud Computing technology and trends driven by AI & Machine learning, IoT and 5G

Cloud computing is the on-demand delivery of IT resources over the internet with pay-as-you-go pricing. …

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!