[Printable Version]

GSML Overview
by the Mercury Design Team

Introduction
Trends in spacecraft operation are moving towards increased satellite connectivity that will enable 24x7, end-to-end access between users and satellite data [Bhasin01]. Meanwhile, the complexity in ground stations remains high as well as their total cost of ownership [Zillig94][Wertz99]. In order to reduce costs while increasing coverage, ground system designers are seeking ground stations that can support multiple heterogeneous missions, as well as operations teams that can interface to multiple heterogeneous ground stations.

We have experienced these trends firsthand with recent university satellite launches. Stanford's first CubeSat mission, QuakeSat, which follows the successful Opal and Sapphire, was launched in June of 2003 with five other CubeSats. All six operations teams were plagued by a lack of multi-mission support at non-primary ground stations when trying to increase coverage times during initial contacts and system check-out phases. As we seek to help support these multiple missions and to take advantage of university ground stations around the world, we have found a pressing need for new, enabling technologies.

The research efforts of the Mercury project are developing technologies to meet this need. We are working on an architecture for flexible application support in ground stations that will allow users to specialize ground station configurations and services without explicit knowledge of these services by the ground station[Cutler03]. We are working on recovery-oriented computing techniques that will enable us to build reliable, highly available ground station networks from stations that are individually unreliable [Patterson02][Cutler01]. Our testbed is a network of university ground stations accessible via the Internet called the Mercury Ground Station Network (MGSN). For the MGSN, we have developed an open-source reference ground station control system, called Mercury, that automates routine ground station services and provides secure Internet access.

This document provides an overview of our development efforts on a generic ground station command and control language used in Mercury and the MGSN, which we call the Ground Station Markup Language (GSML). First, we describe our method of flexible mission support by ground stations which lays the foundation for our ground station paradigm. We then describe our reference model which captures the basic functions and services of a typical ground station. Next, we describe our XML-based command language for controlling the station at three hierarchical levels: the virtual hardware level, the session level, and the network level. We conclude with a description of our MGSN testbed and its support of university satellite missions.

Software Defined Ground Stations
Another trend to take note of in space systems is the replacement of specialized hardware components with software defined components running on general purpose computing platforms. As an example, software defined radios are replacing discrete component systems, thereby enabling extremely flexible radio solutions [Zillig94]. The necessary hardware is shrinking and leads to software defined ground stations. See figure 1 (antenna amplifiers are not shown and more than one CPU may be needed for these functions).

Figure 1 -- Special purpose hardware reduction

We combine this with the rise of workstation virtual machine (VM) technology [Cutler03]. Virtual machines enable a host operating system to run multiple guest operating systems on top of it. See figure 2. To the guest OS, it appears that it is running only on a single machine, when in reality multiple guest OS's may be operating on a single host. VM's have been common place in mainframe computing for years are now making their way into workstations.

Figure 2 -- A virtual machine system.

The benefits of VM's are numerous. Multiple VM's on single computing platform result in higher, more efficient use of CPU platforms. Upgrades are facilitated as VM's can be copied to new hardware with only momentary disruption of VM operation. VM's appear to the host as a simple file directory, which makes manipulation of the them (copy, backup, moves, restoration, etc.) straight forward. The virtual machine monitor (VMM) also provides a high degree of isolation between guest OS's. Errors or malicious intentions of a single guest OS can be contained and isolated by the VMM.

Now, consider if we use VM's for the software defined components of a ground station. Users can download their custom virtual machines pre-configured to perform their satellite specific (de)modulation, bit synchronization, forward error correction (FEC), packetization functions, and any other application level functions (such as data archiving and processing). To the ground station, it simply runs a virtual machine without any explicit knowledge of what application level code the user has implemented in the VM. To the user, the station is running customized, application specific functions for their satellite passes. Thus, generic application support can be achieved.

This virtualization stems from the end-to-end argument, which states that the function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system [Saltzer84]. Therefore, "a lower layer of a system should support the widest possible variety of services and functions, so as to permit applications that cannot be anticipated". Building complexity into a network often optimizes it for that particular application to the detriment of other unforeseen applications [Reed98]. Our ground station work seeks to identify and minimize core ground station services while still allowing application level support at stations.

The concept of a software defined ground station implemented with virtual machines is at the heart of our ground station work. We feel the combination of a reduction in the complexity of core ground station services with complete user defined application level support will enable drastic improvements in multi mission support.

Reference Model
Our ground station reference model is described here in detail.

GSML
Given this reference model, we are developing an application program interface (API) for commanding and controlling these captured ground station services. We call it the Ground Station Markup Language (GSML). GSML encapsulates core state information associated with the hardware and services of the reference model and provides primitives for actuating ground station elements (similar to remote procedure calls).

We have chosen the extensible markup language (XML) as the framework for GSML. XML is a meta-language, a language for describing other languages, which lets you develop custom document markup languages. XML was chosen because it is extensible, transportable, and a wide variety of off the shelf tools are available.

As the name implies, XML was designed to be extensible. The framework allows easy addition of elements to documents that can contain new state for GS objects or new methods for GS services. This will enable GSML to adapt to future hardware and service additions. XML parsers also enable implementations of GSML to ignore unknown elements thereby allowing applications to handle different GSML versions.

