The Mercury Ground Station Reference Model
by the Mercury Design Team

Introduction
Given the heterogeneous nature of ground station installations, the Mercury system must cope with a variety of implementation specific commanding languages for controlling ground station resources. It must be flexible enough to incorporate new and legacy hardware.

We begin with an attempt to capture core ground station services, ones that are shared across multiple missions, and separate out mission specific services. We divide station services along autonomy lines into three hierarchical layers which permit low level hardware control, contact automation for a single station, and peer cooperation among ground stations to enhance space to ground links. We layer these services to hide information, the encapsulation of module specific functions to hide device heterogeneity and provide common, highly utilized virtualized services. Our eventual goal is to develop an architecture that offers core services and standardized mechanisms for flexible application level services.

Virtual Hardware Level
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. At the heart of the ground station is the dedicated hardware to support ground to space communication links, which we call hardware pipelines. Pipelines convert space radio transmissions into digital bits that can be placed on digital networks (and vice versa). These consist of hardware associated with antennas, low noise receive amplifiers (LNA), output power amplifiers, radios, modems, and multiplexing hardware for flexible configurations. In more capable stations, pipelines also perform ranging functions to measure satellite distances and positions.

Session Level
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. A functional view of a ground station at the session level is found in figure 1.


Figure 1 -- Session view components.

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, scheduling will be critical function. Resource availability and user access priority are taken into account during the scheduling of sessions.

The station controller automates execution of satellite contact sessions. It monitors scheduled contact session requests, it 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 authenticates 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. At the application level, there are endless possibilities of data services, some of which have been mentioned above. In our architectural development, we hope to separate out these services and replace them with a mechanism to allow missions to run custom services without the ground station having explicit knowledge of them.

Network Level
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. Local clustering of ground station teams enables static and dynamic optimization of a ground station system through composition of a virtual ground station, a ground station composed of components and services distributed across multiple installations. ( Local refers to stations simultaneously within the footprint of a satellite and depends on satellite altitude.) See figure 2 for views of these networks.


Figure 2 - Here is a component view at the network level. In region 1, station A and B cooperate on maintaining the contact. Station A's transmit power amplifier has failed and B has taken over transmit responsibilities. As the satellite moves into region 2, station B takes over the receive functions to provide a seamless transition. Station B and C then coordinate to provide an optimized virtual station, where B is the primary receiver because of its higher gain antennas and better terrestrial network access and C continues with transmitting until the satellite is out of range.
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.


This text is from Ground Station Virtualization, by James Cutler. In Proceedings of the The Fifth International Symposium on Reducing the Cost of Spacecraft Ground Systems and Operations (RCSGSO), Pasadena, CA, July 8-11, 2003.