With GSML we have separated data format from implementation. The protocol is independent of transport. GSML messages are text and easily transportable with standard Internet protocols. As we will describe below, our testbed currently uses TCP, SSL, and HTTPS for transport. Other forms of delivery are also equally implementable, such as FTP, SMTP, HTTP, or SOAP. This will enable ground station control systems that implement GSML to work on a variety of network configurations and architectures.

A drawback of GSML is its lack of bit efficiency. The messages are verbose and could be expressed in more efficient, optimized formats. This, however, severely restricts its extensibility. We trade off efficiency for this extensibility, counting on Moore's Law to continue providing faster CPUs and networks. Compression of GSML messages can also be used to reduce this bit efficiency.

GSML specifications are under development:

0.2.*	Extends 0.1 to include session and network level. Formally defined with XML Schema. Used in Mercury versions greater than 1.2.
0.1.*	First attempt at capturing hardware level. Used in Mercury versions 1.1.2 and less.

Testbed
The GSML experimental and developmental efforts are carried out on a network of university ground stations. The Mercury Ground Station Network (MGSN) is a loose federation of global university ground stations networked to support university satellite missions. The MGSN is still in its infancy stages and currently contains a small core group of universities in the US, Norway, Denmark, and Germany. We expect to have basic MGSN functionality by early 2004.

The communication protocol of the MGSN is GSML. Stanford has developed an open-source implementation of the GSML API called Mercury. It is built on the Apache webserver, MySQL database, PHP web scripting, and a suite of custom written Java applications for controlling ground station hardware and automation services. See the architecture descriptions online for more information on Mercury.

Due to GSML's XML framework, Mercury is able to use a variety of Internet protocols for relaying messages. Externally, GSML messages are transmitted via TCP sockets, or securely through SSL protected TCP sockets. SSL is used for authentication of GS users as well as encryption of transmitted messages. Internally, a TCP-based centralized message server is used for GSML communication between Mercury components. Essentially, it is a chat server that enables all Mercury components to communicate with one another.

Our Java communication components are autogenerated from the GSML specification file. This makes extensions and modifications of the GSML specification immediately available to the Mercury code base after a re-compilation of the specification. It also helps reduce any coding errors in the core communication components since the number of human written lines of code is reduced.

Heterogeneous hardware components are controlled with GSML drivers. These drivers translate GSML commands to low level hardware specific command sequences. Given that most hardware is controllable via ethernet or serial port (RS-232, etc) interfaces, our Java-based GSML drivers are adequate for controlling GS systems.

A useful tool we use in Mercury for parsing GSML messages is XSLT (eXtensible Stylesheet Language Transformations). We use XSLT in Mercury to generate multiple GSML response messages from a received GSML message. For instance, in the Stanford station, we use digital IO hardware to implement the polarity control of our antennas. An XSLT transform document is loaded into the antenna driver that parses a polarity control command and automatically generates the appropriate digital IO command messages. Driver specific XSLT documents are configured through Mercury's web interface and automatically loaded into the drivers at runtime.

Currently, Mercury supports the hardware and session levels of GSML and is deployed at two Stanford ground stations. Work is underway to deploy it also at stations in Alaska, Iowa, Norway, Germany, and Denmark. We expect to have basic network services running in 2004.

References
[Bhasin01] Kul Bhasin and J Hayden, "Space Internet Architectures and Technologies for NASA Enterprises". In Proceedings of the 2001 IEEE Aerospace Conference, Big Sky, Montana, 2001.

[Cutler01] James W. Cutler and Armando Fox and Kul Bhasin, "Applying the Lessons of Internet Services to Space Systems". In Proceedings of the 2001 IEEE Aerospace Conference, Big Sky, Montana, 2001.

[Cutler03] James Cutler, "Ground Station Virtualization". In the Proceedings of the The Fifth International Symposium on Reducing the Cost of Spacecraft Ground Systems and Operations (RCSGSO), Pasadena, CA, July, 2003.

[Patterson02] David Patterson and Aaron Brown and Pete Broadwell and George Candea and Mike Chen and James Cutler and Patricia Enriquez and Armando Fox and Emre Kiciman and Matthew Merzbacher and David Oppenheimer and Naveen Sastry and William Tetzlaff and Noah Treuhaft, " Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies", Technical Report, UCB/CSD-02-1175, UC Berkeley, 2002.

[Reed98] D. Reed and J. Saltzer and D. Clark, "Active Networking and End-to-End Arguments", IEEE Network, 12(3):66-71, May/June 1998.

[Saltzer84] J.H. Saltzer and D.P. Reed and D.D. Clark, "End-to-End Arguments in System Design", ACM Transactions on Computer Systems, Volume 2, Number 4, pages 277-288, November, 1984.

[Wertz99] James Wertz and Wiley J. Larson, editors, "Space Mission Analysis and Design". Microcosm Press, El Segundo, CA, 3rd edition, 1999.

[Zillig94] David Zillig and Ted Benjamin, "Advanced Ground Station Architecture". In Proceedings of Space Ops, Greenbelt, MD, November, 1994.